From routernumber1 at yahoo.co.in Mon Feb 4 21:10:56 2008 From: routernumber1 at yahoo.co.in (Router Switch) Date: Tue, 5 Feb 2008 05:10:56 +0000 (GMT) Subject: [Xorp-hackers] RefPtr in xorp Message-ID: <422845.6007.qm@web94002.mail.in2.yahoo.com> hi XORP hackers, can anybody explain what is the significance of RefPtr in the following statement:- typedef XorpCallback1::RefPtr AddRoute4CB; regards Arjun --------------------------------- Bollywood, fun, friendship, sports and more. You name it, we have it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080205/b15298f3/attachment.html From routernumber1 at yahoo.co.in Tue Feb 5 02:06:11 2008 From: routernumber1 at yahoo.co.in (Router Switch) Date: Tue, 5 Feb 2008 10:06:11 +0000 (GMT) Subject: [Xorp-hackers] Generating stub code for the target Message-ID: <736133.78270.qm@web94013.mail.in2.yahoo.com> hi XORP hackers, In the case of static routes.tgt, the file static routes.xrls will be generated by tgt-gen. This file simply contains a listing of all the fully expanded XRLs supported by the static routes XRL target. Is there any other use of this .xrls files. I mean will this generated .xrls file will be reffred at the time of ..la library generation. regards Arjun --------------------------------- Why delete messages? Unlimited storage is just a click away. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080205/8c0f7b34/attachment.html From oho at acm.org Tue Feb 5 08:10:41 2008 From: oho at acm.org (Orion Hodson) Date: Tue, 5 Feb 2008 08:10:41 -0800 Subject: [Xorp-hackers] RefPtr in xorp In-Reply-To: <422845.6007.qm@web94002.mail.in2.yahoo.com> References: <422845.6007.qm@web94002.mail.in2.yahoo.com> Message-ID: <98220520-1282-4000-BD4E-526C9885F31D@acm.org> It is a reference counting pointer, the callbacks are reference counted objects. The ref_ptr template is defined in libxorp/ref_ptr.hh. - Orion On Feb 4, 2008, at 9:10 PM, Router Switch wrote: > hi XORP hackers, > > can anybody explain what is the significance of RefPtr in the > following statement:- > typedef XorpCallback1::RefPtr AddRoute4CB; > > regards > Arjun > Bollywood, fun, friendship, sports and more. You name it, we have it. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080205/8d7545bd/attachment.html From bms at icir.org Mon Feb 4 23:39:47 2008 From: bms at icir.org (Bruce M. Simpson) Date: Tue, 05 Feb 2008 07:39:47 +0000 Subject: [Xorp-hackers] RefPtr in xorp In-Reply-To: <422845.6007.qm@web94002.mail.in2.yahoo.com> References: <422845.6007.qm@web94002.mail.in2.yahoo.com> Message-ID: <47A812C3.5070406@icir.org> Router Switch wrote: > hi XORP hackers, > > can anybody explain what is the significance of RefPtr in the > following statement:- > typedef XorpCallback1::RefPtr AddRoute4CB; Callback functor objects should be refcounted to ensure that they are freed, even if their last reference is held outside of the scope where they were instantiated. From pavlin at ICSI.Berkeley.EDU Tue Feb 5 09:52:07 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 05 Feb 2008 09:52:07 -0800 Subject: [Xorp-hackers] Generating stub code for the target In-Reply-To: <736133.78270.qm@web94013.mail.in2.yahoo.com> References: <736133.78270.qm@web94013.mail.in2.yahoo.com> Message-ID: <200802051752.m15Hq76n014702@fruitcake.ICSI.Berkeley.EDU> > In the case of static routes.tgt, the file static routes.xrls will > be generated by tgt-gen. This file simply contains a listing of > all the fully expanded XRLs supported by the static routes XRL target. > > Is there any other use of this .xrls files. > I mean will this generated .xrls file will be reffred at the time of > ..la library generation. On startup, the rtrmgr checks all XRLs used inside the etc/templates/*.tp template files that they actually exist in some of the *.xrls files. In other words, the *.xrls files are used only in runtime. Pavlin From andreas.voellmy at gmail.com Wed Feb 6 11:25:57 2008 From: andreas.voellmy at gmail.com (Andreas Voellmy) Date: Wed, 6 Feb 2008 14:25:57 -0500 Subject: [Xorp-hackers] from and to blocks of policy terms Message-ID: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com> Hi, I've read the XORP user manual and Bittau & Handley's paper on "Decoupling Policy from Protocols" and I am still a bit confused as to how the policy terms work. I understand that policies that do route redistribution, like "from {protocol:rip} to {neighbor: 192.168.1.2} then {accept}" make sense as an export policy, but it's not clear to me why a policy term has both from and to blocks when it is not doing routing redistribution. For example, take the following policy term: from {} to {neighbor: 192.168.1.2} then {accept} As an export policy I understand that it would advertise all routes to neighbor 192.168.1.2. However, if it were an IMPORT policy, what would it mean? More generally, what do any conditions in the to block mean in an import policy? Similarly, what does "from {neighbor: 192.168.1.2} to {} then {accept}" mean as an export policy? What does any condition in the from block of an export policy mean? Thanks! -Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080206/b3554fac/attachment.html From atanu at ICSI.Berkeley.EDU Fri Feb 8 15:17:40 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 08 Feb 2008 15:17:40 -0800 Subject: [Xorp-hackers] OSPF In-Reply-To: Message from "Stefan Gula" of "Fri, 25 Jan 2008 16:26:00 +0100." Message-ID: <99979.1202512660@tigger.icir.org> Hi, Setting passive deliberately announces the host route, this behaviour has now been changed in CVS. Atanu. >>>>> "Stefan" == Stefan Gula writes: Stefan> Hi, Stefan> I am having problem with OSPFv4 configuration. Stefan> ################################## Stefan> # first router Stefan> ################################## Stefan> root at asd1# show protocols ospf4 Stefan> router-id: 1.1.1.1 Stefan> traceoptions { Stefan> flag { Stefan> all { Stefan> } Stefan> } Stefan> } Stefan> area 0.0.0.0 { Stefan> interface vlan2 { Stefan> vif vlan2 { Stefan> address 10.1.1.1 { Stefan> passive: true Stefan> } Stefan> } Stefan> } Stefan> interface vlan4 { Stefan> vif vlan4 { Stefan> address 1.1.1.1 { Stefan> } Stefan> } Stefan> } Stefan> interface vpn0 { Stefan> link-type: "p2p" Stefan> vif vpn0 { Stefan> address 10.1.2.13 { Stefan> passive: true Stefan> } Stefan> } Stefan> } Stefan> interface vlan50 { Stefan> vif vlan50 { Stefan> address 10.10.0.3 { Stefan> passive: true Stefan> } Stefan> } Stefan> } Stefan> } Stefan> root at asd1# show interfaces Stefan> interface vlan2 { Stefan> description: "aaa" Stefan> default-system-config Stefan> } Stefan> interface vlan4 { Stefan> description: "bbb" Stefan> default-system-config Stefan> } Stefan> interface vlan50 { Stefan> description: "ccc" Stefan> default-system-config Stefan> } Stefan> interface vpn0 { Stefan> description: "ddd" Stefan> default-system-config Stefan> } Stefan> ####################################### Stefan> #second router Stefan> ####################################### Stefan> root at asd2# show protocols ospf4 Stefan> router-id: 1.1.1.2 Stefan> traceoptions { Stefan> flag { Stefan> all { Stefan> disable: true Stefan> } Stefan> } Stefan> } Stefan> area 0.0.0.0 { Stefan> interface eth2 { Stefan> vif eth2 { Stefan> address 1.2.2.3 { Stefan> passive: true Stefan> } Stefan> } Stefan> } Stefan> interface vpn0 { Stefan> link-type: "p2p" Stefan> vif vpn0 { Stefan> address 10.1.2.17 { Stefan> passive: true Stefan> } Stefan> } Stefan> } Stefan> interface eth1 { Stefan> vif eth1 { Stefan> address 1.1.1.2 { Stefan> } Stefan> } Stefan> } Stefan> } Stefan> root at asd2# show interfaces Stefan> interface eth0 { Stefan> description: "adewt" Stefan> default-system-config Stefan> } Stefan> interface eth1 { Stefan> description: "asdwt" Stefan> default-system-config Stefan> } Stefan> interface eth2 { Stefan> description: "asdwq" Stefan> default-system-config Stefan> } Stefan> interface vpn0 { Stefan> description: "asdd" Stefan> default-system-config Stefan> } Stefan> Both routers establish connections but they are unable to exchange Stefan> routes. They exchange inly interface informations but with wrong Stefan> masks. E.g. I have interface I have interface vlan2 on router asd1 Stefan> with 10.1.1.1/24 but this route never occur like this on router asd2. Stefan> It occurs only as 10.1.1.1/32 via 1.1.1.1. Stefan> Can somebody please tell me what I am doing wrong? Stefan> Thanks for any ideas. Stefan> -- Stefan> Stefan Gula Stefan> _______________________________________________ Stefan> Xorp-hackers mailing list Stefan> Xorp-hackers at icir.org Stefan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From bms at incunabulum.net Sat Feb 9 01:21:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat, 09 Feb 2008 09:21:39 +0000 Subject: [Xorp-hackers] valgrind detected libxorp leaks In-Reply-To: <479ED55E.2030700@incunabulum.net> References: <479ED55E.2030700@incunabulum.net> Message-ID: <47AD70A3.8080509@incunabulum.net> Bruce M Simpson wrote: > Briefly looking at the code it looks like there is the opportunity for > TaskNodes to be leaked as TaskList has no destructor. > Valgrind results with FreeBSD have been inconclusive. Valgrind results with Linux 2.6 turned up surprisingly few positives -- the STL implementation shipping with gcc 4.1 and above seems to produce smaller and possibly less leaky code. Currently there are no major leaks in the OLSR code as profiled on Linux; however there have been a few hits in libxorp and libxipc. I'll post more detailed results if I get a chance to sit down and do more profiling. > P.S. If anyone can suggest a way of tricking the Router Manager into > running my routing process under Valgrind, I would like to know > I resolved this by using a wrapper script from the template file (%modinfo path). cheers BMS From f.rodriguez at lancaster.ac.uk Fri Feb 15 08:52:28 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Fri, 15 Feb 2008 16:52:28 -0000 Subject: [Xorp-hackers] Dummy Fea Matters Message-ID: Hi, I'm trying to use XORP to do some experiments and I'm a little bit confused on where should I start in other to achieve my goal. What I'm looking to do is to use XORP using the dummy FEA but having the capability to send and receive IPv4/IPv6 raw packets. Currently I'm not interested in using the interface management neither the forwarding table management nor the TCP/UDP I/O packets. I want to use XORP OSPF process with the capacity to exchange routing packets with other devices (routing packets and in XORP case IPv4/6 raw packets) but without needing to set any packet forwarding features (at least not in the machine running the OSPF process). My idea is to use the dummy FEA but modifying its behavior in the case of a process request to send an IPv4/6 raw packet (OSPF LSA packets) as well as to any subscription of the process to claim an IPv4/6 raw packet. Any hint on where could I start would be much appreciated. Cheers, Francisco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080215/d93dde36/attachment.html From pavlin at ICSI.Berkeley.EDU Fri Feb 15 09:59:33 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 15 Feb 2008 09:59:33 -0800 Subject: [Xorp-hackers] Dummy Fea Matters In-Reply-To: References: Message-ID: <200802151759.m1FHxXp9021148@fruitcake.ICSI.Berkeley.EDU> > I'm trying to use XORP to do some experiments and I'm a little bit confused > on where should I start in other to achieve my goal. What I'm looking to do > is to use XORP using the dummy FEA but having the capability to send and > receive IPv4/IPv6 raw packets. Currently I'm not interested in using the > interface management neither the forwarding table management nor the TCP/UDP > I/O packets. I want to use XORP OSPF process with the capacity to exchange > routing packets with other devices (routing packets and in XORP case IPv4/6 > raw packets) but without needing to set any packet forwarding features (at > least not in the machine running the OSPF process). > > > > My idea is to use the dummy FEA but modifying its behavior in the case of a > process request to send an IPv4/6 raw packet (OSPF LSA packets) as well as > to any subscription of the process to claim an IPv4/6 raw packet. Any hint > on where could I start would be much appreciated. It looks like you want to use a mixture of "real" and "dummy" FEA; currently that is not possible. You could use the real FEA with a minor modification: * You need to configure the network interfaces you want to use with the "default-system-config" statement. This will tell the FEA to pick-up the existing system config of the interfaces. * You don't need to include the "fea" section which enables/disables the forwarding in the kernel. * If you want to prevent the OSPF routes reaching the forwarding table in the kernel, off the top of my head I don't think it is possible to do only by using some configuration statements. The simplest solutiont that comes to mind is to modify the following methods inside fea/xrl_fea_target.cc : XrlFeaTarget::redist_transaction4_0_1_add_route() XrlFeaTarget::redist_transaction4_0_1_delete_route() XrlFeaTarget::redist_transaction6_0_1_add_route() XrlFeaTarget::redist_transaction6_0_1_delete_route() In each of those methods you need to add the following statement right in the beginning: return XrlCmdError::OKAY(); I think that's all you need to do that comes to mind. Please let us know if it doesn't help you. Regards, Pavlin From bms at incunabulum.net Sat Feb 16 04:33:53 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat, 16 Feb 2008 12:33:53 +0000 Subject: [Xorp-hackers] Boost.Build for XORP Message-ID: <47B6D831.2080900@incunabulum.net> I've done a conversion from FTJam to Boost.Build in a private Mercurial branch. Would anyone be interested in picking up on this? Wins now: * No more running ./bootstrap every time XORP's software configuration (as in SCM) is changed. * Eliminates the need for Automake. * configure however is still supported for now. * No more generating .deps, Jam-based build tools do their own header scanning. * Sticky dependencies. Libraries are only part of linkage if XORP components specificially require them. * For example, FeaIfMgrMirror and friends are now only linked when libfeaclient is a dependency. * Full dependency checking on XIF and TGT targets with suffix rules used to build them. I wrote Boost.Build extensions to support this. * As a result the .tgt and .xif files may be located outside of xrl/interfaces for contributed code. This should make code sharing much easier to implement, as well as giving us opportunities, at SCM level, for fine grained control over what code actually gets built and linked on each target platform. Wins later: * Size. * Shared libraries * Portability should get easier. * Cross-compilation should get easier. Further work needed: * Tests need to be ported over fully to Boost.Build's unit testing suite. Jam's disadvantage was that it didn't have a unit testing framework. Boost.Build does. At the moment, all regression tests are built, but not all of them are run. * There is no installation support at the moment - development only -- it shouldn't be difficult to add. * Linkage. Boost.Build does away with the 'hammer into anvil' approach of adding libraries which are specifically required for a given OS to the global link line, it takes a more fine grained approach, so libraries will need to be added to the Boost.Build e.g. only link librt when building on Linux. later BMS From bms at incunabulum.net Sun Feb 17 14:52:57 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 17 Feb 2008 22:52:57 +0000 Subject: [Xorp-hackers] Boost.Build for XORP In-Reply-To: <47B6D831.2080900@incunabulum.net> References: <47B6D831.2080900@incunabulum.net> Message-ID: <47B8BAC9.3090908@incunabulum.net> Bruce M Simpson wrote: > I've done a conversion from FTJam to Boost.Build in a private Mercurial > branch. > Would anyone be interested in picking up on this? > Done a bit more work on this now. * A shared library build of XORP is now OK on FreeBSD and Linux (and Windows Longhorn!!) * Most regression tests are run by the unit testing framework in Boost.Build. * It would be great if folk could volunteer to forward port the other regression tests to say Python or similar, as that's OS-neutral. Boost.Build is likely to have trouble dealing with shell scripts as they are not as portable as Python (when Python scripts are written to be portable, that is). * Intel's C++ compiler appears to build the first few modules just fine under FreeBSD, when Boost.Build is configured to use the "intel-linux" tool seet. However there are regression test failures I don't have free time to track down. Not all of the Windows build supports DLLs. In particular there are places where there would be circular dependencies introduced -- when building a DLL, Windows linkers need to see the "import library" for every other DLL which that DLL references. This can gradually be whittled down. Again it would be great if there were a shared Mercurial hosting space where I could publish this as I have no cgi-bin hosting at present. later BMS From f.rodriguez at lancaster.ac.uk Wed Feb 20 04:02:56 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Wed, 20 Feb 2008 12:02:56 -0000 Subject: [Xorp-hackers] Dummy Fea Matters In-Reply-To: <200802151759.m1FHxXp9021148@fruitcake.ICSI.Berkeley.EDU> References: <200802151759.m1FHxXp9021148@fruitcake.ICSI.Berkeley.EDU> Message-ID: Hi Pavlin, Thanks for the tips. I did what you advised me and it worked fine! Learned routes through the OSPF process are stored in the RIB but are not installed in the FEA (as I wanted). The next step that I'm looking to do is to access the RIB database. I'm not 100% sure if accessing to the RIB has to be done through the use of XRLs or not. For this, I'm planning to write an application (I guess a sort of XORP Process) which needs to have the capability to speak to XORP processes, in this case the RIB, and that make other tasks no related with XORP. Any insight that you could give me to start this will be much appreciated. Regards, Francisco -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] Sent: 15 February 2008 18:00 To: Francisco Rodriguez Cc: xorp-hackers at icir.org Subject: Re: [Xorp-hackers] Dummy Fea Matters > I'm trying to use XORP to do some experiments and I'm a little bit confused > on where should I start in other to achieve my goal. What I'm looking to do > is to use XORP using the dummy FEA but having the capability to send and > receive IPv4/IPv6 raw packets. Currently I'm not interested in using the > interface management neither the forwarding table management nor the TCP/UDP > I/O packets. I want to use XORP OSPF process with the capacity to exchange > routing packets with other devices (routing packets and in XORP case IPv4/6 > raw packets) but without needing to set any packet forwarding features (at > least not in the machine running the OSPF process). > > > > My idea is to use the dummy FEA but modifying its behavior in the case of a > process request to send an IPv4/6 raw packet (OSPF LSA packets) as well as > to any subscription of the process to claim an IPv4/6 raw packet. Any hint > on where could I start would be much appreciated. It looks like you want to use a mixture of "real" and "dummy" FEA; currently that is not possible. You could use the real FEA with a minor modification: * You need to configure the network interfaces you want to use with the "default-system-config" statement. This will tell the FEA to pick-up the existing system config of the interfaces. * You don't need to include the "fea" section which enables/disables the forwarding in the kernel. * If you want to prevent the OSPF routes reaching the forwarding table in the kernel, off the top of my head I don't think it is possible to do only by using some configuration statements. The simplest solutiont that comes to mind is to modify the following methods inside fea/xrl_fea_target.cc : XrlFeaTarget::redist_transaction4_0_1_add_route() XrlFeaTarget::redist_transaction4_0_1_delete_route() XrlFeaTarget::redist_transaction6_0_1_add_route() XrlFeaTarget::redist_transaction6_0_1_delete_route() In each of those methods you need to add the following statement right in the beginning: return XrlCmdError::OKAY(); I think that's all you need to do that comes to mind. Please let us know if it doesn't help you. Regards, Pavlin From zealot0630 at gmail.com Wed Feb 20 08:51:37 2008 From: zealot0630 at gmail.com (Zealot) Date: Thu, 21 Feb 2008 00:51:37 +0800 Subject: [Xorp-hackers] gre tunnel problem Message-ID: <47BC5A99.70806@gmail.com> Hi, all: Xorp seems can not get ip address from p2p interface. There is a patch to fix this. It may cause some other problem, but at least it works --- xorp-1.5~cvs.20080128.orig/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc +++ xorp-1.5~cvs.20080128/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc @@ -688,7 +688,7 @@ if (vifp->point_to_point()) { if ((rta_array[IFA_ADDRESS] != NULL) && !is_ifa_address_reassigned) { if (rta_array[IFA_ADDRESS] != NULL) { - if (nlm_decode_ipvx_address(family, rta_array[IFA_BROADCAST], + if (nlm_decode_ipvx_address(family, rta_array[IFA_ADDRESS], peer_addr, has_peer_addr, error_msg) != XORP_OK) { From bms at incunabulum.net Wed Feb 20 09:39:52 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 20 Feb 2008 17:39:52 +0000 Subject: [Xorp-hackers] Dummy Fea Matters In-Reply-To: References: <200802151759.m1FHxXp9021148@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47BC65E8.5080203@incunabulum.net> Francisco Rodriguez wrote: > The next step that I'm looking to do is to access the RIB database. I'm not > 100% sure if accessing to the RIB has to be done through the use of XRLs or > not. For this, I'm planning to write an application (I guess a sort of XORP > Process) which needs to have the capability to speak to XORP processes, in > this case the RIB, and that make other tasks no related with XORP. Any > insight that you could give me to start this will be much appreciated. > I recommend you use XRL. There is a "RIB direct" interface but that is in there largely as a backdoor for testing purposes and I would not condone its use for new code, but for a prototype it may be much easier for you to use. Watch for asynchronicity. All 'Xrl*Client' class 'send*' methods require that you pass a callback parameter and yes these things may happen asynchronously, it's RPC after all. At the moment XRL is best called from C++. Certainly all the client bindings depend upon it. It is a tricky problem to solve unless you reimplement libxipc in a language other than C++, because the XRL sender classes require XORP event loop and callback semantics. These expect C++ linkage i.e. the instance you pass to it must be derived from XorpCallback. How we deal with this in shell scripts, is just to use the call_xrl tool, however this obviously means you block waiting for each XRL call to execute, and it also doesn't let you implement XRL targets outside of C++. I tried to solve this in SWIG the other day, but I can't get my head around how to write typemaps at the level of wrapping we require (ie references to callback types). Hint: XRL targets themselves are actually easy enough to wrap in SWIG-- you just need to instantiate an XrlStdRouter from outside and pass that in. Clients are harder because of asynchronicity. Someone really needs to sit down and solve the scripting language wrapper problem. What would be really cool is if someone slapped together a Bouml plug-in and plug-out which allows XORP XIF RPC specifications to be expressed in UML. I think you can even do this in Python now. This shouldn't be too difficult as the XIF syntax is C-like and the grammar isn't at all complex, and it will let you visualize the XIF interfaces as... nice shiny standard diagrams. cheers BMS From pavlin at ICSI.Berkeley.EDU Wed Feb 20 18:06:37 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Feb 2008 18:06:37 -0800 Subject: [Xorp-hackers] gre tunnel problem In-Reply-To: <47BC5A99.70806@gmail.com> References: <47BC5A99.70806@gmail.com> Message-ID: <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> Zealot wrote: > Hi, all: > Xorp seems can not get ip address from p2p interface. There is a patch to fix this. > It may cause some other problem, but at least it works Yes, this is a bug, and your solution appears correct. Applied in CVS: xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc rev. 1.16 BTW, what program and command did you use to create the p2p tunnel and to trigger the problem? This piece of information could be useful for future testing of the p2p cases. Thanks, Pavlin > --- xorp-1.5~cvs.20080128.orig/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc > +++ xorp-1.5~cvs.20080128/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc > @@ -688,7 +688,7 @@ > if (vifp->point_to_point()) { > if ((rta_array[IFA_ADDRESS] != NULL) && !is_ifa_address_reassigned) { > if (rta_array[IFA_ADDRESS] != NULL) { > - if (nlm_decode_ipvx_address(family, rta_array[IFA_BROADCAST], > + if (nlm_decode_ipvx_address(family, rta_array[IFA_ADDRESS], > peer_addr, has_peer_addr, > error_msg) > != XORP_OK) { > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From zealot0630 at gmail.com Wed Feb 20 22:26:43 2008 From: zealot0630 at gmail.com (Zealot) Date: Thu, 21 Feb 2008 14:26:43 +0800 Subject: [Xorp-hackers] gre tunnel problem In-Reply-To: <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> References: <47BC5A99.70806@gmail.com> <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47BD19A3.1080208@gmail.com> I'm using Debian 2.6.22-3-686 and the gre tunnel is automatically add by ifupdown. And this is corresponding configuration in interface file. auto photo-cz-tele iface photo-cz-tele inet manual up ip tunnel add photo-cz-tele mode gre remote xxx.xxx.xxx.xxx local yyy.yyy.yyy.yyy ttl 64 up ip link set photo-cz-tele up up ip addr add 192.168.82.29/32 peer 192.168.82.30/32 dev photo-cz-tele up ip link set photo-cz-tele multicast on down ip addr del 192.168.82.29/32 peer 192.168.82.30/32 dev photo-cz-tele down ip link set photo-cz-tele down down ip tunnel del photo-cz-tele mode gre remote xxx.xxx.xxx.xxx local yyy.yyy.yyy.yyy ttl 64 Pavlin Radoslavov wrote: > Zealot wrote: > >> Hi, all: >> Xorp seems can not get ip address from p2p interface. There is a patch to fix this. >> It may cause some other problem, but at least it works > > Yes, this is a bug, and your solution appears correct. > Applied in CVS: > xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc > rev. 1.16 > > BTW, what program and command did you use to create the p2p tunnel > and to trigger the problem? This piece of information could be > useful for future testing of the p2p cases. > > Thanks, > Pavlin > >> --- xorp-1.5~cvs.20080128.orig/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc >> +++ xorp-1.5~cvs.20080128/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc >> @@ -688,7 +688,7 @@ >> if (vifp->point_to_point()) { >> if ((rta_array[IFA_ADDRESS] != NULL) && !is_ifa_address_reassigned) { >> if (rta_array[IFA_ADDRESS] != NULL) { >> - if (nlm_decode_ipvx_address(family, rta_array[IFA_BROADCAST], >> + if (nlm_decode_ipvx_address(family, rta_array[IFA_ADDRESS], >> peer_addr, has_peer_addr, >> error_msg) >> != XORP_OK) { >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From zealot0630 at gmail.com Thu Feb 21 03:40:40 2008 From: zealot0630 at gmail.com (Zealot) Date: Thu, 21 Feb 2008 19:40:40 +0800 Subject: [Xorp-hackers] gre tunnel problem In-Reply-To: <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> References: <47BC5A99.70806@gmail.com> <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47BD6338.9020107@gmail.com> Hi, I still have problem. Thus gre interface have 2 addresses one is public ip and another is tunnel ip, when enable igmp or pim on gre interface, sometimes it register the public ip causing erro "Address already in use". I found that vif store ip addresses in a map which is not ordered (the first item is not the one inserted first). in ./fea/data_plane/io/io_ip_socket.cc case AF_INET: { struct ip_mreq mreq; struct in_addr in_addr; // Find the first address IfTreeVif::IPv4Map::const_iterator ai = vifp->ipv4addrs().begin(); if (ai == vifp->ipv4addrs().end()) { error_msg = c_format("Cannot join group %s on interface %s vif %s: " "interface/vif has no address", cstring(group), if_name.c_str(), vif_name.c_str()); return (XORP_ERROR); } const IfTreeAddr4& fa = ai->second; fa.addr().copy_out(in_addr); group.copy_out(mreq.imr_multiaddr); mreq.imr_interface.s_addr = in_addr.s_addr; if (setsockopt(_proto_socket_in, IPPROTO_IP, IP_ADD_MEMBERSHIP, XORP_SOCKOPT_CAST(&mreq), sizeof(mreq)) < 0) { error_msg = c_format("Cannot join group %s on interface %s vif %s: %s", cstring(group), if_name.c_str(), vif_name.c_str(), strerror(errno)); return (XORP_ERROR); } } break; Here primary ip address should be used, but sometimes the first one in IPv4Map isn't the primary ip. I don't know how to fix this problem. Maybe a lot of changes should be taken. > Zealot wrote: > >> Hi, all: >> Xorp seems can not get ip address from p2p interface. There is a patch to fix this. >> It may cause some other problem, but at least it works > > Yes, this is a bug, and your solution appears correct. > Applied in CVS: > xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc > rev. 1.16 > > BTW, what program and command did you use to create the p2p tunnel > and to trigger the problem? This piece of information could be > useful for future testing of the p2p cases. > > Thanks, > Pavlin > >> --- xorp-1.5~cvs.20080128.orig/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc >> +++ xorp-1.5~cvs.20080128/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc >> @@ -688,7 +688,7 @@ >> if (vifp->point_to_point()) { >> if ((rta_array[IFA_ADDRESS] != NULL) && !is_ifa_address_reassigned) { >> if (rta_array[IFA_ADDRESS] != NULL) { >> - if (nlm_decode_ipvx_address(family, rta_array[IFA_BROADCAST], >> + if (nlm_decode_ipvx_address(family, rta_array[IFA_ADDRESS], >> peer_addr, has_peer_addr, >> error_msg) >> != XORP_OK) { >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From f.rodriguez at lancaster.ac.uk Thu Feb 21 10:48:52 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Thu, 21 Feb 2008 18:48:52 -0000 Subject: [Xorp-hackers] Accessing RIB Database Questions In-Reply-To: <47BC4872.4050209@icsi.berkeley.edu> References: <200802151759.m1FHxXp9021148@fruitcake.ICSI.Berkeley.EDU> <47BC4872.4050209@icsi.berkeley.edu> Message-ID: Thanks for your reply. Actually, I was looking into using XRLs since it is the natural IPC for XORP processes. My current objective is to be able to access the final RIB table and any particular routing protocol table from an application that doesn't participates on the XORP (router), but that can interact with different process by doing some queries to them. I've been revising RIB's XRLs targets and some questions: 1) From my understanding the XRLs Targets that RIB implements for doing such thing in XORP are the redistribution XRLS: + rib_0_1_redistenable4/6 and disable + rib_0_1_redisttransaction_enable4/6 and disable + rib_0_1_redistenable4/6 and disable To me it seems like these XRLs have been design only for the routing protocol processes, so I'm not entirely sure that I can call them unless I register the other process (application) that might want to use such XRL I won't be able to use them, I'm right? Then the next questions would be, do I need to register my application? And, where do I register it? 2) Also, looking at the parameters that these XRLs receive, it doesn't seem to me that I can use them for querying the final RIB table. For example, look at the following XRL: XrlCmdError rib_0_1_redist_enable4( // Input values, const string& to_xrl_target, const string& from_protocol, const bool& unicast, const bool& multicast, const IPv4Net& network_prefix, const string& cookie); Them my questions would be, is the final RIB table being declared as protocol in order to access it? How does the rtrmgr process access such table when the CLI request to see the final routing table? Is there a different method or XRL able to use in order to access the final RIB? 3) Also, I'm still a little bit unsure which processes would need to use the rib_0_1_de/register_interest4/6, are they only used for policy routing and redistribution? Do a redistribution request that doesn't filter any route would use it? Cheers, Francisco -----Original Message----- From: Bruce M. Simpson [mailto:bms at icsi.berkeley.edu] Sent: 20 February 2008 15:34 To: Francisco Rodriguez Cc: 'Pavlin Radoslavov'; xorp-hackers at icir.org Subject: Re: [Xorp-hackers] Dummy Fea Matters Francisco Rodriguez wrote: > The next step that I'm looking to do is to access the RIB database. I'm not > 100% sure if accessing to the RIB has to be done through the use of XRLs or > not. For this, I'm planning to write an application (I guess a sort of XORP > Process) which needs to have the capability to speak to XORP processes, in > this case the RIB, and that make other tasks no related with XORP. Any > insight that you could give me to start this will be much appreciated. > I recommend you use XRL. There is a "RIB direct" interface but that is in there largely as a backdoor for testing purposes and I would not condone its use for new code, but for a prototype it may be much easier for you to use. Watch for asynchronicity. All 'Xrl*Client' class 'send*' methods require that you pass a callback parameter and yes these things may happen asynchronously, it's RPC after all. At the moment XRL is best called from C++. Certainly all the client bindings depend upon it. It is a tricky problem to solve unless you reimplement libxipc in a language other than C++, because the XRL sender classes require XORP event loop and callback semantics. These expect C++ linkage i.e. the instance you pass to it must be derived from XorpCallback. How we deal with this in shell scripts, is just to use the call_xrl tool, however this obviously means you block waiting for each XRL call to execute, and it also doesn't let you implement XRL targets outside of C++. I tried to solve this in SWIG the other day, but I can't get my head around how to write typemaps at the level of wrapping we require (ie references to callback types). Hint: XRL targets themselves are actually easy enough to wrap in SWIG-- you just need to instantiate an XrlStdRouter from outside and pass that in. Clients are harder because of asynchronicity. Someone really needs to sit down and solve the scripting language wrapper problem. What would be really cool is if someone slapped together a Bouml plug-in and plug-out which allows XORP XIF RPC specifications to be expressed in UML. I think you can even do this in Python now. This shouldn't be too difficult as the XIF syntax is C-like and the grammar isn't at all complex, and it will let you visualize the XIF interfaces as... nice shiny standard diagrams. cheers BMS From pavlin at ICSI.Berkeley.EDU Thu Feb 21 12:14:52 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 21 Feb 2008 12:14:52 -0800 Subject: [Xorp-hackers] gre tunnel problem In-Reply-To: <47BD6338.9020107@gmail.com> References: <47BC5A99.70806@gmail.com> <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> <47BD6338.9020107@gmail.com> Message-ID: <200802212014.m1LKEq6x022627@fruitcake.ICSI.Berkeley.EDU> > I still have problem. > Thus gre interface have 2 addresses one is public ip and > another is tunnel ip, when enable igmp or pim on gre > interface, sometimes it register the public ip causing erro > "Address already in use". I found that vif store ip addresses > in a map which is not ordered (the first item is not the one > inserted first). What is the output of "ip addr" Linux command and "show interfaces" xorpsh command? I am a bit surprised that the gre interface itself lists the public IP address as one of its own addresses. Also, what your "interfaces" section looks like? If you are using the "default-system-config" statement, you can try to explicitly configure/specify the tunnel IP address for the GRE interface. Regards, Pavlin > in ./fea/data_plane/io/io_ip_socket.cc > > case AF_INET: > { > struct ip_mreq mreq; > struct in_addr in_addr; > > // Find the first address > IfTreeVif::IPv4Map::const_iterator ai = vifp->ipv4addrs().begin(); > if (ai == vifp->ipv4addrs().end()) { > error_msg = c_format("Cannot join group %s on interface %s vif %s: " > "interface/vif has no address", > cstring(group), > if_name.c_str(), > vif_name.c_str()); > return (XORP_ERROR); > } > const IfTreeAddr4& fa = ai->second; > > fa.addr().copy_out(in_addr); > group.copy_out(mreq.imr_multiaddr); > mreq.imr_interface.s_addr = in_addr.s_addr; > > if (setsockopt(_proto_socket_in, IPPROTO_IP, IP_ADD_MEMBERSHIP, > XORP_SOCKOPT_CAST(&mreq), sizeof(mreq)) < 0) { > error_msg = c_format("Cannot join group %s on interface %s vif %s: %s", > cstring(group), > if_name.c_str(), > vif_name.c_str(), > strerror(errno)); > return (XORP_ERROR); > } > } > break; > > Here primary ip address should be used, but sometimes the first one in IPv4Map isn't the primary ip. I don't know how to fix this problem. Maybe a lot of changes should be taken. > > > > Zealot wrote: > > > >> Hi, all: > >> Xorp seems can not get ip address from p2p interface. There is a patch to fix this. > >> It may cause some other problem, but at least it works > > > > Yes, this is a bug, and your solution appears correct. > > Applied in CVS: > > xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc > > rev. 1.16 > > > > BTW, what program and command did you use to create the p2p tunnel > > and to trigger the problem? This piece of information could be > > useful for future testing of the p2p cases. > > > > Thanks, > > Pavlin > > > >> --- xorp-1.5~cvs.20080128.orig/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc > >> +++ xorp-1.5~cvs.20080128/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc > >> @@ -688,7 +688,7 @@ > >> if (vifp->point_to_point()) { > >> if ((rta_array[IFA_ADDRESS] != NULL) && !is_ifa_address_reassigned) { > >> if (rta_array[IFA_ADDRESS] != NULL) { > >> - if (nlm_decode_ipvx_address(family, rta_array[IFA_BROADCAST], > >> + if (nlm_decode_ipvx_address(family, rta_array[IFA_ADDRESS], > >> peer_addr, has_peer_addr, > >> error_msg) > >> != XORP_OK) { > >> > >> _______________________________________________ > >> Xorp-hackers mailing list > >> Xorp-hackers at icir.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at ICSI.Berkeley.EDU Thu Feb 21 14:37:52 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 21 Feb 2008 14:37:52 -0800 Subject: [Xorp-hackers] gre tunnel problem In-Reply-To: <200802212014.m1LKEq6x022627@fruitcake.ICSI.Berkeley.EDU> References: <47BC5A99.70806@gmail.com> <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> <47BD6338.9020107@gmail.com> <200802212014.m1LKEq6x022627@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200802212237.m1LMbr8N017697@fruitcake.ICSI.Berkeley.EDU> Pavlin Radoslavov wrote: > > I still have problem. > > Thus gre interface have 2 addresses one is public ip and > > another is tunnel ip, when enable igmp or pim on gre > > interface, sometimes it register the public ip causing erro > > "Address already in use". I found that vif store ip addresses > > in a map which is not ordered (the first item is not the one > > inserted first). > > What is the output of "ip addr" Linux command and "show interfaces" > xorpsh command? > I am a bit surprised that the gre interface itself lists the public > IP address as one of its own addresses. > > Also, what your "interfaces" section looks like? Never mind the above. I just tested it myself and indeed both addresses are listed by "ip addr" and "show interfaces". I did the same on FreeBSD and "show interfaces" correctly returns only the tunnel IP address, so it seems there is a Linux-specific bug in the FEA the way it handles the p2p IP addresses. > If you are using the "default-system-config" statement, > you can try to explicitly configure/specify the tunnel IP address > for the GRE interface. Please try the above as a short-term solution while I fix the Linux GRE issue. Regards, Pavlin From bms at incunabulum.net Thu Feb 21 14:57:06 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 21 Feb 2008 22:57:06 +0000 Subject: [Xorp-hackers] gre tunnel problem In-Reply-To: <200802212237.m1LMbr8N017697@fruitcake.ICSI.Berkeley.EDU> References: <47BC5A99.70806@gmail.com> <200802210206.m1L26c6e000809@fruitcake.ICSI.Berkeley.EDU> <47BD6338.9020107@gmail.com> <200802212014.m1LKEq6x022627@fruitcake.ICSI.Berkeley.EDU> <200802212237.m1LMbr8N017697@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47BE01C2.9060005@incunabulum.net> Pavlin Radoslavov wrote: > I did the same on FreeBSD and "show interfaces" correctly returns > only the tunnel IP address, so it seems there is a Linux-specific > bug in the FEA the way it handles the p2p IP addresses. > *BSD should only ever expose the outside addresses of the GRE tunnel via the gre(4) specific interface ioctls, it is not part of the sysctl interface MIB or the routing socket messages there. Clearly this issue is specific to the Linux interface handling code. I was under the impression though that Netlink used a TLV message format, so it's possible the relevant fields are in another TLV. later BMS From steweg at ynet.sk Tue Feb 26 04:31:55 2008 From: steweg at ynet.sk (Stefan Gula) Date: Tue, 26 Feb 2008 13:31:55 +0100 Subject: [Xorp-hackers] BGP and policy problem Message-ID: Hi I am currently trying to establish eBGP sessions with another XORP eBGP and iBGP routers like this: Network A,B,C,D are connected to Router R1 and R2 in AS1. They are distributed through OSPF, which works fine. Now there is Network E and F on Router R3 which is in AS2. What I try to achive is that traffic from AS1 going to network E goes through R2 a to network F goes through R1. I achieved this by applying import policy on R1 and R2 by the way of localpref. What I am unable to achive is applying also export policy on R1 and R2 with MED attribute to make sure that R3 will choose the same way that traffic comes in as it goes out. Here is my configuration root at R1# show policy policy-statement "bel_out" { term a { from { protocol: "connected" network4-list: "my_routes" } to { neighbor: 10.1.2.18..10.1.2.18 } then { med: 100 accept { } } } term b { from { protocol: "ospf4" } to { neighbor: 10.1.2.18..10.1.2.18 } then { med: 100 accept { } } } } policy-statement "bel_in" { term a { from { neighbor: 10.1.2.18..10.1.2.18 network4-list: "management" } then { localpref: 100 accept { } } } } network4-list "my_routes" { network 192.168.2.0/26 network 192.168.2.128/26 network 10.1.2.16/30 } network4-list "management" { network 10.1.4.0/24 } root at R1# show protocols bgp bgp-id: 192.168.2.1 local-as: 65535 peer "10.1.2.18" { local-ip: "10.1.2.17" as: 65534 next-hop: 10.1.2.17 } peer "192.168.2.2" { local-ip: "192.168.2.1" as: 65535 next-hop: 192.168.2.1 } traceoptions { flag { all { disable: true } } } export: "bel_out" import: "bel_in" in logs it shows something like this: [ 2008/02/26 13:06:18 WARNING xorp_rib RIB ] Unable to complete XRL: del_route4 for bgp route: Dst: 10.1.2.18/32 Vif: vlan4 NextHop: NH:192.168.2.1 Metric: 2 Protocol: ospf PolicyTags: 5 [ 2008/02/26 13:06:14 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp next table = Merged:(ebgp)+(ibgp) [ 2008/02/26 13:06:14 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp next table = Merged:(ebgp)+(ibgp) [ 2008/02/26 13:06:14 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp next table = Merged:(ebgp)+(ibgp) [ 2008/02/26 13:06:14 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp next table = Merged:(ebgp)+(ibgp) similar configuration is on R2 and also the same problem. Unable to apply import and export policy together. On R3 there is everything Ok. So please can somebody point me to the right direction where is the problem? Thanks for any ideas -- Stefan Gula, CCNP From mkaplan at telcordia.com Tue Feb 26 11:12:06 2008 From: mkaplan at telcordia.com (Kaplan, Michael A) Date: Tue, 26 Feb 2008 14:12:06 -0500 Subject: [Xorp-hackers] Limitations for multiple instances of XORP Message-ID: <9C8CA610679BA74FBAEF300B18B9F39810A46015@rrc-dte-exs03.dte.telcordia.com> I am running multiple instances of XORP on a single machine. I'm looking for some data points in regards to how many instances a system can handle before keeling over. Has anyone else experimented in running multiple XORP instances? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080226/eb3c8f3d/attachment.html From greearb at candelatech.com Tue Feb 26 11:43:06 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 26 Feb 2008 11:43:06 -0800 Subject: [Xorp-hackers] Potential null pointer dereference. Message-ID: <47C46BCA.90509@candelatech.com> While merging my old patch set with the latest xorp tree, I believe I found a potential null pointer dereference. Here is my attempt at fixing it: [greearb at file-server control_socket]$ cvs diff -u netlink_socket_utilities.cc Index: netlink_socket_utilities.cc =================================================================== RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v retrieving revision 1.12 diff -u -r1.12 netlink_socket_utilities.cc --- netlink_socket_utilities.cc 8 Jan 2008 23:30:09 -0000 1.12 +++ netlink_socket_utilities.cc 26 Feb 2008 19:40:36 -0000 @@ -332,9 +332,10 @@ const IfTreeVif* vifp = iftree.find_vif(if_index); if (vifp == NULL) { if (! is_deleted) { - XLOG_FATAL("Could not find interface and vif for index %d", + XLOG_ERROR("Could not find interface and vif for index %d", if_index); } + return XORP_ERROR; } if_name = vifp->ifname(); vif_name = vifp->vifname(); -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue Feb 26 12:07:22 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 26 Feb 2008 12:07:22 -0800 Subject: [Xorp-hackers] Potential null pointer dereference. In-Reply-To: <47C46BCA.90509@candelatech.com> References: <47C46BCA.90509@candelatech.com> Message-ID: <47C4717A.4060701@candelatech.com> Ben Greear wrote: > While merging my old patch set with the latest xorp tree, I believe > I found a potential null pointer dereference. Here is my attempt > at fixing it: > > [greearb at file-server control_socket]$ cvs diff -u netlink_socket_utilities.cc > Index: netlink_socket_utilities.cc > =================================================================== > RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v > retrieving revision 1.12 > diff -u -r1.12 netlink_socket_utilities.cc > --- netlink_socket_utilities.cc 8 Jan 2008 23:30:09 -0000 1.12 > +++ netlink_socket_utilities.cc 26 Feb 2008 19:40:36 -0000 > @@ -332,9 +332,10 @@ > const IfTreeVif* vifp = iftree.find_vif(if_index); > if (vifp == NULL) { > if (! is_deleted) { > - XLOG_FATAL("Could not find interface and vif for index %d", > + XLOG_ERROR("Could not find interface and vif for index %d", > if_index); > } > + return XORP_ERROR; > } > if_name = vifp->ifname(); > vif_name = vifp->vifname(); > Here's another one: [greearb at file-server ifconfig]$ cvs diff -u ifconfig_parse_netlink_socket.cc Index: ifconfig_parse_netlink_socket.cc =================================================================== RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc,v retrieving revision 1.17 diff -u -r1.17 ifconfig_parse_netlink_socket.cc --- ifconfig_parse_netlink_socket.cc 21 Feb 2008 02:02:33 -0000 1.17 +++ ifconfig_parse_netlink_socket.cc 26 Feb 2008 20:06:18 -0000 @@ -603,7 +603,8 @@ // return; } - XLOG_FATAL("Could not find vif with index %u in IfTree", if_index); + XLOG_ERROR("Could not find vif with index %u in IfTree", if_index); + return; } debug_msg("Address event on interface %s vif %s with interface index %u\n", vifp->ifname().c_str(), vifp->vifname().c_str(), -- Ben Greear Candela Technologies Inc http://www.candelatech.com From imipak at yahoo.com Tue Feb 26 14:58:08 2008 From: imipak at yahoo.com (Jonathan Day) Date: Tue, 26 Feb 2008 14:58:08 -0800 (PST) Subject: [Xorp-hackers] XORP on Windows questions Message-ID: <320696.98409.qm@web31503.mail.mud.yahoo.com> Hi, Two questions on XORP on Windows. (Not my favourite platform, but workplace demands it.) First off, the build instructions say that the miminalist GNU (mingw) toolchain is required to build XORP. A lot of the utilities GNU provides (make, autoconf, bison, flex, libtools, etc), however, are available natively under the gnuwin32 project, but not everything. How much of mingw do I actually need, these days, to do a build? (For example, since Intel's C/C++ compiler will build the code, could I get away entirely with gnuwin32 and the Intel compiler and not use mingw at all?) Secondly, the real killer question. XORP is only validated for Windows Server 2003, according to the website, but I need to get the code running on Windows CE 6.0. What is the current impression of Windows developers on the status of the Windows port? Jonathan Day ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From bms at incunabulum.net Tue Feb 26 16:21:47 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 27 Feb 2008 00:21:47 +0000 Subject: [Xorp-hackers] XORP on Windows questions In-Reply-To: <320696.98409.qm@web31503.mail.mud.yahoo.com> References: <320696.98409.qm@web31503.mail.mud.yahoo.com> Message-ID: <47C4AD1B.3090205@incunabulum.net> Jonathan Day wrote: > Hi, > > Two questions on XORP on Windows. (Not my favourite > platform, but workplace demands it.) > > First off, the build instructions say that the > miminalist GNU (mingw) toolchain is required to build > XORP. A lot of the utilities GNU provides (make, > autoconf, bison, flex, libtools, etc), however, are > available natively under the gnuwin32 project, but not > everything. How much of mingw do I actually need, > these days, to do a build? > You generally only require autoconf, bison, flex and libtool if you plan to make changes to the source. A full MinGW and MSYS installation is required. > (For example, since Intel's C/C++ compiler will build > the code, could I get away entirely with gnuwin32 and > the Intel compiler and not use mingw at all?) > No. The use of the configure script is required. Anything other than MinGW's gcc compiler is not supported. > Secondly, the real killer question. XORP is only > validated for Windows Server 2003, according to the > website, but I need to get the code running on Windows > CE 6.0. What is the current impression of Windows > developers on the status of the Windows port? > Only IPv4 unicast routing is supported. I assume by Windows CE you are referring to Windows Mobile. There is no support for anything other than Windows Server 2003. Progress in this area has been slow because of a lack of project funding (or indeed patches) from interested parties. regards BMS From pavlin at ICSI.Berkeley.EDU Wed Feb 27 01:47:07 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 27 Feb 2008 01:47:07 -0800 Subject: [Xorp-hackers] Accessing RIB Database Questions In-Reply-To: References: <200802151759.m1FHxXp9021148@fruitcake.ICSI.Berkeley.EDU> <47BC4872.4050209@icsi.berkeley.edu> Message-ID: <200802270947.m1R9l7ZL001204@fruitcake.ICSI.Berkeley.EDU> Francisco Rodriguez wrote: > > Thanks for your reply. Actually, I was looking into using XRLs since it is > the natural IPC for XORP processes. > > My current objective is to be able to access the final RIB table and any > particular routing protocol table from an application that doesn't > participates on the XORP (router), but that can interact with different > process by doing some queries to them. I've been revising RIB's XRLs targets > and some questions: > 1) From my understanding the XRLs Targets that RIB implements for doing such > thing in XORP are the redistribution XRLS: > + rib_0_1_redistenable4/6 and disable > + rib_0_1_redisttransaction_enable4/6 and disable > + rib_0_1_redistenable4/6 and disable > To me it seems like these XRLs have been design only for the routing > protocol processes, so I'm not entirely sure that I can call them unless I > register the other process (application) that might want to use such XRL I > won't be able to use them, I'm right? Then the next questions would be, do I > need to register my application? And, where do I register it? For an application to use the above XRLs that application obviously needs to be XRL-aware. Basically it needs to use the libxipc library to register with the XRL Finder with its own target name. See the "Introduction to Writing a XORP Process" document and the source code of static_routes for more info on the subject. Then this process needs to implement some of the following XRL targets as appropriate: redist4.xif redist6.xif redist_transaction4.xif redist_transaction6.xif > 2) Also, looking at the parameters that these XRLs receive, it doesn't seem > to me that I can use them for querying the final RIB table. For example, > look at the following XRL: > XrlCmdError rib_0_1_redist_enable4( > // Input values, > const string& to_xrl_target, > const string& from_protocol, > const bool& unicast, > const bool& multicast, > const IPv4Net& network_prefix, > const string& cookie); > Them my questions would be, is the final RIB table being declared as > protocol in order to access it? How does the rtrmgr process access such > table when the CLI request to see the final routing table? Is there a > different method or XRL able to use in order to access the final RIB? If you use the special string "all" as the "from_protocol" it will give you the final (winning) routes. > 3) Also, I'm still a little bit unsure which processes would need to use the > rib_0_1_de/register_interest4/6, are they only used for policy routing and > redistribution? Do a redistribution request that doesn't filter any route > would use it? Currently it is used by BGP by the next-hop resolver mechanism. The advantage of that mechanism vs the redist*.xif mechanism is that your process will get updates only for the particular subnet address you are interested at. The downside is the extra complexity associated with it. Hope that helps, Pavlin From pavlin at ICSI.Berkeley.EDU Wed Feb 27 02:59:58 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 27 Feb 2008 02:59:58 -0800 Subject: [Xorp-hackers] Potential null pointer dereference. In-Reply-To: <47C4717A.4060701@candelatech.com> References: <47C46BCA.90509@candelatech.com> <47C4717A.4060701@candelatech.com> Message-ID: <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > Ben Greear wrote: > > While merging my old patch set with the latest xorp tree, I believe > > I found a potential null pointer dereference. Here is my attempt > > at fixing it: > > > > [greearb at file-server control_socket]$ cvs diff -u netlink_socket_utilities.cc > > Index: netlink_socket_utilities.cc > > =================================================================== > > RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v > > retrieving revision 1.12 > > diff -u -r1.12 netlink_socket_utilities.cc > > --- netlink_socket_utilities.cc 8 Jan 2008 23:30:09 -0000 1.12 > > +++ netlink_socket_utilities.cc 26 Feb 2008 19:40:36 -0000 > > @@ -332,9 +332,10 @@ > > const IfTreeVif* vifp = iftree.find_vif(if_index); > > if (vifp == NULL) { > > if (! is_deleted) { > > - XLOG_FATAL("Could not find interface and vif for index %d", > > + XLOG_ERROR("Could not find interface and vif for index %d", > > if_index); > > } > > + return XORP_ERROR; > > } > > if_name = vifp->ifname(); > > vif_name = vifp->vifname(); > > > > > Here's another one: > [greearb at file-server ifconfig]$ cvs diff -u ifconfig_parse_netlink_socket.cc > Index: ifconfig_parse_netlink_socket.cc > =================================================================== > RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc,v > retrieving revision 1.17 > diff -u -r1.17 ifconfig_parse_netlink_socket.cc > --- ifconfig_parse_netlink_socket.cc 21 Feb 2008 02:02:33 -0000 1.17 > +++ ifconfig_parse_netlink_socket.cc 26 Feb 2008 20:06:18 -0000 > @@ -603,7 +603,8 @@ > // > return; > } > - XLOG_FATAL("Could not find vif with index %u in IfTree", if_index); > + XLOG_ERROR("Could not find vif with index %u in IfTree", if_index); > + return; > } > debug_msg("Address event on interface %s vif %s with interface index %u\n", > vifp->ifname().c_str(), vifp->vifname().c_str(), > Ben, Did you see those FATAL/ERROR statements actually triggered when running XORP? The reason those XLOG statements are FATAL is to capture bugs that might be hiding somewhere else. If you were able to trigger those statements, could you provide instructions how to reproduce the problem so we can investigate it. Thanks, Pavlin From bms at incunabulum.net Wed Feb 27 08:30:16 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 27 Feb 2008 16:30:16 +0000 Subject: [Xorp-hackers] Potential null pointer dereference. In-Reply-To: <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> References: <47C46BCA.90509@candelatech.com> <47C4717A.4060701@candelatech.com> <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47C59018.9080607@incunabulum.net> Pavlin Radoslavov wrote: > The reason those XLOG statements are FATAL is to capture bugs that > might be hiding somewhere else. > If you were able to trigger those statements, could you provide > instructions how to reproduce the problem so we can investigate it. > +1. Whilst Ben's patches are well intentioned, they do not fully address the issues, and you correctly point out they most likely mask the underlying issue. There is definitely a corner case in the first situation, where vifp may be NULL and yet be dereferenced when is_deleted is true. This applies to all netlink socket processing. In the second situation, it looks like the case where the FEA is told of a new interface event by Linux, for an interface which it doesn't know about, this is treated as a fatal error by the FEA. It looks like this issue is also present in the PF_ROUTE support code. Now this reminds me of a situation I saw when testing out the forthcoming OLSR code, under both FreeBSD and Linux. I haven't recorded the details as it hasn't been an immediate priority, however it IS a looming issue. Hot swapping an interface seems to have problems -- that is, if I fire up a full XORP router with an OLSR process, remove its configuration for an interface, add a new interface to the underlying system, and then attempt to bring up OLSR on the new interface, the FEA does not recognise the new interface. Looking at the code it appears this is the case. There's a clear need to be able to add interfaces at runtime to support hot swapping of network interfaces for both ad-hoc and classic routing protocols. Could we be looking at the same underlying issue? I was under the impression the FEA could deal with learning about new interfaces at runtime, this evidence seems to suggest it doesn't and needs fixing. cheers BMS From bms at incunabulum.net Wed Feb 27 08:46:48 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 27 Feb 2008 16:46:48 +0000 Subject: [Xorp-hackers] Limitations for multiple instances of XORP In-Reply-To: <9C8CA610679BA74FBAEF300B18B9F39810A46015@rrc-dte-exs03.dte.telcordia.com> References: <9C8CA610679BA74FBAEF300B18B9F39810A46015@rrc-dte-exs03.dte.telcordia.com> Message-ID: <47C593F8.3050807@incunabulum.net> Kaplan, Michael A wrote: > > I am running multiple instances of XORP on a single machine. I?m > looking for some data points in regards to how many instances a system > can handle before keeling over. Has anyone else experimented in > running multiple XORP instances? > > Haven't done this myself, although it is definitely a research topic. A lot of work has gone into making it possible to run XORP virtual routers for simulation purposes, and I believe this is what some of Mark Handley's students at UCL have been involved with, perhaps they will chime in. What I can tell you is that the sizable runtime memory footprint is going to have an effect -- the short answer is, try it and see. You say nothing about the size of this machine you're running XORP on, which XORP processes you are running, how you've built/linked them, so anything here is pure speculation without real data. But I've just had some coffee, so I'll wax lyrical. ELF lazy symbol binding will probably have a negligible effect on runtime performance, when executables are first loaded. Sure, page sharing will be a factor at the single executable level, but it's not the same as benchmarking the actual reduction in footprint when shared libraries are introduced across the board, something I did last year but haven't published. I've done work on reducing this in build engineering land, by rototiling for shared libraries, something which people don't seem to want to get involved with ("Help me Obi-Wanken Autotools, you're my only hope") judging by the burgeoning silence on the topic -- or, perhaps it's more open source tragedy of the commons, what can we get for nothing this week/month? [Cue slapstick humour] The lack of progress is understandably so, given that the quality of the freely available tools has only recently come to the point where doing it for a moderately sized software project such as XORP, has been feasible, i.e. Boost.Build. Also it qualifies as an "engineering topic", so academics don't get rewarded for writing papers about it. regards BMS From greearb at candelatech.com Wed Feb 27 10:33:40 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 27 Feb 2008 10:33:40 -0800 Subject: [Xorp-hackers] Potential null pointer dereference. In-Reply-To: <47C59005.7050302@icir.org> References: <47C46BCA.90509@candelatech.com> <47C4717A.4060701@candelatech.com> <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> <47C59005.7050302@icir.org> Message-ID: <47C5AD04.5000609@candelatech.com> Bruce M. Simpson wrote: > Pavlin Radoslavov wrote: >> The reason those XLOG statements are FATAL is to capture bugs that >> might be hiding somewhere else. >> If you were able to trigger those statements, could you provide >> instructions how to reproduce the problem so we can investigate it. >> > > +1. > > Whilst Ben's patches are well intentioned, they do not fully address > the issues, and you correctly point out they most likely mask the > underlying issue. > > There is definitely a corner case in the first situation, where vifp > may be NULL and yet be dereferenced when is_deleted is true. This > applies to all netlink socket processing. While doing my testing on virtual interfaces that come and go, I have hit these corner cases. That is why I added these fixes in the first place. As previously mentioned, an interface can disappear at *any* time, so you can *never* be absolutely certain that a system call to ask about a particular interface will work. It's not easy to hit these races, so I can't give you a straight-forward way to reproduce it, but since it obviously can happen, I think you should figure out how to not crash when it does. For what it's worth, my method seemed to work fine. Either way, as Bruce admits, we can deref NULL in this case. If you want to leave it a fatal assert, that is your prerogative, but at least make it an assert and not just a SEGV. Thanks, Ben > > In the second situation, it looks like the case where the FEA is told > of a new interface event by Linux, for an interface which it doesn't > know about, this is treated as a fatal error by the FEA. > > It looks like this issue is also present in the PF_ROUTE support code. > > Now this reminds me of a situation I saw when testing out the > forthcoming OLSR code, under both FreeBSD and Linux. I haven't > recorded the details as it hasn't been an immediate priority, however > it IS a looming issue. > > Hot swapping an interface seems to have problems -- that is, if I fire > up a full XORP router with an OLSR process, remove its configuration > for an interface, add a new interface to the underlying system, and > then attempt to bring up OLSR on the new interface, the FEA does not > recognise the new interface. > > Looking at the code it appears this is the case. There's a clear need > to be able to add interfaces at runtime to support hot swapping of > network interfaces for both ad-hoc and classic routing protocols. > > Could we be looking at the same underlying issue? > > I was under the impression the FEA could deal with learning about new > interfaces at runtime, this evidence seems to suggest it doesn't and > needs fixing. > > cheers > BMS -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Feb 27 10:48:12 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 27 Feb 2008 10:48:12 -0800 Subject: [Xorp-hackers] Potential null pointer dereference. In-Reply-To: <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> References: <47C46BCA.90509@candelatech.com> <47C4717A.4060701@candelatech.com> <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47C5B06C.1090808@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Ben Greear wrote: >> >>> While merging my old patch set with the latest xorp tree, I believe >>> I found a potential null pointer dereference. Here is my attempt >>> at fixing it: >>> >>> [greearb at file-server control_socket]$ cvs diff -u netlink_socket_utilities.cc >>> Index: netlink_socket_utilities.cc >>> =================================================================== >>> RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v >>> retrieving revision 1.12 >>> diff -u -r1.12 netlink_socket_utilities.cc >>> --- netlink_socket_utilities.cc 8 Jan 2008 23:30:09 -0000 1.12 >>> +++ netlink_socket_utilities.cc 26 Feb 2008 19:40:36 -0000 >>> @@ -332,9 +332,10 @@ >>> const IfTreeVif* vifp = iftree.find_vif(if_index); >>> if (vifp == NULL) { >>> if (! is_deleted) { >>> - XLOG_FATAL("Could not find interface and vif for index %d", >>> + XLOG_ERROR("Could not find interface and vif for index %d", >>> if_index); >>> } >>> + return XORP_ERROR; >>> } >>> if_name = vifp->ifname(); >>> vif_name = vifp->vifname(); >>> >>> >> Here's another one: >> [greearb at file-server ifconfig]$ cvs diff -u ifconfig_parse_netlink_socket.cc >> Index: ifconfig_parse_netlink_socket.cc >> =================================================================== >> RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc,v >> retrieving revision 1.17 >> diff -u -r1.17 ifconfig_parse_netlink_socket.cc >> --- ifconfig_parse_netlink_socket.cc 21 Feb 2008 02:02:33 -0000 1.17 >> +++ ifconfig_parse_netlink_socket.cc 26 Feb 2008 20:06:18 -0000 >> @@ -603,7 +603,8 @@ >> // >> return; >> } >> - XLOG_FATAL("Could not find vif with index %u in IfTree", if_index); >> + XLOG_ERROR("Could not find vif with index %u in IfTree", if_index); >> + return; >> } >> debug_msg("Address event on interface %s vif %s with interface index %u\n", >> vifp->ifname().c_str(), vifp->vifname().c_str(), >> >> > > Ben, > > Did you see those FATAL/ERROR statements actually triggered when > running XORP? > The reason those XLOG statements are FATAL is to capture bugs that > might be hiding somewhere else. > If you were able to trigger those statements, could you provide > instructions how to reproduce the problem so we can investigate it. > I have seen both of these. I'm guessing that if you try long enough, you could reproduce it by adding a usb ethernet NIC to your xorp config, and then inserting and removing it while also concurrently telling xorpsh to add/remove the router config for this interface over and over until you get lucky. That is effectively what I was doing, though I was using virtual interfaces instead of yanking cables. Or, just admit the theoretical possibility, and make the code more protective. :) Ben > Thanks, > Pavlin > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Feb 27 11:19:43 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 27 Feb 2008 11:19:43 -0800 Subject: [Xorp-hackers] Potential null pointer dereference. In-Reply-To: <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> References: <47C46BCA.90509@candelatech.com> <47C4717A.4060701@candelatech.com> <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47C5B7CF.3000603@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Ben Greear wrote: >> >>> While merging my old patch set with the latest xorp tree, I believe >>> I found a potential null pointer dereference. Here is my attempt >>> at fixing it: >>> >>> [greearb at file-server control_socket]$ cvs diff -u netlink_socket_utilities.cc >>> Index: netlink_socket_utilities.cc >>> =================================================================== >>> RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v >>> retrieving revision 1.12 >>> diff -u -r1.12 netlink_socket_utilities.cc >>> --- netlink_socket_utilities.cc 8 Jan 2008 23:30:09 -0000 1.12 >>> +++ netlink_socket_utilities.cc 26 Feb 2008 19:40:36 -0000 >>> @@ -332,9 +332,10 @@ >>> const IfTreeVif* vifp = iftree.find_vif(if_index); >>> if (vifp == NULL) { >>> if (! is_deleted) { >>> - XLOG_FATAL("Could not find interface and vif for index %d", >>> + XLOG_ERROR("Could not find interface and vif for index %d", >>> if_index); >>> } >>> + return XORP_ERROR; >>> } >>> if_name = vifp->ifname(); >>> vif_name = vifp->vifname(); >>> >>> >> Here's another one: >> [greearb at file-server ifconfig]$ cvs diff -u ifconfig_parse_netlink_socket.cc >> Index: ifconfig_parse_netlink_socket.cc >> =================================================================== >> RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc,v >> retrieving revision 1.17 >> diff -u -r1.17 ifconfig_parse_netlink_socket.cc >> --- ifconfig_parse_netlink_socket.cc 21 Feb 2008 02:02:33 -0000 1.17 >> +++ ifconfig_parse_netlink_socket.cc 26 Feb 2008 20:06:18 -0000 >> @@ -603,7 +603,8 @@ >> // >> return; >> } >> - XLOG_FATAL("Could not find vif with index %u in IfTree", if_index); >> + XLOG_ERROR("Could not find vif with index %u in IfTree", if_index); >> + return; >> } >> debug_msg("Address event on interface %s vif %s with interface index %u\n", >> vifp->ifname().c_str(), vifp->vifname().c_str(), >> >> > > Ben, > > Did you see those FATAL/ERROR statements actually triggered when > running XORP? > The reason those XLOG statements are FATAL is to capture bugs that > might be hiding somewhere else. > If you were able to trigger those statements, could you provide > instructions how to reproduce the problem so we can investigate it. > I have seen both of these. I'm guessing that if you try long enough, you could reproduce it by adding a usb ethernet NIC to your xorp config, and then inserting and removing it while also concurrently telling xorpsh to add/remove the router config for this interface over and over until you get lucky. That is effectively what I was doing, though I was using virtual interfaces instead of yanking cables. Or, just admit the theoretical possibility, and make the code more protective. :) Ben > Thanks, > Pavlin > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kristian at spritelink.net Thu Feb 28 17:20:17 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Fri, 29 Feb 2008 02:20:17 +0100 Subject: [Xorp-hackers] Potential null pointer dereference. In-Reply-To: <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> References: <47C46BCA.90509@candelatech.com> <47C4717A.4060701@candelatech.com> <200802271100.m1RAxwLr013924@fruitcake.ICSI.Berkeley.EDU> Message-ID: <20080229012016.GA34549@spritelink.se> On Wed, Feb 27, 2008 at 02:59:58AM -0800, Pavlin Radoslavov wrote: > Ben Greear wrote: > > > Ben Greear wrote: > > > While merging my old patch set with the latest xorp tree, I believe > > > I found a potential null pointer dereference. Here is my attempt > > > at fixing it: > > > > > > [greearb at file-server control_socket]$ cvs diff -u netlink_socket_utilities.cc > > > Index: netlink_socket_utilities.cc > > > =================================================================== > > > RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v > > > retrieving revision 1.12 > > > diff -u -r1.12 netlink_socket_utilities.cc > > > --- netlink_socket_utilities.cc 8 Jan 2008 23:30:09 -0000 1.12 > > > +++ netlink_socket_utilities.cc 26 Feb 2008 19:40:36 -0000 > > > @@ -332,9 +332,10 @@ > > > const IfTreeVif* vifp = iftree.find_vif(if_index); > > > if (vifp == NULL) { > > > if (! is_deleted) { > > > - XLOG_FATAL("Could not find interface and vif for index %d", > > > + XLOG_ERROR("Could not find interface and vif for index %d", > > > if_index); > > > } > > > + return XORP_ERROR; > > > } > > > if_name = vifp->ifname(); > > > vif_name = vifp->vifname(); > > > > > > > > > Here's another one: > > [greearb at file-server ifconfig]$ cvs diff -u ifconfig_parse_netlink_socket.cc > > Index: ifconfig_parse_netlink_socket.cc > > =================================================================== > > RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc,v > > retrieving revision 1.17 > > diff -u -r1.17 ifconfig_parse_netlink_socket.cc > > --- ifconfig_parse_netlink_socket.cc 21 Feb 2008 02:02:33 -0000 1.17 > > +++ ifconfig_parse_netlink_socket.cc 26 Feb 2008 20:06:18 -0000 > > @@ -603,7 +603,8 @@ > > // > > return; > > } > > - XLOG_FATAL("Could not find vif with index %u in IfTree", if_index); > > + XLOG_ERROR("Could not find vif with index %u in IfTree", if_index); > > + return; > > } > > debug_msg("Address event on interface %s vif %s with interface index %u\n", > > vifp->ifname().c_str(), vifp->vifname().c_str(), > > > > Ben, > > Did you see those FATAL/ERROR statements actually triggered when > running XORP? > The reason those XLOG statements are FATAL is to capture bugs that > might be hiding somewhere else. > If you were able to trigger those statements, could you provide > instructions how to reproduce the problem so we can investigate it. For a true lab scenario this would probably be the wanted behaviour, but for software that is supposed to be able to work in the real world it is probably not. One of the most interesting parts I've seen with IOS XR (Ciscos new operating system for the CRS-1) is the ability to track what all processes are doing all the time, so if a fault occurs, debug information is saved at all times, even though the administrator of the system has not asked of this. This is very Service Providerisch ;), it'd be nice to see XORP have something like it. -K -- Kristian Larsson KLL-RIPE Network Engineer & Peering Coordinator SpriteLink [AS39525] +46 704 910401 kll at spritelink.net From greearb at candelatech.com Fri Feb 29 23:16:43 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 29 Feb 2008 23:16:43 -0800 Subject: [Xorp-hackers] Why use the home-grown heap.cc? Message-ID: <47C902DB.8010209@candelatech.com> While testing the latest xorp (plus my patches, which certainly could be the cause), I ran into the assert below. Before I dig into this farther, I am curious if there is a good reason we are using a home-grown heap class as opposed to something from the STL? Loaded symbols for /lib/libnss_files.so.2 Core was generated by `xorp_rtrmgr -p 20002 -b vr_conf/xorp-vr10002.conf'. Program terminated with signal 6, Aborted. #0 0xb7f74410 in __kernel_vsyscall () (gdb) bt #0 0xb7f74410 in __kernel_vsyscall () #1 0x0056f690 in raise () from /lib/libc.so.6 #2 0x00570f91 in abort () from /lib/libc.so.6 #3 0x0817f119 in xlog_fatal (module_name=0x820c3b9 "LIBXORP", where=0xbfbfd068 "heap.cc:171 pop_obj", fmt=0x820c484 "-- heap_extract, father %d out of bound 0..%d") at xlog.c:435 #4 0x081a478c in Heap::pop_obj (this=0x84cb478, obj=0x84cf918) at heap.cc:170 #5 0x081a0159 in TimerList::unschedule_node (this=0xbfc010cc, n=0x84cf918) at timer.cc:592 #6 0x081a01c8 in TimerNode::unschedule (this=0x84cf918) at timer.cc:119 #7 0x081a032e in ~TimerNode (this=0x84cf918) at timer.cc:74 #8 0x081a2984 in ~PeriodicTimerNode2 (this=0x84cf918) at timer.cc:188 #9 0x0819f2b0 in TimerNode::release_ref (this=0x84cf918) at timer.cc:87 #10 0x08069322 in ~XorpTimer (this=0x84c9df0) at timer.hh:535 #11 0x08110cd7 in ~Finder (this=0x84c9d6c) at finder.cc:360 #12 0x080f83eb in ~FinderServer (this=0x84c9d68) at finder_server.cc:82 #13 0x08067c5e in Rtrmgr::run (this=0xbfc01438) at main_rtrmgr.cc:350 #14 0x08068353 in main (argc=5, argv=0xbfc01544) at main_rtrmgr.cc:500 (gdb) frame 4 #4 0x081a478c in Heap::pop_obj (this=0x84cb478, obj=0x84cf918) at heap.cc:170 170 heap.cc: No such file or directory. in heap.cc (gdb) print father $1 = 3 (gdb) print _elements $2 = 1 (gdb) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Feb 29 17:05:11 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 29 Feb 2008 17:05:11 -0800 Subject: [Xorp-hackers] RFC: Use one socket per interface for receiving packets in the FEA. In-Reply-To: <200802291920.m1TJKTok018510@fruitcake.ICSI.Berkeley.EDU> References: <200801160237.m0G2bt9d006369@possum.icir.org> <47C36818.1080507@candelatech.com> <200802271026.m1RAQ9Nq007826@fruitcake.ICSI.Berkeley.EDU> <47C6F18D.8030200@candelatech.com> <200802281909.m1SJ9U8Y029564@fruitcake.ICSI.Berkeley.EDU> <47C73D0B.7030501@candelatech.com> <200802282318.m1SNIibh019025@fruitcake.ICSI.Berkeley.EDU> <47C8506B.6020607@candelatech.com> <200802291920.m1TJKTok018510@fruitcake.ICSI.Berkeley.EDU> Message-ID: <47C8ABC7.9020104@candelatech.com> Here's a first attempt at using one rx socket per device, and binding to that particular device. This keeps us from receiving multicast traffic not destined for us when we are running multiple instances of xorp on the same system. This code appears to work, but it does not properly clean up sockets when devices are un-configured. I'll be working on that next. This code will be less efficient than the old way if the OS doesn't support SO_BINDTODEVICE, so I'll also add some code to mimic the old behaviour in that case (ie, windows). There's also some other cruft in there to deal with races around removing interfaces and removing the OSPF multicast groups. These changes have nothing in particular to do with per-interface rx sockets. Suggestions for improvements are welcome. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fea.patch Type: text/x-patch Size: 41612 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080229/aee8a84b/attachment-0001.bin