From bhavin81 at iitb.ac.in Mon Aug 10 18:11:24 2009 From: bhavin81 at iitb.ac.in (bhavin81 at iitb.ac.in) Date: Tue, 11 Aug 2009 06:41:24 +0530 Subject: [Xorp-hackers] xorp architecture] Message-ID: <3f8d71eb3bd9482d75dae13633147d97.squirrel@gpo.iitb.ac.in> Hello All, I need to modify pim-sm implementation in xorp. I have gone through the code of pim-sm moduel of xorp. I need to modify such that user can specify some choice L,M or S in its IGMP message send to router. (which means i also need to modify igmp at user side so that it gives above three chices). The config files provided by user in xorp and their interface seems to be problem for me. Can you tell me that xorp is implemented at application layer or it is using tcp/ip stack of kernel? I mean to say is it simulating at application layer the network layer functionality? The other querry is while going through pim-sm code it uses pim_join prune function for sending join/prune messages but in which moudle is it really sent to another machine? I know most probably it is fea then can you tell me the way it goes from xorp one router to another router? like pim-sm --> pim-vif --> pim-node --> ---likewise. The last querry is from where pim-sm gets routing information since even if we do not run ospf or any other unicast routing protocol it is still capable of achieving multicast. Thanks in advance for you valuable help. Regards, Bhavin, Networking Student. From schintan at gmail.com Tue Aug 11 14:01:44 2009 From: schintan at gmail.com (Chintan Shah) Date: Tue, 11 Aug 2009 17:01:44 -0400 Subject: [Xorp-hackers] Problem in sending multicast traffic Message-ID: Hi, I am having a problem in sending multicast traffic in our testbed. The testbed consists of five linux machines running xorp in the ring topology. A<->B<->C<->D<->E<->A I am trying to send multicast traffic from router A to router B. I am doing this by running a video multicast application (vic )on router A itself. The receiving vic client is also on the same machine that is router B. Each of the machines also has a third interface that is connected to the external network. This default gateway is through this interface. When I run xorp and try to send the multicast traffic , it always goes through the default gateway on the sender side and is received through the external interface on the receiver side. Since I dont want the multicast traffic to go through this interface while running experiments, I disabled these external interfaces. This also results in having no default gateway on the routers. Now when I start xorp on all routers and start the application on the sender side, I get the following error message. setsockopt: IP_ADD_MEMBERSHIP : No such device I think there is no entry in the routing table and the traffic is sent to the default interface and since that is not present , I get this error. I checked that the multicast routing and PIM-SM are enabled in the kernel. Also the interfaces support multicast. I am not sure if it is alright to have the router itself send and receive the multicast traffic with respect to IGMP messages. Is it necessary to have an external machine to send and receive multicast traffic connected to routers A and B. ? Or is there is something else that I am missing.? Thanks in advance for your help. Chintan. P.S The configuration file is as below: interfaces { interface my_discard { unreachable: true vif my_discard { } } /*interface "br1" { vif "br1" { address 10.1.1.1 { prefix-length: 24 } } } */ interface "eth2" { vif "eth2" { address 192.168.6.2 { prefix-length: 24 } } } interface "eth0" { vif "eth0" { address 192.168.2.2 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false } } protocols { static { interface-route 0.0.0.0/0 { next-hop-interface: "my_discard" next-hop-vif: "my_discard" } } ospf4 { router-id: 127.1.0.2 area 0.0.0.0 { interface "eth2" { vif "eth2" { address 192.168.6.2 { interface-cost: 1 } } } interface "eth0" { vif "eth0" { address 192.168.2.2 { interface-cost: 1 } } } } /* area */ /* traceoptions { flag all { disable: false } } */ } fib2mrib { disable: false } igmp { disable: false /* interface "br1" { vif "br1" { 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 "eth2" { vif "eth2" { 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 "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 } } traceoptions { flag { all { disable: false } } } } /* igmp */ pimsm4 { disable: false /* interface "br1" { vif "br1" { disable: false dr-priority: 125 hello-period: 30 hello-triggered-delay: 5 } } */ interface "eth2" { vif "eth2" { disable: false dr-priority: 125 hello-period: 30 hello-triggered-delay: 5 } } interface "eth0" { vif "eth0" { disable: false dr-priority: 125 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.60.0.1 { group-prefix 224.0.0.0/4 { } } }*/ bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { is-scope-zone: false cand-bsr-by-vif-name: "eth0" /*cand-bsr-by-vif-addr: 0.0.0.0*/ bsr-priority: 199 } } cand-rp { group-prefix 224.0.0.0/4 { is-scope-zone: false cand-rp-by-vif-name: "eth0" /*cand-rp-by-vif-addr: 0.0.0.0*/ rp-priority: 101 rp-holdtime: 150 } } } /* bootstrap */ switch-to-spt-threshold { disable: false interval: 100 bytes: 0 } } /* pimsm4 */ } plumbing { mfea4 { disable: false /* interface "br1" { vif "br1" { disable: false } } */ interface "eth2" { vif "eth2" { disable: false } } interface "eth0" { vif "eth0" { disable: false } } interface "register_vif" { vif "register_vif" { disable: false } } } /* mfea4 */ } /* plumbing */ /* End of Config File */ Chintan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090811/d02d3f29/attachment.html From andyyuen at research.telcordia.com Wed Aug 19 08:50:59 2009 From: andyyuen at research.telcordia.com (Andy Yuen) Date: Wed, 19 Aug 2009 11:50:59 -0400 Subject: [Xorp-hackers] [Xorp-users] XORP to implement Muti-Topology Routing In-Reply-To: <4A8BD480.3000307@incunabulum.net> References: <4A80310A.9090207@research.telcordia.com> <4A86C97D.2050906@incunabulum.net> <4A88B8B2.5050201@research.telcordia.com> <4A8BD480.3000307@incunabulum.net> Message-ID: <4A8C1F63.5010801@research.telcordia.com> Bruce Thanks for your response. I am forwarding it to the mailing lists. Cheers Andy Bruce Simpson wrote: > Andy Yuen wrote: >> Thanks Bruce. >> Actually we are going to implement MTR for Cisco routers in our final >> implementation. What we want to do on XORP is for validation of a >> reactive protocols for traffic engineering. When congestion is >> detected at some link, the node will try to reroute some traffic by >> sending a message to the source node of a selected traffic flow. The >> source node then selects an alternate route and topology to reach >> destination. I was wondering for demo purposes, is it possible to use >> policy statement to set different routes for different router tags >> and use the set statement to set all packets arriving with a specific >> router tag? >> I am not familiar with policy statement yet and just curious to know >> if it is possible. > > I think you can match on the tag field in the AS-External-LSA > according to the manual -- I guess this is what you mean by router > tag. Router ID matching isn't supported. I did add this to OLSR as it > seemed reasonable to do that, particularly given OLSR is peer-to-peer > in the p2p sense; OSPF isn't. > > Having said that, TE / MT mods to the OSPF implementation would be > great and something worth considering as a feature, it's a case of who > gets paid to sit down and do it, if it isn't already in XORP, Inc's > product roadmap (I don't believe it is). > > PS It would be great if you could Cc: XORP related traffic to the > xorp-users or xorp-hackers list. thanks! From r.harbird at cs.ucl.ac.uk Fri Aug 21 10:39:52 2009 From: r.harbird at cs.ucl.ac.uk (Rae Harbird) Date: Fri, 21 Aug 2009 18:39:52 +0100 Subject: [Xorp-hackers] Problem with bootstrap Message-ID: Hi I need to generate Makefiles but I am getting an error when I run "bootstrap": Checking configuration files...done. rm -f config.cache rm -f aclocal.m4 rm -f config/aclocal.m4 rm -f mibs/config.cache rm -f mibs/aclocal.m4 aclocal-1.10 -I config config/compiler_flags.m4:156: error: m4_defn: undefined macro: _m4_divert_diversion config/compiler_flags.m4:156: the top level autom4te-2.61: /usr/bin/m4 failed with exit status: 1 aclocal-1.10: autom4te-2.61 failed with exit status: 1 Error running 'aclocal-1.10 -I config' I am running XORP on Ubuntu 9.04, with a 2.6.28-13-generic kernel. I am also running slightly different versions of some autotools: aclocal (GNU automake) 1.10.2 autoconf (GNU Autoconf) 2.63 autoheader (GNU Autoconf) 2.63 autom4te (GNU Autoconf) 2.63 automake (GNU automake) 1.10.2 Can someone suggest a workaround? Thanks Rae From bms at incunabulum.net Mon Aug 24 14:49:08 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 24 Aug 2009 22:49:08 +0100 Subject: [Xorp-hackers] Announcement: XORP code repository is now live again Message-ID: <4A930AD4.90006@incunabulum.net> Hello all, This is to announce that the XORP code repository is now publicly available again. The community version of XORP is now being hosted at SourceForge. Public read-only Subversion access has been enabled. Once again, we are very sorry for the delay involved. Since the transition to XORP, Inc. it was necessary to seek legal advice, to ensure that releasing the code did not affect the company's position with regards to copyright and intellectual property. We are confident these issues have now been resolved, so open development of the code base may now re-commence. We look forward to your feedback, comments and suggestions. Testing of the public code is strongly encouraged; the more feedback we receive, the more quickly we can prepare a 1.7 release candidate from this branch. This would, however, be a maintenance release only, with no new features planned at this time. The major changes to the code in SVN, from 1.6, are as follows: * The adoption of a new Python-based build system, SCons. * The docs/ have been moved out of the source code directory itself. SCons has also been deployed there. * GNU autotools have been completely eliminated from the tree. * Platform support has also narrowed considerably, as we no longer have access to all of the testing resources. We are focusing on Ubuntu, Fedora and FreeBSD at this time. * SNMP support has also been dropped, as the work was incomplete. The main development plan is to refactor the code base to use the Boost C++ Libraries, and to transition XRL to Facebook/Apache's Thrift RPC middleware. This work has already begun. Here are some brief instructions for checking out the XORP code from Sourceforge SVN: XORP SVN Quick Hints ==================== To check out xorp source from trunk read-only: $ svn co http://xorp.svn.sourceforge.net/svnroot/xorp/trunk/xorp The first time you check out XORP you may get a message like this: Error validating server certificate for 'https://xorp.svn.sourceforge.net:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: *.svn.sourceforge.net - Valid: from Tue, 11 Nov 2008 20:25:27 GMT until Mon, 11 Jan 2010 20:25:27 GMT - Issuer: Equifax Secure Certificate Authority, Equifax, US - Fingerprint: 04:b2:70:e9:ba:cf:70:fc:e8:8a:22:86:14:13:51:97:1b:6a:de:38 (R)eject, accept (t)emporarily or accept (p)ermanently? All that should need to be done is to hit the 'p' key. To switch an existing read-only checkout to read-write access: $ svn switch --relocate http://xorp.svn.sourceforge.net/svnroot/xorp https://xorp.svn.sourceforge.net/svnroot/xorp This assumes you have a SourceForge account, and have been granted commit privileges for the xorp project. Once again, thanks for all your encouragement and support over the years, and your patience as we prepare to move in a radically different direction. We look forward to improving XORP further with your help. thanks, BMS From rae.harbird at gmail.com Tue Aug 25 12:56:45 2009 From: rae.harbird at gmail.com (Rae Harbird) Date: Tue, 25 Aug 2009 20:56:45 +0100 Subject: [Xorp-hackers] Announcement: XORP code repository is now live again In-Reply-To: <4A930AD4.90006@incunabulum.net> References: <4A930AD4.90006@incunabulum.net> Message-ID: Hi I am running XORP on Linux Ubuntu 9.04, kernel 2.6.28-13-generic #45-Ubuntu I have checked out the code from the svn repository and started using SCons (which I like). Everything is going well and I can run up "xorp_rtrmgr" successfully. I am having trouble getting scons to install the binaries and libraries for olsr. I have been running scons from the top directory as follows: scons . sudo scons install I have made minor amendments to some of the scons config files which may (or may not) have helped the situation: 1. SConstruct - modified line: env['WITH_OLSR'] = ARGUMENTS.get('enable-olsr', False) to: env['WITH_OLSR'] = ARGUMENTS.get('enable-olsr', True) 2. Modified the subdirs variable in the top-level SConscript directory to include 'olsr' 3. Added or uncommented references to olsr4 in: xrl/interfaces/SConscript xrl/targets/SConscript etc/templates/SConscript I get a warning when I run "scons .": scons: warning: Ignoring missing SConscript 'obj/i686-linux-public17/olsr/SConscript' File "/data/XORP/XORP_SVN_1.6/xorp/SConscript", line 50, in The obj/i686-linux-public17/olsr directory is created although remains empty. There is no olsr directory under /usr/local/xorp/ either. What have I missed? Rae ===== 2009/8/24 Bruce Simpson : > Hello all, > > This is to announce that the XORP code repository is now publicly > available again. The community version of XORP is now being hosted at > SourceForge. Public read-only Subversion access has been enabled. > > ? ?Once again, we are very sorry for the delay involved. Since the > transition to XORP, Inc. it was necessary to seek legal advice, to > ensure that releasing the code did not affect the company's position > with regards to copyright and intellectual property. We are confident > these issues have now been resolved, so open development of the code > base may now re-commence. > > ? ?We look forward to your feedback, comments and suggestions. Testing > of the public code is strongly encouraged; the more feedback we receive, > the more quickly we can prepare a 1.7 release candidate from this > branch. This would, however, be a maintenance release only, with no new > features planned at this time. > > ? ?The major changes to the code in SVN, from 1.6, are as follows: > ?* The adoption of a new Python-based build system, SCons. > ?* The docs/ have been moved out of the source code directory itself. > SCons has also been deployed there. > ?* GNU autotools have been completely eliminated from the tree. > ?* Platform support has also narrowed considerably, as we no longer have > access to all of the testing resources. We are focusing on Ubuntu, > Fedora and FreeBSD at this time. > ?* SNMP support has also been dropped, as the work was incomplete. > > ? ?The main development plan is to refactor the code base to use the > Boost C++ Libraries, and to transition XRL to Facebook/Apache's Thrift > RPC middleware. This work has already begun. > > Here are some brief instructions for checking out the XORP code from > Sourceforge SVN: > > XORP SVN Quick Hints > ==================== > > To check out xorp source from trunk read-only: > > ?$ svn co http://xorp.svn.sourceforge.net/svnroot/xorp/trunk/xorp > > The first time you check out XORP you may get a message like this: > > Error validating server certificate for > 'https://xorp.svn.sourceforge.net:443': > ?- The certificate is not issued by a trusted authority. Use the > ? fingerprint to validate the certificate manually! > Certificate information: > ?- Hostname: *.svn.sourceforge.net > ?- Valid: from Tue, 11 Nov 2008 20:25:27 GMT until Mon, 11 Jan 2010 > 20:25:27 GMT > ?- Issuer: Equifax Secure Certificate Authority, Equifax, US > ?- Fingerprint: 04:b2:70:e9:ba:cf:70:fc:e8:8a:22:86:14:13:51:97:1b:6a:de:38 > (R)eject, accept (t)emporarily or accept (p)ermanently? > > All that should need to be done is to hit the 'p' key. > > To switch an existing read-only checkout to read-write access: > > ?$ svn switch --relocate http://xorp.svn.sourceforge.net/svnroot/xorp > https://xorp.svn.sourceforge.net/svnroot/xorp > > This assumes you have a SourceForge account, and have been granted commit > privileges for the xorp project. > > Once again, thanks for all your encouragement and support over the > years, and your patience as we prepare to move in a radically different > direction. We look forward to improving XORP further with your help. > > thanks, > BMS > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From peterplo at hotmail.com Tue Aug 25 13:01:23 2009 From: peterplo at hotmail.com (Peter Ploter) Date: Tue, 25 Aug 2009 16:01:23 -0400 Subject: [Xorp-hackers] Default OSPF external type Message-ID: Hello, By default, routes (e.g., static, BGP) are redistributed into OSPF as External Type 2. What changes should be made to the code so that by default, routes are instead redistributed as External Type 1? Thank you for your help, Peter _________________________________________________________________ Windows Live: Make it easier for your friends to see what you?re up to on Facebook. http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_facebook:082009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090825/ae5c4ab3/attachment.html From jtc at acorntoolworks.com Tue Aug 25 14:40:12 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Tue, 25 Aug 2009 14:40:12 -0700 Subject: [Xorp-hackers] [Xorp-users] Announcement: XORP code repository is now live again In-Reply-To: (Rae Harbird's message of "Tue, 25 Aug 2009 20:56:45 +0100") References: <4A930AD4.90006@incunabulum.net> Message-ID: <877hwr7etf.fsf@orac.acorntoolworks.com> Rae Harbird writes: > I am running XORP on Linux Ubuntu 9.04, kernel 2.6.28-13-generic #45-Ubuntu > > I have checked out the code from the svn repository and started using > SCons (which I like). Everything is going well and I can run up > "xorp_rtrmgr" successfully. > > I am having trouble getting scons to install the binaries and > libraries for olsr. > > I have been running scons from the top directory as follows: > > scons . > sudo scons install > > I have made minor amendments to some of the scons config files which > may (or may not) have helped the situation: > > 1. SConstruct - modified line: > > env['WITH_OLSR'] = ARGUMENTS.get('enable-olsr', False) > > to: > > env['WITH_OLSR'] = ARGUMENTS.get('enable-olsr', True) This changes the default for OLSR from False to True. It should have been possible to specify this option on the command line with "scons enable-olsr=true ...". The intent is that all build options are available through command line arguments. We recently found some issue with the handling of binary valued options. For example, both enable-olsr=True and enable-olsr=False would actually enable the option because the argument is a string and in Python non- zero length strings evaluate as True in boolean contexts. I've just checked in a fix for this for the 'shared' and 'strip' options, and will extend it to all boolean options over time. > 2. Modified the subdirs variable in the top-level SConscript directory > to include 'olsr' I believe this should have been 'contrib/olsr'. Actually, what's missing is a SConscript within contrib which enables (adds to subdirs) the various contrib modules based on build options. But until that's done, you'll want to add 'contrib/olsr' to the top SConstruct. One word of warning is that will defeat the build option, as the olsr SConscript has no conditionals of its own. > 3. Added or uncommented references to olsr4 in: > > xrl/interfaces/SConscript > xrl/targets/SConscript > etc/templates/SConscript Yes, these are needed. One thing that has been discussed is moving the XLR interface and target files, router manager template files, etc. out of a common directory and into each protocol (There are common bits, of course, that would still have to live in a common directory). The advantage of this is that all the protocol related code would be in one place, and if we go further conditionalizing the building of individual XORP protocols, all those conditionals will be in the protocol's SConscript rather than scattered around/across the source tree. It may not make sense to do this now, especially with the upcoming plans to update the IPC mechanism, but community feedback on this idea would be most welcome. > I get a warning when I run "scons .": > > scons: warning: Ignoring missing SConscript > 'obj/i686-linux-public17/olsr/SConscript' > File "/data/XORP/XORP_SVN_1.6/xorp/SConscript", line 50, in I think this will be fixed once you address 2). > What have I missed? I don't think you've missed much. I'm not sure what the status of OLSR is and how/why it's build was missed. Perhaps Bruce will have something to say on that point. That being said, I'm not suprised by the type of problems you ran into. I expect more of a similar nature as more people check out the new public code and try out the new build system. But they all should be easy to fix, and the faster the problems are reported the quicker they will be resolved. --jtc -- J.T. Conklin From eltonyli at gmail.com Wed Aug 26 03:19:09 2009 From: eltonyli at gmail.com (Eltony Li) Date: Wed, 26 Aug 2009 18:19:09 +0800 Subject: [Xorp-hackers] A question about XrlStdRouter::create_listener() Message-ID: <94a3f25b0908260319i251506d3o5d67bf7592360adc@mail.gmail.com> Hi, Why use default port = 0 for "new XrlPFInProcListener(_e, this);"? I found the default port (0) is used for system call ,bind(...). thanks a lot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090826/a7436b8b/attachment.html From bms at incunabulum.net Wed Aug 26 04:39:56 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 26 Aug 2009 12:39:56 +0100 Subject: [Xorp-hackers] Default OSPF external type In-Reply-To: References: Message-ID: <4A951F0C.7010700@incunabulum.net> Peter Ploter wrote: > > By default, routes (e.g., static, BGP) are redistributed into OSPF as > External Type 2. What changes should be made to the code so that by > default, routes are instead redistributed as External Type 1? Look in External::announce() where policy filtering may already change the value of the E-bit for an AS-External-LSA. Please refer to XORP User Manual section 'Policy', 'OSPF', 'Actions', 'external-type'. thanks, BMS From bms at incunabulum.net Wed Aug 26 04:46:15 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 26 Aug 2009 12:46:15 +0100 Subject: [Xorp-hackers] OLSR build glue In-Reply-To: References: <4A930AD4.90006@incunabulum.net> Message-ID: <4A952087.2050800@incunabulum.net> Hi Rae, Thanks for your ongoing interest in OLSR, which is an optional XORP component at the moment. If you can test a prospective release candidate on Ubuntu, that is excellent, we need all the help we can get to push out a 1.7-RC. Unfortunately, at the moment, OLSR isn't a priority, as we try to bring the XORP install up under the new build system. We may get around to fixing this later on, as we figure out some of the kinks with SCons. For now, we've focused on the core XORP components which people are using. What we really want to see is a means of building/installing optional XORP components without having everything in one central location in the source directory. This was achieved with FTJam, and should be possible with SCons. Based on what you've posted, it sounds like a path needs to be fixed somewhere, as olsr resides under 'contrib'. The obj/ hierarchy which SCons creates corresponds to the source directories. JT just cut over to using the Variables() object in SConstruct, so scons command line options for the build might need a rethink. thanks, BMS From bms at incunabulum.net Wed Aug 26 04:50:47 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 26 Aug 2009 12:50:47 +0100 Subject: [Xorp-hackers] A question about XrlStdRouter::create_listener() In-Reply-To: <94a3f25b0908260319i251506d3o5d67bf7592360adc@mail.gmail.com> References: <94a3f25b0908260319i251506d3o5d67bf7592360adc@mail.gmail.com> Message-ID: <4A952197.4060401@incunabulum.net> Eltony Li wrote: > Why use default port = 0 for "new XrlPFInProcListener(_e, this);"? I > found the default port (0) is used for system call ,bind(...). I assume you're referring to the XrlPFSTCP code, and that XrlPFInProcListener is a typo, as it contains no references to sockets anywhere. In STCP, sockets are being instantiated for ephemeral RPC use, therefore the port chosen is ephemeral (0). From bms at incunabulum.net Wed Aug 26 04:59:36 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 26 Aug 2009 12:59:36 +0100 Subject: [Xorp-hackers] Problem in sending multicast traffic In-Reply-To: References: Message-ID: <4A9523A8.60208@incunabulum.net> Chintan Shah wrote: > ... > Now when I start xorp on all routers and start the application on the > sender side, I get the following error message. > > setsockopt: IP_ADD_MEMBERSHIP : No such device > > I think there is no entry in the routing table and the traffic is sent > to the default interface and since that is not present , I get this error. > I checked that the multicast routing and PIM-SM are enabled in the > kernel. Also the interfaces > support multicast. I am not sure if it is alright to have the router > itself send and receive the multicast traffic with respect to IGMP > messages. IP multicast applications need to be aware of the links available on the host system. Unfortunately over time, IP multicast has been a generally misunderstood topic, and many applications do not support explicitly binding to an interface, although there have been many community resources explaining exactly why this is necessary, and how to achieve it. I believe VLC is not an offender here, however, it sounds as though the legacy multicast socket APIs are being used. Most multicast client implementations will choose the interface of the default gateway when no link is specified (either by IP address or interface index). You probably need to tell VLC to listen for multicast traffic on the IP address of B facing A. From bms at incunabulum.net Wed Aug 26 05:02:44 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 26 Aug 2009 13:02:44 +0100 Subject: [Xorp-hackers] Question about templates In-Reply-To: <200907162352371715409@sina.com> References: <200907161628071651545@sina.com>, <200907161838038121021@sina.com> <200907162352371715409@sina.com> Message-ID: <4A952464.8010408@incunabulum.net> yuzhijun263 wrote: > If the type of test1 change u32,it's ok.The version of xorp is xorp1.4.Don't the version support the type of i32? Can you try updating to the latest SVN release and let us know if this problem still exists? Thanks. From bms at incunabulum.net Thu Aug 27 04:35:45 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 27 Aug 2009 12:35:45 +0100 Subject: [Xorp-hackers] Announce: XORP's Ohloh profile updated Message-ID: <4A966F91.50802@incunabulum.net> Hi all, I have updated the XORP profile page on Ohloh.net: https://www.ohloh.net/p/xorp We're waiting for the SvnSync import to complete, to update the code history. If you are actively using XORP, please feel free to create an Ohloh account, and indicate that you're a XORP user. thanks, BMS From greearb at candelatech.com Thu Aug 27 14:04:55 2009 From: greearb at candelatech.com (Ben Greear) Date: Thu, 27 Aug 2009 14:04:55 -0700 Subject: [Xorp-hackers] HAVE_NETLINK_SOCKET_ATTRIBUTE_RTA_TABLE not #defined when it should be. Message-ID: <4A96F4F7.1040203@candelatech.com> I am trying to merge my patches into the new svn tree. I notice that HAVE_NETLINK_SOCKET_ATTRIBUTE_RTA_TABLE is not #defined on my system, even though it should be. Perhaps this is something to do with scons? (The old CVS repo had some related code in config.h, etc. Anyone know how to go about fixing this? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jtc at acorntoolworks.com Thu Aug 27 17:13:24 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Thu, 27 Aug 2009 17:13:24 -0700 Subject: [Xorp-hackers] HAVE_NETLINK_SOCKET_ATTRIBUTE_RTA_TABLE not #defined when it should be. In-Reply-To: <4A96F4F7.1040203@candelatech.com> (Ben Greear's message of "Thu, 27 Aug 2009 14:04:55 -0700") References: <4A96F4F7.1040203@candelatech.com> Message-ID: <8763c86biz.fsf@orac.acorntoolworks.com> Ben Greear writes: > I am trying to merge my patches into the new svn tree. I notice > that HAVE_NETLINK_SOCKET_ATTRIBUTE_RTA_TABLE is not #defined on > my system, even though it should be. > > Perhaps this is something to do with scons? (The old CVS repo had > some related code in config.h, etc. > > Anyone know how to go about fixing this? Hi Ben, Yes, this is related to the SCons conversion. It appears that we missed this, and perhaps a few more, feature tests. It will have to be "ported" from autoconf to SCons. I wouldn't be surprised if we find more nits of this nature. As such, I encourage everyone who has time to try out the current code to do so, so we can shake things out quickly. --jtc -- J.T. Conklin From bms at incunabulum.net Fri Aug 28 04:36:29 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri, 28 Aug 2009 12:36:29 +0100 Subject: [Xorp-hackers] Compile problems for Xorp on Fedora 11. In-Reply-To: <4A43D346.20703@incunabulum.net> References: <4A42AA4E.5040204@candelatech.com> <4A43AB27.5090506@incunabulum.net> <4A43B1F3.6000008@candelatech.com> <4A43B715.20500@incunabulum.net> <4A43C742.8060008@candelatech.com> <4A43D346.20703@incunabulum.net> Message-ID: <4A97C13D.6070608@incunabulum.net> Just a note to say: #ident has been eliminated from the public SVN sources, as I was able to quickly reproduce this issue with an out-of-the-box Fedora 11 install in Sun VirtualBox. Thanks for reporting this issue. cheers, BMS From greearb at candelatech.com Fri Aug 28 10:03:36 2009 From: greearb at candelatech.com (Ben Greear) Date: Fri, 28 Aug 2009 10:03:36 -0700 Subject: [Xorp-hackers] HAVE_NETLINK_SOCKET_ATTRIBUTE_RTA_TABLE not #defined when it should be. In-Reply-To: <8763c86biz.fsf@orac.acorntoolworks.com> References: <4A96F4F7.1040203@candelatech.com> <8763c86biz.fsf@orac.acorntoolworks.com> Message-ID: <4A980DE8.6060301@candelatech.com> On 08/27/2009 05:13 PM, J.T. Conklin wrote: > Ben Greear writes: >> I am trying to merge my patches into the new svn tree. I notice >> that HAVE_NETLINK_SOCKET_ATTRIBUTE_RTA_TABLE is not #defined on >> my system, even though it should be. >> >> Perhaps this is something to do with scons? (The old CVS repo had >> some related code in config.h, etc. >> >> Anyone know how to go about fixing this? > > Hi Ben, > > Yes, this is related to the SCons conversion. It appears that we > missed this, and perhaps a few more, feature tests. It will have > to be "ported" from autoconf to SCons. > > I wouldn't be surprised if we find more nits of this nature. As such, > I encourage everyone who has time to try out the current code to do > so, so we can shake things out quickly. The attached patch seems to fix the problem for me. Please apply it if you concur. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rta_nl.patch Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090828/7a91b247/attachment.ksh From bms at incunabulum.net Mon Aug 31 05:47:56 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 31 Aug 2009 13:47:56 +0100 Subject: [Xorp-hackers] 'unused parameter' error when build xorp on freebsd with --disable-ipv6 In-Reply-To: <20090504210453.GA31065@expo.ukrweb.net> References: <20090504210453.GA31065@expo.ukrweb.net> Message-ID: <4A9BC67C.9020507@incunabulum.net> Mykola Dzham wrote: > ... > firewall_get_ipfw2.cc:143: warning: unused parameter 'firewall_entry_list' > > I writed patch (attached), that fix build, but i not tested xorp > working. Can anyone confirm build problem and test this patch? > An appropriate fix has been committed as rev 11525 to SVN, thanks! From bms at incunabulum.net Mon Aug 31 05:52:15 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 31 Aug 2009 13:52:15 +0100 Subject: [Xorp-hackers] Bug report. In-Reply-To: <56f9e0990810282312q35807459r1310ae268a6b14ca@mail.gmail.com> References: <56f9e0990810282312q35807459r1310ae268a6b14ca@mail.gmail.com> Message-ID: <4A9BC77F.2070504@incunabulum.net> ??? wrote: > when you entry a "xxx xxxx" value into txt node. The xorpsh will > pass it. But when you use show -all in CLI, the information in your > screen is wrong. Apparently, text should not be "\"abc cba\"". > Sorry for the late reply. Can you please raise a bug report about this issue? We are moving to a new bug tracking system on SourceForge: https://sourceforge.net/apps/trac/xorp/ ...the bugzilla.xorp.org alias now points to this page. You will need to create a SourceForge account to submit bugs using Trac: https://sourceforge.net/account/registration/ thanks, BMS From bms at incunabulum.net Mon Aug 31 06:21:38 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 31 Aug 2009 14:21:38 +0100 Subject: [Xorp-hackers] HAVE_NETLINK_SOCKET_ATTRIBUTE_RTA_TABLE not #defined when it should be. In-Reply-To: <4A980DE8.6060301@candelatech.com> References: <4A96F4F7.1040203@candelatech.com> <8763c86biz.fsf@orac.acorntoolworks.com> <4A980DE8.6060301@candelatech.com> Message-ID: <4A9BCE62.8020808@incunabulum.net> Committed as rev 11526, thanks! From marco.canini at epfl.ch Mon Aug 31 08:13:03 2009 From: marco.canini at epfl.ch (Canini Marco) Date: Mon, 31 Aug 2009 17:13:03 +0200 Subject: [Xorp-hackers] RIB serialization Message-ID: Hi all, I'm working on a research project for which we'd like to be able to dump the RIB at arbitrary checkpoint instants. To do that, I've tried to apply a library called boost serialization that offers some support to write objects to file. I've got to the point where I need to serialize the class OriginTable. Such class has a class member of type Trie*>. Because of the constness of the Trie Payload type, I'm getting into some troubles with boost serialization. How harmful is it if I remove the const there? I'm aware that such a small change is going to require many other changes to basically remove the const attribute in lots of places. Thanks for your advices. Marco Canini, Ph.D. EPFL, Networked Systems Laboratory From greearb at candelatech.com Fri Aug 28 11:16:15 2009 From: greearb at candelatech.com (Ben Greear) Date: Fri, 28 Aug 2009 11:16:15 -0700 Subject: [Xorp-hackers] Patch to FEA to support multiple xorp instances on Linux. Message-ID: <4A981EEF.2090807@candelatech.com> Attached is a patch for just my FEA changes (and a few related bits to make that function properly). I've tested this lightly with OSPF and two virtual routers (no need for OSPF changes, it looks like all my hackings in ospf are for debugging logic). Seems to work as desired. I'm using Fedora 11, 64-bit. Much of this depends on features in Linux, but code *should* function on other OS's as it used to, with no loss of functionality on those platforms. This patch includes several features: * Optimize FEA netlink logic to pay attention to only routes in the routing table it is configured for. Big performance win with lots of xorp instances & routes. * Change iftree logic to only pay attention to interfaces configured for this instance of Xorp. This is a big performance win when you have hundreds or thousands of (probably virtual) interfaces. This patch also deals better with interfaces that come and go while Xorp is running (some fatal warnings related to suddenly disappeared interfaces are less severe.) * Allow reading info for a single interface instead of always requesting info for all interfaces via netlink. This is another optimization that works well with the lazy construction of interface lists. * Allow using one socket per interface for multicast and other socket operations, instead of one global socket that listens to all interfaces. This allows xorp to only receive events for interfaces it cares about...a big performance win when we have lots of xorp instances (and/or lots of interfaces that we do NOT want a particular xorp listening to). USE_SOCKET_PER_IFACE is the #ifdef that controls this. It's currently set in code, but could be an scons variable. See: /fea/data_plane/io/io_ip_socket.hh * Make lower levels of fea aware when interfaces come or go, so it can clean up sockets and/or multicast lists accordingly. ( IoIpSocket::notifyDeletingIface, IoIpSocket::notifyDeletingVif, etc) * Support leaving all mcast groups for an interface. Good to call when an interface is going away (protocols usually learn too late to specifically remove their groups from the mcast socket). * Support using multiple multicast routing tables. This also requires a patch I made against the linux kernel to be functional. If this could be accepted into xorp, I might have better luck getting the patch into linux. This patch makes mfea_mrouter code a bit ugly, but it should be fully backwards compat with normal linux kernels and BSD, etc. If/when we can get this patch (or similar) accepted, I'll post the patches for RIP, PIM, OLSR, and BGP, etc. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp_fea.patch Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090828/4d073640/attachment-0001.ksh From bms at incunabulum.net Mon Aug 31 11:03:34 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 31 Aug 2009 19:03:34 +0100 Subject: [Xorp-hackers] RIB serialization In-Reply-To: References: Message-ID: <4A9C1076.4030604@incunabulum.net> Hi Marco, Thanks for looking into this. We do plan to introduce Boost incrementally to the source tree, however this effort is still at a very early stage. I am curious if you're using the SVN code, as I have not yet committed my changes to the SCons build glue for XORP to detect Boost's libraries and headers. You might have better luck with your immediate issue by raising the question on the Boost-Users list. Yes, changing the constness of the Trie members is likely to cause a lot of code churn. thanks, BMS From marco.canini at epfl.ch Mon Aug 31 11:21:59 2009 From: marco.canini at epfl.ch (Canini Marco) Date: Mon, 31 Aug 2009 20:21:59 +0200 Subject: [Xorp-hackers] RIB serialization In-Reply-To: <4A9C1076.4030604@incunabulum.net> References: <4A9C1076.4030604@incunabulum.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bruce, at the moment I'm hacking on xorp 1.6. To enable boost support I used the m4 macros from the autoconf archive (http://www.nongnu.org/autoconf-archive/). If I read you correctly now xorp uses scons as the build system though. I'll try to avoid changing the constness then. I hope I hit a bug in boost 1.34 and with a newer version I can get around this problem. Thanks Marco Canini, Ph.D. Networked Systems Laboratory, EPFL > -----Original Message----- > From: Bruce Simpson [mailto:bms at incunabulum.net] > Sent: 31 August 2009 20:04 > To: Canini Marco > Cc: xorp-hackers at icir.org > Subject: Re: [Xorp-hackers] RIB serialization > > Hi Marco, > > Thanks for looking into this. We do plan to introduce Boost > incrementally to the source tree, however this effort is still at a > very > early stage. > > I am curious if you're using the SVN code, as I have not yet committed > my changes to the SCons build glue for XORP to detect Boost's libraries > and headers. > > You might have better luck with your immediate issue by raising the > question on the Boost-Users list. Yes, changing the constness of the > Trie members is likely to cause a lot of code churn. > > thanks, > BMS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqcFMcACgkQK52QDm/mFCmglQCfZa8tcEd9oHWzIkhy7UPamAmq EIsAn1lQ+eNohkJfd6sqXzS4Et9megtq =NfC0 -----END PGP SIGNATURE----- From bms at incunabulum.net Mon Aug 31 11:32:57 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 31 Aug 2009 19:32:57 +0100 Subject: [Xorp-hackers] RIB serialization In-Reply-To: References: <4A9C1076.4030604@incunabulum.net> Message-ID: <4A9C1759.8050001@incunabulum.net> Canini Marco wrote: > at the moment I'm hacking on xorp 1.6. To enable boost support I used the m4 macros from the autoconf archive (http://www.nongnu.org/autoconf-archive/). > If I read you correctly now xorp uses scons as the build system though. > Correct... we have ported most, but not all, of XORP's target network stack autoconf tests to SCons. > I'll try to avoid changing the constness then. I hope I hit a bug in boost 1.34 and with a newer version I can get around this problem. > 1.34 is quite old, I don't plan to start working with anything less recent than 1.39. Some bugs were introduced into Boost.ASIO during an optimization attempt, I believe these were fixed in 1.40. thanks, BMS From bms at incunabulum.net Mon Aug 31 12:10:07 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 31 Aug 2009 20:10:07 +0100 Subject: [Xorp-hackers] RIB serialization In-Reply-To: References: <4A9C1076.4030604@incunabulum.net> Message-ID: <4A9C200F.9080801@incunabulum.net> Canini Marco wrote: > I'll try to avoid changing the constness then. I hope I hit a bug in boost 1.34 and with a newer version I can get around this problem. > http://lists.boost.org/Archives/boost/2006/03/101850.php ...may be a good place to start. We are no longer supporting Microsoft Windows (until someone steps up to maintain it), so I believe their remove_const magic should work. From jose.spam at netvisao.pt Mon Aug 31 15:12:54 2009 From: jose.spam at netvisao.pt (Jose Manuel dos Santos Calhariz) Date: Tue, 1 Sep 2009 00:12:54 +0200 Subject: [Xorp-hackers] What will happen to the bug reports Message-ID: <20090831221254.GA10223@calhariz.com> Now that the xorp code have moved to sourceforge what will happen with the bugreports on bugzilla.xorp.org? Now http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=797 it is redirected to https://sourceforge.net/apps/trac/xorp/?id=797, for example. Jose Calhariz -- -- Somente os grandes homens t?m o direito de possuir grandes defeitos --La Rochefoucauld -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090901/1e91e9a1/attachment.bin From jtc at acorntoolworks.com Mon Aug 31 16:17:59 2009 From: jtc at acorntoolworks.com (J.T. Conklin) Date: Mon, 31 Aug 2009 16:17:59 -0700 Subject: [Xorp-hackers] What will happen to the bug reports In-Reply-To: <20090831221254.GA10223@calhariz.com> (Jose Manuel dos Santos Calhariz's message of "Tue, 1 Sep 2009 00:12:54 +0200") References: <20090831221254.GA10223@calhariz.com> Message-ID: <87skf7zi6w.fsf@orac.acorntoolworks.com> Jose Manuel dos Santos Calhariz writes: > Now that the xorp code have moved to sourceforge what will happen with > the bugreports on bugzilla.xorp.org? Our plan is to manually transcribe the open bug reports from Bugzilla to Trac. > Now http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=797 it is > redirected to https://sourceforge.net/apps/trac/xorp/?id=797, for > example. This looks like an error in the redirect. The intent was for all URLs starting with http://bugzilla.xorp.org/... to redirect to https://sourceforge.net/apps/trac . --jtc -- J.T. Conklin