From rbalocca at vyatta.com Tue Aug 1 14:08:21 2006 From: rbalocca at vyatta.com (Rick Balocca) Date: Tue, 1 Aug 2006 14:08:21 -0700 Subject: [Xorp-hackers] Patch for a netlink problem: Can't set MAC address Message-ID: <107d01c6b5ae$9ef60ca0$6cb0010a@embers> In fea/ifconfig_set_netlink.cc , there is code that attempts to set interface MAC addresses. This code fails to work correctly because the netlink payload that it sends is a simple MAC address. The kernel code is looking for a struct sockaddr. One odd-ball thing is that the payload length (rta_len) must be truncated. It must be set to the sizeof sa_family+mac_address_length rather than the larger, and more correct, sizeof sockaddr . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060801/4f5df01a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ifconfig_set_netlink.cc.patch Type: application/octet-stream Size: 1500 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060801/4f5df01a/attachment.obj From atanu at ICSI.Berkeley.EDU Wed Aug 2 16:37:32 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 02 Aug 2006 16:37:32 -0700 Subject: [Xorp-hackers] Announcing XORP Release 1.3 Message-ID: <75907.1154561852@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.3 Release, which is now available from . The major new features with this release are: * IGMPv3 (RFC 3376) * MLDv2 (RFC 3810) In addition, this release contains numerous bug fixes. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.4 release; these are documented in the XORP Bugzilla database . 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 are included below. ------------------------------------------------------------------ XORP RELEASE NOTES This file contains XORP release notes (most recent releases first). Release 1.3 (2006/08/02) ========================= ALL: - Numerous improvements, bug fixes and cleanup. - XORP now builds on Linux Fedora Core5, DragonFlyBSD-1.4, FreeBSD-6.1. - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810). Those are necessary to complete the Source-Specific Multicast support. CONFIGURATION: - Addition of new OSPF configuration statement as part of the MD5 keys: * max-time-drift: u32 (default to 3600, i.e., 1 hour) It is used to set the maximum time drift (in seconds) among all OSPF routers. The allowed values are in the range [0--65535]. If the value is 65535, the time drift is unlimited. - The following statements for configuring static routes have been deprecated: route4, route6, interface-route4, interface-route6, mrib-route4, mrib-route6, mrib-interface-route4, mrib-interface-route6. The new replacement statements are: route, interface-route, mrib-route, mrib-interface-route. Each of the new statements can be used to configure either IPv4Net or IPv6Net route. - The following statements for configuring RIP and RIPng have been renamed: * route-expiry-secs -> route-timeout * route-deletion-secs -> deletion-delay * table-request-secs -> request-interval * interpacket-delay-msecs -> interpacket-delay - The following statements for configuring RIP and RIPng random intervals have been replaced: * triggered-update-min-secs and triggered-update-max-secs with triggered-delay and triggered-jitter * table-announce-min-secs and table-announce-max-secs with update-interval and update-jitter Previously, each interval was specified as [foo-min, foo-max]. Now each interval is specified as [foo - foo * jitter / 100, foo + foo * jitter / 100] where "jitter" is specified as a percentage (an integer in the interval [0, 100]) of the value of "foo". - The "version" statement for configuring an IGMP interface/vif allows values in the range [1-3]. Previously, the allowed range was [1-2]. - The "version" statement for configuring a MLD interface/vif allows values in the range [1-2]. Previously, the allowed range was [1-1]. - The following statement for configuring PIM-SM (pimsm4 and pimsm6) has been renamed: interval-sec -> interval - If a "then" policy block contains "accept" or "reject" statement, now all statements inside the "then" block are evaluated regardless of their position. - Addition of a new "exit" operational mode command that is equivalent to the "quit" operational mode command. - The "create" and "set" configuration commands are merged, so now the new "set" command can be used for setting values and for creating new configuration nodes. For backward compatibility, the obsoleted "create" command is preserved as an alias for the new "set" command, though it may be removed in the future. LIBXORP: - Few bug fixes in the RefTrie implementation. LIBXIPC: - Minor improvement in parsing XRL requests. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Various bug fixes. XORPSH: - Previously, the "commit" command was not available in configuration mode if there were no pending configuration changes. Now the "commit" command is always available, but the following message will be printed instead: "No configuration changes to commit." - Various bug fixes. POLICY: - Various bug fixes. FEA/MFEA: - Bug fix in transmitting large packets on Linux when using IP raw sockets. - Linux-related netlink socket code refactoring and bug fix. - Bug fix in obtaining the incoming interface for raw packets (in case of *BSD). - Bug fix in parsing the ancillary data from recvmsg(). - Accept zeroed source addresses of raw packets, because of protocols like IGMPv3. - Bug fix in restoring kernel routes that were automatically removed when the MAC address or MTU on an interface is modified. - Bug fix in processing IPv4 raw packets if they contain an IP option with a bogus option length. RIB: - Several bug fixes and improvements. RIP: - Various bug fixes in the MD5 authentication support. - Remove route flap when applying/deleting RIP-related import policies. - Fix an issue with INFINITY cost routes that might be bounced indefinitely between two XORP routers. OSPF: - Various bug fixes in the MD5 authentication support. BGP: - Prefix limits on a per peer basis. - Various bug fixes. STATIC_ROUTES: - No significant changes. MLD/IGMP: - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810). - Unification of the IGMP and MLD execution path. PIM-SM: - Bug fix related to the SPT switch (the bug is *BSD specific). - Use the RPF interface toward the BSR when transmitting a Cand-RP Advertisement message. Previously the first interface that is UP was chosen. - Use the RPF interface toward the RP when transmitting PIM Register messages toward the RP. Previously the interface of the directly connected source was chosen. FIB2MRIB: - No significant changes. CLI: - Bug fix related to tracking the window size when it is resized. SNMP: - No significant changes. From chuanhuang_li at pop.zjgsu.edu.cn Thu Aug 3 21:30:25 2006 From: chuanhuang_li at pop.zjgsu.edu.cn (Li Chuanhuang) Date: Fri, 4 Aug 2006 12:30:25 +0800 Subject: [Xorp-hackers] about the implementation of PIM-SM Message-ID: Hi: I'm reading the XORP source code,and I have two questions about the implementation of PIM-SM: 1:In the PIM-SM specification,Data Packet Forwarding Rules: On receipt of data from S to G ,we should deceide whether the KAT should be set,at the same time, we should update the SPTbit(S,G,iif).But in the implementation(XORP),we'll do it only when we received the IGMPMSG_NOCACHE and IGMPMSG_WRONGVIF messages from the Kernel.This is the special cases,not every time we received the multicast data. It seems that the implementation is unconformity with the specification,How to interpret it? 2:Because Linux Kernel only support (S,G) multicast forwarding entries,so XORP also only add the (S,G) entries to the Kernel MFC. If the Kernel received a multicast packet and can't find a MRT in the MFC,it send the IGMPMSG_NOCACHE message to the PIM-SM module.Now we use the user-level task(PIM-SM module) to forward that packet?? is that right?? Hope your answers!! Thanks and best regards!! Li Chuanhuang Zhe Jiang Gongshang University 08/04/2006 From pavlin at icir.org Mon Aug 7 16:36:49 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 Aug 2006 16:36:49 -0700 Subject: [Xorp-hackers] about the implementation of PIM-SM In-Reply-To: Message from "Li Chuanhuang" of "Fri, 04 Aug 2006 12:30:25 +0800." Message-ID: <200608072336.k77NanXw074392@possum.icir.org> > I'm reading the XORP source code,and I have two questions about > the implementation of PIM-SM: > > 1:In the PIM-SM specification,Data Packet Forwarding Rules: > On receipt of data from S to G ,we should deceide whether the KAT > should be set,at the same time, we should update the > SPTbit(S,G,iif).But in the implementation(XORP),we'll do it only > when we received the IGMPMSG_NOCACHE and IGMPMSG_WRONGVIF messages > from the Kernel.This is the special cases,not every time we > received the multicast data. > > It seems that the implementation is unconformity with the > specification,How to interpret it? The Data Packet Forwarding Rules as described in the spec are for correctness. An implementation might use a more practical approach, as long as the result is equivalent. The spec description assumes per-packet updating of the KAT and the SPT bit. In XORP, both the KAT and the SPT bit are kept per routing entry (in user space), hence it will be very inefficient to update them per forwarded data packet. The work-around solution for the KAT is following: When the first multicast data packet arrives, the userland program will receive the IGMPMSG_NOCACHE upcall. Eventually, the processing of that upcall will set the KAT for the corresponding (S,G) routing entry. Also, the userland program starts measuring the forwarding bandwidth for the (S,G) dataflow. The measurement is done by the MFEA (by reading the forwarded packets/bytes from the kernel), or by the kernel itself (e.g., on *BSD systems). If the (S,G) forwarded bandwidth is 0 during the KAT period, then the KAT is timed-out. The work-around solution for the SPTbit is based on the following observation. The Update_SPTbit(S,G,iif) function that should be called per each forwarded data packet is defined as: void Update_SPTbit(S,G,iif) { if ( iif == RPF_interface(S) AND JoinDesired(S,G) == TRUE AND ( DirectlyConnected(S) == TRUE OR RPF_interface(S) != RPF_interface(RP(G)) OR inherited_olist(S,G,rpt) == NULL OR ( ( RPF'(S,G) == RPF'(*,G) ) AND ( RPF'(S,G) != NULL ) ) OR ( I_Am_Assert_Loser(S,G,iif) ) { Set SPTbit(S,G) to TRUE } However, for all practical purpose there is no reason to reevaluate all conditions it per packet; instead, we should reevaluate them only when any of the term is changed. E.g., we should call Update_SPTbit() if one of the following changes: - RPF_interface(S) - JoinDesired(S,G) - DirectlyConnected(S) - RPF_interface(S) - RPF_interface(RP(G)) - inherited_olist(S,G,rpt) ... All of this is implemented by event-tracking mechanism in XORP, hence again we don't need to call Update_SPTbit() per each forwarded data packet. > 2:Because Linux Kernel only support (S,G) multicast forwarding > entries,so XORP also only add the (S,G) entries to the Kernel > MFC. > If the Kernel received a multicast packet and can't find a MRT in > the MFC,it send the IGMPMSG_NOCACHE message to the PIM-SM > module.Now we use the user-level task(PIM-SM module) to forward > that packet?? is that right?? Not exactly. When the kernel sends the IGMPMSG_NOCACHE upcall to userland, it queues the data message for a short period of time (few seconds). When the userland receives the IGMPMSG_NOCACHE upcall, it only installs the corresponding MFC entry in the kernel. During the installation process, the kernel itself checks if there are any data packets queued for this MFC entry. If "yes", those packets are forwarded by using the new MFC entry. Regards, Pavlin From pavlin at icir.org Mon Aug 7 19:24:32 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 Aug 2006 19:24:32 -0700 Subject: [Xorp-hackers] Patch for a netlink problem: Can't set MAC address In-Reply-To: Message from "Rick Balocca" of "Tue, 01 Aug 2006 14:08:21 PDT." <107d01c6b5ae$9ef60ca0$6cb0010a@embers> Message-ID: <200608080224.k782OWLI075795@possum.icir.org> > In fea/ifconfig_set_netlink.cc , there is code that attempts to > set interface MAC addresses. This code fails to work correctly > because the netlink payload that it sends is a simple MAC address. > The kernel code is looking for a struct sockaddr. Thank you for the fix. Now it is applied to CVS: Revision Changes Path 1.28 +35 -4; commitid: 3cdc44d7ee127ea6; xorp/fea/ifconfig_set_netlink.cc > One odd-ball thing is that the payload length (rta_len) must be > truncated. It must be set to the sizeof > sa_family+mac_address_length rather than the larger, and more > correct, sizeof sockaddr Setting the payload length to sa_family+mac_address_length is probably intentiional, because this mechanism is suppose to work with large hardware addresses as indicated in the following email: http://marc2.theaimsgroup.com/?l=linux-kernel&m=104137641925584&w=2 For the record, the patch in that email is an earlier version of what actually was added to the kernel: http://www.ussg.iu.edu/hypermail/linux/kernel/0301.1/2436.html However, what I found really odd is the fact that the payload is suppose to be a MAC address contained inside "struct sockaddr", but rta_len only is suppose to be ETH_ALEN, when the correct value should be sizeof(sa_family) + mac_address_length. I believe this is a bug in the Linux kernel API (at least version 2.6.17). The particular problematic code in the kernel is inside net/core/rtnetlink.c, do_setlink(): ... if (ida[IFLA_ADDRESS - 1]) { ... if (ida[IFLA_ADDRESS - 1]->rta_len != RTA_LENGTH(dev->addr_len)) goto out; err = dev->set_mac_address(dev, RTA_DATA(ida[IFLA_ADDRESS - 1])); ... [ Where dev->set_mac_address() expects to see a second argument of type "struct sockaddr". ] I am going to send an email to the author of that patch about the issue. Thanks, Pavlin P.S. I have added this information to the code itself (in case the API is fixed in the future and we need to fix the XORP code itself). P.P.S. Just curious: how did you find the right solution. I didn't find any online documentation or any sample code while studying your patch, so I had to read the kernel source code to confirm those odd values :) From rbalocca at vyatta.com Tue Aug 8 11:38:01 2006 From: rbalocca at vyatta.com (Rick Balocca) Date: Tue, 8 Aug 2006 11:38:01 -0700 Subject: [Xorp-hackers] Patch for a netlink problem: Can't set MAC address References: <200608080224.k782OWLI075795@possum.icir.org> Message-ID: <025801c6bb19$c7e073b0$6cb0010a@embers> ----- Original Message ----- From: "Pavlin Radoslavov" To: "Rick Balocca" Cc: Sent: Monday, August 07, 2006 7:24 PM Subject: Re: [Xorp-hackers] Patch for a netlink problem: Can't set MAC address <> > P.P.S. Just curious: how did you find the right solution. > I didn't find any online documentation or any sample code while > studying your patch, so I had to read the kernel source code to > confirm those odd values :) That's exactly what I did--read the kernel. The best possible documentation;-) From pavlin at icir.org Tue Aug 8 17:19:14 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 08 Aug 2006 17:19:14 -0700 Subject: [Xorp-hackers] Patch for a netlink problem: Can't set MAC address In-Reply-To: Message from Pavlin Radoslavov of "Mon, 07 Aug 2006 19:24:32 PDT." <200608080224.k782OWLI075795@possum.icir.org> Message-ID: <200608090019.k790JEha027484@possum.icir.org> Pavlin Radoslavov wrote: > > In fea/ifconfig_set_netlink.cc , there is code that attempts to > > set interface MAC addresses. This code fails to work correctly > > because the netlink payload that it sends is a simple MAC address. > > The kernel code is looking for a struct sockaddr. > > Thank you for the fix. Now it is applied to CVS: > > Revision Changes Path > 1.28 +35 -4; commitid: 3cdc44d7ee127ea6; xorp/fea/ifconfig_set_netlink.cc > > > One odd-ball thing is that the payload length (rta_len) must be > > truncated. It must be set to the sizeof > > sa_family+mac_address_length rather than the larger, and more > > correct, sizeof sockaddr > > Setting the payload length to sa_family+mac_address_length is > probably intentiional, because this mechanism is suppose to work > with large hardware addresses as indicated in the following email: > > http://marc2.theaimsgroup.com/?l=linux-kernel&m=104137641925584&w=2 > For the record, the patch in that email is an earlier version of > what actually was added to the kernel: > http://www.ussg.iu.edu/hypermail/linux/kernel/0301.1/2436.html > > However, what I found really odd is the fact that the payload is > suppose to be a MAC address contained inside "struct sockaddr", but > rta_len only is suppose to be ETH_ALEN, when the correct value > should be sizeof(sa_family) + mac_address_length. > I believe this is a bug in the Linux kernel API (at least version > 2.6.17). > > The particular problematic code in the kernel is inside > net/core/rtnetlink.c, do_setlink(): > ... > if (ida[IFLA_ADDRESS - 1]) { > ... > if (ida[IFLA_ADDRESS - 1]->rta_len != RTA_LENGTH(dev->addr_len)) > goto out; > err = dev->set_mac_address(dev, RTA_DATA(ida[IFLA_ADDRESS - 1])); > ... > > [ Where dev->set_mac_address() expects to see a second argument of > type "struct sockaddr". ] > > I am going to send an email to the author of that patch about the > issue. I sent an email to the linux-kernel ML, and it turned that this is a Linux kernel bug which will be fixed in both 2.6.18 and 2.6.17.x-stable. See the following thread for details: http://www.spinics.net/lists/kernel/msg498873.html After the fix, the RTM_SETLINK payload for setting the MAC address will be the MAC address (only) without the "sockaddr" wrapper around it. Hence, I am going to reverse the recent change to fea/ifconfig_set_netlink.cc (rev 1.28) after a Linux kernel with the fix is released, because the original code will be working correctly with that kernel. Pavlin From meyett_donald at bah.com Mon Aug 14 19:22:34 2006 From: meyett_donald at bah.com (Meyett Donald) Date: Mon, 14 Aug 2006 22:22:34 -0400 Subject: [Xorp-hackers] What IDE to use for development? Message-ID: When I load xorp-1.2 or xorp-1.3 source code into kdevelop or anjuta it kills the IDE. Is this a known problem? Is there a recommended Linux-based IDE from which to develop? I've duplicated this across multiple versions of Linux (RHEL ES4, RHEL WS, FC4 and FC5) as well as multiple versions of kdevelop (3.3.1, 3.3.3) and anjuta (1.2.4 and 2.0.2). I'm not sure if this is an issue with the xorp code or a much larger (possibly) kernel related issue. Thanks in advance. Don Meyett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060814/566eb1c7/attachment.html From M.Handley at cs.ucl.ac.uk Wed Aug 16 03:52:57 2006 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Wed, 16 Aug 2006 11:52:57 +0100 Subject: [Xorp-hackers] Is localhost IPv4 or IPv6? Message-ID: <84a612dd0608160352i70a00af9u460eafd2dda2b77f@mail.gmail.com> I'm getting random test failures on MacOS 10.4.7 (intel): Entering ./test_peering1.sh -l -t test34^M local_config 65008 192.150.187.78^M register_rib^M add_peer localhost 10001 localhost 20001 65008 192.150.187.78 30^M [ 2006/08/16 11:12:11 WARNING xorp_bgp:3089 XrlBgpTarget +478 bgp_base.cc hand\ le_bgp_0_2_add_peer ] Handling method for bgp/0.2/add_peer failed: XrlCmdError \ 102 Command failed AddressFamilyMismatch from line 61 of iptuple.cc: mismatch l\ ocalhost localhost^M [ 2006/08/16 11:12:11 ERROR call_xrl:3098 XRL +59 call_xrl.cc response_handler\ ] Failed. Reason: 102 Command failed AddressFamilyMismatch from line 61 of ip\ tuple.cc: mismatch localhost localhost ("finder://bgp/bgp/0.2/add_peer?local_ip\ :txt=localhost&local_port:u32=10001&peer_ip:txt=localhost&peer_port:u32=20001&a\ s:u32=65008&next_hop:ipv4=192.150.187.78&holdtime:u32=30")^M ./test_peering1.sh: Tests Failed^M SIGTERM received. Exiting.^M ./test_peering1.sh: Tests Failed^M ./test_peering1.sh: Tests Failed^M FAIL: test_peering1.sh^M Seemed very odd. The AF of localhost is not the same as the AF of localhost. I can't reproduce this error by running test34 by itself - I only saw it in the middle of the entire test suite. It's not always the same test that fails either, I've also seen test12 fail. I instrumented the code, and it turns out that AF for _local_sock is 30 (IPv6) and AF for _peer_sock is 2 (IPv4) in the particular case I observed, although both are specified as simply "localhost". So, under some circumstances MacOS decides to default to IPv6 for the IP address for "localhost" if you don't specify the AF. This is presumably reasonable, as the default /etc/hosts file contains: ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost I don't understand what the circumstances are where it chooses IPv4 vs IPv6, but it seems like perhaps we should not be specifying localhost by name in the test suite, but by IP address instead. - Mark From atanu at ICSI.Berkeley.EDU Wed Aug 16 15:14:26 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 16 Aug 2006 15:14:26 -0700 Subject: [Xorp-hackers] Is localhost IPv4 or IPv6? In-Reply-To: Message from "Mark Handley" of "Wed, 16 Aug 2006 11:52:57 BST." <84a612dd0608160352i70a00af9u460eafd2dda2b77f@mail.gmail.com> Message-ID: <82808.1155766466@tigger.icir.org> Hi, Either IPv4 or IPv6 addresses are acceptable as a resolution for localhost, getting a mix is not useful. I have changed localhost to 127.0.0.1 where appropriate. Atanu. >>>>> "Mark" == Mark Handley writes: Mark> I'm getting random test failures on MacOS 10.4.7 (intel): Mark> Entering ./test_peering1.sh -l -t test34^M Mark> local_config 65008 192.150.187.78^M Mark> register_rib^M Mark> add_peer localhost 10001 localhost 20001 65008 192.150.187.78 30^M Mark> [ 2006/08/16 11:12:11 WARNING xorp_bgp:3089 XrlBgpTarget +478 bgp_base.cc hand\ Mark> le_bgp_0_2_add_peer ] Handling method for bgp/0.2/add_peer failed: XrlCmdError \ Mark> 102 Command failed AddressFamilyMismatch from line 61 of iptuple.cc: mismatch l\ Mark> ocalhost localhost^M Mark> [ 2006/08/16 11:12:11 ERROR call_xrl:3098 XRL +59 call_xrl.cc response_handler\ Mark> ] Failed. Reason: 102 Command failed AddressFamilyMismatch from line 61 of ip\ Mark> tuple.cc: mismatch localhost localhost ("finder://bgp/bgp/0.2/add_peer?local_ip\ Mark> :txt=localhost&local_port:u32=10001&peer_ip:txt=localhost&peer_port:u32=20001&a\ Mark> s:u32=65008&next_hop:ipv4=192.150.187.78&holdtime:u32=30")^M Mark> ./test_peering1.sh: Tests Failed^M Mark> SIGTERM received. Exiting.^M Mark> ./test_peering1.sh: Tests Failed^M Mark> ./test_peering1.sh: Tests Failed^M Mark> FAIL: test_peering1.sh^M Mark> Seemed very odd. The AF of localhost is not the same as the AF of Mark> localhost. I can't reproduce this error by running test34 by itself - Mark> I only saw it in the middle of the entire test suite. It's not always Mark> the same test that fails either, I've also seen test12 fail. Mark> I instrumented the code, and it turns out that AF for _local_sock is Mark> 30 (IPv6) and AF for _peer_sock is 2 (IPv4) in the particular case I Mark> observed, although both are specified as simply "localhost". Mark> So, under some circumstances MacOS decides to default to IPv6 for the Mark> IP address for "localhost" if you don't specify the AF. This is Mark> presumably reasonable, as the default /etc/hosts file contains: Mark> ## Mark> # Host Database Mark> # Mark> # localhost is used to configure the loopback interface Mark> # when the system is booting. Do not change this entry. Mark> ## Mark> 127.0.0.1 localhost Mark> 255.255.255.255 broadcasthost Mark> ::1 localhost Mark> I don't understand what the circumstances are where it chooses IPv4 vs Mark> IPv6, but it seems like perhaps we should not be specifying localhost Mark> by name in the test suite, but by IP address instead. Mark> - Mark From M.Handley at cs.ucl.ac.uk Wed Aug 16 15:18:46 2006 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Wed, 16 Aug 2006 23:18:46 +0100 Subject: [Xorp-hackers] Is localhost IPv4 or IPv6? In-Reply-To: <82808.1155766466@tigger.icir.org> References: <84a612dd0608160352i70a00af9u460eafd2dda2b77f@mail.gmail.com> <82808.1155766466@tigger.icir.org> Message-ID: <84a612dd0608161518n5b7e91aah263e2a495e45fb40@mail.gmail.com> Thanks - I'll verify that this fixes the random test failures. - Mark On 8/16/06, Atanu Ghosh wrote: > Hi, > > Either IPv4 or IPv6 addresses are acceptable as a resolution for > localhost, getting a mix is not useful. > > I have changed localhost to 127.0.0.1 where appropriate. > > Atanu. > > >>>>> "Mark" == Mark Handley writes: > > Mark> I'm getting random test failures on MacOS 10.4.7 (intel): > Mark> Entering ./test_peering1.sh -l -t test34^M > Mark> local_config 65008 192.150.187.78^M > Mark> register_rib^M > Mark> add_peer localhost 10001 localhost 20001 65008 192.150.187.78 30^M > Mark> [ 2006/08/16 11:12:11 WARNING xorp_bgp:3089 XrlBgpTarget +478 bgp_base.cc hand\ > Mark> le_bgp_0_2_add_peer ] Handling method for bgp/0.2/add_peer failed: XrlCmdError \ > Mark> 102 Command failed AddressFamilyMismatch from line 61 of iptuple.cc: mismatch l\ > Mark> ocalhost localhost^M > Mark> [ 2006/08/16 11:12:11 ERROR call_xrl:3098 XRL +59 call_xrl.cc response_handler\ > Mark> ] Failed. Reason: 102 Command failed AddressFamilyMismatch from line 61 of ip\ > Mark> tuple.cc: mismatch localhost localhost ("finder://bgp/bgp/0.2/add_peer?local_ip\ > Mark> :txt=localhost&local_port:u32=10001&peer_ip:txt=localhost&peer_port:u32=20001&a\ > Mark> s:u32=65008&next_hop:ipv4=192.150.187.78&holdtime:u32=30")^M > Mark> ./test_peering1.sh: Tests Failed^M > Mark> SIGTERM received. Exiting.^M > Mark> ./test_peering1.sh: Tests Failed^M > Mark> ./test_peering1.sh: Tests Failed^M > Mark> FAIL: test_peering1.sh^M > > > Mark> Seemed very odd. The AF of localhost is not the same as the AF of > Mark> localhost. I can't reproduce this error by running test34 by itself - > Mark> I only saw it in the middle of the entire test suite. It's not always > Mark> the same test that fails either, I've also seen test12 fail. > > Mark> I instrumented the code, and it turns out that AF for _local_sock is > Mark> 30 (IPv6) and AF for _peer_sock is 2 (IPv4) in the particular case I > Mark> observed, although both are specified as simply "localhost". > > Mark> So, under some circumstances MacOS decides to default to IPv6 for the > Mark> IP address for "localhost" if you don't specify the AF. This is > Mark> presumably reasonable, as the default /etc/hosts file contains: > > Mark> ## > Mark> # Host Database > Mark> # > Mark> # localhost is used to configure the loopback interface > Mark> # when the system is booting. Do not change this entry. > Mark> ## > Mark> 127.0.0.1 localhost > Mark> 255.255.255.255 broadcasthost > Mark> ::1 localhost > > Mark> I don't understand what the circumstances are where it chooses IPv4 vs > Mark> IPv6, but it seems like perhaps we should not be specifying localhost > Mark> by name in the test suite, but by IP address instead. > > Mark> - Mark > From meyett_donald at bah.com Thu Aug 17 10:25:56 2006 From: meyett_donald at bah.com (Meyett Donald) Date: Thu, 17 Aug 2006 13:25:56 -0400 Subject: [Xorp-hackers] What IDE to use for development? Message-ID: It appears that the culprit is xorp-1.x/Makefile.am. Removing this file results in the IDE loading the project correctly but I imagine there is a loss of functionality, i.e.. being able to automake from the GUI. I haven't narrowed down the exact cause of the problem within the makefile but I will keep you posted in the event I do. Thanks! Don Meyett Booz, Allen, Hamilton Email - meyett_donald at bah.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20060817/956df405/attachment.html From yiwang at cs.princeton.edu Mon Aug 21 09:48:19 2006 From: yiwang at cs.princeton.edu (Yi Wang) Date: Mon, 21 Aug 2006 12:48:19 -0400 Subject: [Xorp-hackers] A question about delete_route() in xorp/bgp/route_table_decision.cc In-Reply-To: <200608111555.k7BFtu1U037750@possum.icir.org> References: <200608111555.k7BFtu1U037750@possum.icir.org> Message-ID: <44E9E3D3.3040407@cs.princeton.edu> Hello, I was looking at the delete_route() function in route_table_decision.cc of the BGP implementation of XORP 1.3. I found the following snippet of code a bit confusing: what if the old_winner (old_winner_clone) and the new_winner are the same, but they both refer to the route to be deleted (the one in rtmsg)? If it is the case and we return -1 here, the delete_route message won't be propagate downstream. if (old_winner_clone != NULL) { if (new_winner != NULL && old_winner_clone->route() == new_winner->route()) { //the winner didn't change. XLOG_ASSERT(old_winner_clone != NULL); delete old_winner_clone; return -1; } ... } My guess is that there is some statement missing in the following "if" statement, at least the comment doesn't seems to match the statement below it. Maybe the author meant to delete the old_winner from alternatives before selecting the new_winner? if (!alternatives.empty()) { //add the new route to the pool of possible winners. new_winner = find_winner(alternatives); } My apology if I made some dumb mistake here. Thanks a lot! Yi From mike at vyatta.com Mon Aug 21 10:28:33 2006 From: mike at vyatta.com (Michael Larson) Date: Mon, 21 Aug 2006 10:28:33 -0700 (PDT) Subject: [Xorp-hackers] fix for xorpsh if TERM env variable is not set Message-ID: <206866.161156181313406.JavaMail.root@mail.vyatta.com> Here's a small fix for the xorpsh when the TERM environmental variable is not set: --- cli_node_net.cc_orig 2006-08-21 10:21:52.000000000 -0700 +++ cli_node_net.cc 2006-08-21 10:17:53.000000000 -0700 @@ -514,8 +514,8 @@ ; // do nothing #else - term_name = getenv("TERM"); - if (term_name.empty()) + char *term = getenv("TERM"); + if (term == NULL || string(term).empty() == true) term_name = DEFAULT_TERM_TYPE; // Set to default #endif } The getenv is returning a NULL ptr which causes a crash when the assignment is applied to the string term_name. The fix is to check for NULL prior to testing for an empty string. Mike Vyatta From pavlin at icir.org Mon Aug 21 12:43:03 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 21 Aug 2006 12:43:03 -0700 Subject: [Xorp-hackers] fix for xorpsh if TERM env variable is not set In-Reply-To: Message from Michael Larson of "Mon, 21 Aug 2006 10:28:33 PDT." <206866.161156181313406.JavaMail.root@mail.vyatta.com> Message-ID: <200608211943.k7LJh3Cs050432@possum.icir.org> > Here's a small fix for the xorpsh when the TERM environmental variable is not set: > > --- cli_node_net.cc_orig 2006-08-21 10:21:52.000000000 -0700 > +++ cli_node_net.cc 2006-08-21 10:17:53.000000000 -0700 > @@ -514,8 +514,8 @@ > > ; // do nothing > #else > - term_name = getenv("TERM"); > - if (term_name.empty()) > + char *term = getenv("TERM"); > + if (term == NULL || string(term).empty() == true) > term_name = DEFAULT_TERM_TYPE; // Set to default > #endif > } > > The getenv is returning a NULL ptr which causes a crash when the > assignment is applied to the string term_name. The fix is to check > for NULL prior to testing for an empty string. Yes, it is a bug, though the fix should be slightly different so term_name is properly assigned if TERM is valid. E.g., see the following patch (note that term_name was set its default value before this code is reached): Index: cli_node_net.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/cli/cli_node_net.cc,v retrieving revision 1.52 diff -u -p -r1.52 cli_node_net.cc --- cli_node_net.cc 24 Jul 2006 21:25:42 -0000 1.52 +++ cli_node_net.cc 21 Aug 2006 19:37:57 -0000 @@ -514,9 +514,9 @@ CliClient::start_connection(string& erro ; // do nothing #else - term_name = getenv("TERM"); - if (term_name.empty()) - term_name = DEFAULT_TERM_TYPE; // Set to default + char *term = getenv("TERM"); + if ((term != NULL) && (! string(term).empty())) + term_name = string(term); #endif } Anyway, I committed the fix to CVS: Revision Changes Path 1.53 +4 -4; commitid: d0f144ea0af37ea6; xorp/cli/cli_node_net.cc Thanks, Pavlin From atanu at ICSI.Berkeley.EDU Tue Aug 22 16:47:19 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 22 Aug 2006 16:47:19 -0700 Subject: [Xorp-hackers] A question about delete_route() in xorp/bgp/route_table_decision.cc In-Reply-To: Message from Yi Wang of "Mon, 21 Aug 2006 12:48:19 EDT." <44E9E3D3.3040407@cs.princeton.edu> Message-ID: <89359.1156290439@tigger.icir.org> Hi, >>>>> "Yi" == Yi Wang writes: Yi> Hello, Yi> I was looking at the delete_route() function in Yi> route_table_decision.cc of the BGP implementation of XORP 1.3. I Yi> found the following snippet of code a bit confusing: what if the Yi> old_winner (old_winner_clone) and the new_winner are the same, Yi> but they both refer to the route to be deleted (the one in Yi> rtmsg)? If it is the case and we return -1 here, the Yi> delete_route message won't be propagate downstream. The new_winner by definition can never refer to the current delete route, it is the winner excluding the route from this peer. This is the case where the current route was not the previous winner and its removal has not caused a new winner to be chosen (I believe that the strange way that MEDs are processed means that a route that is not the current winner being deleted can change the winner). Yi> if (old_winner_clone != NULL) { Yi> if (new_winner != NULL Yi> && old_winner_clone->route() == new_winner->route()) { Yi> //the winner didn't change. Yi> XLOG_ASSERT(old_winner_clone != NULL); Yi> delete old_winner_clone; Yi> return -1; Yi> } Yi> ... Yi> } Yi> My guess is that there is some statement missing in the Yi> following "if" statement, at least the comment doesn't seems to Yi> match the statement below it. Maybe the author meant to delete Yi> the old_winner from alternatives before selecting the Yi> new_winner? The list of alternatives does not contain the route from this peer so it does not need to be removed. The comment seems to have been copied from add_route() and delete_route() and has now been removed. Yi> if (!alternatives.empty()) { Yi> //add the new route to the pool of possible winners. Yi> new_winner = find_winner(alternatives); Yi> } If you look at the implementation of find_alernative_routes() you will see that it doesn't return the route from the current peer, it also returns the previous winner. The find_winner() method uses the set of alternatives (which excludes the current peer) to compute the new winner. Atanu. From s8066410 at kmitl.ac.th Fri Aug 25 12:18:14 2006 From: s8066410 at kmitl.ac.th (s8066410 at kmitl.ac.th) Date: Sat, 26 Aug 2006 02:18:14 +0700 (ICT) Subject: [Xorp-hackers] How to use shell script to control xorp shell Message-ID: <21896.125.24.218.60.1156533494.squirrel@125.24.218.60> Can I write shell script to control xorp shell(xorpsh) from unix shell script ? How I do it ? EX. #!/bin/sh xorpsh < Message-ID: <200608252051.k7PKpKUb009118@possum.icir.org> > Can I write shell script to control xorp shell(xorpsh) from unix shell > script ? How I do it ? > EX. > #!/bin/sh > xorpsh < show host os > ! > But I found it show xorpsh not found > Why? The "xorpsh" binary has to be in the execution path. Alternatively, "xorpsh" should be replaced with "/path/to/xorpsh". I noticed that the above info is missing from the user manual, so I just updated it. Thanks, Pavlin