From bms at incunabulum.net Tue Sep 1 04:25:58 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 01 Sep 2009 12:25:58 +0100 Subject: [Xorp-users] Error:XrlRouter Failed.No Finder?while running ./xorp_rtrmgr In-Reply-To: <701838.69996.qm@web94803.mail.in2.yahoo.com> References: <701838.69996.qm@web94803.mail.in2.yahoo.com> Message-ID: <4A9D04C6.7090907@incunabulum.net> naresh raga wrote: > > > This is my complete error report generated when i executed > xorp_rtrmgr.I have made sure my 127.0.0.1 is up and port 19999 is > free.But even then it results in the same error. > > [WARNING xorp_rtrmgr:10336 LIBXORP +468 timer.cc expire_one ] Timer > Expiry *much* later than scheduled: behind by 52.210000seconds. > [WARNING xorp_rtrmgr:10336 LIBXORP +468 timer.cc expire_one ] Timer > Expiry *much* later than scheduled: behind by 22.250000seconds. > [ERROR xorp_rtrmgr:10336 XRL +634 xrl_router.cc > wait_until_xrl_router_is_ready ] XrlRouter Failed.No Finder? > I don't have much to go on here, other than it sounds like you have a slow machine, or one that is highly loaded -- this is all the information which these log messages give me at the moment. Sorry I can't be of further help with this issue. From bms at incunabulum.net Tue Sep 1 07:34:46 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 01 Sep 2009 15:34:46 +0100 Subject: [Xorp-users] Newbie struggling with Multicast routing In-Reply-To: <467C77F6373BDE4BB16A3E8A62C03955054C3BAA@Exchserv.hatteras.com> References: <467C77F6373BDE4BB16A3E8A62C03955054C3BAA@Exchserv.hatteras.com> Message-ID: <4A9D3106.2030403@incunabulum.net> Hi, We need to see the contents of your multicast forwarding cache, to be sure that MROUTING is an active feature inside your kernel, and that the MFEA is able to push MFC entries to the kernel. You might find these tools helpful, although I don't know if your Linux distribution ships them as packages or not: https://sourceforge.net/projects/mcast-tools/ Try 'cat //proc//net/ip_mr_cache'. thanks BMS From bms at incunabulum.net Tue Sep 1 08:39:15 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 01 Sep 2009 16:39:15 +0100 Subject: [Xorp-users] Newbie struggling with Multicast routing In-Reply-To: <467C77F6373BDE4BB16A3E8A62C03955054C3DFE@Exchserv.hatteras.com> References: <467C77F6373BDE4BB16A3E8A62C03955054C3BAA@Exchserv.hatteras.com> <4A9D3106.2030403@incunabulum.net> <467C77F6373BDE4BB16A3E8A62C03955054C3DFE@Exchserv.hatteras.com> Message-ID: <4A9D4023.1010907@incunabulum.net> Roger Truitt wrote: > Here's the ip_mr_cache while streaming video into eth1: > > [root at st-linux1 rtrmgr]# cat //proc//net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 010101EF 010A0A0A 0 3428 4607232 0 1:1 > [root at st-linux1 rtrmgr]# cat //proc//net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 010101EF 010A0A0A 0 6994 9399936 0 1:1 > [root at st-linux1 rtrmgr]# cat //proc//net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 010101EF 010A0A0A 0 9343 12556992 0 1:1 > > OK, so the MFC looks sane. can you double check these if indexes are sane with 'show interfaces' ? Generally the vif indexes should be the same as for physical interfaces, however this is not guaranteed. Do you have any IGMP snooping switches? Suggest strongly picking up a copy of 'Interdomain Multicast Routing', it explains how PIM and IGMP work in great detail. I have to run. Please Cc: xorp traffic to the lists, I can't respond to support requests personally. Thanks. From bms at incunabulum.net Tue Sep 1 08:46:21 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 01 Sep 2009 16:46:21 +0100 Subject: [Xorp-users] Error recieving routes from BGP peers In-Reply-To: <20090814062706.GA28701@jscinoz> References: <20090814062706.GA28701@jscinoz> Message-ID: <4A9D41CD.5050800@incunabulum.net> Are you using BSD, Linux or something else as the host? If BSD, does 'route -nv monitor' show up any strange looking traffic when the FEA attempts to push the route(s) to the kernel? I can't recall the analogous Linux command off the top of my head, 'iproute2' would be the package to start looking in, specifically the 'ip' command and others. From bms at incunabulum.net Tue Sep 1 08:50:13 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 01 Sep 2009 16:50:13 +0100 Subject: [Xorp-users] policy on static route In-Reply-To: <4A8B2D53.4020409@research.telcordia.com> References: <4A8B2D53.4020409@research.telcordia.com> Message-ID: <4A9D42B5.3050806@incunabulum.net> Hi Andy, Yes, static routes may have policies applied to them. Can you provide details of the error when you try to implement the next-hop rewrite? Andy Yuen wrote: > > Suppose there is a node 10.2.2.2. I want to set up a policy such that > the next-hop to destination 10.1.1.0/24 is 10.2.5.5 when some metric > or tag value is 1 and the next-hop is 10.2.4.4 when the corresponding > metric or value is 2. Is it possible to define policy statement for > static routes? It is likely what you are attempting to do is not possible without additional support from the forwarding plane, as in XORP's RIB, routes are normally exclusively keyed by protocol addresses/network prefixes in the tries. > > Normally, I want to use 10.2.5.5, but occasionally I want to use > 10.2.4.4 based on the current value of metric as defined in the policy > statement. The reason behind doing this is making it possible to > modify the static route by modifying a metric value only, instead of > uploading the whole router configuration with new static route. This > try to emulate multi-topology routing, where the metric value > corresponds to the DSCP value. XORP will not be able to see or rewrite the DSCP field without assistance from the kernel. One workaround for this would be to implement an outgoing packet rewrite policy using your favorite OS's packet filtering facilities. Obviously because XORP attempts to drive several host OS layers, it is not guaranteed that this can be integrated within the configuration language / framework. Patches for this and other issues are very welcome. thanks BMS From greearb at candelatech.com Tue Sep 1 11:24:00 2009 From: greearb at candelatech.com (Ben Greear) Date: Tue, 01 Sep 2009 11:24:00 -0700 Subject: [Xorp-users] Who is doing what with Xorp? Message-ID: <4A9D66C0.9000104@candelatech.com> I thought it might be nice to see a show of hands as to who is actively using the Xorp SVN tree (or who might start doing so shortly). Please describe what you are doing and to what extent. I'll go first: We use xorp, with our virtualization patches, to provide virtual router emulation in Linux. We have a tool that configures xorp instances automatically and runs multiple instances of xorp on a single Linux OS. Each xorp has it's own routing table and own set of interfaces it pays attention to. We use OSPF (IPv4, v6), multicast (IPv4 only currently), BGP, RIP, and OLSR. We can easily do regression tests with dynamic networks (links come and go, link connections degrade (pkt loss, latency, etc). We use the 'veth' device in Linux to connect xorp instances, and some of our own proprietary network emulation logic for the impairments. We do not use Xorp on any platform besides Linux. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From rtruitt at hatterasnetworks.com Tue Sep 1 13:43:18 2009 From: rtruitt at hatterasnetworks.com (Roger Truitt) Date: Tue, 1 Sep 2009 16:43:18 -0400 Subject: [Xorp-users] Newbie struggling with Multicast routing Message-ID: <467C77F6373BDE4BB16A3E8A62C039550557ADB0@Exchserv.hatteras.com> With my limited Linux skills, I don't know if I'm deciphering the ip_mr_cache correctly, but if Iif is the vif index, it does not match the physical index of eth1. xorp at st-linux1.hatteras.com> show interfaces eth1/eth1: Flags: mtu 1500 speed 100 Mbps inet 10.10.10.10 subnet 10.10.10.0/24 broadcast 10.10.10.255 physical index 3 <<<< ether 0:e:c:83:12:c7 eth2/eth2: Flags: mtu 1500 speed 100 Mbps inet 10.20.20.20 subnet 10.20.20.0/24 broadcast 10.20.20.255 physical index 2 ether 0:4:2e:1:e1:9c xorp at st-linux1.hatteras.com> If this is the case, how would one correct this mismatch? I do not have igmp snooping switches in my simple setup yet. That was the next step. I wanted to get just the xorp router working between the video server and client before adding a igmp snooping switch to the mix (baby steps). _____________________________________________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential and proprietary information of Hatteras Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this email message, please contact the sender by reply email and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. -----Original Message----- From: Bruce Simpson [mailto:bms at incunabulum.net] Sent: Tuesday, September 01, 2009 11:39 AM To: Roger Truitt; xorp users Subject: Re: [Xorp-users] Newbie struggling with Multicast routing Roger Truitt wrote: > Here's the ip_mr_cache while streaming video into eth1: > > [root at st-linux1 rtrmgr]# cat //proc//net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 010101EF 010A0A0A 0 3428 4607232 0 1:1 > [root at st-linux1 rtrmgr]# cat //proc//net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 010101EF 010A0A0A 0 6994 9399936 0 1:1 > [root at st-linux1 rtrmgr]# cat //proc//net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 010101EF 010A0A0A 0 9343 12556992 0 1:1 > > OK, so the MFC looks sane. can you double check these if indexes are sane with 'show interfaces' ? Generally the vif indexes should be the same as for physical interfaces, however this is not guaranteed. Do you have any IGMP snooping switches? Suggest strongly picking up a copy of 'Interdomain Multicast Routing', it explains how PIM and IGMP work in great detail. I have to run. Please Cc: xorp traffic to the lists, I can't respond to support requests personally. Thanks. From naresh_raga at yahoo.co.in Wed Sep 2 04:06:24 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Wed, 2 Sep 2009 16:36:24 +0530 (IST) Subject: [Xorp-users] Error:XrlRouter Failed.No Finder?while running ./xorp_rtrmgr In-Reply-To: <4A9D04C6.7090907@incunabulum.net> Message-ID: <139665.97124.qm@web94814.mail.in2.yahoo.com> Hi Bruce, > [WARNING xorp_rtrmgr:10336 LIBXORP +468 timer.cc expire_one ] Timer Expiry *much* later than scheduled: behind by 52.210000seconds. > [WARNING xorp_rtrmgr:10336 LIBXORP +468 timer.cc expire_one ] Timer Expiry *much* later than scheduled: behind by 22.250000seconds. > [ERROR xorp_rtrmgr:10336 XRL +634 xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter Failed.No Finder? > >I don't have much to go on here, other than it sounds like you have >a slow machine, or one that is highly loaded -- this is all the >information which these log messages give me at the moment. >Sorry I can't be of further help with this issue. Sorry Bruce,if I am really troubling you.I am so particular about this because it is my current project target set by my professor.I will give the TS7300 kit details on which I am working. 200MHz ARM9 CPU PC/104 expansion bus 32MB SDRAM 2 10/100 ethernet ports 1 VGA out w/ 8MB RAM 800x600 Debian Linux is default on SD Card Linux-based Bootloader available I have also read on some mailing list that this error usually happens when the cpu is overloaded.Is that 32MB SDRAM is insufficient to run xorp ?What are the minimum requirements of hardware to run xorp?Is that the error happens in my case is really because of insufficient processing power or memory requirments? My apologies if I have troubled you. Regards, T.Raga Naresh Kumar, M.Tech,Computer Technology, IIT DELHI See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090902/a595388e/attachment.html From bms at incunabulum.net Wed Sep 2 07:44:43 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 02 Sep 2009 15:44:43 +0100 Subject: [Xorp-users] Error:XrlRouter Failed.No Finder?while running ./xorp_rtrmgr In-Reply-To: <139665.97124.qm@web94814.mail.in2.yahoo.com> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> Message-ID: <4A9E84DB.2020702@incunabulum.net> naresh raga wrote: > ... > > I have also read on some mailing list that this error usually > happens when the cpu is overloaded.Is that 32MB SDRAM is > insufficient to run xorp ? > 32MB is probably really pushing it. 64MB is perhaps a more realistic lower bound. > What are the minimum requirements of hardware to run xorp?Is that > the error happens in my case is really because of insufficient > processing power or memory requirments? > Without run-time profiling, I couldn't say for sure exactly what the minimum requirements would be. I've had XORP run on a PII-400MHz with 128MB of memory, albeit without all routing protocols configured. Again, as development has always happened on x86 systems of reasonable spec, we really rely on user contribution and experimentation here for the community code, except where the code is known to support specific targets. thanks BMS From jtc at acorntoolworks.com Wed Sep 2 10:21:09 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Wed, 02 Sep 2009 10:21:09 -0700 Subject: [Xorp-users] Error:XrlRouter Failed.No Finder?while running ./xorp_rtrmgr In-Reply-To: <139665.97124.qm@web94814.mail.in2.yahoo.com> (naresh raga's message of "Wed, 2 Sep 2009 16:36:24 +0530 (IST)") References: <139665.97124.qm@web94814.mail.in2.yahoo.com> Message-ID: <8763c1s1oa.fsf@orac.acorntoolworks.com> naresh raga writes: > Sorry Bruce,if I am really troubling you.I am so particular about > this because it is my current project target set by my professor.I > will give the TS7300 kit details on which I am working. > > 200MHz ARM9 CPU > PC/104 expansion bus > 32MB SDRAM > 2 10/100 ethernet ports > 1 VGA out w/ 8MB RAM 800x600 > Debian Linux is default on SD Card > Linux-based Bootloader available > > I have also read on some mailing list that this error usually > happens when the cpu is overloaded.Is that 32MB SDRAM is > insufficient to run xorp ?What are the minimum requirements of > hardware to run xorp?Is that the error happens in my case is really > because of insufficient processing power or memory requirments? > > My apologies if I have troubled you. Hi Naresh, There have been improvements to the XORP static footprint that are in the current SVN repo. There is also the ability to build with shared libraries. The combination may make it possible to run, albeit with a very small routing table, on target like yours. XORP's exensible, modular architecture does make it difficult to scale downwards. One thing I've been thinking about is colocating everything in a single process, which would allow us to factor out the IPC. I can't say for certain whether the problems you're experiencing are related to processing power or memory requirements. If I was in your position, I'd look to ensure that the unit tests, especially the XRL tests, function correctly on your target. Beyond that, I'd be looking with tcpdump to capture the I/O between XORP the processes and using a debugger (or inline debug output) to capture the interaction. There may be timeouts that just need to be tweaked. If you do find something interesting, please share it with the rest of the community. --jtc -- J.T. Conklin From rtruitt at hatterasnetworks.com Thu Sep 3 04:28:57 2009 From: rtruitt at hatterasnetworks.com (Roger Truitt) Date: Thu, 3 Sep 2009 07:28:57 -0400 Subject: [Xorp-users] Newbie struggling with Multicast routing In-Reply-To: <4A9F2ED0.3050907@incunabulum.net> References: <467C77F6373BDE4BB16A3E8A62C03955054C3BAA@Exchserv.hatteras.com> <4A9F2ED0.3050907@incunabulum.net> Message-ID: <467C77F6373BDE4BB16A3E8A62C039550557B083@Exchserv.hatteras.com> The TTL of the video stream is set to a value of 10 (should make it through the one hop (router)). _____________________________________________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential and proprietary information of Hatteras Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this email message, please contact the sender by reply email and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. -----Original Message----- From: Bruce Simpson [mailto:bms at incunabulum.net] Sent: Wednesday, September 02, 2009 10:50 PM To: Roger Truitt Subject: Re: [Xorp-users] Newbie struggling with Multicast routing Is the TTL of your video stream set correctly? From vommwa at yahoo.com Mon Sep 7 02:09:50 2009 From: vommwa at yahoo.com (victor omwando) Date: Mon, 7 Sep 2009 02:09:50 -0700 (PDT) Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <8763c1s1oa.fsf@orac.acorntoolworks.com> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> Message-ID: <385207.37478.qm@web56603.mail.re3.yahoo.com> Hello guys, I'm still a bit new to xorp, I have one quick question. I'm running xorp 1.6 on a Debian based virtual machine. I am interested in starting xorp_rtrmgr with a config script, and still get my terminal back after running xorp_rtrmgr -b /path/to/myconfig.config. However, to regain use of my terminal, I find that I have to end the preceding command with an &. Is there any workaround to this that gives me control my shell without me giving it the &? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090907/d882ba22/attachment.html From bms at incunabulum.net Mon Sep 7 02:36:25 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 07 Sep 2009 10:36:25 +0100 Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <385207.37478.qm@web56603.mail.re3.yahoo.com> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> Message-ID: <4AA4D419.9040803@incunabulum.net> victor omwando wrote: > > Hello guys, I'm still a bit new to xorp, I have one quick question. > I'm running xorp 1.6 on a Debian based virtual machine. I am > interested in starting xorp_rtrmgr with a config script, and still get > my terminal back after running xorp_rtrmgr -b > /path/to/myconfig.config. However, to regain use of my terminal, I > find that I have to end the preceding command with an &. Is there any > workaround to this that gives me control my shell without me giving it > the &? Thanks. Sounds like you want the -d option. Feel free to add documentation (or contribute a man page) if it isn't present already. The -L and -P options may also need documenting, these control logging and PID file creation. See also: http://xorp.svn.sourceforge.net/viewvc/xorp/trunk/xorp/rtrmgr/main_rtrmgr.cc?r1=10710&r2=10711 A fix for syslog support exists in SVN trunk which does not exist in the 1.6 release. From vommwa at yahoo.com Mon Sep 7 08:12:02 2009 From: vommwa at yahoo.com (victor omwando) Date: Mon, 7 Sep 2009 08:12:02 -0700 (PDT) Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <4AA4D419.9040803@incunabulum.net> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> <4AA4D419.9040803@incunabulum.net> Message-ID: <96999.26466.qm@web56608.mail.re3.yahoo.com> I'll look into adding documentation for that pretty soon. Thanks very much. ________________________________ From: Bruce Simpson To: victor omwando Cc: xorp-users at xorp.org Sent: Monday, September 7, 2009 2:36:25 AM Subject: Re: [Xorp-users] running xorp_rtrmgr victor omwando wrote: > > Hello guys, I'm still a bit new to xorp, I have one quick question. I'm running xorp 1.6 on a Debian based virtual machine. I am interested in starting xorp_rtrmgr with a config script, and still get my terminal back after running xorp_rtrmgr -b /path/to/myconfig.config. However, to regain use of my terminal, I find that I have to end the preceding command with an &. Is there any workaround to this that gives me control my shell without me giving it the &? Thanks. Sounds like you want the -d option. Feel free to add documentation (or contribute a man page) if it isn't present already. The -L and -P options may also need documenting, these control logging and PID file creation. See also: http://xorp.svn.sourceforge.net/viewvc/xorp/trunk/xorp/rtrmgr/main_rtrmgr.cc?r1=10710&r2=10711 A fix for syslog support exists in SVN trunk which does not exist in the 1.6 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090907/d8146d5c/attachment.html From vommwa at yahoo.com Mon Sep 7 08:19:46 2009 From: vommwa at yahoo.com (victor omwando) Date: Mon, 7 Sep 2009 08:19:46 -0700 (PDT) Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <4AA4D419.9040803@incunabulum.net> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> <4AA4D419.9040803@incunabulum.net> Message-ID: <896011.1106.qm@web56601.mail.re3.yahoo.com> Is there a way to update the documentation available on the XORP website? I found that the xorp_rtrmgr manpage describes the use of the -d switch, but just in general, I feel some changes to the pdf are forthcoming, especially to improve it in terms of clarity in some areas. Thanks. ________________________________ From: Bruce Simpson To: victor omwando Cc: xorp-users at xorp.org Sent: Monday, September 7, 2009 2:36:25 AM Subject: Re: [Xorp-users] running xorp_rtrmgr victor omwando wrote: > > Hello guys, I'm still a bit new to xorp, I have one quick question. I'm running xorp 1.6 on a Debian based virtual machine. I am interested in starting xorp_rtrmgr with a config script, and still get my terminal back after running xorp_rtrmgr -b /path/to/myconfig.config. However, to regain use of my terminal, I find that I have to end the preceding command with an &. Is there any workaround to this that gives me control my shell without me giving it the &? Thanks. Sounds like you want the -d option. Feel free to add documentation (or contribute a man page) if it isn't present already. The -L and -P options may also need documenting, these control logging and PID file creation. See also: http://xorp.svn.sourceforge.net/viewvc/xorp/trunk/xorp/rtrmgr/main_rtrmgr.cc?r1=10710&r2=10711 A fix for syslog support exists in SVN trunk which does not exist in the 1.6 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090907/04f9cb60/attachment.html From vommwa at yahoo.com Mon Sep 7 08:59:49 2009 From: vommwa at yahoo.com (victor omwando) Date: Mon, 7 Sep 2009 08:59:49 -0700 (PDT) Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <896011.1106.qm@web56601.mail.re3.yahoo.com> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> <4AA4D419.9040803@incunabulum.net> <896011.1106.qm@web56601.mail.re3.yahoo.com> Message-ID: <254262.47368.qm@web56608.mail.re3.yahoo.com> Another thing, still keeping with the -d and -b options, I find that I can't use both at the same time ie if I use -d first, the xorp_Rtrmgr process will be daemonized,but it wil ltry and open /usr/lib/xorp/boot.config, regardless of which config file I specify using the -b option. When -b comes first, the process does not daemonize. Also, is there a gatekeeping system in place for the SVN repos? Thanks. ________________________________ From: victor omwando To: Bruce Simpson Cc: xorp-users at xorp.org Sent: Monday, September 7, 2009 8:19:46 AM Subject: Re: [Xorp-users] running xorp_rtrmgr Is there a way to update the documentation available on the XORP website? I found that the xorp_rtrmgr manpage describes the use of the -d switch, but just in general, I feel some changes to the pdf are forthcoming, especially to improve it in terms of clarity in some areas. Thanks. ________________________________ From: Bruce Simpson To: victor omwando Cc: xorp-users at xorp.org Sent: Monday, September 7, 2009 2:36:25 AM Subject: Re: [Xorp-users] running xorp_rtrmgr victor omwando wrote: > > Hello guys, I'm still a bit new to xorp, I have one quick question. I'm running xorp 1.6 on a Debian based virtual machine. I am interested in starting xorp_rtrmgr with a config script, and still get my terminal back after running xorp_rtrmgr -b /path/to/myconfig.config. However, to regain use of my terminal, I find that I have to end the preceding command with an &. Is there any workaround to this that gives me control my shell without me giving it the &? Thanks. Sounds like you want the -d option. Feel free to add documentation (or contribute a man page) if it isn't present already. The -L and -P options may also need documenting, these control logging and PID file creation. See also: http://xorp.svn.sourceforge.net/viewvc/xorp/trunk/xorp/rtrmgr/main_rtrmgr.cc?r1=10710&r2=10711 A fix for syslog support exists in SVN trunk which does not exist in the 1.6 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090907/b00161a6/attachment.html From bms at incunabulum.net Mon Sep 7 09:25:28 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 07 Sep 2009 17:25:28 +0100 Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <254262.47368.qm@web56608.mail.re3.yahoo.com> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> <4AA4D419.9040803@incunabulum.net> <896011.1106.qm@web56601.mail.re3.yahoo.com> <254262.47368.qm@web56608.mail.re3.yahoo.com> Message-ID: <4AA533F8.70507@incunabulum.net> victor omwando wrote: > Another thing, still keeping with the -d and -b options, I find that I > can't use both at the same time ie if I use -d first, the xorp_Rtrmgr > process will be daemonized,but it wil ltry and open > /usr/lib/xorp/boot.config, regardless of which config file I specify > using the -b option. When -b comes first, the process > does not daemonize. Also, is there a gatekeeping system in place for > the SVN repos? Thanks. At the moment, only JT Conklin and I have commit access to the public SVN. We'd like to open it up to contributors, and docs/ would be an excellent starting point, as these changes are usually much easier to review and push in than for the source code itself (the xorp/ module on trunk). To update the PDF documentation, you'll need to check out the docs/ module in the repository, and update the LaTeX source files. The docs/ themselves are now also built with SCons, and you'll need a full TeTeX or similar toolchain installed; usually, installing Kile (the KDE LaTeX editor) is enough to pull in all the tools you'll need on most systems. Thanks for pointing out that the -b switch apparently can't co-exist with -d. I don't see the "boot.config" filename referenced anywhere in the source tree, perhaps you mean "config.boot" ? Reading the main_rtrmgr.cc file, the processing of the 'd' switch happens in the same switch() block as for the 'b' switch; I don't see any code which could obviously clobber the value of 'boot_file' in main(). Are you specifying an absolute path to the configuration when you use the 'd' switch? The call to daemonize the Router Manager does not change to the root directory, unlike most daemons, so relative paths should still work. Can you confirm that you are seeing the issue with the latest SVN code? If so, please submit a bug report via Trac on SourceForge, and fill out which OS/distribution/architecture you are using, and I'll try to reproduce this when I can:- https://sourceforge.net/apps/trac/xorp/ You will need a SourceForge account to submit bug reports, or participate in development in XORP SVN. thanks, BMS From jtc at acorntoolworks.com Mon Sep 7 09:49:00 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Mon, 07 Sep 2009 09:49:00 -0700 Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <896011.1106.qm@web56601.mail.re3.yahoo.com> (victor omwando's message of "Mon, 7 Sep 2009 08:19:46 -0700 (PDT)") References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> <4AA4D419.9040803@incunabulum.net> <896011.1106.qm@web56601.mail.re3.yahoo.com> Message-ID: <87ws4asnsz.fsf@orac.acorntoolworks.com> victor omwando writes: > Is there a way to update the documentation available on the XORP > website? I found that the xorp_rtrmgr manpage describes the use of > the -d switch, but just in general, I feel some changes to the pdf > are forthcoming, especially to improve it in terms of clarity in > some areas. Thanks. Hi Victor, The documentation is treated as if it was source code, and patches to it can be submitted in just the same way as patches to the routing code itself. The "source code" for the documentation used to be in the same module as the rest of the XORP source, but in the new SVN repo it has been moved to it's own repo. With the move to SF, there is also the Trac wiki. It currently has the default contents, but I believe this is a good place for community members to contribute. A Frequently Asked Questions (FAQ) page immediately comes to mind. Organization and content doesn't have to be perfect up front. In my experience, proper organization doesn't become apparent until there is sufficent content. --jtc -- J.T. Conklin From vommwa at yahoo.com Tue Sep 8 10:02:06 2009 From: vommwa at yahoo.com (victor omwando) Date: Tue, 8 Sep 2009 10:02:06 -0700 (PDT) Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <4AA533F8.70507@incunabulum.net> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> <4AA4D419.9040803@incunabulum.net> <896011.1106.qm@web56601.mail.re3.yahoo.com> <254262.47368.qm@web56608.mail.re3.yahoo.com> <4AA533F8.70507@incunabulum.net> Message-ID: <316168.57680.qm@web56604.mail.re3.yahoo.com> >Thanks for pointing out that the -b switch apparently can't co-exist with -d. I don't see the "boot.config" filename referenced anywhere in the source tree, perhaps you mean "config.boot" ? >Reading the main_rtrmgr.cc file, the processing of the 'd' switch happens in the same switch() block as for the 'b' switch; I don't see any code which could obviously clobber the value of 'boot_file' in main(). >Are you specifying an absolute path to the configuration when you use the 'd' switch? The call to daemonize the Router Manager does not change to the root directory, unlike most daemons, so relative paths should still work. >Can you confirm that you are seeing the issue with the latest SVN code? If so,please submit a bug report via Trac on SourceForge, and fill out which OS/distribution/architecture you are using, and I'll try to reproduce this when I can:- https://sourceforge.net/apps/trac/xorp/ >You will need a SourceForge account to submit bug reports, or participate in development in XORP SVN. Oh, sorry I meant config.boot. After downloading the latest sourcee from the repo and corss-compiling it, rerun rtrmgr and the problem did not show up. I was using an old version of xorp-1.6 that I obtained from the website a few months back and did not really work with. Everything checks out now. ________________________________ From: Bruce Simpson To: victor omwando Cc: xorp-users at xorp.org Sent: Monday, September 7, 2009 9:25:28 AM Subject: Re: [Xorp-users] running xorp_rtrmgr victor omwando wrote: > Another thing, still keeping with the -d and -b options, I find that I can't use both at the same time ie if I use -d first, the xorp_Rtrmgr process will be daemonized,but it wil ltry and open /usr/lib/xorp/boot.config, regardless of which config file I specify using the -b option. When -b comes first, the process does not daemonize. Also, is there a gatekeeping system in place for the SVN repos? Thanks. At the moment, only JT Conklin and I have commit access to the public SVN. We'd like to open it up to contributors, and docs/ would be an excellent starting point, as these changes are usually much easier to review and push in than for the source code itself (the xorp/ module on trunk). To update the PDF documentation, you'll need to check out the docs/ module in the repository, and update the LaTeX source files. The docs/ themselves are now also built with SCons, and you'll need a full TeTeX or similar toolchain installed; usually, installing Kile (the KDE LaTeX editor) is enough to pull in all the tools you'll need on most systems. Thanks for pointing out that the -b switch apparently can't co-exist with -d. I don't see the "boot.config" filename referenced anywhere in the source tree, perhaps you mean "config.boot" ? Reading the main_rtrmgr.cc file, the processing of the 'd' switch happens in the same switch() block as for the 'b' switch; I don't see any code which could obviously clobber the value of 'boot_file' in main(). Are you specifying an absolute path to the configuration when you use the 'd' switch? The call to daemonize the Router Manager does not change to the root directory, unlike most daemons, so relative paths should still work. Can you confirm that you are seeing the issue with the latest SVN code? If so, please submit a bug report via Trac on SourceForge, and fill out which OS/distribution/architecture you are using, and I'll try to reproduce this when I can:- https://sourceforge.net/apps/trac/xorp/ You will need a SourceForge account to submit bug reports, or participate in development in XORP SVN. thanks, BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090908/9210ddb6/attachment.html From bms at incunabulum.net Wed Sep 9 08:38:24 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 09 Sep 2009 16:38:24 +0100 Subject: [Xorp-users] running xorp_rtrmgr In-Reply-To: <316168.57680.qm@web56604.mail.re3.yahoo.com> References: <139665.97124.qm@web94814.mail.in2.yahoo.com> <8763c1s1oa.fsf@orac.acorntoolworks.com> <385207.37478.qm@web56603.mail.re3.yahoo.com> <4AA4D419.9040803@incunabulum.net> <896011.1106.qm@web56601.mail.re3.yahoo.com> <254262.47368.qm@web56608.mail.re3.yahoo.com> <4AA533F8.70507@incunabulum.net> <316168.57680.qm@web56604.mail.re3.yahoo.com> Message-ID: <4AA7CBF0.7090303@incunabulum.net> Victor, Thanks for confirming the daemonization issue appears to be gone. Currently the LiveUSB build of XORP has not been modified to take advantage of the daemonization and syslog features; it was developed before daemon mode was fully introduced, so it polls the Router Manager's log files for startup (lame, I know, but there was really no other way to deliver by the specific deadline involved). victor omwando wrote: > > Oh, sorry I meant config.boot. After downloading the latest sourcee > from the repo and corss-compiling it, rerun rtrmgr and the problem did > not show up. I was using an old version of xorp-1.6 that I obtained > from the website a few months back and did not really work with. You are cross-compiling the SVN code? If you have modified the SCons files to handle cross-compilation, it would be great to see patches as it would help others in this forum. If you can think of better wording for documentation, please do send us a patch and we'll check it in. thanks again, BMS From naresh_raga at yahoo.co.in Tue Sep 15 05:04:49 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Tue, 15 Sep 2009 17:34:49 +0530 (IST) Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP Message-ID: <972049.98116.qm@web94801.mail.in2.yahoo.com> Hi, I have checked out a copy of xorp 1.7-WIP from https://xorp.svn.sourceforge.net/svnroot/xorp/trunk/xorp raganaresh at raganaresh-laptop:~/xorp$ scons scons: Reading SConscript files ... NameError: name 'Variables' is not defined: ? File "/home/raganaresh/xorp/SConstruct", line 52: ??? vars = Variables() What is Variables.Also I need to know is the checked out version contain all the functionalities of xorp. Regards, Naresh. Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090915/1ac86a69/attachment.html From jtc at acorntoolworks.com Tue Sep 15 07:23:27 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Tue, 15 Sep 2009 07:23:27 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <972049.98116.qm@web94801.mail.in2.yahoo.com> (naresh raga's message of "Tue, 15 Sep 2009 17:34:49 +0530 (IST)") References: <972049.98116.qm@web94801.mail.in2.yahoo.com> Message-ID: <87zl8w8exs.fsf@orac.acorntoolworks.com> Hi Naresh, naresh raga writes: > Hi, > I have checked out a copy of xorp 1.7-WIP from > > https://xorp.svn.sourceforge.net/svnroot/xorp/trunk/xorp > > raganaresh at raganaresh-laptop:~/xorp$ scons > scons: Reading SConscript files ... > NameError: name 'Variables' is not defined: > ? File "/home/raganaresh/xorp/SConstruct", line 52: > ??? vars = Variables() > > What is Variables.Also I need to know is the checked out version > contain all the functionalities of xorp. Variables is a SCons feature for managing command line arguments. It appears that the version of SCons on your system doesn't have it; you may have to upgrade to the current version. I'll add something to the toplevel SConstruct file to handle the error better. Yes, the version you checked out is the most current code. --jtc -- J.T. Conklin From naresh_raga at yahoo.co.in Tue Sep 15 10:27:43 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Tue, 15 Sep 2009 22:57:43 +0530 (IST) Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <87zl8w8exs.fsf@orac.acorntoolworks.com> Message-ID: <636295.79659.qm@web94809.mail.in2.yahoo.com> > raganaresh at raganaresh-laptop:~/xorp$ scons > scons: Reading SConscript files ... > NameError: name 'Variables' is not defined: > ? File "/home/raganaresh/xorp/SConstruct", line 52: > ??? vars = Variables() > > What is Variables.Also I need to know is the checked out version > contain all the functionalities of xorp. >Variables is a SCons feature for managing command line arguments.? It >appears that the version of SCons on your system doesn't have it; you? >may have to upgrade to the current version.? I'll add something to >the toplevel SConstruct file to handle the error better. Thanks J.T.Conklin. Yes,The problem is with the version.I have upgraded scons to the current version 1.2.Now ,Its running properly.Now I have one more question.Can I build this current version of xorp for arm architecture using cross-compiler following the steps in BUILD_NOTES. Thanks, Naresh. Yahoo! India has a new look. Take a sneak peek http://in.yahoo.com/trynew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090915/f8b3a636/attachment.html From naresh_raga at yahoo.co.in Tue Sep 15 10:58:05 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Tue, 15 Sep 2009 23:28:05 +0530 (IST) Subject: [Xorp-users] Error:XrlRouter Failed.No Finder?while running ./xorp_rtrmgr Message-ID: <923070.19527.qm@web94802.mail.in2.yahoo.com> >Hi Naresh, >There have been improvements to the XORP static footprint that are in >the current SVN repo. There is also the ability to build with shared >libraries. The combination may make it possible to run, albeit with a >very small routing table, on target like yours. >XORP's exensible, modular architecture does make it difficult to scale >downwards. One thing I've been thinking about is colocating everything >in a single process, which would allow us to factor out the IPC. >I can't say for certain whether the problems you're experiencing are >related to processing power or memory requirements. If I was in your >position, I'd look to ensure that the unit tests, especially the XRL >tests, function correctly on your target. Beyond that, I'd be looking >with tcpdump to capture the I/O between XORP the processes and using >a debugger (or inline debug output) to capture the interaction. There >may be timeouts that just need to be tweaked. >If you do find something interesting, please share it with the rest of >the community. > --jtc -- >J.T. Conklin Thanks Bruce and J.T.Conklin for your valuable suggestions. You said that xorp can be build with shared libraries. How to build xorp with shared libraries so that my executable xorp_rtrmgr would be small in size. Try the new Yahoo! India Homepage. Click here. http://in.yahoo.com/trynew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090915/bf7f7fe2/attachment.html From jtc at acorntoolworks.com Tue Sep 15 11:02:37 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Tue, 15 Sep 2009 11:02:37 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <636295.79659.qm@web94809.mail.in2.yahoo.com> (naresh raga's message of "Tue, 15 Sep 2009 22:57:43 +0530 (IST)") References: <636295.79659.qm@web94809.mail.in2.yahoo.com> Message-ID: <873a6odr2a.fsf@orac.acorntoolworks.com> Hi Naresh, naresh raga writes: > Thanks J.T.Conklin. > > Yes,The problem is with the version.I have upgraded scons to the > current version 1.2.Now ,Its running properly.Now I have one more > question.Can I build this current version of xorp for arm > architecture using cross-compiler following the steps in > BUILD_NOTES. No, you won't be able to build with the steps in BUILD_NOTES, as the support for the GNU Build System (GBS) based build has been removed. This is something we'll need to update for the 1.7 RC. In a way, I'm glad you pointed this out. Cross compilation support is not up to the same standard as it was with the GBS build, but it _should_ be possible with a little work. You may run into some rough edges that you'll have to adapt to. Ideally, something like: scons arch=arm os=linux CC=arm-linux-gcc CXX=arm-linux-g++ would work, but there isn't any code to allow you to override CC or CXX in the toplevel SConstruct yet. For now, you'll have to edit it and explicitly set env['CC'] and env['CXX']. See where we do it for env['STRIP']. I'll see if I can add a command line override of CC and CXX in the next day or so. --jtc -- J.T. Conklin From naresh_raga at yahoo.co.in Tue Sep 15 11:04:01 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Tue, 15 Sep 2009 23:34:01 +0530 (IST) Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <636295.79659.qm@web94809.mail.in2.yahoo.com> Message-ID: <573662.823.qm@web94807.mail.in2.yahoo.com> Hi Conklin and Bruce, Now I am facing new error with scons build of xorp-1.7-WIP obj/i686-linux-public17/libxipc/libxipc.a(hmac_md5.o): In function `hmac_md5': /home/student/xorp/libxipc/hmac_md5.c:63: undefined reference to `MD5_Init' /home/student/xorp/libxipc/hmac_md5.c:64: undefined reference to `MD5_Update' /home/student/xorp/libxipc/hmac_md5.c:65: undefined reference to `MD5_Final' /home/student/xorp/libxipc/hmac_md5.c:96: undefined reference to `MD5_Init' /home/student/xorp/libxipc/hmac_md5.c:97: undefined reference to `MD5_Update' /home/student/xorp/libxipc/hmac_md5.c:98: undefined reference to `MD5_Update' /home/student/xorp/libxipc/hmac_md5.c:99: undefined reference to `MD5_Final' /home/student/xorp/libxipc/hmac_md5.c:103: undefined reference to `MD5_Init' /home/student/xorp/libxipc/hmac_md5.c:104: undefined reference to `MD5_Update' /home/student/xorp/libxipc/hmac_md5.c:105: undefined reference to `MD5_Update' /home/student/xorp/libxipc/hmac_md5.c:106: undefined reference to `MD5_Final' collect2: ld returned 1 exit status scons: *** [obj/i686-linux-public17/libxipc/call_xrl] Error 1 scons: building terminated because of errors. What is this error.How to get rid of it.Where are the definitions of functions related to MD5. Thanks, Naresh Add whatever you love to the Yahoo! India homepage. Try now! http://in.yahoo.com/trynew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090915/82d4ab1c/attachment.html From jtc at acorntoolworks.com Tue Sep 15 11:07:48 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Tue, 15 Sep 2009 11:07:48 -0700 Subject: [Xorp-users] Error:XrlRouter Failed.No Finder?while running ./xorp_rtrmgr In-Reply-To: <923070.19527.qm@web94802.mail.in2.yahoo.com> (naresh raga's message of "Tue, 15 Sep 2009 23:28:05 +0530 (IST)") References: <923070.19527.qm@web94802.mail.in2.yahoo.com> Message-ID: <87vdjkcc97.fsf@orac.acorntoolworks.com> naresh raga writes: > Thanks Bruce and J.T.Conklin for your valuable suggestions. > You said that xorp can be build with shared libraries. > How to build xorp with shared libraries so that my executable xorp_rtrmgr > would be small in size. Hi Naresh, Use: scons shared=True to build the XORP code from the SVN repo with shared libraries. I think you'll find a substantial static footprint reduction. --jtc -- J.T. Conklin From jtc at acorntoolworks.com Tue Sep 15 11:27:56 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Tue, 15 Sep 2009 11:27:56 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <573662.823.qm@web94807.mail.in2.yahoo.com> (naresh raga's message of "Tue, 15 Sep 2009 23:34:01 +0530 (IST)") References: <573662.823.qm@web94807.mail.in2.yahoo.com> Message-ID: <87hbv4cbbn.fsf@orac.acorntoolworks.com> naresh raga writes: > Hi Conklin and Bruce, > Now I am facing new error with scons build of xorp-1.7-WIP > > obj/i686-linux-public17/libxipc/libxipc.a(hmac_md5.o): In function `hmac_md5': > /home/student/xorp/libxipc/hmac_md5.c:63: undefined reference to `MD5_Init' > [...] > scons: building terminated because of errors. > > What is this error.How to get rid of it. Where are the definitions > of functions related to MD5. Hi Naresh, XORP uses the crypto functions from OpenSSL's libcrypto library. libcrypto should be added to each SCons environment that is used to build/link an executable that uses libxipc. As far as I can tell, this is only currently done in libproto. We may have missed this because many systems now have MD5 functions with the same API/ABI in libc as well. You may be in the best position to find out where this is needed. If you are able to fix the problem for your system, please send the patch to us and we'll try to integrate it. --jtc -- J.T. Conklin From jtc at acorntoolworks.com Tue Sep 15 14:22:55 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Tue, 15 Sep 2009 14:22:55 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <873a6odr2a.fsf@orac.acorntoolworks.com> (J. T. Conklin's message of "Tue, 15 Sep 2009 11:02:37 -0700") References: <636295.79659.qm@web94809.mail.in2.yahoo.com> <873a6odr2a.fsf@orac.acorntoolworks.com> Message-ID: <87d45raonk.fsf@orac.acorntoolworks.com> jtc at acorntoolworks.com (J.T. Conklin) writes: > Cross compilation support is not up to the same standard as it was > with the GBS build, but it _should_ be possible with a little work. > You may run into some rough edges that you'll have to adapt to. > > Ideally, something like: > > scons arch=arm os=linux CC=arm-linux-gcc CXX=arm-linux-g++ > > would work, but there isn't any code to allow you to override CC or > CXX in the toplevel SConstruct yet. For now, you'll have to edit it > and explicitly set env['CC'] and env['CXX']. See where we do it for > env['STRIP']. > > I'll see if I can add a command line override of CC and CXX in the > next day or so. Hi Naresh, I added this to the SVN repo's SConstruct this morning, and tested it a cross building for a powerpc 85xx using ELDK 4.2. There was a small problem in VRRP related to pointer alignment, that I think you'll find with the arm as well, but other than that it built fine. For reference, the command line I used was: scons CC=powerpc-linux-gcc CXX=powerpc-linux-g++ STRIP=powerpc-linux-strip arch=powerpc os=linux strip=True DESTDIR=/tmp/foo install Hope this helps. --jtc -- J.T. Conklin From naresh_raga at yahoo.co.in Wed Sep 16 03:45:20 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Wed, 16 Sep 2009 16:15:20 +0530 (IST) Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <87d45raonk.fsf@orac.acorntoolworks.com> Message-ID: <259122.97223.qm@web94808.mail.in2.yahoo.com> Thanks J.T.Conklin, I have successfully build xorp1.7-WIP on my ubuntu 9.04 x86 machine.I am facing one more problem. student at student-desktop:~/xorp/obj/i686-linux-public17/rtrmgr$ sudo ./xorp_rtrmgr [sudo] password for student: [ 2009/09/16 15:57:31? ERROR xorp_rtrmgr:28855 RTRMGR +245 rtrmgr/main_rtrmgr.cc run ] Shutting down due to an init error: Failed to find XRL files in /home/student/xorp/xrl/targets Actually the targets are in /home/student/xorp/obj/i686-linux-public17/xrl/. But the xorp_rtrmgr is searching for targets in xrl folder in the top directory of xorp.Actually this would be the case with previous versions.I think now all the executables are in the obj folder.Even now I am running xorp_rtrmgr executable from obj/i686-linux-public17/rtrmgr/. Conklin please adjust the path that xorp_rtrmgr is searching for. Thanks, Naresh. Add whatever you love to the Yahoo! India homepage. Try now! http://in.yahoo.com/trynew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090916/7938a792/attachment.html From bms at incunabulum.net Wed Sep 16 04:04:21 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 16 Sep 2009 12:04:21 +0100 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <259122.97223.qm@web94808.mail.in2.yahoo.com> References: <259122.97223.qm@web94808.mail.in2.yahoo.com> Message-ID: <4AB0C635.1030208@incunabulum.net> naresh raga wrote: > > Conklin please adjust the path that xorp_rtrmgr is searching for. > Off the top of my head, you need to specify the '-t' switch to xorp_rtrmgr to change the search path for the template files. However I'm not sure this will work for the XRL files -- I think you need to set XORP_ROOT in the environment to point to obj/ here, as it will have the layout it's looking for -- assuming you are trying to run XORP from a SCons build directory without installing it. From rtruitt at hatterasnetworks.com Tue Sep 15 07:02:42 2009 From: rtruitt at hatterasnetworks.com (Roger Truitt) Date: Tue, 15 Sep 2009 10:02:42 -0400 Subject: [Xorp-users] Newbie struggling with Multicast routing Message-ID: <467C77F6373BDE4BB16A3E8A62C03955056432C5@Exchserv.hatteras.com> Making some progress but still not successful getting multicast xorp router running with CentOS 5 Linux. Found mc_forwarding was set to zero and was read-only. Recompiled the kernel, now running version 2.6.30.6. Mc_forwarding is now set to 1 but the video packets are still not being forwarded from eth 1 to eth2. The Iif in the ip_mr_cache now looks bogus (-1). root at st-linux1 rtrmgr]# cat //proc//net/ip_mr_cache Group Origin Iif Pkts Bytes Wrong Oifs 010101EB 010A0A0A -1 0 0 0 xorp at st-linux1.hatteras.com> show mfea interface Interface State Vif/PifIndex Addr Flags eth1 UP 0/2 10.10.10.10 MULTICAST BROADCAST KERN_UP eth2 UP 1/4 10.20.20.20 MULTICAST BROADCAST KERN_UP register_vif UP 2/2 10.10.10.10 PIM_REGISTER KERN_UP xorp at st-linux1.hatteras.com> show igmp group Interface Group Source LastReported Timeout V State eth1 224.0.0.2 0.0.0.0 10.10.10.10 183 2 E eth1 224.0.0.22 0.0.0.0 10.10.10.10 181 2 E eth1 224.0.0.251 0.0.0.0 10.10.10.10 184 2 E eth2 224.0.0.2 0.0.0.0 10.20.20.20 185 2 E eth2 224.0.0.22 0.0.0.0 10.20.20.20 179 2 E eth2 224.0.0.251 0.0.0.0 10.20.20.20 188 2 E eth2 235.1.1.1 0.0.0.0 10.20.20.5 180 2 E xorp at st-linux1.hatteras.com> show igmp interface [root at st-linux1 rtrmgr]# cat config.boot /* $XORP: xorp/rtrmgr/config/multicast4.boot,v 1.1 2007/08/29 06:49:43 pavlin Exp $ */ interfaces { interface eth1 { disable: false discard: false vif eth1 { address 10.10.10.10 { prefix-length: 24 broadcast: 10.10.10.255 disable: false } } } interface eth2 { disable: false discard: false vif eth2 { address 10.20.20.20 { prefix-length: 24 disable: false } } } } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { 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 eth1 { vif eth1 { version: 2 disable: false enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } interface eth2 { vif eth2 { version: 2 disable: false enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag all { disable: false } } } fib2mrib { disable: false } } /* protocols { static { mrib-route 10.30.0.0/16 { next-hop: 10.10.10.20 } } } */ [root at st-linux1 rtrmgr]# 2009/09/15 08:04:52 INFO xorp_igmp MLD6IGMP ] Protocol enabled [ 2009/09/15 08:04:52 INFO xorp_igmp MLD6IGMP ] CLI enabled [ 2009/09/15 08:04:52 INFO xorp_igmp MLD6IGMP ] CLI started [ 2009/09/15 08:04:53 INFO xorp_igmp MLD6IGMP ] Protocol started [ 2009/09/15 08:04:53 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] pif_index: 2 vif_index: 0 addr: 10.10.10.10 subnet: 10.10.10.0/24 broadcast: 10.10.10.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2009/09/15 08:04:53 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth2] pif_index: 4 vif_index: 1 addr: 10.20.20.20 subnet: 10.20.20.0/24 broadcast: 10.20.20.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2009/09/15 08:04:54 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth1] pif_index: 2 vif_index: 0 addr: 10.10.10.10 subnet: 10.10.10.0/24 broadcast: 10.10.10.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2009/09/15 08:04:54 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth1] pif_index: 2 vif_index: 0 addr: 10.10.10.10 subnet: 10.10.10.0/24 broadcast: 10.10.10.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2009/09/15 08:04:54 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth2] pif_index: 4 vif_index: 1 addr: 10.20.20.20 subnet: 10.20.20.0/24 broadcast: 10.20.20.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2009/09/15 08:04:54 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth2] pif_index: 4 vif_index: 1 addr: 10.20.20.20 subnet: 10.20.20.0/24 broadcast: 10.20.20.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2009/09/15 08:04:54 INFO xorp_rtrmgr:3719 RTRMGR +2233 task.cc run_task ] No more tasks to run [ 2009/09/15 09:56:02 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.10.10.10 to 224.0.0.1 [ 2009/09/15 09:56:02 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.10.10.10 to 224.0.0.1 on vif eth1 [ 2009/09/15 09:56:02 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.20.20.20 to 224.0.0.1 [ 2009/09/15 09:56:02 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.20.20.20 to 224.0.0.1 on vif eth2 [ 2009/09/15 09:56:03 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.20 to 224.0.0.22 on vif eth2 [ 2009/09/15 09:56:05 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:56:06 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.20 to 224.0.0.2 on vif eth2 [ 2009/09/15 09:56:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.10.10.1 to 224.0.0.251 on vif eth1 [ 2009/09/15 09:56:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.20 to 224.0.0.251 on vif eth2 [ 2009/09/15 09:56:08 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.10.10.10 to 224.0.0.2 on vif eth1 [ 2009/09/15 09:56:08 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.5 to 235.1.1.1 on vif eth2 [ 2009/09/15 09:56:12 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.10.10.10 to 224.0.0.22 on vif eth1 [ 2009/09/15 09:56:15 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:56:25 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:56:35 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:56:45 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:56:55 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:57:05 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:57:15 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:57:25 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:57:35 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:57:45 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:57:55 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:58:05 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:58:07 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.10.10.10 to 224.0.0.1 [ 2009/09/15 09:58:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.10.10.10 to 224.0.0.1 on vif eth1 [ 2009/09/15 09:58:07 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.20.20.20 to 224.0.0.1 [ 2009/09/15 09:58:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.20.20.20 to 224.0.0.1 on vif eth2 [ 2009/09/15 09:58:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.10.10.10 to 224.0.0.22 on vif eth1 [ 2009/09/15 09:58:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.10.10.10 to 224.0.0.2 on vif eth1 [ 2009/09/15 09:58:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.10.10.10 to 224.0.0.251 on vif eth1 [ 2009/09/15 09:58:09 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.5 to 235.1.1.1 on vif eth2 [ 2009/09/15 09:58:10 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.20 to 224.0.0.251 on vif eth2 [ 2009/09/15 09:58:13 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.20 to 224.0.0.2 on vif eth2 [ 2009/09/15 09:58:14 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.20.20.20 to 224.0.0.22 on vif eth2 [ 2009/09/15 09:58:15 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 [ 2009/09/15 09:58:25 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.10.10.1 dst = 235.1.1.1 _____________________________________________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential and proprietary information of Hatteras Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this email message, please contact the sender by reply email and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090915/ceff20b1/attachment-0001.html From jtc at acorntoolworks.com Wed Sep 16 10:24:15 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Wed, 16 Sep 2009 10:24:15 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <259122.97223.qm@web94808.mail.in2.yahoo.com> (naresh raga's message of "Wed, 16 Sep 2009 16:15:20 +0530 (IST)") References: <259122.97223.qm@web94808.mail.in2.yahoo.com> Message-ID: <87ab0uref4.fsf@orac.acorntoolworks.com> naresh raga writes: > I have successfully build xorp1.7-WIP on my ubuntu 9.04 x86 > machine.I am facing one more problem. > > [...] > But the xorp_rtrmgr is searching for targets in xrl folder in the > top directory of xorp.Actually this would be the case with previous > versions.I think now all the executables are in the obj folder.Even > now I am running xorp_rtrmgr executable from > obj/i686-linux-public17/rtrmgr/. Conklin please adjust the path > that xorp_rtrmgr is searching for. Hi Naresh, I think Bruce is correct in assuming that you're trying to run the executables in the build/object directory instead of an install tree. While I think you can make this work by following Bruce's advice, I'll recommend that you "install" XORP and use it from the install location. By default, the install location is /usr/local/xorp. You may already know this, but this can be overriden by specifying "prefix=/foo/bar/quux" on the command line when you invoke scons. In the past, it was possible to run XORP in-situ in the build directory. IMO, this introduced compromises in both the source and install filesystem hierarchy. For example, in the source tree, the XRL target and interface files, router manager templates, etc. for all protocol modules are coupled together in common directories. And in the install tree, the directory layout is forced to mirror the source tree, instead of using a more standard layout with bin, sbin, lib, etc, subdirectories described in BSD hier(7) or the GNU standards. Over time, we have the ability to address these sorts of issues, at the expense of running in-situ. So even if it's currently possible to run in the build/object tree, I would recommend getting into the habit of installing and running from there. --jtc -- J.T. Conklin From gibsonc at gmail.com Wed Sep 16 13:58:27 2009 From: gibsonc at gmail.com (Chris Gibson) Date: Wed, 16 Sep 2009 13:58:27 -0700 Subject: [Xorp-users] Looking for XORP performance metrics Message-ID: Hello xorp-users, I have been looking for performance and scalability metrics for XORP. I'm specifically interested in the performance and scalability numbers for the xorp_bgp implementation. This periodically appears to come up on various xorp-* mailing lists, yet I cannot seem to find any solid, good quality research. The best thing I have really found up to now has been Hasso's 2006 work and subsequent paper, which I assume is now sufficiently outdated to not be of any immediate relevance. To give you an idea of the sort of data that I am searching for: * Scalability numbers for xorp_bgp: - e.g. number of routes, number of peers, routes per peer, memory usage, cpu utilization, convergence times, what hardware the tests were run on, etc. * How the rest of XORP performs: - e.g. performance of policy engine, cli memory/cpu usage under multi-user load, IPC overhead, fea vs number of interfaces, etc. Does anyone know where I could find this data or have their own data that they would like to share? If you don't have any data to share, but are yourself interested in possibly seeing the results of new xorp scalability and performance research: What tests would you run? Where do think the performance will shine, and where will the performance suck? What would you test? What hardware would you use? I'm open to any and all suggestions. Thanks, Chris. -- Chris Gibson gibsonc at gmail.com :: email http://transidian.com :: blog http://twitter.com/cgibson :: twitter From naresh_raga at yahoo.co.in Thu Sep 17 00:11:53 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Thu, 17 Sep 2009 12:41:53 +0530 (IST) Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <87ab0uref4.fsf@orac.acorntoolworks.com> Message-ID: <558397.44720.qm@web94802.mail.in2.yahoo.com> Hi , >Off the top of my head, you need to specify the '-t' switch to xorp_rtrmgr to >change the search path for the template files. However I'm not sure this will >work for the XRL files -- I think you need to set XORP_ROOT in the >environment to point to obj/ here, as it will have the layout it's looking for -- >assuming you are trying to run XORP from a SCons build directory without >installing it. >--Bruce The interesting part is there is no etc directory in my obj folder. So what I have done is: student at student-desktop:~/Desktop/xorp/obj/i686-linux-public17/rtrmgr$??? sudo ./xorp_rtrmgr -x /home/student/Desktop/xorp/obj/i686-linux-public17/xrl/targets -t /home/student/Desktop/xorp/etc/templates [ 2009/09/17 12:37:36? ERROR xorp_rtrmgr:19254 RTRMGR +255 rtrmgr/main_rtrmgr.cc run ] Shutting down due to an init error: Error in module olsr4 XRL olsr4/common/0.1/get_status->status:u32&reason:txt: the XRL is not specified in the XRL targets directory What is this new error? Regards, Naresh. Connect more, do more and share more with Yahoo! India Mail. Learn more. http://in.overview.mail.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090917/9fe0ec70/attachment.html From naresh_raga at yahoo.co.in Thu Sep 17 02:34:29 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Thu, 17 Sep 2009 15:04:29 +0530 (IST) Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <87ab0uref4.fsf@orac.acorntoolworks.com> Message-ID: <828155.6210.qm@web94816.mail.in2.yahoo.com> Hi Naresh, I think Bruce is correct in assuming that you're trying to run the executables in the build/object directory instead of an install tree. While I think you can make this work by following Bruce's advice, I'll recommend that you "install" XORP and use it from the install location.? By default, the install location is /usr/local/xorp.? You may already know this, but this can be overriden by specifying "prefix=/foo/bar/quux" on the command line when you invoke scons. Hi Bruce and Conklin, Actually I have tried building scons using prefix=/home/student/xorp.But nothing is getting installed into that folder which is supposed to be the install path.I have also tried to build without prefix using the default install path /usr/local/xorp.Even then nothing is getting installed into /usr/local/xorp.What could be the issue? Thanks for your constant valuable suggestions. Naresh. Now, send attachments up to 25MB with Yahoo! India Mail. Learn how. http://in.overview.mail.yahoo.com/photos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090917/a5f9a133/attachment.html From bms at incunabulum.net Thu Sep 17 05:39:10 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 17 Sep 2009 13:39:10 +0100 Subject: [Xorp-users] Looking for XORP performance metrics In-Reply-To: References: Message-ID: <4AB22DEE.5040908@incunabulum.net> Hi Chris, Chris Gibson wrote: > I have been looking for performance and scalability metrics for XORP. > I'm specifically interested in the performance and scalability numbers > for the xorp_bgp implementation. > > This periodically appears to come up on various xorp-* mailing lists, > yet I cannot seem to find any solid, good quality research. The best > thing I have really found up to now has been Hasso's 2006 work and > subsequent paper, which I assume is now sufficiently outdated to not > be of any immediate relevance. > The XORP BGP implementation hasn't fundamentally changed, at least in terms of design, since Hasso's work. There have been some performance related improvements in the area, however I'm not really in a position to give a summary of that right now -- best check SVN history, now that it's re-opened. I understand Mark Handley has a lot of BGP code changes queued up. It is known that the BGP-RIB-FEA path is a bottleneck. One of the things I'm looking at right now is how the RPC layer, XRL, can be optimized further to reduce this bottleneck. In the corporate branch, a batch route update optimization was committed; that should help. A similar patch exists for an older version of the community branch: http://imunes.net/perf-rib-fea-diff3 thanks, BMS From bms at incunabulum.net Thu Sep 17 05:44:40 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 17 Sep 2009 13:44:40 +0100 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <828155.6210.qm@web94816.mail.in2.yahoo.com> References: <828155.6210.qm@web94816.mail.in2.yahoo.com> Message-ID: <4AB22F38.1070805@incunabulum.net> naresh raga wrote: > > > > Hi Bruce and Conklin, > Actually I have tried building scons using > prefix=/home/student/xorp.But nothing is getting installed into > that folder which is supposed to be the install path.I have also > tried to build without prefix using the default install path > /usr/local/xorp.Even then nothing is getting installed into > /usr/local/xorp.What could be the issue? > Points to consider: Did you create the directory before attempting to install? Are you running two invocations of scons -- once to build, once to install? Are you passing the prefix argument to all invocations of scons? Do you get any error(s) when you attempt to install? If you re-target the prefix then the build may need to recompile some files. You shouldn't need to install as root if your destination directory does not have root ownership. The installation is known to work at least under FreeBSD 7.2, Ubuntu 9.04 Desktop, and Fedora 11. I normally test under FreeBSD. I haven't tested on Linux for a few weeks. Hope this helps. thanks, BMS From jtc at acorntoolworks.com Thu Sep 17 09:23:09 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Thu, 17 Sep 2009 09:23:09 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <828155.6210.qm@web94816.mail.in2.yahoo.com> (naresh raga's message of "Thu, 17 Sep 2009 15:04:29 +0530 (IST)") References: <828155.6210.qm@web94816.mail.in2.yahoo.com> Message-ID: <87skel4k2a.fsf@orac.acorntoolworks.com> Hi Naresh, naresh raga writes: > Hi Bruce and Conklin, Please call me J.T. Everyone else does :-) > Actually I have tried building scons using > prefix=/home/student/xorp.But nothing is getting installed into that > folder which is supposed to be the install path.I have also tried to > build without prefix using the default install path > /usr/local/xorp.Even then nothing is getting installed into > /usr/local/xorp.What could be the issue? The issue is that we haven't updated the build / install instructions to reflect the SCons build. Unfortunately, you have been running into problems because of that oversight. What you need to do is a second scons invocation telling it to perform the install. For example, if you build with: scons CC=arm-linux-gcc CXX=arm-linux-g++ prefix=/opt/xorp You need to install with: scons CC=arm-linux-gcc CXX=arm-linux-g++ prefix=/opt/xorp install Actually, in many cases, you can skip the separate build step and just do a "scons ... install". Again I'm sorry you've had to run into these problems. At least there is some good that will come out of this. We'll be able to fix up the instructions before the next release candidate. --jtc -- J.T. Conklin From jtc at acorntoolworks.com Thu Sep 17 09:49:50 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Thu, 17 Sep 2009 09:49:50 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <558397.44720.qm@web94802.mail.in2.yahoo.com> (naresh raga's message of "Thu, 17 Sep 2009 12:41:53 +0530 (IST)") References: <558397.44720.qm@web94802.mail.in2.yahoo.com> Message-ID: <87ocp94itt.fsf@orac.acorntoolworks.com> naresh raga writes: >>Off the top of my head, you need to specify the '-t' switch to > xorp_rtrmgr to >change the search path for the template files. However > I'm not sure this will >work for the XRL files -- I think you need to > set XORP_ROOT in the >environment to point to obj/ here, as it will have > the layout it's looking for -- >assuming you are trying to run XORP from > a SCons build directory without >installing it. >>--Bruce > The interesting part is there is no etc directory in my obj folder. > So what I have done is: > > student at student-desktop:~/Desktop/xorp/obj/i686-linux-public17/rtrmgr$??? > sudo ./xorp_rtrmgr -x /home/student/Desktop/xorp/obj/i686-linux-public17/xrl/targets -t /home/student/Desktop/xorp/etc/templates > > [ 2009/09/17 12:37:36? ERROR xorp_rtrmgr:19254 RTRMGR +255 rtrmgr/main_rtrmgr.cc run ] Shutting down due to an init error: Error in module olsr4 XRL olsr4/common/0.1/get_status->status:u32&reason:txt: the XRL is not specified in the XRL targets directory > > What is this new error? Hi Naresh, I think this demonstrates some of the issues I raised about protocol coupling in one the messages I sent yesterday. The OLSR protocol is in the "contrib" directory, since it's not (yet) considered a core part of XORP. As such, we've deferred adding it to the SCons build. But since router manager templates and XRL target / interface files for all protocols have to be in the same directories, there are olsr4.cmds and olsr4.tp files in the etc/templates directory. I believe that these, without the rest of the OLSR protocol, is what's confusing the router manager. You may have luck by removing these files and carrying on as you had, but I think it's best that you work from an install tree. I sent a message earlier this morning that should explain what you were missing wrt. that. Good luck, --jtc -- J.T. Conklin From naresh_raga at yahoo.co.in Fri Sep 18 06:06:06 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 18 Sep 2009 18:36:06 +0530 (IST) Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <87ocp94itt.fsf@orac.acorntoolworks.com> Message-ID: <337867.97517.qm@web94806.mail.in2.yahoo.com> Hi Bruce and J.T. You are true.I was able to build and install xorp in different paths using prefix.I have run scons two times ,one for build and the other for install using same prefix path as said in previous message by J.T.Now I am free from all errors in building xorp-1.7 on my system. But when I am cross-compiling ,I have used the below arguments for scons scons CC=/home/rupesh/Desktop/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc CXX=/home/rupesh/Desktop/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-g++ STRIP=/home/rupesh/Desktop/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-strip arch=arm-linux os=linux strip=True prefix=/media/disk/naresh/xorpinstall shared=True DESTDIR=/media/disk/naresh/destdir it is resulting in the below errors: /home/rupesh/Desktop/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc -o obj/arm-linux-linux-public17/libxipc/hmac_md5.os -c -g -Werror -W -Wall -Wwrite-strings -Wbad-function-cast -Wmissing-prototypes -Wcast-qual -Wmissing-declarations -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -Iobj/arm-linux-linux-public17 -I. -I. libxipc/hmac_md5.c libxipc/hmac_md5.c:42:25: openssl/md5.h: No such file or directory libxipc/hmac_md5.c: In function `hmac_md5': libxipc/hmac_md5.c:53: error: `MD5_CTX' undeclared (first use in this function) libxipc/hmac_md5.c:53: error: (Each undeclared identifier is reported only once libxipc/hmac_md5.c:53: error: for each function it appears in.) libxipc/hmac_md5.c:53: error: parse error before "context" libxipc/hmac_md5.c:61: error: parse error before "tctx" libxipc/hmac_md5.c:63: warning: implicit declaration of function `MD5_Init' libxipc/hmac_md5.c:63: error: `tctx' undeclared (first use in this function) libxipc/hmac_md5.c:64: warning: implicit declaration of function `MD5_Update' libxipc/hmac_md5.c:65: warning: implicit declaration of function `MD5_Final' libxipc/hmac_md5.c:96: error: `context' undeclared (first use in this function) scons: *** [obj/arm-linux-linux-public17/libxipc/hmac_md5.os] Error 1 scons: building terminated because of errors. I am not getting any errors for scons build if I am not cross-compiling.What could be the issue.I have observed the reduction in size of xorp_rtrmgr when I have built with shared libraries enabled.I am really curious that this can solve my issue.Please help me out. Regards, Naresh Add whatever you love to the Yahoo! India homepage. Try now! http://in.yahoo.com/trynew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090918/1e84fdf1/attachment.html From chuyram28 at msn.com Fri Sep 18 13:47:20 2009 From: chuyram28 at msn.com (JESUS RAMIREZ) Date: Fri, 18 Sep 2009 14:47:20 -0600 Subject: [Xorp-users] (no subject) Message-ID: Hello, I just have a question ? How can i paste the Xorp screen in word ? or do u have any command to send out the screen to printer ? Thank you. _________________________________________________________________ Insert movie times and more without leaving Hotmail?. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090918/a58b8b11/attachment.html From jtc at acorntoolworks.com Fri Sep 18 14:42:02 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Fri, 18 Sep 2009 14:42:02 -0700 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <337867.97517.qm@web94806.mail.in2.yahoo.com> (naresh raga's message of "Fri, 18 Sep 2009 18:36:06 +0530 (IST)") References: <337867.97517.qm@web94806.mail.in2.yahoo.com> Message-ID: <87fxakj5g5.fsf@orac.acorntoolworks.com> naresh raga writes: > But when I am cross-compiling ,I have used the below arguments for scons > > [...] > > it is resulting in the below errors: > > [...] > > I am not getting any errors for scons build if I am not > cross-compiling.What could be the issue.I have observed the > reduction in size of xorp_rtrmgr when I have built with shared > libraries enabled.I am really curious that this can solve my > issue.Please help me out. Hi Naresh, I think the difference is that your native host development tools include the openssl headers and libraries, while your cross tools do not. Since openssl is a prerequisite, you'll need to build or otherwise obtain openssl for your cross target, only after that will you be able to build XORP. --jtc -- J.T. Conklin From bms at incunabulum.net Sun Sep 20 07:33:17 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 20 Sep 2009 15:33:17 +0100 Subject: [Xorp-users] (no subject) In-Reply-To: References: Message-ID: <4AB63D2D.3010101@incunabulum.net> JESUS RAMIREZ wrote: > > Hello, I just have a question ? > How can i paste the Xorp screen in word ? > or do u have any command to send out the screen to printer ? > Thank you. Assuming you're using a terminal program of some kind to log into a machine running xorpsh from Windows, you should be able to just drag-select, copy and paste text as with any other GUI application. XORP is not a GUI application, so there are no native facilities for doing this. Having a printer hooked up to a router is a pretty unusual situation (and isn't something which we'd considered), there is no command to print from the xorpsh directly. Feel free to add your own command template for doing this if it works for you. For an example of adding arbitrary commands to the xorpsh, please see the files used to build the LiveCD image, which makes changes to the misc.tp file. thanks, BMS From bms at incunabulum.net Sun Sep 20 07:39:09 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 20 Sep 2009 15:39:09 +0100 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <337867.97517.qm@web94806.mail.in2.yahoo.com> References: <337867.97517.qm@web94806.mail.in2.yahoo.com> Message-ID: <4AB63E8D.1060108@incunabulum.net> naresh raga wrote: > > > I am not getting any errors for scons build if I am not > cross-compiling.What could be the issue.I have observed the reduction > in size of xorp_rtrmgr when I have built with shared libraries > enabled.I am really curious that this can solve my issue.Please help > me out. > As JT points out, it just sounds as though you need to have a cross-compiled installation of OpenSSL in your staging area for building cross-compiled binaries. These are separate and distinct from the libraries installed on your host system. If you are using a shared library version of OpenSSL, you will need to find a way to deploy them on your target once you've built the source. You might find this online article useful: http://landley.net/writing/docs/cross-compiling.html thanks, BMS From bhavin81 at iitb.ac.in Mon Sep 21 03:21:53 2009 From: bhavin81 at iitb.ac.in (bhavin81 at iitb.ac.in) Date: Mon, 21 Sep 2009 15:51:53 +0530 Subject: [Xorp-users] querry related with cache miss control message Message-ID: Hello Friends, There are 3 control messages provied by kernel while parsing multicast packet : (a)Cache miss (b)Wrond iif (c)Whole pkt. S,G entry is entered inside the MFC. Now if any data pkt arrives and it does not find entry inside MFC then kernel will generate the cache miss message which can be processed and we can look in to MRT. Now my question is what happens to the data packet since kernel only passes the header and control message to the user. Thanks in advance for your help. Regards, Bhavin. From james.dutton at gmail.com Mon Sep 21 05:14:00 2009 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Mon, 21 Sep 2009 13:14:00 +0100 Subject: [Xorp-users] BGP MD5 Message-ID: Hi, How do I configure MD5 authentication on BGP peer connections? It is not contained in the manual, but some release notes imply that it is supported. Kind Regards James From bms at incunabulum.net Mon Sep 21 07:38:47 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 21 Sep 2009 15:38:47 +0100 Subject: [Xorp-users] BGP MD5 In-Reply-To: References: Message-ID: <4AB78FF7.6000804@incunabulum.net> James Courtier-Dutton wrote: > Hi, > > How do I configure MD5 authentication on BGP peer connections? > It is not contained in the manual, but some release notes imply that > it is supported. > It's a tricky one, and further work may be needed to make it useful out-of-the-box, which is probably why it hasn't been documented in the user manual. Some background: TCP-MD5 is a transport layer security mechanism specified by a rather concise published RFC. It was originally developed to address security concerns with TCP at a time when sequence numbers for TCP sessions were easily guessable. BGP is the main consumer of this feature. This feature is implemented within the BSDs as the TCP_MD5SIG option (this is the socket option used to enable it for a new socket, before connect() or bind() have been invoked). I'm not up to date with how it's implemented within Linux, however, I believe they have since taken the TCP_MD5SIG option. Within XORP, the feature relies on support for TCP-MD5 within the host's network stack, and there is a set of XRLs for setting it on a BGP session -- but not the keys themselves. In the template file, the md5-password field(s) are currently commented out. I implemented the XORP kernel glue and BGP module changes first thing when I was hired at ICSI, however, this was only grafting on to what I'd implemented in the FreeBSD kernel. The problem is that configuring the *session keys* requires platform specific support. In FreeBSD, at least, a special SPI entry in the IPSEC tables is used for BGP-MD5 sessions; the setkey(8) utility speaks PF_KEY to get this done. I don't know what's required to configure the kernel-side key in Linux. As far as I know, you still need to do this outside of XORP configuration. See here for information about configuring TCP-MD5 host keys in FreeBSD: http://www.freebsd.org/cgi/man.cgi?query=setkey&apropos=0&sektion=0&manpath=FreeBSD+7.2-RELEASE&format=html If you feel up to making the required changes to implement the feature fully, please do send a patch against SVN and we can try to incorporate it. Hope this helps. thanks, BMS From bms at incunabulum.net Mon Sep 21 07:45:14 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 21 Sep 2009 15:45:14 +0100 Subject: [Xorp-users] querry related with cache miss control message In-Reply-To: References: Message-ID: <4AB7917A.6030404@incunabulum.net> Hi there, I'm afraid that I can't be of great help on this issue at the moment. The best thing I can suggest is that you read the MROUTING implementation itself (in either the Linux or BSD kernels) and learn how it works. bhavin81 at iitb.ac.in wrote: > Now my > question is > what happens to the data packet since kernel only passes the header and > control message to the user. > If PIM is not active then my best guess is the packet will be dropped, however if a PIM register vif is up and enabled, the packet will probably be tunneled and forwarded to the RP. thanks, BMS From james.dutton at gmail.com Mon Sep 21 12:23:17 2009 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Mon, 21 Sep 2009 20:23:17 +0100 Subject: [Xorp-users] BGP MD5 In-Reply-To: <4AB78FF7.6000804@incunabulum.net> References: <4AB78FF7.6000804@incunabulum.net> Message-ID: 2009/9/21 Bruce Simpson : > Some background: > ? TCP-MD5 is a transport layer security mechanism specified by a rather > concise published RFC. It was originally developed to address security > concerns with TCP at a time when sequence numbers for TCP sessions were > easily guessable. BGP is the main consumer of this feature. > ? This feature is implemented within the BSDs as the TCP_MD5SIG option (this > is the socket option used to enable it for a new socket, before connect() or > bind() have been invoked). > ? I'm not up to date with how it's implemented within Linux, however, I > believe they have since taken the TCP_MD5SIG option. > > ? Within XORP, the feature relies on support for TCP-MD5 within the host's > network stack, and there is a set of XRLs for setting it on a BGP session -- > but not the keys themselves. > > ? In the template file, the md5-password field(s) are currently commented > out. I implemented the XORP kernel glue and BGP module changes first thing > when I was hired at ICSI, however, this was only grafting on to what I'd > implemented in the FreeBSD kernel. > > ? The problem is that configuring the *session keys* requires platform > specific support. In FreeBSD, at least, a special SPI entry in the IPSEC > tables is used for BGP-MD5 sessions; the setkey(8) utility speaks PF_KEY to > get this done. I don't know what's required to configure the kernel-side key > in Linux. As far as I know, you still need to do this outside of XORP > configuration. > > See here for information about configuring TCP-MD5 host keys in FreeBSD: > http://www.freebsd.org/cgi/man.cgi?query=setkey&apropos=0&sektion=0&manpath=FreeBSD+7.2-RELEASE&format=html > > If you feel up to making the required changes to implement the feature > fully, please do send a patch against SVN and we can try to incorporate it. > Hope this helps. > In Linux, I think the password is set in the socket calls. The api is along these lines (cut and pasted from quagga): +/* + * Set MD5 key for the socket, for the given IPv4 peer address. + * If the password is NULL or zero-length, the option will be disabled. + */ +int +bgp_md5_set (int sock, union sockunion *su, const char *password) +{ + int ret, en; + + if ( bgpd_privs.change (ZPRIVS_RAISE) ) + zlog_err ("bgp_md5_set: could not raise privs"); + + ret = sockopt_tcp_signature (sock, su, password); + en = errno; + + if (bgpd_privs.change (ZPRIVS_LOWER) ) + zlog_err ("bgp_md5_set: could not lower privs"); + + if (ret < 0) + zlog (NULL, LOG_WARNING, "can't set TCP_MD5SIG option on socket %d: %s", + sock, safe_strerror (en)); + + return ret; +} From bms at incunabulum.net Mon Sep 21 16:02:32 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 22 Sep 2009 00:02:32 +0100 Subject: [Xorp-users] BGP MD5 In-Reply-To: References: <4AB78FF7.6000804@incunabulum.net> Message-ID: <4AB80608.5020701@incunabulum.net> James Courtier-Dutton wrote: > In Linux, I think the password is set in the socket calls. > The api is along these lines (cut and pasted from quagga): > Thanks for the pointer. If you can send us a patch for XORP, we can check it in, provided it doesn't break anything for the non-Linux case. thanks again, BMS From karl at sipxx.com Thu Sep 24 12:47:59 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Thu, 24 Sep 2009 15:47:59 -0400 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX Message-ID: <4ABBCCEF.8030608@sipxx.com> When compiling XORP 1.7 on linux the scons system never defines HAVE_IPV6_MULTICAST despite the system supporting it and XORP-1.6 distribution configuring it correctly. This causes OSPFv3 to be inoperable. When HAVE_IPV6_MULTICAST definition is added manually to xorp_config.h and the code rebuilt, OSPFv3 seems to work at least as well as on XORP-1.6. -Karl From bms at incunabulum.net Thu Sep 24 13:25:58 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 24 Sep 2009 21:25:58 +0100 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABBCCEF.8030608@sipxx.com> References: <4ABBCCEF.8030608@sipxx.com> Message-ID: <4ABBD5D6.1080801@incunabulum.net> XORP at sipxx.com wrote: > When compiling XORP 1.7 on linux the scons system never defines > HAVE_IPV6_MULTICAST despite the system supporting it and XORP-1.6 > distribution configuring it correctly. This causes OSPFv3 to be inoperable. > When HAVE_IPV6_MULTICAST definition is added manually to xorp_config.h > and the code rebuilt, OSPFv3 seems to work at least as well as on XORP-1.6. > -Karl Thanks for the feedback. As you have probably noticed, we've changed build systems, so issues like this are not unexpected. To make sure that this issue doesn't fall through the cracks for a 1.7-RC, can you please raise a bug report on XORP's Trac at SourceForge? You will need to create a SourceForge account to do this:- http://bugzilla.xorp.org/ It would be helpful if you could attach the config.log and xorp_config.h files from the obj// directory. Are you able to send us a patch for the IPv6 feature tests in site_scons/config/allconfig.py ? If so we can check it in, provided it doesn't break the non-Linux case. There is a bug fix against OSPFv3 for the injection of default routes in a non-stub area in SVN. regards, BMS From bms at incunabulum.net Thu Sep 24 13:42:13 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 24 Sep 2009 21:42:13 +0100 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABBCCEF.8030608@sipxx.com> References: <4ABBCCEF.8030608@sipxx.com> Message-ID: <4ABBD9A5.2010906@incunabulum.net> P.S. We also need to know exactly which Linux distribution, version, and kernel version you are using, when trying to address problems like this. Some distributions install optional kernel header files and userland wrapper libraries separately using a package system. We recommend recent Ubuntu or Fedora as those are distributions which participants here are known to be using. From greearb at candelatech.com Thu Sep 24 13:54:32 2009 From: greearb at candelatech.com (Ben Greear) Date: Thu, 24 Sep 2009 13:54:32 -0700 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABBD9A5.2010906@incunabulum.net> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> Message-ID: <4ABBDC88.1000000@candelatech.com> On 09/24/2009 01:42 PM, Bruce Simpson wrote: > P.S. We also need to know exactly which Linux distribution, version, and > kernel version you are using, when trying to address problems like this. > > Some distributions install optional kernel header files and userland > wrapper libraries separately using a package system. > > We recommend recent Ubuntu or Fedora as those are distributions which > participants here are known to be using. I'm going to have to get xorp and ipv6 running early next week, so I'll probably be able to fix or hack around this in some manner in a few days, if no one beats me to it. I'm using Fedora 11 and FC 8 currently. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From karl at sipxx.com Thu Sep 24 14:48:32 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Thu, 24 Sep 2009 17:48:32 -0400 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABBD9A5.2010906@incunabulum.net> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> Message-ID: <4ABBE930.4000104@sipxx.com> One linux was Fedora 7, another RHEL5. However, this is actually not just a Linux problem, I don't see how it can work on FreeBSD even, the necessary test just doesn't exist at all. Unfortunately, I can't even compile the 1.7 version on FreeBSD 7 to test it, there are other hard compile failures in FEA which don't happen on Linux, and they don't happen in 1.6. Bruce Simpson wrote: > P.S. We also need to know exactly which Linux distribution, version, > and kernel version you are using, when trying to address problems like > this. > > Some distributions install optional kernel header files and userland > wrapper libraries separately using a package system. > > We recommend recent Ubuntu or Fedora as those are distributions which > participants here are known to be using. > From bms at incunabulum.net Thu Sep 24 15:25:17 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 24 Sep 2009 23:25:17 +0100 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABBE930.4000104@sipxx.com> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> Message-ID: <4ABBF1CD.3030908@incunabulum.net> XORP at sipxx.com wrote: > One linux was Fedora 7, another RHEL5. > However, this is actually not just a Linux problem, I don't see how it > can work on FreeBSD even, the necessary test just doesn't exist at all. > Unfortunately, I can't even compile the 1.7 version on FreeBSD 7 to test > it, there are other hard compile failures in FEA which don't happen on > Linux, and they don't happen in 1.6. > That sounds pretty serious, I'm sorry to hear that. Can you provide full detail(s) of the errors you are seeing? I am actively hacking on the code base on FreeBSD 7.2-STABLE right now, and do not see any compile failures with SVN trunk with a fresh compile. We no longer have tinderbox coverage for the community branch, so we do depend on volunteers reporting tree breakage; however we really need full details of such breakage to be able to help out. If you look at site_scons/config/allconfig.py, around line 406, you can see where HAVE_IPV4_MULTICAST is defined by the SCons configuration tests. I haven't tested with Ubuntu or Fedora in a few weeks. The tests for HAVE_IPV4_MULTICAST all run successfully on my system. The tests are quite simple, they just check for the relevant headers and declarations (IP_MULTICAST_IF, IP_MULTICAST_TTL, IP_MULTICAST_LOOP, IP_ADD_MEMBERSHIP, IP_DROP_MEMBERSHIP). If all of these are present, then HAVE_IPV4_MULTICAST will be defined. Can you please provide your config.log and xorp_config.h file, uname -a output, so we can try to help you better? Is there anything special or different about your machine from a base FreeBSD install (have you modified any kernel headers, is this a fresh copy of FreeBSD, source installed, did you use buildworld/installworld etc) ? best regards, BMS From bms at incunabulum.net Thu Sep 24 15:31:15 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 24 Sep 2009 23:31:15 +0100 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABBF1CD.3030908@incunabulum.net> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> Message-ID: <4ABBF333.5060504@incunabulum.net> Bruce Simpson wrote: > If you look at site_scons/config/allconfig.py, around line 406, you can > see where HAVE_IPV4_MULTICAST is defined by the SCons configuration > tests. I haven't tested with Ubuntu or Fedora in a few weeks. > Whoops. I misread your message -- sorry about that, I am under a lot of time pressure at the moment. It looks like we've missed out the HAVE_IPV6_MULTICAST check in porting over the SCons tests from Autoconf. There probably just needs to be an additional check in allconfig.py to check for the appropriate IPv6 socket options. Adding it shouldn't be too difficult Can you please raise a Trac ticket about this, and I'll try to look into it when less pressed? I'm busy refactoring libxipc at the moment, so I am unable to look at this issue right away. JT might also be able to look into it, but he's pretty tied up too. If you are able to submit a patch for this issue, then it's likely to get fixed more quickly, providing it doesn't break the non-Linux case. Sorry for the noise! thanks, BMS From karl at sipxx.com Fri Sep 25 10:22:34 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Fri, 25 Sep 2009 13:22:34 -0400 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABBF1CD.3030908@incunabulum.net> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> Message-ID: <4ABCFC5A.5000707@sipxx.com> I updated my svn tree again and reran a build on FreeBSD to see what the errors were. The errors are actually link time missing references. Are the latest svn commits supposed to build? I had unresolved references into xuid.cc which is now commented out of the sources, putting it back solved that problem, but allowed other problems to surface. I tried going back a few revs, but haven't found a working one yet. The build system also orders the link libraries incorrectly, the path to /usr/local/lib (for example, among others) is searched first for libraries (-L), rather than the product specific directories under obj. This causes the build to try to link against libospf from quagga which lives in /usr/local/lib, which causes havoc naturally. XORP 1.6 didn't do that, it explicitly linked in the required libraries with full path. It can be properly with -L too, but care needs to be take with the order. Quagga could be uninstalled of course, but that is not a proper solution, you can't expect to build this only on a freshly installed OS with no other apps present. The tree should link properly internally. Later, ... Karl Bruce Simpson wrote: > XORP at sipxx.com wrote: >> One linux was Fedora 7, another RHEL5. >> However, this is actually not just a Linux problem, I don't see how >> it can work on FreeBSD even, the necessary test just doesn't exist at >> all. >> Unfortunately, I can't even compile the 1.7 version on FreeBSD 7 to >> test it, there are other hard compile failures in FEA which don't >> happen on Linux, and they don't happen in 1.6. >> > > That sounds pretty serious, I'm sorry to hear that. Can you provide > full detail(s) of the errors you are seeing? I am actively hacking on > the code base on FreeBSD 7.2-STABLE right now, and do not see any > compile failures with SVN trunk with a fresh compile. > > We no longer have tinderbox coverage for the community branch, so we > do depend on volunteers reporting tree breakage; however we really > need full details of such breakage to be able to help out. > > If you look at site_scons/config/allconfig.py, around line 406, you > can see where HAVE_IPV4_MULTICAST is defined by the SCons > configuration tests. I haven't tested with Ubuntu or Fedora in a few > weeks. > > The tests for HAVE_IPV4_MULTICAST all run successfully on my system. > The tests are quite simple, they just check for the relevant headers > and declarations (IP_MULTICAST_IF, IP_MULTICAST_TTL, > IP_MULTICAST_LOOP, IP_ADD_MEMBERSHIP, IP_DROP_MEMBERSHIP). If all of > these are present, then HAVE_IPV4_MULTICAST will be defined. > > Can you please provide your config.log and xorp_config.h file, uname > -a output, so we can try to help you better? > > Is there anything special or different about your machine from a base > FreeBSD install (have you modified any kernel headers, is this a fresh > copy of FreeBSD, source installed, did you use buildworld/installworld > etc) ? > > best regards, > BMS > From bms at incunabulum.net Fri Sep 25 11:13:58 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri, 25 Sep 2009 19:13:58 +0100 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABCFC5A.5000707@sipxx.com> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> <4ABCFC5A.5000707@sipxx.com> Message-ID: <4ABD0866.40306@incunabulum.net> XORP at sipxx.com wrote: > I had unresolved references into xuid.cc Good catch, checked in and uncommented -- the FEA socket manager is using it. > The build system also orders the link libraries incorrectly, the path to > /usr/local/lib (for example, among others) is searched first for > libraries (-L), rather than the product specific directories under obj. > I would consider this a teething problem with SCons and should be looked at before 1.7-RC is cut; the current scheme is not desirable (/opt/sfw doesn't exist in a number of places, for example). There are a number of link line items which could do with being pushed down to individual areas of the tree. Even with Autotools, we've tended to skip this, as just having the library in the ld.so depends is cheap even if none of the functions get called (and thus no PLT entries resolved at runtime). One of the things that isn't in, for example, is using the linker $ORIGIN facility, although SCons has hooks for dealing with this. For example, it's not always possible to run binaries directly w/o installing them or setting LD_RUN_PATH/LD_LIBRARY_PATH in the environment. I've made a lot of progress on Thrift this week, and it looks like we can cut over to it from XRL without mass refactoring of the protocols, so I'll try to look at the HAVE_IPV6_MULTICAST issue next week, if Ben has a crack first, even better. cheers, BMS From bms at incunabulum.net Fri Sep 25 15:49:52 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri, 25 Sep 2009 23:49:52 +0100 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABD2239.3040500@sipxx.com> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> <4ABCFC5A.5000707@sipxx.com> <4ABD0866.40306@incunabulum.net> <4ABD2239.3040500@sipxx.com> Message-ID: <4ABD4910.6020207@incunabulum.net> Thanks for the report Can you also send the output of these commands, this does look like a link ordering issue (it's fine on my FreeBSD 7.2 systems) and I'm trying to think if there have been any changes to ld/g++ stage2 which might account for what you're seeing:- tack:~ % ld -v GNU ld version 2.15 [FreeBSD] 2004-05-23 tack:~ % gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] tack:~ % g++ -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] From karl at sipxx.com Fri Sep 25 16:02:54 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Fri, 25 Sep 2009 19:02:54 -0400 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABD4910.6020207@incunabulum.net> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> <4ABCFC5A.5000707@sipxx.com> <4ABD0866.40306@incunabulum.net> <4ABD2239.3040500@sipxx.com> <4ABD4910.6020207@incunabulum.net> Message-ID: <4ABD4C1E.8050303@sipxx.com> My versions are identical to yours: $ ld -v GNU ld version 2.15 [FreeBSD] 2004-05-23 $ gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] $ g++ -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] Bruce Simpson wrote: > Thanks for the report Can you also send the output of these commands, > this does look like a link ordering issue (it's fine on my FreeBSD 7.2 > systems) and I'm trying to think if there have been any changes to > ld/g++ stage2 which might account for what you're seeing:- > > tack:~ % ld -v > GNU ld version 2.15 [FreeBSD] 2004-05-23 > tack:~ % gcc -v > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > tack:~ % g++ -v > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > > From karl at sipxx.com Fri Sep 25 16:40:51 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Fri, 25 Sep 2009 19:40:51 -0400 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABD4910.6020207@incunabulum.net> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> <4ABCFC5A.5000707@sipxx.com> <4ABD0866.40306@incunabulum.net> <4ABD2239.3040500@sipxx.com> <4ABD4910.6020207@incunabulum.net> Message-ID: <4ABD5503.8040704@sipxx.com> I took another look at the problem, now that we know we have identical build tools, this time I solved the problem, a problem which I had already pointed out but were a victim to again, nevertheless. Turns out the build process linked against one of the libospf libraries in /usr/local/lib from Quagga and therefore the XORP lib wasn't linked in. I had relocated Quagga into /opt/quagga and renamed leftover libraries in /usr/local. I thought I had renamed them all, but did so only for the shared library. All is well now, however, the XORP build system really needs to assure that it links only against its own libs, like 1.6 did. Thanks... Bruce Simpson wrote: > Thanks for the report Can you also send the output of these commands, > this does look like a link ordering issue (it's fine on my FreeBSD 7.2 > systems) and I'm trying to think if there have been any changes to > ld/g++ stage2 which might account for what you're seeing:- > > tack:~ % ld -v > GNU ld version 2.15 [FreeBSD] 2004-05-23 > tack:~ % gcc -v > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > tack:~ % g++ -v > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > > From greearb at candelatech.com Fri Sep 25 17:02:05 2009 From: greearb at candelatech.com (Ben Greear) Date: Fri, 25 Sep 2009 17:02:05 -0700 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABD5503.8040704@sipxx.com> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> <4ABCFC5A.5000707@sipxx.com> <4ABD0866.40306@incunabulum.net> <4ABD2239.3040500@sipxx.com> <4ABD4910.6020207@incunabulum.net> <4ABD5503.8040704@sipxx.com> Message-ID: <4ABD59FD.1010201@candelatech.com> To change back to the original topic: Here is a patch that lets xorp compile IPV6 multicast logic on Linux, at least. I haven't tested functionality. * Properly detect RFC3542 support on Linux. (it probably exists, certainly does on F11) * Check for HAVE_IPV6_MULTICAST * Allow HAVE_IPV6_MULTICAST_ROUTING on Linux. PS. In case anyone ever wants to know, the scons test files are located in obj/[platform]/.sconf_temp Had to run strace to figure out where it was hiding these things :P Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp_mcast6_scons.patch Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090925/455a3b2f/attachment.ksh From karl at sipxx.com Fri Sep 25 13:04:09 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Fri, 25 Sep 2009 16:04:09 -0400 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABD0866.40306@incunabulum.net> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> <4ABCFC5A.5000707@sipxx.com> <4ABD0866.40306@incunabulum.net> Message-ID: <4ABD2239.3040500@sipxx.com> Ok, updated my tree from svn, xuid.cc is now included again. But build fails in another place with unresolved references. This time I am attaching the log file from the build, so you can figure out what goes wrong. I extracted the offending link statement to run separately, but haven't found a combination of libraries that works and at this point it's taking too much time. I actual suspect that something isn't being compiled in that should be. I am sure you can figure it out quicker. The system is rather standard FreeBSD 7.0 on 32bit i386 processor. Bruce Simpson wrote: > XORP at sipxx.com wrote: >> I had unresolved references into xuid.cc > > Good catch, checked in and uncommented -- the FEA socket manager is > using it. > >> The build system also orders the link libraries incorrectly, the path >> to /usr/local/lib (for example, among others) is searched first for >> libraries (-L), rather than the product specific directories under >> obj. > > I would consider this a teething problem with SCons and should be > looked at before 1.7-RC is cut; the current scheme is not desirable > (/opt/sfw doesn't exist in a number of places, for example). > > There are a number of link line items which could do with being pushed > down to individual areas of the tree. Even with Autotools, we've > tended to skip this, as just having the library in the ld.so depends > is cheap even if none of the functions get called (and thus no PLT > entries resolved at runtime). > > One of the things that isn't in, for example, is using the linker > $ORIGIN facility, although SCons has hooks for dealing with this. For > example, it's not always possible to run binaries directly w/o > installing them or setting LD_RUN_PATH/LD_LIBRARY_PATH in the > environment. > > I've made a lot of progress on Thrift this week, and it looks like we > can cut over to it from XRL without mass refactoring of the protocols, > so I'll try to look at the HAVE_IPV6_MULTICAST issue next week, if Ben > has a crack first, even better. > > cheers, > BMS > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freebsd70.log Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090925/47a09d1d/attachment-0002.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.log Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090925/47a09d1d/attachment-0003.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp_config.h Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090925/47a09d1d/attachment-0001.h From karl at sipxx.com Sat Sep 26 11:04:07 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Sat, 26 Sep 2009 14:04:07 -0400 Subject: [Xorp-users] [PATCH]: prepend project libs search path instead of appending list Message-ID: <4ABE5797.40408@sipxx.com> As discussed in another thread, XORP builds its components by *appending* the local components' link library search paths to the system list. This caused false linking against identically named libraries in the system wide paths (e.g. libospf). This patch corrects the search order by *prepending* the local component directories. It was successfully tested on FreeBSD 7.0 with foreign libraries present in system directories. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp_libspath.patch Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090926/611a1e7d/attachment.ksh From karl at sipxx.com Sat Sep 26 11:22:34 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Sat, 26 Sep 2009 14:22:34 -0400 Subject: [Xorp-users] [PATCH]: prepend project libs search path instead of appending list In-Reply-To: <4ABE5797.40408@sipxx.com> References: <4ABE5797.40408@sipxx.com> Message-ID: <4ABE5BEA.4020703@sipxx.com> The first patch only included the first level of directories, forgot to add all, sorry. Attached is the second part of the patch that covers all lower level directories. Note: this patch is an *addition* to the first part which is not included again. XORP at sipxx.com wrote: > As discussed in another thread, XORP builds its components by > *appending* the local components' link library search paths to the > system list. This caused false linking against identically named > libraries in the system wide paths (e.g. libospf). > This patch corrects the search order by *prepending* the local > component directories. > It was successfully tested on FreeBSD 7.0 with foreign libraries > present in system directories. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp_libspath_part2.patch Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090926/25f3e0b3/attachment.ksh From karl at sipxx.com Sat Sep 26 11:32:28 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Sat, 26 Sep 2009 14:32:28 -0400 Subject: [Xorp-users] BUG: 1.7 build system does not have dependencies against SConscript files Message-ID: <4ABE5E3C.7060102@sipxx.com> The new build system does not implement any dependency checking on SConscript files. For example, when applying a patch to SConscript files for fixing the library path problem addressed in another thread, the system should detect that SConscript files have changed and should relink the executables, or whatever is necessary to build a subsystem correctly. Ideally this should only do the absolutely minimum work, like just relinking the executables, but may involve recompilations, since some compiler flags may have been changed. -Karl From jtc at acorntoolworks.com Sat Sep 26 15:59:43 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Sat, 26 Sep 2009 15:59:43 -0700 Subject: [Xorp-users] BUG: 1.7 build system does not have dependencies against SConscript files In-Reply-To: <4ABE5E3C.7060102@sipxx.com> (XORP at sipxx com's message of "Sat, 26 Sep 2009 14:32:28 -0400") References: <4ABE5E3C.7060102@sipxx.com> Message-ID: <87ljk148io.fsf@orac.acorntoolworks.com> "XORP at sipxx.com" writes: > The new build system does not implement any dependency checking on > SConscript files. > > For example, when applying a patch to SConscript files for fixing the > library path problem addressed in another thread, the system should > detect that SConscript files have changed and should relink the > executables, or whatever is necessary to build a subsystem correctly. > Ideally this should only do the absolutely minimum work, like just > relinking the executables, but may involve recompilations, since some > compiler flags may have been changed. This is supposed to "just work". Scons builds a dependency graph from the declarations in the SConscript files, and then checks to see if each node in the DAG is up to date. If a new file or library is added, the DAG will be out of date, and the executable should be rebuilt. If this is not happening, a fully worked example needs to be filed as a bug. Include the version of SCons and Python as well. --jtc -- J.T. Conklin From jtc at acorntoolworks.com Sat Sep 26 16:25:01 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Sat, 26 Sep 2009 16:25:01 -0700 Subject: [Xorp-users] [PATCH]: prepend project libs search path instead of appending list In-Reply-To: <4ABE5797.40408@sipxx.com> (XORP at sipxx com's message of "Sat, 26 Sep 2009 14:04:07 -0400") References: <4ABE5797.40408@sipxx.com> Message-ID: <87d45d47ci.fsf@orac.acorntoolworks.com> "XORP at sipxx.com" writes: > As discussed in another thread, XORP builds its components by > *appending* the local components' link library search paths to the > system list. This caused false linking against identically named > libraries in the system wide paths (e.g. libospf). I'm not sure this is the way to go. The root cause of the problem is that there are identically named libraries in the system wide paths in the first place. If we build XORP with shared libraries and prefix=/usr/local (or whatever path prefix has that identically named library), we're going to blow it away when we install our version. This shouldn't happen now, as our default prefix is /usr/local/xorp; but there is a desire to move to a more BSD heir(7), Linux LSB, GNU standard, etc. file layout. When that's done, XORP may very well be installed in the same directory as other packages. Rather than tweak LIBPATH and link order, which seems fragile, I think we may want to consider ensuring that all XORP libraries (and perhaps even executables) have a "xorp_" prefix. --jtc -- J.T. Conklin From karl at sipxx.com Sat Sep 26 16:44:23 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Sat, 26 Sep 2009 19:44:23 -0400 Subject: [Xorp-users] BUG: 1.7 build system does not have dependencies against SConscript files In-Reply-To: <87ljk148io.fsf@orac.acorntoolworks.com> References: <4ABE5E3C.7060102@sipxx.com> <87ljk148io.fsf@orac.acorntoolworks.com> Message-ID: <4ABEA757.70004@sipxx.com> Yes, you would think it should just work. And yes, if you add a subdirectory, or a source file, it indeed does. But if you just edit a script file and change the configuration, for example, add a directory to a LIBPATH array, it won't detect it. Easy to demonstrate, just edit a script file and make some simple modifications. SCons (1.2) is compiled from latest release sources and Python is up to date on Linux and FreeBSD systems. System type doesn't matter, in fact. For example, build a complete tree and add the following patch in ospf directory: Index: SConscript =================================================================== --- SConscript (revision 11556) +++ SConscript (working copy) @@ -35,7 +35,8 @@ '$BUILDDIR', ]) -env.AppendUnique(LIBPATH = [ +env.PrependUnique(LIBPATH = [ + '.', '../libxorp', '../libcomm', '../libxipc', The patch simply changes Append to Prepend and adds the current directory '.' to the LIBPATH (for no particular reason, just to demonstrate the ineffectiveness) Then rerunning scons from the top of the tree will tell you that everything is 'up to date', e.g.: scons: `obj/x86_64-linux-public17/ospf/tools/clear_database' is up to date. scons: `obj/x86_64-linux-public17/ospf/tools/print_lsas' is up to date. scons: `obj/x86_64-linux-public17/ospf/tools/print_neighbours' is up to date. scons: `obj/x86_64-linux-public17/ospf/xorp_ospfv2' is up to date. scons: `obj/x86_64-linux-public17/ospf/xorp_ospfv3' is up to date. J.T. Conklin wrote: > "XORP at sipxx.com" writes: > >> The new build system does not implement any dependency checking on >> SConscript files. >> >> For example, when applying a patch to SConscript files for fixing the >> library path problem addressed in another thread, the system should >> detect that SConscript files have changed and should relink the >> executables, or whatever is necessary to build a subsystem correctly. >> Ideally this should only do the absolutely minimum work, like just >> relinking the executables, but may involve recompilations, since some >> compiler flags may have been changed. >> > > This is supposed to "just work". Scons builds a dependency graph from > the declarations in the SConscript files, and then checks to see if > each node in the DAG is up to date. If a new file or library is added, > the DAG will be out of date, and the executable should be rebuilt. > > If this is not happening, a fully worked example needs to be filed as a > bug. Include the version of SCons and Python as well. > > --jtc > > From karl at sipxx.com Sat Sep 26 16:50:44 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Sat, 26 Sep 2009 19:50:44 -0400 Subject: [Xorp-users] [PATCH]: prepend project libs search path instead of appending list In-Reply-To: <87d45d47ci.fsf@orac.acorntoolworks.com> References: <4ABE5797.40408@sipxx.com> <87d45d47ci.fsf@orac.acorntoolworks.com> Message-ID: <4ABEA8D4.6070202@sipxx.com> yes, I agree, the components should have unique names. Nevertheless, local libraries should be searched first in any event. The same applies to the CPP include path, btw; right now the system paths (/usr/include, etc) are searched first. J.T. Conklin wrote: > "XORP at sipxx.com" writes: > >> As discussed in another thread, XORP builds its components by >> *appending* the local components' link library search paths to the >> system list. This caused false linking against identically named >> libraries in the system wide paths (e.g. libospf). >> > > I'm not sure this is the way to go. > > The root cause of the problem is that there are identically named > libraries in the system wide paths in the first place. If we build > XORP with shared libraries and prefix=/usr/local (or whatever path > prefix has that identically named library), we're going to blow it > away when we install our version. > > This shouldn't happen now, as our default prefix is /usr/local/xorp; > but there is a desire to move to a more BSD heir(7), Linux LSB, GNU > standard, etc. file layout. When that's done, XORP may very well be > installed in the same directory as other packages. > > Rather than tweak LIBPATH and link order, which seems fragile, I think > we may want to consider ensuring that all XORP libraries (and perhaps > even executables) have a "xorp_" prefix. > > --jtc > > From bms at incunabulum.net Mon Sep 28 02:25:41 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 28 Sep 2009 10:25:41 +0100 Subject: [Xorp-users] HAVE_IPV6_MULTICAST never defined in XORP-1.7 on LINUX In-Reply-To: <4ABD59FD.1010201@candelatech.com> References: <4ABBCCEF.8030608@sipxx.com> <4ABBD9A5.2010906@incunabulum.net> <4ABBE930.4000104@sipxx.com> <4ABBF1CD.3030908@incunabulum.net> <4ABCFC5A.5000707@sipxx.com> <4ABD0866.40306@incunabulum.net> <4ABD2239.3040500@sipxx.com> <4ABD4910.6020207@incunabulum.net> <4ABD5503.8040704@sipxx.com> <4ABD59FD.1010201@candelatech.com> Message-ID: <4AC08115.9040801@incunabulum.net> Thanks for looking into this, I'll try to get around to testing this when I have free time. From bms at incunabulum.net Mon Sep 28 02:31:33 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 28 Sep 2009 10:31:33 +0100 Subject: [Xorp-users] Problem with scons build in xorp 1.7-WIP In-Reply-To: <87fxakj5g5.fsf@orac.acorntoolworks.com> References: <337867.97517.qm@web94806.mail.in2.yahoo.com> <87fxakj5g5.fsf@orac.acorntoolworks.com> Message-ID: <4AC08275.7080100@incunabulum.net> J.T. Conklin wrote: > I think the difference is that your native host development tools > include the openssl headers and libraries, while your cross tools > do not. Since openssl is a prerequisite, you'll need to build or > otherwise obtain openssl for your cross target, only after that > will you be able to build XORP. > There are only 4 places in the code base where MD5 is used: the Router Manager, RIP's auth support, OSPF's auth support, and the HMAC codes generated for Finder XRL messages. We don't use TLS, SSL or any of the stream ciphers directly -- just MD5. Because MD5 is 'commodity', it pops up in lots of places. FreeBSD, for example, ships it in the base system in 'libmd.so'. How this link requirement normally gets satisfied in XORP, is to link against OpenSSL's libcrypto. These are the only places where we actually need to pull in an external crypto library. We could just put the object in libxorp and ship it directly, although this duplicates code which folk would likely have present on a router node anyway, and only marginally makes life easier for folk who are attempting to cross-compile the code. There are so many frameworks for cross-compiling open source packages out there, that supporting them directly isn't realistic with the resources we have; at the end of the day, folk are best off directing questions about cross-compilation to groups more familiar with the environment they're trying to use for this, but we'll try to provide general advice where we can. Of course, if folk find issues with embedded use, specific to the XORP code base (e.g. problems on strong alignment architectures), please do send us a patch if possible. There are a few known culprits for this in the tree. cheers, BMS From bms at incunabulum.net Mon Sep 28 02:32:47 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 28 Sep 2009 10:32:47 +0100 Subject: [Xorp-users] [PATCH]: prepend project libs search path instead of appending list In-Reply-To: <87d45d47ci.fsf@orac.acorntoolworks.com> References: <4ABE5797.40408@sipxx.com> <87d45d47ci.fsf@orac.acorntoolworks.com> Message-ID: <4AC082BF.4030706@incunabulum.net> J.T. Conklin wrote: > Rather than tweak LIBPATH and link order, which seems fragile, I think > we may want to consider ensuring that all XORP libraries (and perhaps > even executables) have a "xorp_" prefix. > In SVN I renamed the libtecla fork to 'libtecla_xorp' for just this reason. The libtecla we have in XORP is not binary/ABI compatible with the one that ships -- and we've got a number of modifications in there for security and compatibility, which are totally XORP specific. Now that the code base is GPLv2, using readline is a possibility -- it only makes the license viral for the CLI itself. As to the protocol libraries themselves: yes, they probably should be renamed as you describe, although it could be argued that Quagga is an equal 'offender' for installing application-specific libraries in a very general system location. :-) From jtc at acorntoolworks.com Mon Sep 28 06:44:18 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Mon, 28 Sep 2009 06:44:18 -0700 Subject: [Xorp-users] BUG: 1.7 build system does not have dependencies against SConscript files In-Reply-To: <4ABEA757.70004@sipxx.com> (XORP at sipxx com's message of "Sat, 26 Sep 2009 19:44:23 -0400") References: <4ABE5E3C.7060102@sipxx.com> <87ljk148io.fsf@orac.acorntoolworks.com> <4ABEA757.70004@sipxx.com> Message-ID: <87d45b9ob1.fsf@orac.acorntoolworks.com> "XORP at sipxx.com" writes: > Yes, you would think it should just work. And yes, if you add a > subdirectory, or a source file, it indeed does. But if you just edit > a script file and change the configuration, for example, add a > directory to a LIBPATH array, it won't detect it. Easy to > demonstrate, just edit a script file and make some simple > modifications. > > SCons (1.2) is compiled from latest release sources and Python is up > to date on Linux and FreeBSD systems. System type doesn't matter, in > fact. I'll follow up on this with the Scons folks this week. --jtc -- J.T. Conklin From greearb at candelatech.com Mon Sep 28 12:27:43 2009 From: greearb at candelatech.com (Ben Greear) Date: Mon, 28 Sep 2009 12:27:43 -0700 Subject: [Xorp-users] Unofficial xorp development tree available. Message-ID: <4AC10E2F.5080703@candelatech.com> In order to aid sharing our patches with upstream xorp developers and other users, I've made our xorp source tree available on our server. I'm using 'git' instead of 'svn', but they have a similar feature set. I plan to sync my tree with the upstream xorp svn code tree often, and will post significant patches to the xorp-users mailing list in case the upstream developers want to incorporate the patches. If Bruce or some other official Xorp person perfers it, I can automatically post the changes to my tree to xorp-cvs or similar mailing list. I'm not going to spam those lists unless specifically requested, however. Please understand that the official Xorp project bears no responsibility for my xorp.ct tree. Any bug reports against it should be directed to me. Right now, the tree is read-only for outside users. I am certainly willing to consider applying patches, even for new experimental routing protocols and such, as long as they do not overly risk de-stabilizing the existing protocols, and as long as the changes do not make it too difficult to keep synchronized with the upstream xorp tree. http://www.candelatech.com/oss/xorp-ct.html Suggestions & comments welcome. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From karl at sipxx.com Mon Sep 28 17:54:56 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Mon, 28 Sep 2009 20:54:56 -0400 Subject: [Xorp-users] BUG: 1.7 build system has builddir feature but creates files in source tree, build with read-only source tree fails Message-ID: <4AC15AE0.7060701@sipxx.com> The XORP-1.7 build system has a feature to use an alternate build directory (builddir option), while this indeed relocates the creation of object files and build targets, scons still creates build specific files in the source tree. If the source tree is read-only for the compiling user, the build fails. The attached log file of such an attempt was obtained with scons prefix=/opt/xorp builddir=../build-1.7 There doesn't seem to be an easy way to completely build in a separate directory as was the case with XORP-1.6. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp17-build.log Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090928/06040c95/attachment.ksh From fazlina at sapura.com.my Mon Sep 28 20:41:21 2009 From: fazlina at sapura.com.my (Fazlina Zuria Mohd Anuar) Date: Tue, 29 Sep 2009 11:41:21 +0800 Subject: [Xorp-users] multicast using xorp Message-ID: <47E179216C509646865919E8F4F4F85B0102C121@pluto.sapura.com> Hello!! I would like to ask some advice about configuring multicast network using xorp. I would like to multicast video streaming using vlc player between 2 xorp router. Network diagram: PC--------------------------Xorp Router1-------------------------Xorp Router2-------------------------PC Eth0 Eth0 Eth1 Eth0 Eth1 Eth0 10.160.6.2/24 10.160.6.1/24 10.160.5.1/24 10.160.5.2/24 10.160.7.1/24 10.160.7.2/24 My configuration: /*XORP Configuration File Xorp Router1, v1.0*/ protocols { fib2mrib { disable: false } igmp { disable: false interface eth0 { vif eth0 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } interface eth1 { vif eth1 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag { all { disable: false } } } } pimsm4 { disable: false interface eth0 { vif eth0 { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface eth1 { vif eth1 { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface "register_vif" { vif "register_vif" { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } static-rps { rp 10.160.5.1 { group-prefix 224.0.0.0/4 { rp-priority: 192 hash-mask-len: 30 } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 102400 } traceoptions { flag { all { disable: false } } } } } fea { unicast-forwarding4 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "" disable: false discard: false unreachable: false management: false vif eth0 { disable: false address 10.160.5.1 { prefix-length: 24 broadcast: 10.160.5.255 disable: false } } } interface eth1 { description: "" disable: false discard: false unreachable: false management: false vif eth1 { disable: false address 10.160.6.1 { prefix-length: 24 broadcast: 10.160.6.255 disable: false } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface "register_vif" { vif "register_vif" { disable: false } } traceoptions { flag { all { disable: false } } } } } Both router using same setting & the multicast doesn't working...please advice..TQ!!! Faz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090929/3c22b790/attachment-0001.html From jtc at acorntoolworks.com Mon Sep 28 20:48:54 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Mon, 28 Sep 2009 20:48:54 -0700 Subject: [Xorp-users] BUG: 1.7 build system has builddir feature but creates files in source tree, build with read-only source tree fails In-Reply-To: <4AC15AE0.7060701@sipxx.com> (XORP at sipxx com's message of "Mon, 28 Sep 2009 20:54:56 -0400") References: <4AC15AE0.7060701@sipxx.com> Message-ID: <874oqmh0m1.fsf@orac.acorntoolworks.com> "XORP at sipxx.com" writes: > The XORP-1.7 build system has a feature to use an alternate build > directory (builddir option), while this indeed relocates the creation > of object files and build targets, scons still creates build specific > files in the source tree. If the source tree is read-only for the > compiling user, the build fails. > The attached log file of such an attempt was obtained with scons > prefix=/opt/xorp builddir=../build-1.7 > There doesn't seem to be an easy way to completely build in a separate > directory as was the case with XORP-1.6. I think the only thing that is currently written in the source directory is the .sconsign.dblite file. Scons has a SConsignFile() directive. I'll investigate whether it can be used with a command line argument to override the default, similar to what is done for the build directory. --jtc -- J.T. Conklin From jtc at acorntoolworks.com Tue Sep 29 06:58:48 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Tue, 29 Sep 2009 06:58:48 -0700 Subject: [Xorp-users] BUG: 1.7 build system has builddir feature but creates files in source tree, build with read-only source tree fails In-Reply-To: <874oqmh0m1.fsf@orac.acorntoolworks.com> (J. T. Conklin's message of "Mon, 28 Sep 2009 20:48:54 -0700") References: <4AC15AE0.7060701@sipxx.com> <874oqmh0m1.fsf@orac.acorntoolworks.com> Message-ID: <87r5tpvomf.fsf@orac.acorntoolworks.com> jtc at acorntoolworks.com (J.T. Conklin) writes: > "XORP at sipxx.com" writes: >> The XORP-1.7 build system has a feature to use an alternate build >> directory (builddir option), while this indeed relocates the creation >> of object files and build targets, scons still creates build specific >> files in the source tree. If the source tree is read-only for the >> compiling user, the build fails. >> >> [...] > > I think the only thing that is currently written in the source > directory is the .sconsign.dblite file. Scons has a SConsignFile() > directive. I'll investigate whether it can be used with a command > line argument to override the default, similar to what is done for > the build directory. I commited a change that uses SConsignFile() to put .sconsign.dblite in the build directory. There didn't seem to be any benefit to make it so it's location could be set separately. I tested it with a read only workspace (I did a chmod -R a-w), which worked as hoped. This change will require a full build once workspaces are updated. This might be avoided by moving any existing .sconsign.dblite file from the source directory to the build directory. --jtc -- J.T. Conklin From karl at sipxx.com Tue Sep 29 18:02:57 2009 From: karl at sipxx.com (XORP at sipxx.com) Date: Tue, 29 Sep 2009 21:02:57 -0400 Subject: [Xorp-users] BUG: 1.7 build system has builddir feature but creates files in source tree, build with read-only source tree fails In-Reply-To: <87r5tpvomf.fsf@orac.acorntoolworks.com> References: <4AC15AE0.7060701@sipxx.com> <874oqmh0m1.fsf@orac.acorntoolworks.com> <87r5tpvomf.fsf@orac.acorntoolworks.com> Message-ID: <4AC2AE41.2090700@sipxx.com> Thank you. This works fine on a read-only file system. For the rest of the problem on a r/w-able file system, I have tried to find out how to disable the storage of the python import module compilations into the source tree, but haven't found the answer. Since python obviously doesn't *need* to have the compiled files, it seems the import function ought to have some flag to turn it off. Since there isn't a 'clean' target either, this is still a very unclean situation. In general, I think, compiling outside the source tree should actually start from the builddir, not the source directory. Instead of having to specify the build directory on the command line, one should specify the source directory while having the builddir as current directory. This is much more convenient when, for example, one wants to capture/redirect the console output of the process to a file in the build directory, and it is the traditional method. J.T. Conklin wrote: > jtc at acorntoolworks.com (J.T. Conklin) writes: > >> "XORP at sipxx.com" writes: >> >>> The XORP-1.7 build system has a feature to use an alternate build >>> directory (builddir option), while this indeed relocates the creation >>> of object files and build targets, scons still creates build specific >>> files in the source tree. If the source tree is read-only for the >>> compiling user, the build fails. >>> >>> [...] >>> >> I think the only thing that is currently written in the source >> directory is the .sconsign.dblite file. Scons has a SConsignFile() >> directive. I'll investigate whether it can be used with a command >> line argument to override the default, similar to what is done for >> the build directory. >> > > I commited a change that uses SConsignFile() to put .sconsign.dblite > in the build directory. There didn't seem to be any benefit to make > it so it's location could be set separately. > > I tested it with a read only workspace (I did a chmod -R a-w), which > worked as hoped. > > This change will require a full build once workspaces are updated. > This might be avoided by moving any existing .sconsign.dblite file > from the source directory to the build directory. > > --jtc > > From bms at incunabulum.net Wed Sep 30 01:48:42 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 30 Sep 2009 09:48:42 +0100 Subject: [Xorp-users] BUG: 1.7 build system has builddir feature but creates files in source tree, build with read-only source tree fails In-Reply-To: <87r5tpvomf.fsf@orac.acorntoolworks.com> References: <4AC15AE0.7060701@sipxx.com> <874oqmh0m1.fsf@orac.acorntoolworks.com> <87r5tpvomf.fsf@orac.acorntoolworks.com> Message-ID: <4AC31B6A.6010303@incunabulum.net> J.T. Conklin wrote: > I commited a change that uses SConsignFile() to put .sconsign.dblite > in the build directory. There didn't seem to be any benefit to make > it so it's location could be set separately. > Thanks for sorting this out! cheers, BMS From bms at incunabulum.net Wed Sep 30 02:10:08 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 30 Sep 2009 10:10:08 +0100 Subject: [Xorp-users] BUG: 1.7 build system has builddir feature but creates files in source tree, build with read-only source tree fails In-Reply-To: <4AC2AE41.2090700@sipxx.com> References: <4AC15AE0.7060701@sipxx.com> <874oqmh0m1.fsf@orac.acorntoolworks.com> <87r5tpvomf.fsf@orac.acorntoolworks.com> <4AC2AE41.2090700@sipxx.com> Message-ID: <4AC32070.70703@incunabulum.net> XORP at sipxx.com wrote: > Thank you. This works fine on a read-only file system. > For the rest of the problem on a r/w-able file system, I have tried to > find out how to disable the storage of the python import module > compilations into the source tree, but haven't found the answer. Since > python obviously doesn't *need* to have the compiled files, it seems the > import function ought to have some flag to turn it off. Python will not create the .pyc files if it can't. I agree that creating files under the source tree does violate principle of least astonishment (POLA) where folk are hosting the source e.g. on an NFS file system. This seems to be an ongoing issue within the Python community: http://bugs.python.org/issue602345 (this is in trunk, but hasn't been backported) http://www.python.org/dev/peps/pep-0304/ (a withdrawn PEP) I'm mostly using Python 2.6 these days. There is also 'importlib', that only just got backported to 2.7. If it's a real issue for you, then it would make sense to take it up with the Python guys. I can see how it would bite embedded systems with a flash filesystem. > Since there > isn't a 'clean' target either, this is still a very unclean situation. > To clean a SCons build, use 'scons -c'. I had hoped to add syntactic sugar to provide folk with a 'scons clean' target, however, I haven't been able to find free time to do that yet. It shouldn't be too difficult for someone familiar with Python (and willing to get familiar with SCons) to add, and there are other projects using SCons which this can be cribbed from (e.g. Mapnik). > In general, I think, compiling outside the source tree should actually > start from the builddir, not the source directory. Instead of having to > specify the build directory on the command line, one should specify the > source directory while having the builddir as current directory. This is > much more convenient when, for example, one wants to capture/redirect > the console output of the process to a file in the build directory, and > it is the traditional method. > In the Automake world, yes, folk usually run configure with a relative path to do this, from a build directory which has just been created. A patch to implement some of this behaviour in the SCons world would be interesting. cheers, BMS From fazlina at sapura.com.my Wed Sep 30 02:08:24 2009 From: fazlina at sapura.com.my (Fazlina Zuria Mohd Anuar) Date: Wed, 30 Sep 2009 17:08:24 +0800 Subject: [Xorp-users] multicast using xorp Message-ID: <47E179216C509646865919E8F4F4F85B0102C397@pluto.sapura.com> Hello!! I would like to ask some advice about configuring multicast network using xorp. I would like to multicast video streaming using vlc player between 2 xorp router. Network diagram: PC--------------------------Xorp Router1-------------------------Xorp Router2-------------------------PC Eth0 Eth0 Eth1 Eth0 Eth1 Eth0 10.160.6.2/24 10.160.6.1/24 10.160.5.1/24 10.160.5.2/24 10.160.7.1/24 10.160.7.2/24 My configuration: /*XORP Configuration File Xorp Router1, v1.0*/ protocols { fib2mrib { disable: false } igmp { disable: false interface eth0 { vif eth0 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } interface eth1 { vif eth1 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag { all { disable: false } } } } pimsm4 { disable: false interface eth0 { vif eth0 { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface eth1 { vif eth1 { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface "register_vif" { vif "register_vif" { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } static-rps { rp 10.160.5.1 { group-prefix 224.0.0.0/4 { rp-priority: 192 hash-mask-len: 30 } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 102400 } traceoptions { flag { all { disable: false } } } } } fea { unicast-forwarding4 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "" disable: false discard: false unreachable: false management: false vif eth0 { disable: false address 10.160.5.1 { prefix-length: 24 broadcast: 10.160.5.255 disable: false } } } interface eth1 { description: "" disable: false discard: false unreachable: false management: false vif eth1 { disable: false address 10.160.6.1 { prefix-length: 24 broadcast: 10.160.6.255 disable: false } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface "register_vif" { vif "register_vif" { disable: false } } traceoptions { flag { all { disable: false } } } } } Both router using same setting & the multicast doesn't working...please advice..TQ!!! Faz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090930/81cb8b17/attachment-0001.html From bms at incunabulum.net Wed Sep 30 09:13:31 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 30 Sep 2009 17:13:31 +0100 Subject: [Xorp-users] multicast using xorp In-Reply-To: <47E179216C509646865919E8F4F4F85B0102C397@pluto.sapura.com> References: <47E179216C509646865919E8F4F4F85B0102C397@pluto.sapura.com> Message-ID: <4AC383AB.5020108@incunabulum.net> Hi, Thanks for your question about XORP multicast support. Fazlina Zuria Mohd Anuar wrote: > > I would like to ask some advice about configuring multicast network > using xorp. > > I would like to multicast video streaming using vlc player between 2 > xorp router. > > ... > > Both router using same setting & the multicast doesn?t working?please > advice..TQ!!! > Your configuration looks OK off the top of my head. Have you checked that IP multicast forwarding cache entries are being pushed to the Linux kernel? The place to look is /proc/net//ip_mr_cache/. Unfortunately I can't be of further help on this issue at the moment, hopefully others on the list can help out. thanks, BMS From phillip.blenkinsopp at logica.com Wed Sep 30 09:31:08 2009 From: phillip.blenkinsopp at logica.com (Blenkinsopp, Phil) Date: Wed, 30 Sep 2009 17:31:08 +0100 Subject: [Xorp-users] multicast using xorp In-Reply-To: <4AC383AB.5020108@incunabulum.net> References: <47E179216C509646865919E8F4F4F85B0102C397@pluto.sapura.com> <4AC383AB.5020108@incunabulum.net> Message-ID: Have you checked that the TTL of the traffic is sufficient? I've been frustrated by this when using VLC in the past because it was set to 1 causing all my traffic to be dropped and the TTL setting is quite well hidden in the UI. -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Bruce Simpson Sent: 30 September 2009 17:14 To: Fazlina Zuria Mohd Anuar Cc: xorp-users at xorp.org Subject: Re: [Xorp-users] multicast using xorp Hi, Thanks for your question about XORP multicast support. Fazlina Zuria Mohd Anuar wrote: > > I would like to ask some advice about configuring multicast network > using xorp. > > I would like to multicast video streaming using vlc player between 2 > xorp router. > > ... > > Both router using same setting & the multicast doesn???t working???please > advice..TQ!!! > Your configuration looks OK off the top of my head. Have you checked that IP multicast forwarding cache entries are being pushed to the Linux kernel? The place to look is /proc/net//ip_mr_cache/. Unfortunately I can't be of further help on this issue at the moment, hopefully others on the list can help out. thanks, BMS _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu sch?tzen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.