From cevhers at gmail.com Tue Jul 1 11:50:09 2008 From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=) Date: Tue, 1 Jul 2008 14:50:09 -0400 Subject: [Xorp-hackers] waiting for a callback return Message-ID: <803a75c30807011150o7a35ab92q8b91ec41ebc6c507@mail.gmail.com> Hi All, I want to call an xrl method of a process X in the middle of a function defined in some other process Y. The callback function defined in Y which processes the values returned by X simply sets a boolean variable VAR to TRUE if the value of XrlError object is OKAY. Below is how I called the xrl method of process X in Y, and wait for the callback to return: send_request(argument_list); while(!VAR) { // Do nothing } // When VAR becomes true, do something where send_request(argument_list) is a local function in Y which calls the xrl method in the client interface of process X till the request has been successfully sent (As expected, it also sends across the name of the callback function in Y). VAR is set to TRUE when the callback in Y is called with an argument of XrlError::OKAY. However, waiting in a while loop for VAR to become TRUE through the callback in Y even prevents the xrl_method handler in process X from being called. Hence, the while loop above turns into an infinite loop since VAR will never be set to TRUE by the callback in Y. What is the proper way other than a while loop like above for waiting for VAR to become true ? Thanks, Selcuk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080701/21cc42be/attachment.html From oho at acm.org Tue Jul 1 16:11:28 2008 From: oho at acm.org (Orion Hodson) Date: Tue, 1 Jul 2008 16:11:28 -0700 Subject: [Xorp-hackers] waiting for a callback return In-Reply-To: <803a75c30807011150o7a35ab92q8b91ec41ebc6c507@mail.gmail.com> References: <803a75c30807011150o7a35ab92q8b91ec41ebc6c507@mail.gmail.com> Message-ID: <24AF3A2E-6B99-4225-A400-A1106C4FE25D@acm.org> XORP processes use a single-threaded event driven model (and implicitly process level parallelism). A loop like the one below can therefore never exit because the execution path never falls back into the event loop dispatcher. The event loop dispatcher handles I/O, timers, etc, and is crucial to the operation of a XORP process. The correct way to achieve the desired effect here is to have the callback execute the code that would have happened after the while loop below. A model that XORP could adopt that would allow code like the example is Max Krohn's Tame framework: http://www.okws.org/doku.php?id=sfslite:tame2 which hides the execution path tearing that is inherent in traditional event based coding from the programmer. - Orion On Jul 1, 2008, at 11:50 AM, Sel?uk Cevher wrote: > Hi All, > > I want to call an xrl method of a process X in the middle of a > function defined in some other process Y. > > The callback function defined in Y which processes the values > returned by X simply sets a boolean variable VAR to TRUE if the > value of XrlError object is OKAY. > > Below is how I called the xrl method of process X in Y, and wait for > the callback to return: > > send_request(argument_list); > > while(!VAR) > { > // Do nothing > } > > // When VAR becomes true, do something > > where send_request(argument_list) is a local function in Y which > calls the xrl method in the client interface of process X till the > request has been successfully sent (As expected, it also sends > across the name of the callback function in Y). > > VAR is set to TRUE when the callback in Y is called with an argument > of XrlError::OKAY. > > However, waiting in a while loop for VAR to become TRUE through the > callback in Y even prevents the xrl_method handler in process X from > being called. Hence, the while loop above turns into an infinite > loop since VAR will never be set to TRUE by the callback in Y. > > What is the proper way other than a while loop like above for > waiting for VAR to become true ? > > Thanks, > Selcuk > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From esa_salahuddin at yahoo.com Tue Jul 1 17:23:28 2008 From: esa_salahuddin at yahoo.com (esa) Date: Tue, 1 Jul 2008 17:23:28 -0700 (PDT) Subject: [Xorp-hackers] BFD implementation available on XORP Message-ID: <200114.83028.qm@web50908.mail.re2.yahoo.com> Hi, ? Does?XORP currently support BFD protocol? http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-08.txt ? I have an implementation at http://sourceforge.net/projects/bfd-server?that I want to try out with other implementations for an interop or integration itself. ? thx, Esa ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080701/3c71671d/attachment.html From bms at incunabulum.net Wed Jul 2 01:59:11 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 02 Jul 2008 09:59:11 +0100 Subject: [Xorp-hackers] waiting for a callback return In-Reply-To: <803a75c30807011150o7a35ab92q8b91ec41ebc6c507@mail.gmail.com> References: <803a75c30807011150o7a35ab92q8b91ec41ebc6c507@mail.gmail.com> Message-ID: <486B435F.90505@incunabulum.net> Sel?uk Cevher wrote: > > I want to call an xrl method of a process X in the middle of a > function defined in some other process Y. > > What is the proper way other than a while loop like above for waiting > for VAR to become true ? As Orion points out, you need to make sure the Event Loop runs so that your callback will be invoked. The XORP Event Loop is not preemptive. It could be made preemptive, but that's a lot of work. If someone wants to step up and do it, we'll give them all the help we can. cheers BMS From esa_salahuddin at yahoo.com Wed Jul 2 04:30:11 2008 From: esa_salahuddin at yahoo.com (esa) Date: Wed, 2 Jul 2008 04:30:11 -0700 (PDT) Subject: [Xorp-hackers] BFD implementation available on XORP In-Reply-To: <486B4312.7050607@icir.org> Message-ID: <585277.94319.qm@web50907.mail.re2.yahoo.com> Hi Bruce, ? I would like to! ? However, I registered this project under GPL, and if understand correctly XORP is using some limited BSD license. So, if i understand correctly, ? - I can do a port on a private copy OR - To contribute port publicly, I HAVE TO change the license of my work to be same as XORP ? Is my understanding correct? ? thx, Esa --- On Wed, 7/2/08, Bruce M. Simpson wrote: From: Bruce M. Simpson Subject: Re: [Xorp-hackers] BFD implementation available on XORP To: esa_salahuddin at yahoo.com Cc: xorp-hackers at icir.org Date: Wednesday, July 2, 2008, 4:57 AM esa wrote: > > Does XORP currently support BFD protocol? > http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-08.txt > No, do you plan to port it? thanks BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080702/45676946/attachment.html From cevhers at gmail.com Wed Jul 2 12:40:04 2008 From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=) Date: Wed, 2 Jul 2008 15:40:04 -0400 Subject: [Xorp-hackers] creating a RoutingTable object Message-ID: <803a75c30807021240w7b18b13eg4cf273a22cce5f19@mail.gmail.com> Hi All, I added a new process into xorp in which a RoutingTable object is created in the same way as ospf does. Then, the entries in the table are populated by this new process without any dependency on ospf. It seems that a RoutingTable object should take an ospf object as input in its constructor while being created. Hence, I just created an ospf object in the new process's main function as follows which exists only to allow the creation of the RoutingTable object (ospf object is not used for anything else including route calculation): EventLoop eventloop; //EventLoop fakeEventloop; string feaname = "fea"; string ribname = "rib"; XrlStdRouter xrl_router(eventloop, "ospfv2"); XrlIO io(eventloop, xrl_router, feaname, ribname); Ospf ospf(OspfTypes::V2, eventloop, &io); The variable eventloop is the main event loop of the new process. After creating an ospf object this way which is later on inputted to the constructor of my own RoutingTable object, I observed that the new process successfully computes the routes. However, I am not sure that using the primary event loop of the new process for the purpose of creating an useless ospf object has some side-effects even though I did not observe any. First, I had created a "fake" event loop before as can be seen from commented out line above, but it gave me some timer errors. Hence, I began to use the primary event loop of the new process, which worked fine. Does anyone have an idea creation of an ospf object this way has any side-effects ? Thanks, Selcuk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080702/125a5b35/attachment.html From bms at incunabulum.net Thu Jul 3 02:15:11 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 03 Jul 2008 10:15:11 +0100 Subject: [Xorp-hackers] FreeBSD and gif(4) connected route issue Message-ID: <486C989F.7070401@incunabulum.net> Interesting observation with FreeBSD 6.3-RELEASE, whilst trying to reproduce someone's informal bug report: "connected" routes are not appearing in the routing table for the network prefixes assigned to gif(4) interfaces, when the network prefix is other than /32. Normally I wouldn't expect this to be a problem, but I am explicitly assigning them network prefixes in both "ifconfig" and in the XORP configuration. If I use /32's, everything is fine. It's just something you guys might want to keep in mind -- the submitter had an OSPF ptp setup and it's been necessary to emulate it. cheers BMS From bms at incunabulum.net Thu Jul 3 01:40:50 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 03 Jul 2008 09:40:50 +0100 Subject: [Xorp-hackers] BFD implementation available on XORP In-Reply-To: <585277.94319.qm@web50907.mail.re2.yahoo.com> References: <585277.94319.qm@web50907.mail.re2.yahoo.com> Message-ID: <486C9092.7080808@incunabulum.net> esa wrote: > > I would like to! > > However, I registered this project under GPL, and if understand > correctly XORP is using some limited BSD license. So, if i understand > correctly, > > - I can do a port on a private copy OR > > - To contribute port publicly, I HAVE TO change the license of my work > to be same as XORP > No, this isn't necessarily the case. Whilst we prefer that contributed code is placed under the XORP license, there's no reason why you can't license or even dual-license your code. However, code which does not use the XORP license can only be placed under the contrib/ directory and will not become part of the base XORP install. Using the XORP license just makes it more likely that we can pick up and incorporate code, as then there are no license compatibility issues. You're correct that the XORP license is a BSD derived license. thanks BMS From pavlin at ICSI.Berkeley.EDU Thu Jul 3 12:20:16 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 03 Jul 2008 12:20:16 -0700 Subject: [Xorp-hackers] FreeBSD and gif(4) connected route issue In-Reply-To: <486C989F.7070401@incunabulum.net> References: <486C989F.7070401@incunabulum.net> Message-ID: <200807031920.m63JKG8T002748@fruitcake.ICSI.Berkeley.EDU> Bruce M Simpson wrote: > Interesting observation with FreeBSD 6.3-RELEASE, whilst trying to > reproduce someone's informal bug report: Do you see the same behavior with FreeBSD-7.0? > "connected" routes are not appearing in the routing table for the > network prefixes assigned to gif(4) interfaces, when the network prefix > is other than /32. I presume you mean the routes are in the kernel, but not in the XORP "connected" routing table. If this is the case, then it is probably a bug in XORP. Please submit a Bugzilla entry with instructions how to reproduce it. Pavlin > Normally I wouldn't expect this to be a problem, but I am explicitly > assigning them network prefixes in both "ifconfig" and in the XORP > configuration. If I use /32's, everything is fine. > > It's just something you guys might want to keep in mind -- the submitter > had an OSPF ptp setup and it's been necessary to emulate it. > > cheers > BMS > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kfall at cs.berkeley.edu Sun Jul 6 22:23:54 2008 From: kfall at cs.berkeley.edu (Kevin Fall) Date: Sun, 6 Jul 2008 22:23:54 -0700 Subject: [Xorp-hackers] question on MLD querier -- rtalert extension header? Message-ID: <766FBB5D-A732-4ED1-9832-110D31A4B74B@cs.berkeley.edu> It appears to me that MLD query messages do not include the HBH/Router- Alert extension header. I believe this is incorrect. (queries need to be processed by non-querier multicast routers on the same subnet). Can somebody very/explain whether I have this correct? thx, - K From pavlin at ICSI.Berkeley.EDU Mon Jul 7 00:22:59 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 07 Jul 2008 00:22:59 -0700 Subject: [Xorp-hackers] question on MLD querier -- rtalert extension header? In-Reply-To: <766FBB5D-A732-4ED1-9832-110D31A4B74B@cs.berkeley.edu> References: <766FBB5D-A732-4ED1-9832-110D31A4B74B@cs.berkeley.edu> Message-ID: <200807070723.m677Mx46027430@fruitcake.ICSI.Berkeley.EDU> > It appears to me that MLD query messages do not include the HBH/Router- > Alert extension header. I believe this is incorrect. > (queries need to be processed by non-querier multicast routers on the > same subnet). Can somebody very/explain whether > I have this correct? Yes, all MLD messages must include the IPv6 Router Alert option. I just tested it on FreeBSD-7.0, and the Query messages actually include the Router Alert extension header, so the problem is probably OS-specific. If this option is missing in your setup, then this is a bug. In that case please submit a Bugzilla entry with information how to reproduce the problem, OS version, etc. Pavlin (still waiting for your .config Linux kernel config file :) From cevhers at gmail.com Mon Jul 7 10:24:41 2008 From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=) Date: Mon, 7 Jul 2008 13:24:41 -0400 Subject: [Xorp-hackers] core dump Message-ID: <803a75c30807071024u7366dafs36edc4fcb32c3193@mail.gmail.com> Hi All, I get the following error when I run a newly added xorp process, which basically receives the link state database from ospfv2 and then processes it: [ 2008/07/07 08:50:30 ERROR xorp_rtrmgr:22570 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/sha/xorp_pname": terminated with signal 11; aborted with a core dump. [ 2008/07/07 08:50:30 INFO xorp_rtrmgr:22570 RTRMGR +291 module_manager.cc module_exited ] Module coredumped: pname Since it may be related to the problem, before getting the above error, I keep getting the following warnings (I just listed some of them -- actually, there are many of them): [ 2008/07/07 08:50:30 WARNING xorp_fea FEA ] proto_socket_read() failed: RX packet from 10.4.4.4 to 224.0.0.5 pif_index 2722: no vif found [ 2008/07/07 08:50:30 WARNING xorp_fea FEA ] proto_socket_read() failed: RX packet from 10.3.4.4 to 224.0.0.5 pif_index 2733: no vif found [ 2008/07/07 08:50:30 WARNING xorp_fea FEA ] proto_socket_read() failed: RX packet from 99.1.1.4 to 224.0.0.5 pif_index 2739: no vif found [ 2008/07/07 08:50:30 WARNING xorp_fea FEA ] proto_socket_read() failed: RX packet from 10.3.4.4 to 224.0.0.5 pif_index 2731: no vif found What may be causing this problem ? If you need more detailed information about the error, please let me know. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080707/d42362a7/attachment.html From greearb at candelatech.com Mon Jul 7 10:34:07 2008 From: greearb at candelatech.com (Ben Greear) Date: Mon, 07 Jul 2008 10:34:07 -0700 Subject: [Xorp-hackers] core dump In-Reply-To: <803a75c30807071024u7366dafs36edc4fcb32c3193@mail.gmail.com> References: <803a75c30807071024u7366dafs36edc4fcb32c3193@mail.gmail.com> Message-ID: <4872538F.901@candelatech.com> Sel?uk Cevher wrote: > Hi All, > > I get the following error when I run a newly added xorp process, which > basically receives the link state database from ospfv2 and then > processes it: > > [ 2008/07/07 08:50:30 ERROR xorp_rtrmgr:22570 RTRMGR +747 > module_manager.cc done_cb ] Command "/usr/local/xorp/sha/xorp_pname": > terminated with signal 11; aborted with a core dump. > [ 2008/07/07 08:50:30 INFO xorp_rtrmgr:22570 RTRMGR +291 > module_manager.cc module_exited ] Module coredumped: pname Use gdb to diagnose the core file (get a backtrace at least). It's unlikely we can help you otherwise, especially since this is probably crashing in your own code. The vif errors are perhaps because you do not have interface objects in your sha config option? I'm not too sure about this, however... Thanks, -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kfall at cs.berkeley.edu Mon Jul 7 21:09:53 2008 From: kfall at cs.berkeley.edu (Kevin Fall) Date: Mon, 7 Jul 2008 21:09:53 -0700 Subject: [Xorp-hackers] question on MLD querier -- rtalert extension header? In-Reply-To: <200807070723.m677Mx46027430@fruitcake.ICSI.Berkeley.EDU> References: <766FBB5D-A732-4ED1-9832-110D31A4B74B@cs.berkeley.edu> <200807070723.m677Mx46027430@fruitcake.ICSI.Berkeley.EDU> Message-ID: <55FC92A5-DA69-4ED2-8433-9DADB5ADC41D@cs.berkeley.edu> Ok, this took me most of the day (unfortunately), but here it is: I am running on a Redhat linux system, and my problem was due to the issue discussed here: http://sourceware.org/bugzilla/show_bug.cgi?id=5760 Basically, inet6_opt_init() was setting the v6 extension header length to the value 1 instead of 0, even for small extensions like the HBH/RtAlert one. This is wrong. But the consequence is that the apparent size of the option + cmsg structure was too big. If cmsg_len is appropriately trimmed to the option size based on return values of inet_opt_XX, then the kernel (correctly) gives an EINVAL because it thinks the option is longer than the ancillary data provided to hold it :(. Attached is the .config for you. I'm looking into the best way to fix this, but it would appear that verifying and whacking as necessary the header produced by inet6_opt_init would be a first step. thx, - K -------------- next part -------------- A non-text attachment was scrubbed... Name: RC7-CONFIG.gz Type: application/x-gzip Size: 20498 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080707/6c8c0712/attachment-0001.gz -------------- next part -------------- On Jul 7, 2008, at Jul 712:22 AMPDT, Pavlin Radoslavov wrote: >> It appears to me that MLD query messages do not include the HBH/ >> Router- >> Alert extension header. I believe this is incorrect. >> (queries need to be processed by non-querier multicast routers on the >> same subnet). Can somebody very/explain whether >> I have this correct? > > Yes, all MLD messages must include the IPv6 Router Alert option. > I just tested it on FreeBSD-7.0, and the Query messages actually > include the Router Alert extension header, so the problem is > probably OS-specific. > > If this option is missing in your setup, then this is a bug. In that > case please submit a Bugzilla entry with information how to > reproduce the problem, OS version, etc. > > Pavlin > (still waiting for your .config Linux kernel config file :) > From cevhers at gmail.com Tue Jul 8 08:33:41 2008 From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=) Date: Tue, 8 Jul 2008 11:33:41 -0400 Subject: [Xorp-hackers] get_neighbour_info() Message-ID: <803a75c30807080833r22a57eb0s89106678978e4c63@mail.gmail.com> Hi All, I need the uint32_t value of rid argument (router ID) of type IPv4* returned by get_neighbour_info() xrl interface of ospfv2. I noticed that rid's uint32_t value shows up in reverse order when used IPv4::addr() (if the address is 10.10.1.2, it shows up as 2.1.10.10). The second issue is that what is the proper way of reseting a RoutingTable object (removing all the entries in it) other than iterating over all the items ? Thanks, Selcuk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080708/3f9259dc/attachment.html From greearb at candelatech.com Tue Jul 8 08:42:50 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 08 Jul 2008 08:42:50 -0700 Subject: [Xorp-hackers] get_neighbour_info() In-Reply-To: <803a75c30807080833r22a57eb0s89106678978e4c63@mail.gmail.com> References: <803a75c30807080833r22a57eb0s89106678978e4c63@mail.gmail.com> Message-ID: <48738AFA.9040604@candelatech.com> Sel?uk Cevher wrote: > Hi All, > > I need the uint32_t value of rid argument (router ID) of type IPv4* > returned by get_neighbour_info() xrl interface of ospfv2. > > I noticed that rid's uint32_t value shows up in reverse order when > used IPv4::addr() (if the address is 10.10.1.2 , it > shows up as 2.1.10.10 ). It's probably in network byte order...try: u32 v = ntohl(rid) before passing it to IPv4::addr() > > The second issue is that what is the proper way of reseting a > RoutingTable object (removing all the entries in it) other than > iterating over all the items ? No idea...what's wrong with iterating over all of the items? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Wed Jul 9 15:51:57 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 09 Jul 2008 15:51:57 -0700 Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.5 Message-ID: <60045.1215643917@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.5 Release Candidate, which is now available from . New features in this release include preliminary firewall support, VLANs and BGP support for four-octet AS numbers. In addition, this release contains numerous bug fixes. Once the release candidate has proven to be stable, the actual 1.5 release will be prepared. This is planned to occur before the end of the month. In the intervening period we will be fixing minor problems and updating the documentation. In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users at xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback at xorp.org. - The XORP Team P.S. Release notes included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.5-RC (2008/07/08) =========================== ALL: - XORP now builds on DragonFlyBSD-1.10.1, Linux Fedora 7, Linux Fedora 8, Linux Debian-4.0 (etch), Linux Ubuntu-7.04, Linux Ubuntu-7.10, NetBSD-4.0, OpenBSD-4.1, and OpenBSD-4.2. CONFIGURATION: - Addition of new FEA configuration statements to set the IPv4/IPv6 unicast forwarding table IDs: fea { unicast-forwarding4 { table-id: 254 } unicast-forwarding6 { table-id: 254 } } If the table ID is not configured, the FEA will use the default table ID for the system. Note that not all systems support multiple forwarding tables. Currently, they exist only on Linux (among all systems supported by XORP). - The "DISCARD" network interface flag is printed as appropriate when displaying the list of interfaces in the CLI. - Addition of new FEA configuration statement to support "unreachable" interfaces. Such interfaces are similar to "discard" interfaces, except that instead of silently throwing away packets, the system will respond with "ICMP destination unreachable". interfaces { interface my_unreachable { unreachable: true vif my_unreachable { } } } The default value for the "unreachable" statement is false. - Addition of new FEA configuration statement to flag an interface for "management" purpose. An interface that is flagged as "management" might be used in the future by some of the protocols for protocol-specific purpose. interfaces { interface fxp0 { management: true vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } } } The default value for the "management" statement is false. - Addition of support to configure VLANs on an interface. A VLAN is configured by using a "vlan" block that includes the VLAN ID: interfaces { interface fxp0 { vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } vif vlan1 { vlan { vlan-id: 1 } address 10.10.20.20 { prefix-length: 24 } } } } - Addition of preliminary support to configure firewall rules. Firewall rules are configured by using numbered entries: firewall { rule4 100 { action: "drop" protocol: 6 /* TCP */ source { interface: "fxp0" vif: "fxp0" network: 0.0.0.0/0 port-begin: 0 port-end: 65535 } destination { network: 10.10.0.0/24 port-begin: 0 port-end: 1024 } } } Note that compiling firewall support on Linux systems require patching some of the system header files. See ERRATA for details. - The following PIM-SM configuration statements have been deprecated, because PIM-SM doesn't use Router Alert IP option anymore: protocols { pimsm4 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } protocols { pimsm6 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } LIBXORP: - The local system-independent xorp_random() implemenation is used instead of the random(3) provided by the system. - Improved MAC address support (classes Mac and EtherMac). - More consistent usage of XORP_OK and XORP_ERROR to return error codes. LIBXIPC: - Bug fix in the internal mechanism for obtaining the IPv4 addresses from the system. After the bug fix, a secondary (alias) IP address can be specified with the "-i " command-line option to the xorp_rtrmgr or xorp_finder binaries. LIBFEACLIENT: - No significant changes. XRL: - Critical bug fix that can be triggered by malformatted XRLs. - Addition of support for 64-bit integers: i64 and u64 for signed and unsigned respectively. RTRMGR: - Addition of preliminary mechanism to log events to a file or to a syslog facility. - Addition of support to run XORP in background (in daemon mode). XORPSH: - Bug fix related to assigning the node ID position in case the previous (sibling) node was deleted at the same time a new node was added. This fixes "Found out-of-order term(s) inside policy ..." error inside the policy manager. - The "-c " command line option can be used more than once to run multiple commands. - Fix a long configuration delay when using xorpsh in non-interactive mode (e.g., "cat commands.txt | xorpsh"). - Addition of a new "-e" command line option. It can be used to tell xorpsh to exit immediately if the connection to the Finder fails. POLICY: - No significant changes. FEA/MFEA: - Major refactoring of the FEA/MFEA internals. - Critical bug fix that affects recent NetBSD and OpenBSD releases. - Critical IPv6-related bug fix when adding unicast forwarding entries to the kernel. This bug was exposed only on *BSD systems with 64-bit CPU. - If MFEA is started, it will explicitly enable the multicast forwarding flags that have been added to recent OpenBSD releases: net.inet.ip.mforwarding (for OpenBSD-3.9 and later) and net.inet6.ip6.mforwarding (for OpenBSD-4.0 and later). RIB: - No significant changes. RIP/RIPng: - Addition of support for "show ripng" xorpsh operational commands. - Critical RIPng-related bug fix. Previously the RIPng installed routes had incorrect outgoing interface toward the destination. - Bug fix related to the TTL for RIPng multicast packets: now it is set to 255 as specified in the protocol specification (RFC 2080) instead of 1. OSPF: - Bug fix related to OSPFv3 link-local scope LSAs. Previously the link-local scope LSAs were incorrectly flooded to links other than the one they belonged to. - Bug fix related to OSPFv3 Inter-Area-Prefix-LSAs. The check for the minimum size of an Inter-Area-Prefix-LSA was incorrect so short prefixes such as the default route would be rejected. - Added a clear database command. - In the OSPFv2 configuration "passive" is no longer a bool but a directive. Previously setting an interface to passive would set the interface to loopback and announce a host route for the interface. Using the passive keyword will still set the interface to loopback but now the network will be announced. If the previous behaviour of of announcing the host route is required the host variable can be set to true. BGP: - Added support for 4-byte AS numbers, as detailed in RFC 4893. From 1st Jan 2009 4-byte AS numbers will be allocated by default by RIPE, so it is desirable that all BGP implementations support four-byte AS numbers by that time. Currently 4-byte support is not enabled in XORP by default, but can be enabled using the "enable-4byte-as-numbers" configuration option. STATIC_ROUTES: - Bug fix that prevented the deletion of interface-specific routes using xorpsh. MLD/IGMP: - No significant changes. PIM-SM: - No significant changes. FIB2MRIB: - No significant changes. CLI: - No significant changes. SNMP: - No significant changes. From pavlin at ICSI.Berkeley.EDU Wed Jul 9 22:28:12 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 09 Jul 2008 22:28:12 -0700 Subject: [Xorp-hackers] question on MLD querier -- rtalert extension header? In-Reply-To: <55FC92A5-DA69-4ED2-8433-9DADB5ADC41D@cs.berkeley.edu> References: <766FBB5D-A732-4ED1-9832-110D31A4B74B@cs.berkeley.edu> <200807070723.m677Mx46027430@fruitcake.ICSI.Berkeley.EDU> <55FC92A5-DA69-4ED2-8433-9DADB5ADC41D@cs.berkeley.edu> Message-ID: <200807100528.m6A5SCbH000835@fruitcake.ICSI.Berkeley.EDU> Kevin Fall wrote: > Ok, this took me most of the day (unfortunately), but here it is: > > I am running on a Redhat linux system, and my problem was due to the issue > discussed here: > > http://sourceware.org/bugzilla/show_bug.cgi?id=5760 > > Basically, inet6_opt_init() was setting the v6 extension header length to the > value 1 instead of 0, even for small > extensions like the HBH/RtAlert one. > > This is wrong. But the consequence is that the apparent size of the option + > cmsg structure was > too big. If cmsg_len is appropriately trimmed to the option size based on > return values of inet_opt_XX, then the kernel (correctly) gives an EINVAL > because it thinks > the option is longer than the ancillary data provided to hold it :(. Thanks for the info. The problem appears to be in glibc and according to the above Bugzilla entry it has been fixed in their repository. I didn't understand your comment about cmsg_len. Are you suggesting that its value should be set by using the return value of, say, inet6_opt_init(), inet6_opt_append(), etc? Currently, cmsg_len is set by using the following assignment: cmsgp->cmsg_len = CMSG_LEN(...) which is actually based on the sample code from RFC 3542. > Attached is the .config for you. I'm looking into the best way to fix this, > but it would appear > that verifying and whacking as necessary the header produced by > inet6_opt_init would be a first step. It looks like the RFC3542 support for Linux has some issues. The right solution for Router Alert problem would be to apply the glibc fix for inet6_opt_init(). I don't know whether the original issue (the "Invalid argument" error) is related to the inet6_opt_init(), but anyway I just added a Bugzilla entry on your behalf re. the "Invalid argument" issue you were seeing: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=761 I wish I have the time to start playing with the 2.6.26 release candidates. Unfortunately I would have to wait until Linux kernel 2.6.26 is released and is available for Ubuntu before I try to fix it. This will also tell us whether the problem is RedHat specific or applies to more than one distribution. In the mean time please add any additional information on the subject to the new Bugzilla entry. Pavlin > thx, > > - K > > On Jul 7, 2008, at Jul 712:22 AMPDT, Pavlin Radoslavov wrote: > > >> It appears to me that MLD query messages do not include the HBH/ Router- > >> Alert extension header. I believe this is incorrect. > >> (queries need to be processed by non-querier multicast routers on the > >> same subnet). Can somebody very/explain whether > >> I have this correct? > > > > Yes, all MLD messages must include the IPv6 Router Alert option. > > I just tested it on FreeBSD-7.0, and the Query messages actually > > include the Router Alert extension header, so the problem is > > probably OS-specific. > > > > If this option is missing in your setup, then this is a bug. In that > > case please submit a Bugzilla entry with information how to > > reproduce the problem, OS version, etc. > > > > Pavlin > > (still waiting for your .config Linux kernel config file :) > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Thu Jul 10 17:49:28 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 10 Jul 2008 17:49:28 -0700 Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <60045.1215643917@tigger.icir.org> References: <60045.1215643917@tigger.icir.org> Message-ID: <4876AE18.7060509@candelatech.com> Atanu Ghosh wrote: > On behalf of the entire XORP team, I'm delighted to announce the XORP > 1.5 Release Candidate, which is now available from . > > New features in this release include preliminary firewall > support, VLANs and BGP support for four-octet AS numbers. I want to say thanks for all the hard work. The stability and feature sets for weirder configurations (such as my own) has improved greatly in the last year. I'm currently digging into BGP and ipv6 multicast routing. Do you happen to have an updated user-guide for 1.5? I'll be happy to help proof read and debug it for you... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Thu Jul 10 18:32:38 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 10 Jul 2008 18:32:38 -0700 Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <4876AE18.7060509@candelatech.com> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> Message-ID: <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> > I'm currently digging into BGP and ipv6 multicast routing. Do you happen > to have an updated user-guide for 1.5? I'll be happy to help proof read > and debug it for you... The user-guide changes will happen between now and the release itself. Content-wise there will be relatively few changes. It will be great if you can proof read and debug it. Which implies that we should make the changes sooner to give extra time for proof reading. Thanks, Pavlin From cevhers at gmail.com Fri Jul 11 06:31:12 2008 From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=) Date: Fri, 11 Jul 2008 09:31:12 -0400 Subject: [Xorp-hackers] route calculation: next hop's interface address ? Message-ID: <803a75c30807110631nddf6cbek6bd517d8da272981@mail.gmail.com> Hi All, As you know, to compute the routes to all destinations in the network, an ospf router creates an Spt object, and adds itself to it as the root (area_router.cc). Then, the source router sets some relevant information such as version, node id, origin, type, and more importantly the LSA for each node added to the Spt object including itself. Then, it calls compute() function on Spt object, and finds the routes to all destinations. However, under the assumtion that I have the entire link state advertisement database, I want to identify one of destinations in the network as the root of my own Spt object, rather than "myself" (So, I will compute routes for somebody else). (For example, If router A (i.e., "myself") is the router computing the routes, A creates an Spt object and sets B, one of the destinations in the network, as the root of the Spt object). Even though A ("myself") makes the necessary settings (LSA, version, type, router ID, etc.) properly for B (of course, B's LSA should be obtained from the link state database), the interface addresses of the next hops of calculated routes for B show up as zero (0.0.0.0). However, router ID's for the destinations and next hops are correct (I already know the network topology). If my question does not lack sufficient information, what may be causing the interface addresses of the next hops to show up as 0.0.0.0 when computing the routes for somebody else ? (When computing the routes for myself, next hop interface addresses look fine) Thanks, Selcuk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080711/77d0b2dd/attachment.html From greearb at candelatech.com Tue Jul 15 15:24:03 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 15 Jul 2008 15:24:03 -0700 Subject: [Xorp-hackers] Xorp FEA crash Message-ID: <487D2383.10408@candelatech.com> NOTE: This is with my patches applied, so it could be my fault. But, it looks like it could be a generic problem. I'm getting a crash in io_ip_socket.cc while trying to send a packet. The crash is because cmsgp is NULL. It looks like CMSG_NXTHDR can return NULL if there is no more space available, so the code should probably check for NULL and take evasive action.... // // Set the TTL // crash is here: cmsgp->cmsg_len = CMSG_LEN(sizeof(int)); cmsgp->cmsg_level = IPPROTO_IPV6; cmsgp->cmsg_type = IPV6_HOPLIMIT; int_val = ip_ttl; embed_host_int(CMSG_DATA(cmsgp), int_val); cmsgp = CMSG_NXTHDR(&_sndmh, cmsgp); Full backtrace: #0 0x081358ec in IoIpSocket::send_packet (this=0x8478b40, if_name=@0x849f1c8, vif_name=@0x84a01a8, src_address=@0xbf8437d0, dst_address=@0xbf8437bc, ip_ttl=1, ip_tos=0, ip_router_alert=true, ip_internet_control=true, ext_headers_type=@0xbf84378c, ext_headers_payload=@0xbf843780, payload=@0x844b708, error_msg=@0xbf84170c) at io_ip_socket.cc:2529 #1 0x080a8a92 in IoIpComm::send_packet (this=0x8478ac0, if_name=@0x849f1c8, vif_name=@0x84a01a8, src_address=@0xbf8437d0, dst_address=@0xbf8437bc, ip_ttl=1, ip_tos=-1, ip_router_alert=true, ip_internet_control=true, ext_headers_type=@0xbf84378c, ext_headers_payload=@0xbf843780, payload=@0x844b708, error_msg=@0xbf843798) at io_ip_manager.cc:311 #2 0x080a8f8d in IoIpManager::send (this=0xbf84fec4, if_name=@0x849f1c8, vif_name=@0x84a01a8, src_address=@0xbf8437d0, dst_address=@0xbf8437bc, ip_protocol=58 ':', ip_ttl=1, ip_tos=-1, ip_router_alert=true, ip_internet_control=true, ext_headers_type=@0xbf84378c, ext_headers_payload=@0xbf843780, payload=@0x844b708, error_msg=@0xbf843798) at io_ip_manager.cc:851 #3 0x0805436a in XrlFeaTarget::raw_packet6_0_1_send (this=0xbf8508b8, if_name=@0x849f1c8, vif_name=@0x84a01a8, src_address=@0x84a22f0, dst_address=@0x849e0a0, ip_protocol=@0x8398344, ip_ttl=@0x849e8e4, ip_tos=@0x8398504, ip_router_alert=@0x849f1ec, ip_internet_control=@0x849f20c, ext_headers_type=@0x849e360, ext_headers_payload=@0x84a0348, payload=@0x844b708) at xrl_fea_target.cc:3388 #4 0x081adf23 in XrlFeaTargetBase::handle_raw_packet6_0_1_send (this=0xbf8508b8, xa_inputs=@0xbf8478ac) at fea_base.cc:4546 #5 0x081c5591 in XorpMemberCallback2B0::dispatch (this=0x84313b8, a1=@0xbf8478ac, a2=0xbf847890) at ../../libxorp/callback_nodebug.hh:4615 #6 0x0826b0a9 in XrlCmdEntry::dispatch (this=0x843140c, inputs=@0xbf8478ac, outputs=0xbf847890) at xrl_cmd_map.hh:37 #7 0x08271b9e in XrlDispatcher::dispatch_xrl (this=0xbf84fa0c, method_name=@0xbf847820, inputs=@0xbf8478ac, outputs=@0xbf847890) at xrl_dispatcher.cc:60 #8 0x082561d5 in XrlRouter::dispatch_xrl (this=0xbf84fa0c, method_name=@0xbf8478a8, inputs=@0xbf8478ac, outputs=@0xbf847890) at xrl_router.cc:587 #9 0x0827a127 in STCPRequestHandler::dispatch_request (this=0x849f820, seqno=4, packed_xrl=0xb7c7d46e "?", packed_xrl_bytes=343) at xrl_pf_stcp.cc:239 #10 0x0827a7fd in STCPRequestHandler::read_event (this=0x849f820, ev=BufferedAsyncReader::DATA, buffer=0xb7c7d456 "STCP\001\001", buffer_bytes=367) at xrl_pf_stcp.cc:202 #11 0x0827be3c in XorpMemberCallback4B0::dispatch (this=0x849f6f8, a1=0x849f828, a2=BufferedAsyncReader::DATA, a3=0xb7c7d456 "STCP\001\001", a4=367) at ../libxorp/callback_nodebug.hh:8965 Missing separate debuginfos, use: debuginfo-install gcc.i386 glibc.i686 ncurses.i386 openssl.i686 zlib.i386 ---Type to continue, or q to quit--- #12 0x082a0f3f in BufferedAsyncReader::announce_event (this=0x849f828, ev=BufferedAsyncReader::DATA) at buffered_asyncio.cc:251 #13 0x082a127e in BufferedAsyncReader::io_event (this=0x849f828, fd={_filedesc = 44}, type=IOT_READ) at buffered_asyncio.cc:204 #14 0x082a1b0e in XorpMemberCallback2B0::dispatch ( this=0x84a1f60, a1={_filedesc = 44}, a2=IOT_READ) at ../libxorp/callback_nodebug.hh:4635 #15 0x082bdada in SelectorList::Node::run_hooks (this=0x84a0fb8, m=SEL_RD, fd={_filedesc = 44}) at selector.cc:149 #16 0x082bc745 in SelectorList::wait_and_dispatch (this=0xbf850938, timeout=@0xbf84f99c) at selector.cc:435 #17 0x082a348e in EventLoop::run (this=0xbf8508fc) at eventloop.cc:97 #18 0x0804d222 in fea_main (finder_hostname=@0xbf850b20, finder_port=19999) at xorp_fea.cc:101 #19 0x0804d508 in main (argc=0, argv=0xbf850be8) at xorp_fea.cc:175 (gdb) frame 0 #0 0x081358ec in IoIpSocket::send_packet (this=0x8478b40, if_name=@0x849f1c8, vif_name=@0x84a01a8, src_address=@0xbf8437d0, dst_address=@0xbf8437bc, ip_ttl=1, ip_tos=0, ip_router_alert=true, ip_internet_control=true, ext_headers_type=@0xbf84378c, ext_headers_payload=@0xbf843780, payload=@0x844b708, error_msg=@0xbf84170c) at io_ip_socket.cc:2529 2529 in io_ip_socket.cc (gdb) print smsgp No symbol "smsgp" in current context. (gdb) print cmsgp $1 = (cmsghdr *) 0x0 (gdb) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue Jul 15 16:17:33 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 15 Jul 2008 16:17:33 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <487D2383.10408@candelatech.com> References: <487D2383.10408@candelatech.com> Message-ID: <487D300D.3040800@candelatech.com> Ben Greear wrote: > NOTE: This is with my patches applied, so it could > be my fault. But, it looks like it could be a generic > problem. I added some more debugging. It is hitting the assert at the end of this code. It looks like we should not be doing the CMSG_NXTHDR if neither of the #ifdefs in this section are defined? // // Include the Router Alert option if needed // if (ip_router_alert) { #ifdef HAVE_RFC3542 int currentlen; void *hbhbuf, *optp = NULL; cmsgp->cmsg_len = CMSG_LEN(hbhlen); cmsgp->cmsg_level = IPPROTO_IPV6; cmsgp->cmsg_type = IPV6_HOPOPTS; hbhbuf = CMSG_DATA(cmsgp); currentlen = inet6_opt_init(hbhbuf, hbhlen); if (currentlen == -1) { error_msg = c_format("inet6_opt_init(len = %d) failed", hbhlen); return (XORP_ERROR); } currentlen = inet6_opt_append(hbhbuf, hbhlen, currentlen, IP6OPT_ROUTER_ALERT, 2, 2, &optp); if (currentlen == -1) { error_msg = c_format("inet6_opt_append(len = %d) failed", currentlen); return (XORP_ERROR); } inet6_opt_set_val(optp, 0, &rtalert_code6, sizeof(rtalert_code6)); if (inet6_opt_finish(hbhbuf, hbhlen, currentlen) == -1) { error_msg = c_format("inet6_opt_finish(len = %d) failed", currentlen); return (XORP_ERROR); } #else // ! HAVE_RFC3542 (i.e., the old advanced API) #ifdef HAVE_IPV6_MULTICAST_ROUTING // // TODO: XXX: temporary use HAVE_IPV6_MULTICAST_ROUTING // to conditionally compile, because Linux doesn't // have inet6_option_* // if (inet6_option_init((void *)cmsgp, &cmsgp, IPV6_HOPOPTS)) { error_msg = c_format("inet6_option_init(IPV6_HOPOPTS) failed"); return (XORP_ERROR); } assert(cmsgp); if (inet6_option_append(cmsgp, ra_opt6, 4, 0)) { error_msg = c_format("inet6_option_append(Router Alert) failed"); return (XORP_ERROR); } assert(cmsgp); #endif // HAVE_IPV6_MULTICAST_ROUTING #endif // ! HAVE_RFC3542 assert(cmsgp); cmsgp = CMSG_NXTHDR(&_sndmh, cmsgp); assert(cmsgp); } -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Wed Jul 16 11:23:24 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 16 Jul 2008 11:23:24 -0700 Subject: [Xorp-hackers] Power Outage Message-ID: <19473.1216232604@tigger.icir.org> Hi, For unexplained PG&E's will be removing power from ICSI where the XORP servers reside. We will therefore be shutting down the servers today Wednesday 16th July at 17:00PDT (UTC -8), the power is supposed to be restored tomorrow Thursday 17th July 6:00PDT. We will bring the servers back up as soon as power is restored. The mirror sites will still be available. Atanu. From bms at incunabulum.net Fri Jul 18 03:38:15 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 18 Jul 2008 11:38:15 +0100 Subject: [Xorp-hackers] Announcement: OLSR support in XORP 1.5 Message-ID: <48807297.6060309@incunabulum.net> Hi, This is just a brief announcement to let everyone know about the OLSR implementation which will be in the XORP 1.5 release. CenGen, Inc. generously funded the development of an RFC 3626 Optimized Link State Routing (OLSR) implementation over late 2007 and early 2008. This code has been made available under the XORP license. Currently it is in the contrib/olsr directory, is a configure-time option, and is a fully fledged XORP routing process. Route redistribution is supported and I understand CenGen had success with exporting into OSPF in their testbed. The code has some limitations, in particular, it does not currently support the ETX link metric feature ('link quality' in olsrd), however it could do so with some changes. Other than that, it interworks successfully with the olsrd.org implementation. I'd also be interested to hear from folk interested in porting features from Joe Macker's NRL implementation of OLSR. The regression testing is pretty thorough, though as is always the case with building a routing protocol, it can be difficult, if not impossible, to exercise all possible combinations of protocol state which can result. In particular the MPR behaviour could do with 3rd party review. I would very much like to hear from anyone who is interested in using XORP to build mesh network solutions with the XORP/OLSR code base (currently we have folk from UCL doing so), so we can gauge interest in the code going forward, and establish what lies in the future as regards support. many thanks BMS From pavlin at ICSI.Berkeley.EDU Fri Jul 18 11:33:08 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 18 Jul 2008 11:33:08 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <487D300D.3040800@candelatech.com> References: <487D2383.10408@candelatech.com> <487D300D.3040800@candelatech.com> Message-ID: <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > Ben Greear wrote: > > NOTE: This is with my patches applied, so it could > > be my fault. But, it looks like it could be a generic > > problem. > > I added some more debugging. It is hitting the assert at the end > of this code. It looks like we should not be doing the CMSG_NXTHDR > if neither of the #ifdefs in this section are defined? Ben, The only reason I can think of that CMSG_NXTHDR() returns NULL is if the _sndmh.msg_controllen value is too small to accomodate all the options. For sending purpose, the _sndmh.msg_controllen value is set to "ctllen" which is precomputed on-the-fly before the ancillary data is setup. If the problem is indeed a small _sndmh.msg_controllen, then "ctllen" wasn't calculated properly, which is a bug in that part of the code. Could you add some debug statements to print the value of _sndmh.msg_controllen and the calculation of "ctllen". Also, it will be helpful if you can try the same setup with vanilla XORP source code. In any case, could you send your OS and kernel version, and your XORP configuration file so I can also try to replicate and debug the problem. Thanks, Pavlin > // > // Include the Router Alert option if needed > // > if (ip_router_alert) { > #ifdef HAVE_RFC3542 > int currentlen; > void *hbhbuf, *optp = NULL; > > cmsgp->cmsg_len = CMSG_LEN(hbhlen); > cmsgp->cmsg_level = IPPROTO_IPV6; > cmsgp->cmsg_type = IPV6_HOPOPTS; > hbhbuf = CMSG_DATA(cmsgp); > currentlen = inet6_opt_init(hbhbuf, hbhlen); > if (currentlen == -1) { > error_msg = c_format("inet6_opt_init(len = %d) failed", > hbhlen); > return (XORP_ERROR); > } > currentlen = inet6_opt_append(hbhbuf, hbhlen, currentlen, > IP6OPT_ROUTER_ALERT, 2, 2, &optp); > if (currentlen == -1) { > error_msg = c_format("inet6_opt_append(len = %d) failed", > currentlen); > return (XORP_ERROR); > } > inet6_opt_set_val(optp, 0, &rtalert_code6, sizeof(rtalert_code6)); > if (inet6_opt_finish(hbhbuf, hbhlen, currentlen) == -1) { > error_msg = c_format("inet6_opt_finish(len = %d) failed", > currentlen); > return (XORP_ERROR); > } > > #else // ! HAVE_RFC3542 (i.e., the old advanced API) > > #ifdef HAVE_IPV6_MULTICAST_ROUTING > // > // TODO: XXX: temporary use HAVE_IPV6_MULTICAST_ROUTING > // to conditionally compile, because Linux doesn't > // have inet6_option_* > // > if (inet6_option_init((void *)cmsgp, &cmsgp, IPV6_HOPOPTS)) { > error_msg = c_format("inet6_option_init(IPV6_HOPOPTS) failed"); > return (XORP_ERROR); > } > assert(cmsgp); > if (inet6_option_append(cmsgp, ra_opt6, 4, 0)) { > error_msg = c_format("inet6_option_append(Router Alert) failed"); > return (XORP_ERROR); > } > assert(cmsgp); > #endif // HAVE_IPV6_MULTICAST_ROUTING > > #endif // ! HAVE_RFC3542 > assert(cmsgp); > cmsgp = CMSG_NXTHDR(&_sndmh, cmsgp); > assert(cmsgp); > } > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Fri Jul 18 11:44:54 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 18 Jul 2008 11:44:54 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> References: <487D2383.10408@candelatech.com> <487D300D.3040800@candelatech.com> <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4880E4A6.5050408@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> Ben Greear wrote: >>> NOTE: This is with my patches applied, so it could >>> be my fault. But, it looks like it could be a generic >>> problem. >> I added some more debugging. It is hitting the assert at the end >> of this code. It looks like we should not be doing the CMSG_NXTHDR >> if neither of the #ifdefs in this section are defined? > > Ben, > > The only reason I can think of that CMSG_NXTHDR() returns NULL is if > the _sndmh.msg_controllen value is too small to accomodate all the > options. > For sending purpose, the _sndmh.msg_controllen value is set to > "ctllen" which is precomputed on-the-fly before the ancillary data > is setup. > If the problem is indeed a small _sndmh.msg_controllen, then > "ctllen" wasn't calculated properly, which is a bug in that part of > the code. > > Could you add some debug statements to print the value of > _sndmh.msg_controllen and the calculation of "ctllen". > > Also, it will be helpful if you can try the same setup with vanilla > XORP source code. In any case, could you send your OS and kernel > version, and your XORP configuration file so I can also try to > replicate and debug the problem. If neither of those #defines are met, then I believe CMSG_NXTHDR is called twice in a row (because it was called before that big if branch, but the cmsgp is not modified within that if in this case), without initializing the msg header values. Here is the patch I have been successfully running with. Obviously the asserts can be removed... [greearb at file-server xorp_local_git]$ git diff diff --git a/fea/data_plane/io/io_ip_socket.cc b/fea/data_plane/io/io_ip_socket.cc index 8f27f6e..eba1892 100644 --- a/fea/data_plane/io/io_ip_socket.cc +++ b/fea/data_plane/io/io_ip_socket.cc @@ -2467,7 +2467,8 @@ IoIpSocket::send_packet(const string& if_name, } src_address.copy_out(sndpktinfo->ipi6_addr); cmsgp = CMSG_NXTHDR(&_sndmh, cmsgp); - + assert(cmsgp); + // // Include the Router Alert option if needed // @@ -2499,6 +2500,10 @@ IoIpSocket::send_packet(const string& if_name, currentlen); return (XORP_ERROR); } + + assert(cmsgp); + cmsgp = CMSG_NXTHDR(&_sndmh, cmsgp); + assert(cmsgp); #else // ! HAVE_RFC3542 (i.e., the old advanced API) @@ -2512,15 +2517,17 @@ IoIpSocket::send_packet(const string& if_name, error_msg = c_format("inet6_option_init(IPV6_HOPOPTS) failed"); return (XORP_ERROR); } + assert(cmsgp); if (inet6_option_append(cmsgp, ra_opt6, 4, 0)) { error_msg = c_format("inet6_option_append(Router Alert) failed"); return (XORP_ERROR); } + assert(cmsgp); + cmsgp = CMSG_NXTHDR(&_sndmh, cmsgp); + assert(cmsgp); #endif // HAVE_IPV6_MULTICAST_ROUTING #endif // ! HAVE_RFC3542 - - cmsgp = CMSG_NXTHDR(&_sndmh, cmsgp); } // -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Fri Jul 18 11:50:09 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 18 Jul 2008 11:50:09 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <4880E4A6.5050408@candelatech.com> References: <487D2383.10408@candelatech.com> <487D300D.3040800@candelatech.com> <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> <4880E4A6.5050408@candelatech.com> Message-ID: <200807181850.m6IIo9wx005623@fruitcake.ICSI.Berkeley.EDU> Ben, Given that we are very close to the 1.5 release, I need to be able to replicate myself the crash (and to verify that the fix takes care of that crash), hence please send me the following info: * OS and kernel version * the top-level config.h that is auto-generated after running ./configure * the XORP config Thanks, Pavlin From greearb at candelatech.com Fri Jul 18 12:14:30 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 18 Jul 2008 12:14:30 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <200807181850.m6IIo9wx005623@fruitcake.ICSI.Berkeley.EDU> References: <487D2383.10408@candelatech.com> <487D300D.3040800@candelatech.com> <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> <4880E4A6.5050408@candelatech.com> <200807181850.m6IIo9wx005623@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4880EB96.6090801@candelatech.com> Pavlin Radoslavov wrote: > Ben, > > Given that we are very close to the 1.5 release, I need to be able > to replicate myself the crash (and to verify that the fix takes care > of that crash), hence please send me the following info: > > * OS and kernel version > * the top-level config.h that is auto-generated after running ./configure > * the XORP config I'm compiling on FC5-32-bit but with kernel headers from FC8 (so that greater than 255 routing tables work, etc). I'm running this on an FC8 system, with patched kernel to support multiple multicast tables and some extra virtual interface support and other assorted hacks. And, xorp is patched fairly extensively as well. What I mean to imply is that it may be impossible for you to reproduce this, but per my explanation below, I think you can verify the bug by code inspection. The config.h is attached. I don't recall the exact config I was using to test this, but it I am pretty sure it had IPv6 OSPF enabled and OSPFv4 enabled. I was enabling multicast as well at some point. (It would have to be sending IPv6 pkts to hit this error case.) However, I think it will take some luck to reproduce this since I believe the reason it happens is that the cmsg struct must have non-zero values in it that are NOT initialized properly when you do two CMSG_NXTHDR calls in a row. I ran this for days before I hit the problem, but of course a customer trying out our beta hit it immediately. If you want to leave this out until after 1.5 that is fine with me, but if you look at the Linux CMSG_NXTHDR implementation (at least on Linux), and if you assume that both the #ifdefs are false in the code I was patching, you can see how this bug can happen. Thanks, Ben > > Thanks, > Pavlin -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: config.h Type: text/x-chdr Size: 25469 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080718/06592b23/attachment.bin From pavlin at ICSI.Berkeley.EDU Fri Jul 18 12:28:58 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 18 Jul 2008 12:28:58 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <4880EB96.6090801@candelatech.com> References: <487D2383.10408@candelatech.com> <487D300D.3040800@candelatech.com> <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> <4880E4A6.5050408@candelatech.com> <200807181850.m6IIo9wx005623@fruitcake.ICSI.Berkeley.EDU> <4880EB96.6090801@candelatech.com> Message-ID: <200807181928.m6IJSwnX011987@fruitcake.ICSI.Berkeley.EDU> Thanks for the detailed info. Now I have enough information to work with. Pavlin From pavlin at ICSI.Berkeley.EDU Fri Jul 18 16:20:40 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 18 Jul 2008 16:20:40 -0700 Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> Pavlin Radoslavov wrote: > > I'm currently digging into BGP and ipv6 multicast routing. Do you happen > > to have an updated user-guide for 1.5? I'll be happy to help proof read > > and debug it for you... Ben, You can get a preliminary version of the new XORP User Manual from http://www.icir.org/pavlin/.private/xorp/user_manual.pdf There might be few more things that will change in the manual before the release, but those probably will be minor. It will be great if you (and anybody else) can provide provide feedback. Thanks, Pavlin From pavlin at ICSI.Berkeley.EDU Fri Jul 18 17:57:08 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 18 Jul 2008 17:57:08 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <200807181928.m6IJSwnX011987@fruitcake.ICSI.Berkeley.EDU> References: <487D2383.10408@candelatech.com> <487D300D.3040800@candelatech.com> <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> <4880E4A6.5050408@candelatech.com> <200807181850.m6IIo9wx005623@fruitcake.ICSI.Berkeley.EDU> <4880EB96.6090801@candelatech.com> <200807181928.m6IJSwnX011987@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200807190057.m6J0v81Z028093@fruitcake.ICSI.Berkeley.EDU> Ben, After looking a bit more carefully into the problem, you are right. The bug is trivial to understand even without trying to replicate it on a running system. I just committed the fix to CVS. Thanks, Pavlin From greearb at candelatech.com Mon Jul 21 17:03:17 2008 From: greearb at candelatech.com (Ben Greear) Date: Mon, 21 Jul 2008 17:03:17 -0700 Subject: [Xorp-hackers] Xorp FEA crash In-Reply-To: <200807190057.m6J0v81Z028093@fruitcake.ICSI.Berkeley.EDU> References: <487D2383.10408@candelatech.com> <487D300D.3040800@candelatech.com> <200807181833.m6IIX8NS003070@fruitcake.ICSI.Berkeley.EDU> <4880E4A6.5050408@candelatech.com> <200807181850.m6IIo9wx005623@fruitcake.ICSI.Berkeley.EDU> <4880EB96.6090801@candelatech.com> <200807181928.m6IJSwnX011987@fruitcake.ICSI.Berkeley.EDU> <200807190057.m6J0v81Z028093@fruitcake.ICSI.Berkeley.EDU> Message-ID: <488523C5.8020200@candelatech.com> Pavlin Radoslavov wrote: > Ben, > > After looking a bit more carefully into the problem, you are right. > The bug is trivial to understand even without trying to replicate it > on a running system. > > I just committed the fix to CVS. Thanks! I'm merging now and will continue testing. -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Jul 21 17:04:36 2008 From: greearb at candelatech.com (Ben Greear) Date: Mon, 21 Jul 2008 17:04:36 -0700 Subject: [Xorp-hackers] Xorp RPMs Message-ID: <48852414.9040405@candelatech.com> Is there any support for generating Xorp RPMs? If not, I'll add something with support for creating the xorp user, xorp group, and install it all in /usr/local/xorp* Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Tue Jul 22 02:29:50 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 10:29:50 +0100 Subject: [Xorp-hackers] Xorp RPMs In-Reply-To: <48852414.9040405@candelatech.com> References: <48852414.9040405@candelatech.com> Message-ID: <4885A88E.4040006@incunabulum.net> Ben Greear wrote: > Is there any support for generating Xorp RPMs? If not, I'll > add something with support for creating the xorp user, xorp group, > and install it all in /usr/local/xorp* > There's some stuff in contrib/packages/ for Debian, but not RPM -- we'd be very happy to take it there once you have a diff ready to go. FreeBSD has a port which currently lives outside the XORP repo. We're finding ourselves making changes before the port is out, so we might end up putting that there too. cheers! BMS From bms at incunabulum.net Tue Jul 22 02:32:46 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 10:32:46 +0100 Subject: [Xorp-hackers] [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <48856A19.3070700@einfochips.com> References: <48856A19.3070700@einfochips.com> Message-ID: <4885A93E.8070902@incunabulum.net> Tushar Mehta wrote: > I am currently facing problem in the XORP regarding IGMPv3 protocol. > I want to check whether XORP router is sending the IGMPv3 report when > you send IGMP General Query without router alert option. > It should not send IGMPv3 report when it get the General Query with > router alert option in the IP header as per the rfc-3376 > In my it is sending the IGMPv3 report. this is the problem i am > getting now. I'm confused by the above. Are you running XORP as a multicast router? Sending a General Query to a IGMPv3 querier or router shouldn't matter. Or are you having problems with XORP as a multicast end-station? > > also when i am sending IGMPv3 report without router alert option XORP > is accepting it and making appropriate entry in multicast routing table. > It should not do that as per rfc-3376 Which OS are you using? That would be a big help -- the processing of IGMPv3 reports is dependent upon raw sockets and that's an OS specific thing. thanks BMS From bms at incunabulum.net Tue Jul 22 02:34:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 10:34:39 +0100 Subject: [Xorp-hackers] [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <48856D06.1090802@einfochips.com> References: <48856D06.1090802@einfochips.com> Message-ID: <4885A9AF.9050203@incunabulum.net> Tushar Mehta wrote: > Can anyone tell me how i can find the Unsolicited Report Interval that > is used when any IGMP host use while transmitting state change record? > > ... > by default Unsolicited Report Interval should be 1 but XORP is not > following it. it is picking up this interval randamly. > The URI is subject to jitter, as are most IGMPv3 protocol timers. It isn't in any of the packets, it sits only in the end station's IP stack. URI is entirely specific to the IGMPv3 host mode implementation. You don't specify which OS is showing this behaviour so it's difficult to give useful feedback here. cheers BMS From kristian at spritelink.net Tue Jul 22 07:15:21 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 22 Jul 2008 16:15:21 +0200 Subject: [Xorp-hackers] OSPF[46]... Message-ID: <20080722141521.GA58197@spritelink.se> Dear hackers, I would like to raise the question on names and syntax regarding IPv4 vs IPv6 in xorpsh. As it stands today, many of the commands use a postfix of either 4 or 6 to denote which address-family they belong to. In the case of OSPFv2 and OSPFv3 it maps in nicely, since OSPFv2 only does IPv4 and OSPFv3 only does IPv6. OSPFv3 have the ability, thanks to a TLV based format, to support IPv4 as well. If that would be the case, what would be your way to proceed? Looking at IS-IS, for which development will hopefully begin soon, what syntax will be used for IS-IS as it can handle both IPv4 and IPv6? Will isis4 be used for commands regarding v4 and isis6 for v6? Looking at IOS there's an address-family command for IS-IS and for ospf it's called 'router ospf' and 'ipv6 router ospf'. Now, IOS was invented in a time when IPv6 and thus OSPFv3 wasn't around. If we instead take a look at the two dominating router OSes that were designed recently enough for v6 to exist (XR and JUNOS) they both aptly name it 'ospf' and 'ospfv3'. The [46] notation fits in perfectly for the fea or plumbing parts but when used for ospf or some other protocol it tries to imply limits that's not really there. Abstracting away routing protocols is not something network administrators appreciates. Principle of least astonishment is pretty clear on this I believe. People used to XORP expect ospf[46] while everyone else coming from some platform not being XORP would expect (ospf[v3]). As XORPs user base is rather limited (btw, does anyone have any figures?), I think it's clear that ospf[v3] is the way to go, especially as it eases transition from other platforms. An easy transition path would be to add an alias for ospf4 to ospf and likewise for ospf6 to ospfv3, possibly adding a warning that ospf[46] is deprecated somewhere in the CLI. What's your take on this? Kind regards, Kristian. PS. I realized I dug real deep into the ospf[46] thing here while I really wanted to bring up the general question of separating routing protocols this way into address-families. It would apply to ISIS, OLSR or some other protocol as well... DS. -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From bms at incunabulum.net Tue Jul 22 08:21:08 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 16:21:08 +0100 Subject: [Xorp-hackers] OSPF[46]... In-Reply-To: <20080722141521.GA58197@spritelink.se> References: <20080722141521.GA58197@spritelink.se> Message-ID: <4885FAE4.5090304@incunabulum.net> Kristian Larsson wrote: > What's your take on this? > It's easy to draw boxes around things and paint them different colours. Some people call this art. Abstraction is not implementation. We're talking about a code delta which is relatively large compared to asking people to adapt a little to get their IP routing thing for potentially less money. At the moment, "it ain't broke", so let's just leave it for now, IMO. thanks BMS From pavlin at ICSI.Berkeley.EDU Tue Jul 22 09:56:45 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 09:56:45 -0700 Subject: [Xorp-hackers] Xorp RPMs In-Reply-To: <4885A88E.4040006@incunabulum.net> References: <48852414.9040405@candelatech.com> <4885A88E.4040006@incunabulum.net> Message-ID: <200807221656.m6MGujiL024888@fruitcake.ICSI.Berkeley.EDU> Bruce M Simpson wrote: > Ben Greear wrote: > > Is there any support for generating Xorp RPMs? If not, I'll > > add something with support for creating the xorp user, xorp group, > > and install it all in /usr/local/xorp* > > > > There's some stuff in contrib/packages/ for Debian, but not RPM -- we'd > be very happy to take it there once you have a diff ready to go. It appears there are XORP RPM packages for earlier release, though I haven't tried them: http://dag.wieers.com/rpm/packages/xorp/ You might want to coordinate with the author/maintainer of those packages so at the end we converge on a single solution. Pavlin From kristian at spritelink.net Tue Jul 22 10:52:49 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 22 Jul 2008 19:52:49 +0200 Subject: [Xorp-hackers] [Xorp-users] Announcing XORP Release Candidate 1.5 In-Reply-To: <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> Message-ID: <20080722175249.GB58197@spritelink.se> On Fri, Jul 18, 2008 at 04:20:40PM -0700, Pavlin Radoslavov wrote: > Pavlin Radoslavov wrote: > > > > I'm currently digging into BGP and ipv6 multicast routing. Do you happen > > > to have an updated user-guide for 1.5? I'll be happy to help proof read > > > and debug it for you... > > Ben, > > You can get a preliminary version of the new XORP User Manual from > http://www.icir.org/pavlin/.private/xorp/user_manual.pdf > > There might be few more things that will change in the manual before > the release, but those probably will be minor. > > It will be great if you (and anybody else) can provide provide > feedback. Having only read through half of the manual, these are my current nitpickings... ;) In the definitions section.. EGP is not only a term covering, basically only, BGP but it is also a protocol of it's own. Would be nice if that was reflected in the manual. You write 'an user' throughout the paper while I believe that 'a user' would be the correct article. I bring forth evidence A ;) http://www.googlefight.com/index.php?lang=en_GB&word1=%22a+user%22&word2=%22an+user%22 For those seeking an explanation I found the following two pages excellent: http://en.allexperts.com/q/English-Second-Language-1815/vs.htm http://owl.english.purdue.edu/handouts/esl/esliart.html Now given that English is not my native tongue I might be wrong.. In the OSPF section I would like to change the router-id part, as it's not an IPv4 address, it's rather just an 4 byte ID usually displayed in dotted quad notation. "The smallest IP address of an interface belonging to the router is a good choice." An address belonging to a loopback is probably a better choice if available and I think 'lowest' instead of 'smallest' is more correct, no? page 57, source->vif section: "The value mist be" should probably be "The value must be", same thing in vif section. page 61 "packets and then forwards then from one" ==> "packets and then forwards _them_ from one" I'll continue reading when I get home :) Kind regards, Kristian. -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From pavlin at ICSI.Berkeley.EDU Tue Jul 22 11:56:52 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 11:56:52 -0700 Subject: [Xorp-hackers] [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <48856A19.3070700@einfochips.com> References: <48856A19.3070700@einfochips.com> Message-ID: <200807221857.m6MIuqct015648@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > I am currently facing problem in the XORP regarding IGMPv3 protocol. > I want to check whether XORP router is sending the IGMPv3 report when you send > IGMP General Query without router alert option. > It should not send IGMPv3 report when it get the General Query with router > alert option in the IP header as per the rfc-3376 > In my it is sending the IGMPv3 report. this is the problem i am getting now. XORP implements only the router-side of IGMP/MLD. The IGMPv3 reports generated by the router running XORP are actually generated by the kernel. Hence, this issue is related to the particular OS/kernel you are running. > also when i am sending IGMPv3 report without router alert option XORP is > accepting it and making appropriate entry in multicast routing table. > It should not do that as per rfc-3376 In XORP there is an IGMP/MLD configuration flag regarding this: protocols { igmp { interface eth0 { vif eth0 { enable-ip-router-alert-option-check: true ... } } ... } } The default value for the flag is false. If you set it to true, the XORP router-side implementation will drop all IGMP/MLD messages that don't have the Router Alert option set. FYI, the reasoning for the default value being "false" is to be able to work out-of-the-box with earlier IGMP implementations that don't use Router Alert. It looks like you have set the value to true in your config so it should work and you should just see warning messages like: "RX ...: missing IP Router Alert option" What XORP version are you using? Please try the latest code from CVS (or the XORP-1.5-RC) and see whether you still have the problem. Pavlin > so where is the problem lies. > here i am sending the configuration file that i am using for my setup. > > -- > _____________________________________________________________________ > Disclaimer: This e-mail message and all attachments transmitted with it > are intended solely for the use of the addressee and may contain legally > privileged and confidential information. If the reader of this message > is not the intended recipient, or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution, copying, or other use of > this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any > views expressed in this message are those of the individual sender > unless otherwise stated.Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > _____________________________________________________________________ > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "ethernet interface" > disable: false > default-system-config > } > /* interface eth1 { > description: "ethernet interface" > disable: false > default-system-config > }*/ > } > > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > > policy { > /* Describe connected routes for redistribution */ > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > policy { > /* Describe static routes for redistribution */ > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > /* interface eth1 { > vif eth1 { > disable: false > } > }*/ > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 5 > query-last-member-interval: 5 > query-response-interval: 2 > robust-count: 5 > } > } > /* interface eth1 { > vif eth1 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 10 > query-last-member-interval: 5 > query-response-interval: 10 > robust-count: 3 > } > }*/ > traceoptions { > flag all { > disable: false > } > } > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Tue Jul 22 12:08:28 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 12:08:28 -0700 Subject: [Xorp-hackers] [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <48856D06.1090802@einfochips.com> References: <48856D06.1090802@einfochips.com> Message-ID: <200807221909.m6MJ8S45017553@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > Can anyone tell me how i can find the Unsolicited Report Interval that > is used when any IGMP host use while transmitting state change record? > > according to the rfc-3376: > - To cover the possibility of the State-Change Report being missed by > one or more multicast routers, it is retransmitted [Robustness > Variable] - 1 more times, at intervals chosen at random from the range > (0, [Unsolicited Report Interval]). > > - Unsolicited Report Interval > The Unsolicited Report Interval is the time between repetitions of a > host's initial report of membership in a group. Default: 1 second. > > by default Unsolicited Report Interval should be 1 but XORP is not > following it. it is picking up this interval randamly. As Bruce mentioned in another email on the subject, this is kernel-related config. To clarify: IGMP/MLD has two parts: router-side and host-side. The host-side is typically implemented by the OS (in the kernel). The router-side is typically an userland process. XORP implements only the router-side, and for the host-side relies on the kernel implementation. The configuration changes in XORP apply only to the router side; the host-side configuration changes are OS specific and you should refer to the particular OS/kernel documentation for that. In the future we might expose the host-side configuration in the xorpsh, but right now this is a very low priority for us. Hope that helps, Pavlin > i m attaching the configuration file that i am using for my set up. > > > -- > _____________________________________________________________________ > Disclaimer: This e-mail message and all attachments transmitted with it > are intended solely for the use of the addressee and may contain legally > privileged and confidential information. If the reader of this message > is not the intended recipient, or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution, copying, or other use of > this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any > views expressed in this message are those of the individual sender > unless otherwise stated.Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > _____________________________________________________________________ > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian at spritelink.net Tue Jul 22 14:56:06 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 22 Jul 2008 23:56:06 +0200 Subject: [Xorp-hackers] OSPF[46]... In-Reply-To: <4885FAE4.5090304@incunabulum.net> References: <20080722141521.GA58197@spritelink.se> <4885FAE4.5090304@incunabulum.net> Message-ID: <20080722215605.GC58197@spritelink.se> On Tue, Jul 22, 2008 at 04:21:08PM +0100, Bruce M Simpson wrote: > We're talking about a code delta which is relatively large compared to > asking people to adapt a little to get their IP routing thing for > potentially less money. A code delta which is very easy to produce with sed and friends. Though you are kind of missing my point... > At the moment, "it ain't broke", so let's just leave it for now, IMO. I work in the Internet service provider business and have done so for the last couple of years. I spend roughly half my day staring at an IOS prompt and I know a great deal of people just like me. What I don't know, is someone using XORP. A lot of people have heard about it and many have tried it out but rejected it for some reason. Now, I don't only stare at this IOS prompt for a living, I'm also quite interested in it on a personal level and spend a considerable amount of my free time tinkering with network stuff. Although my budget is nowhere near that of my employer I have managed to gather a quite nice pile of equipment ranging from GSRs to M5s. Over time I have learn that GSRs consume a shitload of electricity and puts out an almost equal amount of heat not to mention the space they occupy - and finding fast interface for a Juniper is a bi***. This is where I imagine XORP and other routing suites would step in. A lot of people pursue the open-source-routing-suite-path for slightly different reasons than I but I believe the reasons for not choosing XORP are the same. More on that in a bit... What I would like is of course to find an open and extensible router platform to suit my needs. When I was unable to do so, I instead looked at what would be the closest match and try improve on that. Et voila... XORP! The ambition of course being to help XORP into world domination. Not being a programmer has proven to be somewhat of an obstacle - I've spent countless hours going through XORP code and eventually just giving up on whatever I had set out to do. Coding isn't my ballgame, so what can I do to help? Well, I know what I like about routers and I know what I don't like, perhaps sharing this could help the project gain some acceptance amongst other networkers like me. Hasso Tepper wrote an excellent piece http://hasso.linux.ee/doku.php/english:network:xorpsucks I'm just going to give a +1 on the whole thing. The lack of support for recursing routes and with it the absolutely silly side-effect of having to specify next-hop for your BGP neighbors make the BGP module close to worthless for iBGP relations. No templating or even per-peer policies is hilarious, how do you expect anyone to be able to use this in a real network? I have routers with hundreds of peers, keeping one policy for all those up to date would be close to impossible. At least so difficult I don't even want to think about trying. As Hasso mentions the CLI displays things in an awful manner. No leaf-nodes without value or the mandatory {} for all branch-nodes makes it painful just to look at the configuration. The only thing that I can come up with from the top of my head that I would list as a nice feature is the marking of new lines (">") in the config. .. well, then you have the multicast protocols as well, but XORP doesn't have much competition amongst the open source alternatives in that area. Competing against commercial vendors we are down to the ">"-marking part. I got carried away a bit, returning to the [46] thingy... If we go back to when this was implemented, why was ospf4 and ospf6 chosen in the first place? Why wasn't the already familiar ospf[v3] nomenclature chosen? Why have a Junos-similar shell but deviate for no apparent reason? I've hardly seen a discussion on a list _before_ the name for something was chosen, rather the implementor chooses something and then it sticks. For this reason I would like to know the plan for future "stuff" and maybe even have a saying in it. I would be sad to see another deviation from what is the de facto syntax out there. It makes networking kind of guys dislike the software and that is probably the worst thing for an open source routing suite. It has been argued before that the user base of XORP is familiar with X and changing X would create a disturbance and thus it is left as is. Does XORP have an active user base (more than the handful of people on this list) ? For how many people would changing something become a nuisance? Why not try to adhere to what people are used to and try to get the basic stuff like CLI and BGP to work before implementing fancy stuff like firewall rules? Not that the latter is a bad thing, I'd just like to see a different prioritization here. Kind regards, Kristian. PS. I'm still impressed by XORPs architecture (creds for that) though that doesn't change the fact that I as a network engineer hate to use it. DS. -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From pavlin at ICSI.Berkeley.EDU Tue Jul 22 15:35:13 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 15:35:13 -0700 Subject: [Xorp-hackers] [Xorp-users] Announcing XORP Release Candidate 1.5 In-Reply-To: <20080722175249.GB58197@spritelink.se> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> <20080722175249.GB58197@spritelink.se> Message-ID: <200807222235.m6MMZDbg020884@fruitcake.ICSI.Berkeley.EDU> Thanks for the feedbacks. Reply below. Kristian Larsson wrote: > Having only read through half of the manual, these > are my current nitpickings... ;) > > In the definitions section.. > EGP is not only a term covering, basically only, > BGP but it is also a protocol of it's own. Would > be nice if that was reflected in the manual. EGP (the protocol) is considered obsolete, and probably the set of people who know about it will know the difference :) Anyway, I just added a footnote to clarify that. > You write 'an user' throughout the paper while I > believe that 'a user' would be the correct > article. I bring forth evidence A ;) > http://www.googlefight.com/index.php?lang=en_GB&word1=%22a+user%22&word2=%22an+user%22 > For those seeking an explanation I found the > following two pages excellent: > http://en.allexperts.com/q/English-Second-Language-1815/vs.htm > http://owl.english.purdue.edu/handouts/esl/esliart.html > Now given that English is not my native > tongue I might be wrong.. I will leave this to the native English speakers :) > In the OSPF section I would like to change the > router-id part, as it's not an IPv4 address, it's > rather just an 4 byte ID usually displayed in > dotted quad notation. > "The smallest IP address of an interface belonging > to the router is a good choice." > An address belonging to a loopback is probably a > better choice if available and I think 'lowest' > instead of 'smallest' is more correct, no? Technically, I think you are correct about the 4 byte ID. My preference for the smallest vs lowest would be to say "the numerically smallest IP address". In any case I will leave the OSPF editing to the OSPF folks. > page 57, source->vif section: > "The value mist be" should probably be "The value > must be", same thing in vif section. Both fixed. > page 61 > "packets and then forwards then from one" ==> > "packets and then forwards _them_ from one" Fixed. Thanks, Pavlin > I'll continue reading when I get home :) > > Kind regards, > Kristian. > > > -- > Kristian Larsson KLL-RIPE > Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] > +46 704 910401 kll at spritelink.net > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From bms at incunabulum.net Wed Jul 23 07:10:45 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 23 Jul 2008 15:10:45 +0100 Subject: [Xorp-hackers] OSPF[46]... In-Reply-To: <20080722215605.GC58197@spritelink.se> References: <20080722141521.GA58197@spritelink.se> <4885FAE4.5090304@incunabulum.net> <20080722215605.GC58197@spritelink.se> Message-ID: <48873BE5.1050801@incunabulum.net> Kristian, I understand your frustration, but, well, it boils down to the same thing in any sphere of human endeavour -- those who do things, invariably end up steering where those things go, and there's no substitute for rolling one's sleeves up and getting involved. Kristian Larsson wrote: > The ambition of course being to help XORP into > world domination. Not being a programmer has > proven to be somewhat of an obstacle - I've spent > countless hours going through XORP code and > eventually just giving up on whatever I had set > out to do. Coding isn't my ballgame, so what can I > do to help? > I've been working on a means to build XORP processes (of any kind) in Python. Trouble is, I don't have a lot of free time to work on it, although the idea is pretty clear -- make it possible for people to script things more readily in a language which is hopefully more accessible. Maybe that will help? cheers BMS From atanu at ICSI.Berkeley.EDU Wed Jul 23 08:42:32 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 23 Jul 2008 08:42:32 -0700 Subject: [Xorp-hackers] Announcing XORP Release 1.5 Message-ID: <81050.1216827752@tigger.icir.org> Today is a big day for XORP. First off, we're announcing the XORP 1.5 Release and would like to extend our sincere thanks to the contributors and other community members who helped make it happen. We hope you'll visit our site (http://xorp.org), download our code, play with it, challenge it, build on it, extend it ... And, most importantly, send us feedback about your experience and what you'd like to see in XORP and do with XORP going forward. We're also announcing today the formation of XORP, Inc. (http://xorp.net), a startup founded by the leaders of the XORP.org project, funded by two top-tier VC's, Onset Ventures and Highland Capital Partners, and led by network industry veteran and seasoned entrepreneur, Vivek Ragavan. XORP, Inc. is committed both to supporting the XORP.org community and code base and to building a successful open source business. XORP 1.5 is the first community release to be made under the auspices of XORP, Inc. and we will continue to release community versions of XORP on a regular basis. You'll hear more about XORP, Inc.'s product plans in the months to come. Finally, we want to thank the International Computer Science Institute (ICSI) in Berkeley, CA which until now has hosted the XORP.org project and housed the core team of developers. ICSI's support, together with that of XORP.org's industrial and government sponsors, has been essential in making this a big day. --The XORP Team P.S. Release notes are included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.5 (2008/07/22) ======================== ALL: - XORP now builds on DragonFlyBSD-1.10.1, DragonFlyBSD-1.12.2, FreeBSD-7.0, Linux Debian-4.0 (etch), Linux Fedora 7, Linux Fedora 8, Linux Fedora 9, Linux Gentoo 2008.0, Linux Ubuntu-7.04, Linux Ubuntu-7.10, Linux Ubuntu-8.04.1, NetBSD-4.0, OpenBSD-4.1, OpenBSD-4.2, OpenBSD-4.3, Mac OS X 10.5.2, Mac OS 10.5.3, and Mac OS X 10.5.4. CONFIGURATION: - Addition of new FEA configuration statements to set the IPv4/IPv6 unicast forwarding table IDs: fea { unicast-forwarding4 { table-id: 254 } unicast-forwarding6 { table-id: 254 } } If the table ID is not configured, the FEA will use the default table ID for the system. Note that not all systems support multiple forwarding tables. Currently, they exist only on Linux (among all systems supported by XORP). - The "DISCARD" network interface flag is printed as appropriate when displaying the list of interfaces in the CLI. - Addition of new FEA configuration statement to support "unreachable" interfaces. Such interfaces are similar to "discard" interfaces, except that instead of silently throwing away packets, the system will respond with "ICMP destination unreachable". interfaces { interface my_unreachable { unreachable: true vif my_unreachable { } } } The default value for the "unreachable" statement is false. - Addition of new FEA configuration statement to flag an interface for "management" purpose. An interface that is flagged as "management" might be used in the future by some of the protocols for protocol-specific purpose. interfaces { interface fxp0 { management: true vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } } } The default value for the "management" statement is false. - Addition of support to configure VLANs on an interface. A VLAN is configured by using a "vlan" block that includes the VLAN ID: interfaces { interface fxp0 { vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } vif vlan1 { vlan { vlan-id: 1 } address 10.10.20.20 { prefix-length: 24 } } } } - Addition of preliminary support to configure firewall rules. Firewall rules are configured by using numbered entries: firewall { rule4 100 { action: "drop" protocol: 6 /* TCP */ source { interface: "fxp0" vif: "fxp0" network: 0.0.0.0/0 port-begin: 0 port-end: 65535 } destination { network: 10.10.0.0/24 port-begin: 0 port-end: 1024 } } } Note that compiling firewall support on Linux systems require patching some of the system header files. See ERRATA for details. - The following PIM-SM configuration statements have been deprecated, because PIM-SM doesn't use Router Alert IP option anymore: protocols { pimsm4 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } protocols { pimsm6 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } LIBXORP: - The local system-independent xorp_random() implemenation is used instead of the random(3) provided by the system. - Improved MAC address support (classes Mac and EtherMac). - More consistent usage of XORP_OK and XORP_ERROR to return error codes. LIBXIPC: - Bug fix in the internal mechanism for obtaining the IPv4 addresses from the system. After the bug fix, a secondary (alias) IP address can be specified with the "-i " command-line option to the xorp_rtrmgr or xorp_finder binaries. LIBFEACLIENT: - No significant changes. XRL: - Critical bug fix that can be triggered by malformatted XRLs. - Addition of support for 64-bit integers: i64 and u64 for signed and unsigned respectively. RTRMGR: - Addition of preliminary mechanism to log events to a file or to a syslog facility. - Addition of support to run XORP in background (in daemon mode). XORPSH: - Bug fix related to assigning the node ID position in case the previous (sibling) node was deleted at the same time a new node was added. This fixes "Found out-of-order term(s) inside policy ..." error inside the policy manager. - The "-c " command line option can be used more than once to run multiple commands. - Fix a long configuration delay when using xorpsh in non-interactive mode (e.g., "cat commands.txt | xorpsh"). - Addition of a new "-e" command line option. It can be used to tell xorpsh to exit immediately if the connection to the Finder fails. POLICY: - No significant changes. FEA/MFEA: - Major refactoring of the FEA/MFEA internals. - Critical bug fix that affects recent NetBSD and OpenBSD releases. - Critical IPv6-related bug fix when adding unicast forwarding entries to the kernel. This bug was exposed only on *BSD systems with 64-bit CPU. - If MFEA is started, it will explicitly enable the multicast forwarding flags that have been added to recent OpenBSD releases: net.inet.ip.mforwarding (for OpenBSD-3.9 and later) and net.inet6.ip6.mforwarding (for OpenBSD-4.0 and later). RIB: - No significant changes. RIP/RIPng: - Addition of support for "show ripng" xorpsh operational commands. - Critical RIPng-related bug fix. Previously the RIPng installed routes had incorrect outgoing interface toward the destination. - Bug fix related to the TTL for RIPng multicast packets: now it is set to 255 as specified in the protocol specification (RFC 2080) instead of 1. OLSR: - Added support for RFC 3626 Optimized Link State Routing Protocol. This is a fully fledged XORP routing process with policy route redistribution capability. The work was generously funded over 2007/2008 by CenGen, Inc. OSPF: - Bug fix related to OSPFv3 link-local scope LSAs. Previously the link-local scope LSAs were incorrectly flooded to links other than the one they belonged to. - Bug fix related to OSPFv3 Inter-Area-Prefix-LSAs. The check for the minimum size of an Inter-Area-Prefix-LSA was incorrect so short prefixes such as the default route would be rejected. - Added a clear database command. - In the OSPFv2 configuration "passive" is no longer a bool but a directive. Previously setting an interface to passive would set the interface to loopback and announce a host route for the interface. Using the passive keyword will still set the interface to loopback but now the network will be announced. If the previous behaviour of of announcing the host route is required the host variable can be set to true. BGP: - Added support for 4-byte AS numbers, as detailed in RFC 4893. From 1st Jan 2009 4-byte AS numbers will be allocated by default by RIPE, so it is desirable that all BGP implementations support four-byte AS numbers by that time. Currently 4-byte support is not enabled in XORP by default, but can be enabled using the "enable-4byte-as-numbers" configuration option. STATIC_ROUTES: - Bug fix that prevented the deletion of interface-specific routes using xorpsh. MLD/IGMP: - No significant changes. MLD/IGMP-Lite: - An implementation of Lightweight IGMP/MLD is available in directory ${XORP}/contrib/mld6igmp_lite. It can be used instead of the existing MLD/IGMP vanilla implementation by using the following command before compiling XORP: ./configure --with-mld6igmp_lite PIM-SM: - No significant changes. FIB2MRIB: - No significant changes. CLI: - No significant changes. SNMP: - No significant changes. From greearb at candelatech.com Wed Jul 23 13:15:28 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 23 Jul 2008 13:15:28 -0700 Subject: [Xorp-hackers] Minor xorpsh bugs Message-ID: <48879160.3000303@candelatech.com> I believe xorpsh -e does not work: [root at lanforge-D0-20 bin]# ./xorpsh -e created new heap in find_heap, ptr: 0x8254210 [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused .... I would expect it to abort immediately. Also, xorpsh -h exits with error code 1 instead of zero. This matters because I'm trying to run an automated test to see if xorp can start (ie, libraries are all configured right, etc). [root at lanforge-D0-20 bin]# ./xorpsh -h Usage: xorpsh [options] Options: -c Specify command(s) to execute -e Exit immediately if cannot connect to the rtrmgr -h Display this information -v Print verbose information -t Specify templates directory -x Specify Xrl targets directory Defaults: Templates directory := /usr/local/xorp/etc/templates Xrl targets directory := /usr/local/xorp/xrl/targets Print verbose information := false [root at lanforge-D0-20 bin]# echo $? 1 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Jul 23 13:47:04 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 23 Jul 2008 13:47:04 -0700 Subject: [Xorp-hackers] Minor xorpsh bugs In-Reply-To: <48879160.3000303@candelatech.com> References: <48879160.3000303@candelatech.com> Message-ID: <488798C8.30704@candelatech.com> Ben Greear wrote: > I believe xorpsh -e does not work: > > [root at lanforge-D0-20 bin]# ./xorpsh -e > created new heap in find_heap, ptr: 0x8254210 > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > .... > > I would expect it to abort immediately. > > Also, xorpsh -h exits with error code 1 instead of zero. > > This matters because I'm trying to run an automated test to > see if xorp can start (ie, libraries are all configured right, etc). > > [root at lanforge-D0-20 bin]# ./xorpsh -h > Usage: xorpsh [options] > Options: > -c Specify command(s) to execute > -e Exit immediately if cannot connect to the rtrmgr > -h Display this information > -v Print verbose information > -t Specify templates directory > -x Specify Xrl targets directory > Defaults: > Templates directory := /usr/local/xorp/etc/templates > Xrl targets directory := /usr/local/xorp/xrl/targets > Print verbose information := false > [root at lanforge-D0-20 bin]# echo $? > 1 Here's the trivial patch for this one: diff --git a/rtrmgr/xorpsh_main.cc b/rtrmgr/xorpsh_main.cc index ce9407c..582e5cf 100644 --- a/rtrmgr/xorpsh_main.cc +++ b/rtrmgr/xorpsh_main.cc @@ -877,7 +877,7 @@ main(int argc, char *argv[]) case 'h': usage(argv[0]); display_defaults(); - errcode = 1; + errcode = 0; goto cleanup; } } > > > Thanks, > Ben > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Jul 23 13:53:19 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 23 Jul 2008 13:53:19 -0700 Subject: [Xorp-hackers] Xorp RPMs In-Reply-To: <200807221656.m6MGujiL024888@fruitcake.ICSI.Berkeley.EDU> References: <48852414.9040405@candelatech.com> <4885A88E.4040006@incunabulum.net> <200807221656.m6MGujiL024888@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48879A3F.2090900@candelatech.com> Pavlin Radoslavov wrote: > Bruce M Simpson wrote: > >> Ben Greear wrote: >>> Is there any support for generating Xorp RPMs? If not, I'll >>> add something with support for creating the xorp user, xorp group, >>> and install it all in /usr/local/xorp* >>> >> There's some stuff in contrib/packages/ for Debian, but not RPM -- we'd >> be very happy to take it there once you have a diff ready to go. > > It appears there are XORP RPM packages for earlier release, though I > haven't tried them: > > http://dag.wieers.com/rpm/packages/xorp/ > > You might want to coordinate with the author/maintainer of those > packages so at the end we converge on a single solution. After some more thinking, I decided to just do a simple install script. RPMs seem to prefer working from source and seems like more overhead than justified for what I need. Here's a script that adds the xorp user, sets up the groups correctly, and fixes (hacks) a library linkage so that xorp compiled on fc5 works on at least fc5 and fc8.... Feel free to use this as you wish. Firt, the script to package it up after the make_install: #!/bin/bash # Script for packaging up a stripped xorp tarball. make install cp xorp_install.bash /usr/local/xorp/ chmod a+x /usr/local/xorp/xorp_install.bash cd /usr/local if [ "$1_" != "nostrip" ] then find xorp -name "*" -print|xargs strip fi tar -cvzf /tmp/xorp.tgz xorp cd - And the install script, called xorp_install.bash #!/bin/bash # Xorp should be un-tarred in /usr/local if [ `pwd` != "/usr/local/xorp" ] then echo "ERROR: You must un-tar xorp.tgz in /usr/local so that the files are placed in /usr/local/xorp" exit 1 fi # Add xorp user and group echo "Creating xorp user and adding xorp to xorp and root groups..." adduser xorp usermod -a -G xorp xorp usermod -a -G root xorp # I compile xorp on FC5, and it has a hard dependency on libpcap.0.9.4 and libcrypto.so.6 # Fake out the link here so that it will start OK. This works on Ubuntu 8.0.4 & FC8, no idea # if it will work elsewhere. --Ben if [ ! -f /usr/lib/libpcap.so.0.9.4 ] then echo "Attempting to soft-link /usr/lib/libpcap.so.9.4 to a similar library...." ln -s /usr/lib/libpcap.so.0.9.* /usr/lib/libpcap.so.0.9.4 fi # This is required on Ubunto 8.0.4, but no needed on Fedora, so # commenting this out. --Ben #if [ ! -f /usr/lib/libcrypto.so.6 ] # then # echo "Attempting to soft-link /usr/lib/libcrypto.so.6 to a similar library...." # ln -s /usr/lib/libcrypto.so.0.9.* /usr/lib/libcrypto.so.6 #fi echo "Completed installation setup for Xorp, testing library linkage...." if /usr/local/xorp/bin/xorpsh -h > /dev/null 2>&1 then echo "Seems to work fine..." else echo "ERROR: xorpsh returned error code. Please contact support." fi Thanks, Ben > > Pavlin -- Ben Greear Candela Technologies Inc http://www.candelatech.com From steweg at ynet.sk Wed Jul 23 16:26:39 2008 From: steweg at ynet.sk (=?ISO-8859-2?Q?=A9tefan_Gula?=) Date: Thu, 24 Jul 2008 01:26:39 +0200 Subject: [Xorp-hackers] Broken startup Message-ID: Hi folks, I tried new release of XORP-1.5. But unfortunately I am unable to start xorp with all required modules (ospf, bgp....). The startup log looks like this: [ 2008/07/24 01:09:56 INFO xorp_rtrmgr:21039 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, firewall, fea, rib, fib2mrib, policy, static_routes, bgp, ospf4 [ 2008/07/24 01:09:56 INFO xorp_rtrmgr:21039 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2008/07/24 01:09:57 INFO xorp_fea MFEA ] MFEA enabled [ 2008/07/24 01:09:57 INFO xorp_fea MFEA ] CLI enabled [ 2008/07/24 01:09:57 INFO xorp_fea MFEA ] CLI started [ 2008/07/24 01:09:57 INFO xorp_fea MFEA ] MFEA enabled [ 2008/07/24 01:09:57 INFO xorp_fea MFEA ] CLI enabled [ 2008/07/24 01:09:57 INFO xorp_fea MFEA ] CLI started ] Executing module: rib (rib/xorp_rib) [ 2008/07/24 01:10:10 INFO xorp_rtrmgr:21039 RTRMGR +96 module_manager.cc execute ] Executing module: fib2mrib (fib2mrib/xorp_fib2mrib) [ 2008/07/24 01:10:12 INFO xorp_rtrmgr:21039 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy) [ 2008/07/24 01:10:14 INFO xorp_rtrmgr:21039 RTRMGR +96 module_manager.cc execute ] Executing module: static_routes (static_routes/xorp_static_routes) [ 2008/07/24 01:10:16 INFO xorp_rtrmgr:21039 RTRMGR +96 module_manager.cc execute ] Executing module: bgp (bgp/xorp_bgp) [ 2008/07/24 01:10:18 TRACE xorp_bgp BGP ] policy filter: 4 [ 2008/07/24 01:10:18 TRACE xorp_bgp BGP ] policy filter: 2 [ 2008/07/24 01:10:18 TRACE xorp_bgp BGP ] policy filter: 1 The problematic section is BGP where I try to turn on traceoptions for better debugging but I didn't find anything that could point me to some kind of misconfiguration. When I remove bgp section from configuration file xorp starts normally. So first I thought that the problem is in configuration so I tried to configure it one more time through xorpsh. This procedure was successful and I get what I needed, but when I saved new configuration and restart my xorp I was at the beginning because it hangs during the startup of BGP section. Can anybody please point to right direction where is the problem? I can also provide my configuration files if needed but I think this is general problem with startup procedure of xorp-1.5 because my configuration files works fine with xorp-1.4. Thanks a lot. -- Stefan Gula, CCNP From pavlin at ICSI.Berkeley.EDU Thu Jul 24 00:01:34 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 24 Jul 2008 00:01:34 -0700 Subject: [Xorp-hackers] Minor xorpsh bugs In-Reply-To: <488798C8.30704@candelatech.com> References: <48879160.3000303@candelatech.com> <488798C8.30704@candelatech.com> Message-ID: <200807240701.m6O71YZp025191@fruitcake.ICSI.Berkeley.EDU> Ben, Thank you for the patch. I just committed it to CVS. Regarding "xorpsh -e" it appears a bug, hence please submit a Bugzilla entry. Pavlin Ben Greear wrote: > Ben Greear wrote: > > I believe xorpsh -e does not work: > > > > [root at lanforge-D0-20 bin]# ./xorpsh -e > > created new heap in find_heap, ptr: 0x8254210 > > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > > .... > > > > I would expect it to abort immediately. > > > > Also, xorpsh -h exits with error code 1 instead of zero. > > > > This matters because I'm trying to run an automated test to > > see if xorp can start (ie, libraries are all configured right, etc). > > > > [root at lanforge-D0-20 bin]# ./xorpsh -h > > Usage: xorpsh [options] > > Options: > > -c Specify command(s) to execute > > -e Exit immediately if cannot connect to the rtrmgr > > -h Display this information > > -v Print verbose information > > -t Specify templates directory > > -x Specify Xrl targets directory > > Defaults: > > Templates directory := /usr/local/xorp/etc/templates > > Xrl targets directory := /usr/local/xorp/xrl/targets > > Print verbose information := false > > [root at lanforge-D0-20 bin]# echo $? > > 1 > > Here's the trivial patch for this one: > > diff --git a/rtrmgr/xorpsh_main.cc b/rtrmgr/xorpsh_main.cc > index ce9407c..582e5cf 100644 > --- a/rtrmgr/xorpsh_main.cc > +++ b/rtrmgr/xorpsh_main.cc > @@ -877,7 +877,7 @@ main(int argc, char *argv[]) > case 'h': > usage(argv[0]); > display_defaults(); > - errcode = 1; > + errcode = 0; > goto cleanup; > } > } > > > > > > > > Thanks, > > Ben > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > 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 Jul 24 00:12:08 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 24 Jul 2008 00:12:08 -0700 Subject: [Xorp-hackers] Xorp RPMs In-Reply-To: <48879A3F.2090900@candelatech.com> References: <48852414.9040405@candelatech.com> <4885A88E.4040006@incunabulum.net> <200807221656.m6MGujiL024888@fruitcake.ICSI.Berkeley.EDU> <48879A3F.2090900@candelatech.com> Message-ID: <200807240712.m6O7C87g026566@fruitcake.ICSI.Berkeley.EDU> > Here's a script that adds the xorp user, sets up the groups > correctly, and fixes (hacks) a library linkage so that xorp compiled > on fc5 works on at least fc5 and fc8.... Can you confirm that the library linkage hack is actually needed for the latest 1.5 code? For example, the configure mechanism will test for various things (incl. whether libpcap is installed), and libpcap will be actually used only if it is available. The same applies for libcrypto. Pavlin > Feel free to use this as you wish. > > > Firt, the script to package it up after the make_install: > > #!/bin/bash > # Script for packaging up a stripped xorp tarball. > > make install > cp xorp_install.bash /usr/local/xorp/ > chmod a+x /usr/local/xorp/xorp_install.bash > > cd /usr/local > if [ "$1_" != "nostrip" ] > then > find xorp -name "*" -print|xargs strip > fi > tar -cvzf /tmp/xorp.tgz xorp > cd - > > > And the install script, called xorp_install.bash > > > #!/bin/bash > > # Xorp should be un-tarred in /usr/local > if [ `pwd` != "/usr/local/xorp" ] > then > echo "ERROR: You must un-tar xorp.tgz in /usr/local so that the files are placed in /usr/local/xorp" > exit 1 > fi > > # Add xorp user and group > echo "Creating xorp user and adding xorp to xorp and root groups..." > adduser xorp > usermod -a -G xorp xorp > usermod -a -G root xorp > > # I compile xorp on FC5, and it has a hard dependency on libpcap.0.9.4 and libcrypto.so.6 > # Fake out the link here so that it will start OK. This works on Ubuntu 8.0.4 & FC8, no idea > # if it will work elsewhere. --Ben > if [ ! -f /usr/lib/libpcap.so.0.9.4 ] > then > echo "Attempting to soft-link /usr/lib/libpcap.so.9.4 to a similar library...." > ln -s /usr/lib/libpcap.so.0.9.* /usr/lib/libpcap.so.0.9.4 > fi > > # This is required on Ubunto 8.0.4, but no needed on Fedora, so > # commenting this out. --Ben > #if [ ! -f /usr/lib/libcrypto.so.6 ] > # then > # echo "Attempting to soft-link /usr/lib/libcrypto.so.6 to a similar library...." > # ln -s /usr/lib/libcrypto.so.0.9.* /usr/lib/libcrypto.so.6 > #fi > > echo "Completed installation setup for Xorp, testing library linkage...." > > if /usr/local/xorp/bin/xorpsh -h > /dev/null 2>&1 > then > echo "Seems to work fine..." > else > echo "ERROR: xorpsh returned error code. Please contact support." > fi > > > Thanks, > Ben > > > > > > Pavlin > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From bms at incunabulum.net Thu Jul 24 02:37:18 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 24 Jul 2008 10:37:18 +0100 Subject: [Xorp-hackers] Broken startup In-Reply-To: References: Message-ID: <48884D4E.6060600@incunabulum.net> ?tefan Gula wrote: > ... > when I saved new configuration and restart my xorp I was at the > beginning because it hangs during the startup of BGP section. > How many policy filters do you have in your configuration? We fixed a bug between 1.4 and 1.5 in the processing of large policy filter lists. Can you try turning off traceoptions for BGP also? It would be useful if you post your configuration file. thanks BMS From steweg at ynet.sk Thu Jul 24 02:55:37 2008 From: steweg at ynet.sk (=?ISO-8859-2?Q?=A9tefan_Gula?=) Date: Thu, 24 Jul 2008 11:55:37 +0200 Subject: [Xorp-hackers] Broken startup In-Reply-To: <48884C33.9070401@icir.org> References: <48884C33.9070401@icir.org> Message-ID: Ok I tried to disable traceoptions but it doesn't help. So my configuration file looks like this: protocols { bgp { bgp-id: 1.1.1.1 local-as: "65535" enable-4byte-as-numbers: false traceoptions { flag { all { disable: false } } } } fib2mrib { disable: false } ospf4 { router-id: 1.1.1.1 rfc1583-compatibility: false ip-router-alert: false traceoptions { flag { all { disable: true } } } area 0.0.0.0 { area-type: "normal" interface vlan2 { link-type: "broadcast" vif vlan2 { address 1.1.2.1 { priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 authentication { simple-password: "" md5 127 { password: "XYZ" start-time: "" end-time: "" max-time-drift: 3600 } } passive { disable: false host: false } disable: false } } } interface vlan4 { link-type: "broadcast" vif vlan4 { address 1.1.1.1 { priority: 199 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 authentication { simple-password: "" md5 127 { password: "XYZ" start-time: "" end-time: "" max-time-drift: 3600 } } disable: false } } } interface vpn0 { link-type: "broadcast" vif vpn0 { address 2.2.2.1 { priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 authentication { simple-password: "" md5 127 { password: "XYZ" start-time: "" end-time: "" max-time-drift: 3600 } } passive { disable: false host: false } disable: false } } } } } static { disable: false route 3.3.3.3/32 { next-hop: 1.1.1.2 metric: 1 } } } policy { policy-statement "moout1" { term a { from { protocol: "connected" } to { neighbor: 2.2.2.2..2.2.2.2 } then { med: 150 accept { } } } term b { from { protocol: "ospf4" } to { neighbor: 2.2.2.2..2.2.2.2 } then { med: 150 accept { } } } } policy-statement "moin1" { term a { from { neighbor: 2.2.2.2..2.2.2.2 network4-list: "xyzlist" } then { localpref: 150 accept { } } } term b { from { neighbor: 2.2.2.2..2.2.2.2 } then { localpref: 100 accept { } } } } network4-list "xyzlist" { network 4.4.4.0/24 } } fea { unicast-forwarding4 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface vlan2 { disable: false discard: false unreachable: false management: false default-system-config } interface vlan4 { disable: false discard: false unreachable: false management: false default-system-config } interface vlan50 { disable: false discard: false unreachable: false management: false default-system-config } interface vpn0 { disable: false discard: false unreachable: false management: false default-system-config } } 2008/7/24 Bruce M. Simpson : > (c)tefan Gula wrote: >> >> ... >> when I saved new configuration and restart my xorp I was at the >> beginning because it hangs during the startup of BGP section. >> > > How many policy filters do you have in your configuration? We fixed a bug > between 1.4 and 1.5 in the processing of large policy filter lists. > > Can you try turning off traceoptions for BGP also? > > It would be useful if you post your configuration file. > > thanks > BMS > > -- Stefan Gula, CCNP From steweg at ynet.sk Thu Jul 24 07:20:05 2008 From: steweg at ynet.sk (=?ISO-8859-2?Q?=A9tefan_Gula?=) Date: Thu, 24 Jul 2008 16:20:05 +0200 Subject: [Xorp-hackers] Broken startup In-Reply-To: <488878F0.2040702@icir.org> References: <48884C33.9070401@icir.org> <488878F0.2040702@icir.org> Message-ID: Well, I was planing to establish BGP sessions with two peers, but I never get so far. So the answer is no. I even disable any connections About the backtracing, I tried to backtrace main process (xorp_rtrmgr) with gdb: (gdb) backtrace #0 0x00002b395b840a83 in select () from /lib/libc.so.6 #1 0x000000000055a57a in ?? () #2 0x0000000000546705 in ?? () #3 0x000000000042172f in ?? () #4 0x00000000004221e7 in ?? () #5 0x00002b395b7a45a4 in __libc_start_main () from /lib/libc.so.6 #6 0x0000000000406359 in ?? () #7 0x00007fff4fd74c68 in ?? () #8 0x0000000000000000 in ?? () and when I tried to backtrace xorp_policy (gdb) backtrace #0 0x00002ae3d6201a83 in select () from /lib/libc.so.6 #1 0x000000000050930e in ?? () #2 0x00000000004fb6c1 in ?? () #3 0x0000000000405507 in ?? () #4 0x0000000000405630 in ?? () #5 0x00002ae3d61655a4 in __libc_start_main () from /lib/libc.so.6 #6 0x0000000000405339 in ?? () #7 0x00007fffd53b3c98 in ?? () #8 0x0000000000000000 in ?? () and finaly backtrace of xorp_bgp (gdb) backtrace #0 0x00002b06d5b64a83 in select () from /lib/libc.so.6 #1 0x000000000067f4f6 in ?? () #2 0x000000000066d171 in ?? () #3 0x000000000040a625 in ?? () #4 0x0000000000419952 in ?? () #5 0x00002b06d5ac85a4 in __libc_start_main () from /lib/libc.so.6 #6 0x0000000000405709 in ?? () #7 0x00007fffd5a50ca8 in ?? () #8 0x0000000000000000 in ?? () I also tried to compile with -g flag for debugging but I still get only ?? in results. (maybe I compile it with wrong flags...) I am not sure if it helps to troubleshoot the problem but when I tried to user xorpsh on broken xorp it creates this messages in log file: [ 2008/07/24 16:15:31 WARNING xorp_rtrmgr:25287 XrlFinderTarget +668 ../xrl/targets/finder_base.cc handle_finder_event_notifier_0_1_register_class_event_interest ] Handling method for finder_event_notifier/0.1/register_class_event_interest failed: XrlCmdError 102 Command failed failed to add watch [ 2008/07/24 16:15:31 ERROR xorp_rtrmgr:25287 RTRMGR +326 xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with finder about XRL xorpsh-30780-xyz (err: Command failed) 2008/7/24 Bruce M. Simpson : > (c)tefan Gula wrote: >> >> Ok I tried to disable traceoptions but it doesn't help. So my >> configuration file looks like this: >> > > ... > > > It looks like it may be policy related, but I can't say for sure. Do you > have peer(s) which are immediately connecting to the BGP process? > > Is it possible for you to attach a debugger to xorp_bgp and obtain a > backtrace of exactly where the process is blocking? > > You could also try completely omitting the traceoptions {} block if it isn't > being used. > > thanks > BMS > > -- Stefan Gula, CCNP From greearb at candelatech.com Thu Jul 24 08:50:00 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 24 Jul 2008 08:50:00 -0700 Subject: [Xorp-hackers] Xorp RPMs In-Reply-To: <200807240712.m6O7C87g026566@fruitcake.ICSI.Berkeley.EDU> References: <48852414.9040405@candelatech.com> <4885A88E.4040006@incunabulum.net> <200807221656.m6MGujiL024888@fruitcake.ICSI.Berkeley.EDU> <48879A3F.2090900@candelatech.com> <200807240712.m6O7C87g026566@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4888A4A8.3030407@candelatech.com> Pavlin Radoslavov wrote: >> Here's a script that adds the xorp user, sets up the groups >> correctly, and fixes (hacks) a library linkage so that xorp compiled >> on fc5 works on at least fc5 and fc8.... >> > > Can you confirm that the library linkage hack is actually needed for > the latest 1.5 code? > For example, the configure mechanism will test for various things > (incl. whether libpcap is installed), and libpcap will be actually > used only if it is available. > The same applies for libcrypto. > Well, I compile on a system that has it (FC5), but running on FC8, the libpcap is a different version, and it seems to compile/link in such a way that it needs the exact version (or a faked out link like my script adds) to work. I'm using the latest cvs code and synced yesterday while testing the script. So, xorp builds and runs fine on the machine that compiles it, but it is slightly more tricky to get it to work on later OSs w/out recompiling. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kristian at spritelink.net Fri Jul 25 09:22:00 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Fri, 25 Jul 2008 18:22:00 +0200 Subject: [Xorp-hackers] OSPF[46]... In-Reply-To: <48873BE5.1050801@incunabulum.net> References: <20080722141521.GA58197@spritelink.se> <4885FAE4.5090304@incunabulum.net> <20080722215605.GC58197@spritelink.se> <48873BE5.1050801@incunabulum.net> Message-ID: <20080725162159.GA62283@spritelink.se> On Wed, Jul 23, 2008 at 03:10:45PM +0100, Bruce M Simpson wrote: > Kristian, > > I understand your frustration, but, well, it boils down to the same > thing in any sphere of human endeavour -- those who do things, > invariably end up steering where those things go, and there's no > substitute for rolling one's sleeves up and getting involved. In any successful company you will find people specialized in their field. Being a programmer means you write code, not necessarily designing a user interface. Anyway, I understand your point although it makes me wonder if the XORP project is at all interested in what its few users have to say about it. > Kristian Larsson wrote: > > The ambition of course being to help XORP into > > world domination. Not being a programmer has > > proven to be somewhat of an obstacle - I've spent > > countless hours going through XORP code and > > eventually just giving up on whatever I had set > > out to do. Coding isn't my ballgame, so what can I > > do to help? > > > > I've been working on a means to build XORP processes (of any kind) in > Python. > > Trouble is, I don't have a lot of free time to work on it, although the > idea is pretty clear -- make it possible for people to script things > more readily in a language which is hopefully more accessible. > > Maybe that will help? Well, I wouldn't want my BGP daemon written in Python, but for a lot of the other stuff, setting hostname, AAA stuff and so forth I sure think XORP could benefit from being able to write stuff in python or some other scripting dialect. I mostly code in Perl, but I'd have no problem taking on Python for the sake of writing some XORP thingy. Regards, Kristian. -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From john.tavs at xorp.net Fri Jul 25 10:03:50 2008 From: john.tavs at xorp.net (John Tavs) Date: Fri, 25 Jul 2008 10:03:50 -0700 Subject: [Xorp-hackers] OSPF[46]... In-Reply-To: <20080725162159.GA62283@spritelink.se> References: <20080722141521.GA58197@spritelink.se> <4885FAE4.5090304@incunabulum.net> <20080722215605.GC58197@spritelink.se> <48873BE5.1050801@incunabulum.net> <20080725162159.GA62283@spritelink.se> Message-ID: <1570429E-9431-48A5-8350-682AC583B4D0@xorp.net> First, let me introduce myself. My name is John Tavs and I am new VP of Engineering for XORP. Clearly my first challenge is to get more people working on the XORP project and that is where I am focusing my time right now. One of the persons I am planning to bring in someone that can implement what network admins need for a successful XORP deployment. And that person will reach out to those who are using XORP to learn from the experience of the community. Regards, John Tavs john.tavs at xorp.net On Jul 25, 2008, at 9:22 AM, Kristian Larsson wrote: On Wed, Jul 23, 2008 at 03:10:45PM +0100, Bruce M Simpson wrote: > Kristian, > > I understand your frustration, but, well, it boils down to the same > thing in any sphere of human endeavour -- those who do things, > invariably end up steering where those things go, and there's no > substitute for rolling one's sleeves up and getting involved. In any successful company you will find people specialized in their field. Being a programmer means you write code, not necessarily designing a user interface. Anyway, I understand your point although it makes me wonder if the XORP project is at all interested in what its few users have to say about it. > Kristian Larsson wrote: >> The ambition of course being to help XORP into >> world domination. Not being a programmer has >> proven to be somewhat of an obstacle - I've spent >> countless hours going through XORP code and >> eventually just giving up on whatever I had set >> out to do. Coding isn't my ballgame, so what can I >> do to help? >> > > I've been working on a means to build XORP processes (of any kind) in > Python. > > Trouble is, I don't have a lot of free time to work on it, although > the > idea is pretty clear -- make it possible for people to script things > more readily in a language which is hopefully more accessible. > > Maybe that will help? Well, I wouldn't want my BGP daemon written in Python, but for a lot of the other stuff, setting hostname, AAA stuff and so forth I sure think XORP could benefit from being able to write stuff in python or some other scripting dialect. I mostly code in Perl, but I'd have no problem taking on Python for the sake of writing some XORP thingy. Regards, Kristian. -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at ICSI.Berkeley.EDU Fri Jul 25 16:49:54 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 25 Jul 2008 16:49:54 -0700 Subject: [Xorp-hackers] Minor xorpsh bugs In-Reply-To: <200807240701.m6O71YZp025191@fruitcake.ICSI.Berkeley.EDU> References: <48879160.3000303@candelatech.com> <488798C8.30704@candelatech.com> <200807240701.m6O71YZp025191@fruitcake.ICSI.Berkeley.EDU> Message-ID: <14679.1217029794@jack.ICSI.Berkeley.EDU> From pavlin at ICSI.Berkeley.EDU Fri Jul 25 16:52:33 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 25 Jul 2008 16:52:33 -0700 Subject: [Xorp-hackers] Minor xorpsh bugs In-Reply-To: <200807240701.m6O71YZp025191@fruitcake.ICSI.Berkeley.EDU> References: <48879160.3000303@candelatech.com> <488798C8.30704@candelatech.com> <200807240701.m6O71YZp025191@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200807252352.m6PNqXOk005055@fruitcake.ICSI.Berkeley.EDU> Pavlin Radoslavov wrote: > Ben, > > Thank you for the patch. I just committed it to CVS. > Regarding "xorpsh -e" it appears a bug, hence please submit a > Bugzilla entry. I just submitted Bugzilla entry so the issue is not lost: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=763 Pavlin > Ben Greear wrote: > > > Ben Greear wrote: > > > I believe xorpsh -e does not work: > > > > > > [root at lanforge-D0-20 bin]# ./xorpsh -e > > > created new heap in find_heap, ptr: 0x8254210 > > > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > > > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > > > .... > > > > > > I would expect it to abort immediately. > > > > > > Also, xorpsh -h exits with error code 1 instead of zero. > > > > > > This matters because I'm trying to run an automated test to > > > see if xorp can start (ie, libraries are all configured right, etc). > > > > > > [root at lanforge-D0-20 bin]# ./xorpsh -h > > > Usage: xorpsh [options] > > > Options: > > > -c Specify command(s) to execute > > > -e Exit immediately if cannot connect to the rtrmgr > > > -h Display this information > > > -v Print verbose information > > > -t Specify templates directory > > > -x Specify Xrl targets directory > > > Defaults: > > > Templates directory := /usr/local/xorp/etc/templates > > > Xrl targets directory := /usr/local/xorp/xrl/targets > > > Print verbose information := false > > > [root at lanforge-D0-20 bin]# echo $? > > > 1 > > > > Here's the trivial patch for this one: > > > > diff --git a/rtrmgr/xorpsh_main.cc b/rtrmgr/xorpsh_main.cc > > index ce9407c..582e5cf 100644 > > --- a/rtrmgr/xorpsh_main.cc > > +++ b/rtrmgr/xorpsh_main.cc > > @@ -877,7 +877,7 @@ main(int argc, char *argv[]) > > case 'h': > > usage(argv[0]); > > display_defaults(); > > - errcode = 1; > > + errcode = 0; > > goto cleanup; > > } > > } > > > > > > > > > > > > > Thanks, > > > Ben > > > > > > > > > -- > > Ben Greear > > Candela Technologies Inc http://www.candelatech.com > > > > _______________________________________________ > > 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 van_nam_78 at yahoo.com Tue Jul 29 02:22:16 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Tue, 29 Jul 2008 02:22:16 -0700 (PDT) Subject: [Xorp-hackers] Problem with writing a xorp process Message-ID: <297282.34335.qm@web50211.mail.re2.yahoo.com> ----- Forwarded Message ---- From: Nguyen Van Nam To: xorp-hackers at icir.org Sent: Tuesday, July 29, 2008 11:16:20 AM Subject: Problem with writing a xorp prorocess Hello, I have written a code source as in the following to detect LSDB change in OSPF protocol. XrlStdRouter xrl_router(_ospf.get_eventloop(), "ospf_loopfree"); //debug_msg("Waiting for router"); xrl_router.finalize(); XrlOspfLoopfreeV0p1Client xrl_ospf_loopfree_client(&xrl_router); wait_until_xrl_router_is_ready(_ospf.get_eventloop(), xrl_router); //debug_msg("\n"); //event loop run bool success=false; success=xrl_ospf_loopfree_client.send_reveive_lsdb_change("ospf_loopfree", callback(this,&AreaRouter::send_reveive_lsdb_change_cb )); if (success) cout<< "LSDB change"< References: <297282.34335.qm@web50211.mail.re2.yahoo.com> Message-ID: <488F0822.80802@incunabulum.net> Nguyen Van Nam wrote: > ... > > But I found the errors: > BufferAsyncReader::annouce_event(BufferedAsyncReader::Event): > Assertion _cb.is_only()==true failed > > Could you please help me to fix these? This assertion means that more than one callback was assigned to an instance of BufferedAsyncReader. Generally, the only code which uses this class is the libxipc library. Can you please obtain a debugging backtrace using gdb and post it to the list? You may need to set breakpoints in order for this to work as the call frame(s) are often not preserved after the exception is actually caught. thanks BMS From van_nam_78 at yahoo.com Tue Jul 29 08:13:20 2008 From: van_nam_78 at yahoo.com (N N) Date: Tue, 29 Jul 2008 08:13:20 -0700 Subject: N N Äã má»i bạn tham gia Friendster Message-ID: <70nihl$102jf6h@c300b.gbxsc.friendster.com> B?n ???c m?i tham gia v?o m?ng b?n b? c?a N N. Khi tham gia v?o Friendster l? b?n c? th? li?n l?c l?i v?i b?n c?, g?p g? b?n m?i, b?t ??u t?o blog, x?y d?ng h? s? t?y ch?nh, theo d?i sinh nh?t v? nhi?u h?n n?a! B?n th?m ch? v?n c? th? gi? li?n l?c ???c khi chuy?n ?i xa, ??i ??a ch? email hay l?m m?t ?i?n tho?i di ??ng. Nh?p v?o b?n d??i ?? tham gia v?o m?ng c?a N. http://www.friendster.com/join.php?inviteref=76520494&invite=Hatn1lIfwBlRmgj58w-oQeamrwk08AzKTay097YW6VY*&lang=vi-VN ***************************************************************** N?u b?n kh?ng mu?n nh?n th?ng b?o b?ng email t? Friendster, vui l?ng nh?p v?o b?n d??i: http://www.friendster.com/blockemails.php?invite=eG9ycC1oYWNrZXJzQGljaXIub3Jn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080729/78721529/attachment.html From bms at incunabulum.net Tue Jul 29 08:40:07 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 29 Jul 2008 16:40:07 +0100 Subject: [Xorp-hackers] Problem with writing a xorp process In-Reply-To: <164270.94595.qm@web50210.mail.re2.yahoo.com> References: <164270.94595.qm@web50210.mail.re2.yahoo.com> Message-ID: <488F39D7.60503@incunabulum.net> Nguyen Van Nam wrote: > Hi, > > I have modified the code source, but the following errors occur: > [ERROR xrl_router. cc send] NO FINDER > Could you explain me why is that? > Thanks Is the xorp_finder process running? Can you verify that your executable is able to connect to it? You can use tests such as telnetting locally to the Finder's default port 19999 to ensure the Finder is actually available. Use tools such as netstat to verify that the port is bound and listening. On FreeBSD, sockstat can be used to verify that 19999 is bound by the process you'd expect. There are similar tools for Windows, Linux etc. PS Please Cc replies to the list. thanks BMS From van_nam_78 at yahoo.com Tue Jul 29 08:41:15 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Tue, 29 Jul 2008 08:41:15 -0700 (PDT) Subject: [Xorp-hackers] Fw: Problem with writing a xorp process Message-ID: <823102.80493.qm@web50210.mail.re2.yahoo.com> ----- Forwarded Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: xorp-hackers Sent: Tuesday, July 29, 2008 5:40:07 PM Subject: Re: [Xorp-hackers] Problem with writing a xorp process Nguyen Van Nam wrote: > Hi, > > I have modified the code source, but the following errors occur: > [ERROR xrl_router. cc send] NO FINDER > Could you explain me why is that? > Thanks Is the xorp_finder process running? Can you verify that your executable is able to connect to it? You can use tests such as telnetting locally to the Finder's default port 19999 to ensure the Finder is actually available. Use tools such as netstat to verify that the port is bound and listening. On FreeBSD, sockstat can be used to verify that 19999 is bound by the process you'd expect. There are similar tools for Windows, Linux etc. PS Please Cc replies to the list. thanks BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080729/98005337/attachment.html From van_nam_78 at yahoo.com Tue Jul 29 02:18:26 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Tue, 29 Jul 2008 02:18:26 -0700 (PDT) Subject: [Xorp-hackers] Fw: Problem with writing a xorp prorocess Message-ID: <612047.63945.qm@web50203.mail.re2.yahoo.com> ----- Forwarded Message ---- From: Nguyen Van Nam To: xorp-hackers at icir.org Sent: Tuesday, July 29, 2008 11:16:20 AM Subject: Problem with writing a xorp prorocess Hello, I have written a code source as in the following to detect LSDB change in OSPF protocol. XrlStdRouter xrl_router(_ospf.get_eventloop(), "ospf_loopfree"); //debug_msg("Waiting for router"); xrl_router.finalize(); XrlOspfLoopfreeV0p1Client xrl_ospf_loopfree_client(&xrl_router); wait_until_xrl_router_is_ready(_ospf.get_eventloop(), xrl_router); //debug_msg("\n"); //event loop run bool success=false; success=xrl_ospf_loopfree_client.send_reveive_lsdb_change("ospf_loopfree", callback(this,&AreaRouter::send_reveive_lsdb_change_cb )); if (success) cout<< "LSDB change"< References: <376933.63993.qm@web50203.mail.re2.yahoo.com> Message-ID: <488F83A0.5030104@incunabulum.net> Hi, Please ignore my earlier comment about multiple callbacks, as it doesn't apply here. Nguyen Van Nam wrote: > Hi, > I use telnet localhost 19999 to verify xorp_finder. It is running. But > the error still occurs. > Note that: my source code is place at the module area_router.cc. > So what should I do now? Based on the screenshot you've posted,and the data so far, it seems as though the xorp_ospfv2 process is either not processing event callbacks or is not returning from them. Could you have introduced anything into the code which results in the EventLoop not being called? This seems to be the most likely root cause of the problem you're seeing. thanks, BMS From bms at incunabulum.net Wed Jul 30 03:22:52 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 30 Jul 2008 11:22:52 +0100 Subject: [Xorp-hackers] Problem with writing a xorp process In-Reply-To: <107606.1036.qm@web50209.mail.re2.yahoo.com> References: <107606.1036.qm@web50209.mail.re2.yahoo.com> Message-ID: <489040FC.7050704@incunabulum.net> Nguyen Van Nam wrote: > Hi, > I have changed many ways to fix the errors. > Firstly, if i place : wait_until_xrl_router_is_ready(...), it produces > the errors: Assertion ..._cb==true failed. > Secondly, not using wait_until_xrl_router_is_ready(...), i have called > only _ospf.get_eventloop().run() and next the xrl command > (_xrl_ospf_loopfree.send_notify_lsdb_change). The following errors > occur: [xrl_router.cc send ] NO FINDER. > More than that, I have placed the code source not only in > area_router.cc but also in xrl_io.cc and xrl_target.cc (in these > cases, i want to use XrlRouter and EventLoop of the two classes). The > result is: error NO FINDER. > I don't really understand why? You definitely need to wait for the XRL router to come up in the beginning -- this is needed in order to begin to communicate with the Finder. Otherwise the XRL client code will try to send XRLs and fail, causing the "NO FINDER" message to be printed anyway. The most likely explanation for what you're seeing is that a function you have added to the call graph in the code is not returning to the EventLoop, or is somehow doing something which causes the EventLoop not to be run. It's impossible to give more specific advice than this without seeing full diffs. Good luck BMS From van_nam_78 at yahoo.com Wed Jul 30 03:14:17 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Wed, 30 Jul 2008 03:14:17 -0700 (PDT) Subject: [Xorp-hackers] Problem with writing a xorp process Message-ID: <107606.1036.qm@web50209.mail.re2.yahoo.com> Hi, I have changed many ways to fix the errors. Firstly, if i place : wait_until_xrl_router_is_ready(...), it produces the errors: Assertion ..._cb==true failed. Secondly, not using wait_until_xrl_router_is_ready(...), i have called only _ospf.get_eventloop().run() and next the xrl command (_xrl_ospf_loopfree.send_notify_lsdb_change). The following errors occur: [xrl_router.cc send ] NO FINDER. More than that, I have placed the code source not only in area_router.cc but also in xrl_io.cc and xrl_target.cc (in these cases, i want to use XrlRouter and EventLoop of the two classes). The result is: error NO FINDER. I don't really understand why? Thank you so much for explaining me NGuyen Van Nam ///---------------------------------------------------------------------- try { //EventLoop eventloop; XrlStdRouter xrl_router(_ospf.get_eventloop(), "area_router"); //debug_msg("Waiting for router"); xrl_router.finalize(); XrlOspfLoopfreeV0p1Client xrl_ospf_loopfree_client(&xrl_router); //cout<<"Test"< To: Nguyen Van Nam Cc: xorp-hackers Sent: Tuesday, July 29, 2008 10:54:56 PM Subject: Re: [Xorp-hackers] Problem with writing a xorp process Hi, Please ignore my earlier comment about multiple callbacks, as it doesn't apply here. Nguyen Van Nam wrote: > Hi, > I use telnet localhost 19999 to verify xorp_finder. It is running. But > the error still occurs. > Note that: my source code is place at the module area_router.cc. > So what should I do now? Based on the screenshot you've posted,and the data so far, it seems as though the xorp_ospfv2 process is either not processing event callbacks or is not returning from them. Could you have introduced anything into the code which results in the EventLoop not being called? This seems to be the most likely root cause of the problem you're seeing. thanks, BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080730/5cfa1a31/attachment.html From bms at incunabulum.net Wed Jul 30 10:34:12 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 30 Jul 2008 18:34:12 +0100 Subject: [Xorp-hackers] Problem with writing a xorp process In-Reply-To: <407297.4838.qm@web50207.mail.re2.yahoo.com> References: <407297.4838.qm@web50207.mail.re2.yahoo.com> Message-ID: <4890A614.30800@incunabulum.net> Nguyen Van Nam wrote: > Hi, > Thanks so much for your answer. > But could you please answer me another question? > I have implemented my code as in print_lsas modul. > In such a way, I defined my own EventLoop, my own XrlRouter, and i > wait_for_xrl_ router_is ready. > But I found the following error when i declared EventLoop evenloop. > [timer.cc] Assertion 'thetimerList==(!null)' failed. > Another time, could you please explain me? This assertion is only present in the TimerList constructor. Could you have done anything which caused the constructor to be called more than once? Are you using threads, for example (we don't support this) ? thanks BMS From bms at incunabulum.net Thu Jul 31 04:23:50 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 31 Jul 2008 12:23:50 +0100 Subject: [Xorp-hackers] Any interest in OLSRv2? Message-ID: <4891A0C6.4040802@incunabulum.net> Is there any interest in OLSRv2 out there for XORP? The IETF MANET group is currently reviewing OLSRv2, it's currently an Internet Draft. One of the shortcomings of the current implementation is that it doesn't implement ETX link metrics. Based on what I'm seeing on the MANET list, there's some argument about how best to proceed as they move towards Experimental RFC status. We need not start from scratch if implementing this in XORP -- one of the strengths of the current implementation is that we can grandfather in a new encapsulation format. cheers BMS From bms at incunabulum.net Thu Jul 31 14:22:21 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 31 Jul 2008 22:22:21 +0100 Subject: [Xorp-hackers] Minor xorpsh bugs In-Reply-To: <48879160.3000303@candelatech.com> References: <48879160.3000303@candelatech.com> Message-ID: <48922D0D.3000906@incunabulum.net> Ben Greear wrote: > I believe xorpsh -e does not work: > > [root at lanforge-D0-20 bin]# ./xorpsh -e > created new heap in find_heap, ptr: 0x8254210 > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > [ 2008/07/23 13:11:24 WARNING xorpsh LIBXORP ] read error: _fd: 22 offset: 0 total-len: 4 error: Connection refused > .... > > I would expect it to abort immediately. > A fix has been committed for this bug to CVS, can folk please test on Linux (and/or other platforms if possible). thanks BMS From f.rodriguez at lancaster.ac.uk Thu Jul 31 13:40:36 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Thu, 31 Jul 2008 21:40:36 +0100 Subject: [Xorp-hackers] OSPF problem present in XORP-1.5 Message-ID: <000901c8f34d$afa8dd50$c5e05894@lancs.local> Hi, I?m currently trying to migrate some of my experiments from XORP-1.4 to XORP-1.5 version, but I?m having some problems. Before moving to XORP-1.5, I had the following setting running with version 1.4: PC1 ? Running as Route Server --> Running XORP 1.4 | PC2 ? Bridge --> Debian Linux running as packet forwarders (No routing software running here) | Router 1 --> Running XORP 1.4 | Router 2 --> Running XORP 1.4 Basically I?m using XORP as an OSPF Route Server which is running in PC1. PC2 is just a box that is in charge of all the forwarding without doing any routing calculating. With previous setup, I can exchange packets between PC1 and Router1 without any problem and OSPF runs fine and I see how the adjacencies are form. The problem comes when running XORP-1.5, I cannot make the previous setup work. The OSPF neighbours? state remains in ExStart , which means that the OSPF packets are seen by both ends but for some reason they cannot form the adjacency. This is the output of my debugging: On PC1 (Router Server): root at Route-Server> show ospf4 neighbor Address Interface State ID Pri Dead 192.168.1.3 eth1.13/eth1.13 ExStart 192.168.1.3 128 39 192.168.2.3 eth1.14/eth1.14 ExStart 192.168.2.3 128 39 root at Route-Server> show ospf4 database OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.0.2 172.16.0.2 0x80000001 434 0x2 0x68b7 60 root at Route-Server> show ospf4 database detail OSPF link state database, Area 0.0.0.0 Router-LSA: LS age 436 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 172.16.0.2 Advertising Router 172.16.0.2 LS sequence number 0x80000001 LS checksum 0x68b7 length 60 bit Nt false bit V false bit E false bit B false Type 3 Stub network Subnet number 172.16.0.0 Mask 255.255.255.0 Metric 1 Type 3 Stub network Subnet number 192.168.1.0 Mask 255.255.255.0 Metric 1 Type 3 Stub network Subnet number 192.168.2.0 Mask 255.255.255.0 Metric 1 root at Route-Server> show ospf4 neighbor detail Address Interface State ID Pri Dead 192.168.1.3 eth1.13/eth1.13 ExStart 192.168.1.3 128 29 Area 0.0.0.0, opt 0x2, DR 192.168.1.3, BDR 192.168.1.2 Up 00:07:21 192.168.2.3 eth1.14/eth1.14 ExStart 192.168.2.3 128 39 Area 0.0.0.0, opt 0x2, DR 192.168.2.3, BDR 192.168.2.2 Up 00:07:11 On Router 1: root at XORP1> show ospf4 neighbor Address Interface State ID Pri Dead 192.168.2.2 eth1/eth1 ExStart 172.16.0.2 128 31 192.168.4.2 eth2/eth2 Full 192.168.3.2 128 39 root at XORP1> show ospf4 neighbor det Possible completions: Show Neighbors detail Show Neighbors root at XORP1> show ospf4 neighbor detail Address Interface State ID Pri Dead 192.168.2.2 eth1/eth1 ExStart 172.16.0.2 128 37 Area 0.0.0.0, opt 0x2, DR 192.168.2.3, BDR 192.168.2.2 Up 00:39:43 192.168.4.2 eth2/eth2 Full 192.168.3.2 128 35 Area 0.0.0.0, opt 0x2, DR 192.168.4.2, BDR 192.168.4.1 Up 00:40:15, adjacent 00:39:29 root at XORP1> show ospf4 database OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *192.168.2.3 192.168.2.3 0x80000002 593 0x2 0x73a7 48 Router 192.168.3.2 192.168.3.2 0x80000004 594 0x2 0xf0b6 48 Router 192.168.1.3 192.168.1.3 0x80000003 595 0x2 0x4cd2 48 Network 192.168.3.2 192.168.3.2 0x80000002 594 0x2 0x8c14 32 Network 192.168.4.2 192.168.3.2 0x80000002 594 0x2 0x8e10 32 root at XORP1> show ospf4 database detail OSPF link state database, Area 0.0.0.0 Router-LSA: LS age 596 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 192.168.2.3 Advertising Router 192.168.2.3 LS sequence number 0x80000002 LS checksum 0x73a7 length 48 bit Nt false bit V false bit E false bit B false Type 3 Stub network Subnet number 192.168.2.0 Mask 255.255.255.0 Metric 1 Type 2 Transit network IP address of Designated router 192.168.4.2 Routers interface address 192.168.4.1 Metric 1 Router-LSA: LS age 597 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 192.168.3.2 Advertising Router 192.168.3.2 LS sequence number 0x80000004 LS checksum 0xf0b6 length 48 bit Nt false bit V false bit E false bit B false Type 2 Transit network IP address of Designated router 192.168.4.2 Routers interface address 192.168.4.2 Metric 1 Type 2 Transit network IP address of Designated router 192.168.3.2 Routers interface address 192.168.3.2 Metric 1 Router-LSA: LS age 598 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 192.168.1.3 Advertising Router 192.168.1.3 LS sequence number 0x80000003 LS checksum 0x4cd2 length 48 bit Nt false bit V false bit E false bit B false Type 3 Stub network Subnet number 192.168.1.0 Mask 255.255.255.0 Metric 1 Type 2 Transit network IP address of Designated router 192.168.3.2 Routers interface address 192.168.3.1 Metric 1 Network-LSA: LS age 597 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 192.168.3.2 Advertising Router 192.168.3.2 LS sequence number 0x80000002 LS checksum 0x8c14 length 32 Network Mask 0xffffff00 Attached Router 192.168.3.2 Attached Router 192.168.1.3 Network-LSA: LS age 597 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 192.168.4.2 Advertising Router 192.168.3.2 LS sequence number 0x80000002 LS checksum 0x8e10 length 32 Network Mask 0xffffff00 Attached Router 192.168.3.2 Attached Router 192.168.2.3 On PC2 (Bridge): Tcpdump output while Router 1 and PC 1 are trying to establish an adjacency FwdM1:~# tcpdump -i eth2 -v tcpdump: WARNING: eth2: no IPv4 address assigned tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes 20:56:20.103523 IP (tos 0xc0, ttl 1, id 42263, offset 0, flags [none], proto OSPF (89), length 68) 192.168.2.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48 Router-ID: 172.16.0.2, Backbone Area, Authentication Type: none (0) Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 255.255.255.0, Priority: 128 Designated Router 192.168.2.3, Backup Designated Router 192.168.2.2 Neighbor List: 192.168.2.3 20:56:21.509478 IP (tos 0xc0, ttl 1, id 64760, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 20:56:21.509510 IP (tos 0xc0, ttl 64, id 47641, offset 0, flags [none], proto ICMP (1), length 80) 192.168.2.1 > 192.168.2.3: ICMP time exceeded in-transit, length 60 --> For some reason both ends are rejecting its LSA packets!!! IP (tos 0xc0, ttl 1, id 64760, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 20:56:26.133523 IP (tos 0xc0, ttl 1, id 29548, offset 0, flags [none], proto OSPF (89), length 68) 192.168.2.3 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 255.255.255.0, Priority: 128 Designated Router 192.168.2.3, Backup Designated Router 192.168.2.2 Neighbor List: 172.16.0.2 20:56:26.133719 IP (tos 0xc0, ttl 1, id 64761, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 20:56:26.133739 IP (tos 0xc0, ttl 64, id 47642, offset 0, flags [none], proto ICMP (1), length 80) 192.168.2.1 > 192.168.2.3: ICMP time exceeded in-transit, length 60 IP (tos 0xc0, ttl 1, id 64761, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 20:56:26.509440 arp who-has 192.168.2.3 tell 192.168.2.1 20:56:26.549518 arp reply 192.168.2.3 is-at 52:54:00:12:38:52 (oui Unknown) 20:56:30.103479 IP (tos 0xc0, ttl 1, id 42266, offset 0, flags [none], proto OSPF (89), length 68) 192.168.2.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48 Router-ID: 172.16.0.2, Backbone Area, Authentication Type: none (0) Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 255.255.255.0, Priority: 128 Designated Router 192.168.2.3, Backup Designated Router 192.168.2.2 Neighbor List: 192.168.2.3 20:56:31.038015 IP (tos 0xc0, ttl 1, id 64762, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 20:56:31.038040 IP (tos 0xc0, ttl 64, id 47643, offset 0, flags [none], proto ICMP (1), length 80) 192.168.2.1 > 192.168.2.3: ICMP time exceeded in-transit, length 60 IP (tos 0xc0, ttl 1, id 64762, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 20:56:36.077607 IP (tos 0xc0, ttl 1, id 29550, offset 0, flags [none], proto OSPF (89), length 68) 192.168.2.3 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 255.255.255.0, Priority: 128 Designated Router 192.168.2.3, Backup Designated Router 192.168.2.2 Neighbor List: 172.16.0.2 20:56:36.077788 IP (tos 0xc0, ttl 1, id 64763, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 20:56:36.077808 IP (tos 0xc0, ttl 64, id 47644, offset 0, flags [none], proto ICMP (1), length 80) 192.168.2.1 > 192.168.2.3: ICMP time exceeded in-transit, length 60 IP (tos 0xc0, ttl 1, id 64763, offset 0, flags [none], proto OSPF (89), length 52) 192.168.2.3 > 192.168.2.2: OSPFv2, Database Description, length: 32 Router-ID: 192.168.2.3, Backbone Area, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] Any insights on how can I fix this matter would be much appreciated. Cheers, Francisco ------------------------- Francisco Rodr?guez Computing Department InfoLab 21 South Drive Lancaster University Lancaster LA1 4WA, UK ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080731/cfe03290/attachment-0001.html