From atanu@ICSI.Berkeley.EDU Thu Sep 1 02:19:07 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 31 Aug 2005 18:19:07 -0700 Subject: [Xorp-hackers] bgp reflector client In-Reply-To: Message from Per Svensson of "Wed, 31 Aug 2005 11:37:02 +0200." <1125481022.43157a3eae64b@webmail.uu.se> Message-ID: <18609.1125537547@tigger.icir.org> The XORP BGP does not support route reflection yet. We have been given some patches for route reflection and confederations that we intend to apply in the next few weeks. Atanu. >>>>> "Per" == Per Svensson writes: Per> Hi! I would like to use a Xorp as a reflector client. What I Per> actually need is the ORIGINATOR-ID attribute (type code Per> 9). Does it exist a version of Xorp that has this implemented? Per> If such a version doesn't exist, can someone give me some hints Per> on where to look in the sourcecode if I want to implement Per> support for the ORIGINATOR-ID attribute? Per> Thanks Per Svensson Uppsala University Per> _______________________________________________ Xorp-hackers Per> mailing list Xorp-hackers@icir.org Per> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian@juniks.net Thu Sep 1 16:21:52 2005 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 1 Sep 2005 17:21:52 +0200 Subject: [Xorp-hackers] Counter and version Message-ID: <20050901152152.GA7097@juniks.net> Hi! I would like to know if the version of XORP is defined anywhere in the source code? And is there some builtin clock in XORP? I would need a "cron" like function so that functions could be scheduled within the rtrmgr. BTW, I just saw a bug report regarding set/create/edit (#172) and would once again like bring up the discussion. Is it really necessary to have the create command? IMHO create just complicates things as it's functionality could as well be integrated into the 'set' command. Why not merge the two? Regards, Kristian Larsson From Per.Svensson.6835@student.uu.se Thu Sep 1 07:13:27 2005 From: Per.Svensson.6835@student.uu.se (Per Svensson) Date: Thu, 01 Sep 2005 08:13:27 +0200 Subject: [Xorp-hackers] bgp reflector client In-Reply-To: <18609.1125537547@tigger.icir.org> References: <18609.1125537547@tigger.icir.org> Message-ID: <1125555207.43169c0733cac@webmail.uu.se> If it is possible I would be very happy if I could use the reflection patches until you have included it in the official release of Xorp. I'm working on a research project and currently nothing will be used by anyone outside this project. Is it possible to mail the reflection patches to me? Thanks / Per Citerar Atanu Ghosh : > The XORP BGP does not support route reflection yet. We have been given > some patches for route reflection and confederations that we intend to > apply in the next few weeks. > > Atanu. > > >>>>> "Per" == Per Svensson writes: > > Per> Hi! I would like to use a Xorp as a reflector client. What I > Per> actually need is the ORIGINATOR-ID attribute (type code > Per> 9). Does it exist a version of Xorp that has this implemented? > Per> If such a version doesn't exist, can someone give me some hints > Per> on where to look in the sourcecode if I want to implement > Per> support for the ORIGINATOR-ID attribute? > > Per> Thanks Per Svensson Uppsala University > > Per> _______________________________________________ Xorp-hackers > Per> mailing list Xorp-hackers@icir.org > Per> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From kristian@juniks.net Sat Sep 3 23:22:55 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 4 Sep 2005 00:22:55 +0200 Subject: [Xorp-hackers] Bugzilla #54 Message-ID: <20050903222255.GA7031@juniks.net> I've written a small patch to resolve #54. It acts as "normal" giving an error when trying to overwrite a file. However if you add 'overwrite' to the command, save /home/xorp-user/xorp-config overwrite it will overwrite the file. It's rather untested but on the other hand it's fairly simple so there's not much that can go wrong (right? :) ). The patch can be found at: http://skalman.juniks.net/~ply/xorp/overwrite.patch Regards, Kristian From leclanch@enst.fr Sun Sep 4 00:56:24 2005 From: leclanch@enst.fr (leclanch@enst.fr) Date: Sun, 4 Sep 2005 01:56:24 +0200 (CEST) Subject: [Xorp-hackers] IGMPv3 patch & sources Message-ID: <43536.81.62.228.115.1125791784.squirrel@webmail.rezel.enst.fr> ------=_20050904015624_60524 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello, as promised, a little late yet, I provide the result of my humble coding on xorp. I've made XORP a little IGMPv3-compliant. What does the "a little" mean ? Well, IGMPv3 RFC is implemented, and retrocompatibility seemed to work. However, the black points are : - MLDv2 is not implemented (yet a big part of code is shared with igmp) - It can crash and can behave weirdly - It has not been truely tested, since I didn't do tests with PIM, I only tested if XORP maintained a coherent and legal internal state, what it did in the end most of the time (show igmp groups is now igmpv3-friendly) - IT HAS BEEN CODED WITH JUNE 20th XORP SOURCES ! Therefore it does not include any latter changes, including the Windows support. So attached to this mail : A file summarizing all the changes, also placed in the tar.gz To get the igmpv3 mld6igmp source and the diff file for some other files in XORP (libxorp/ip* and igmp template): http://perso.enst.fr/~leclanch/mld6igmp-enst-igmpv3.tar.gz http://perso.enst.fr/~leclanch/igmpv3-others-xorp.diff Feel free to ask anything about this quite unfinished work, I'm sure I forgot to say important things. Guillaume. ------=_20050904015624_60524 Content-Type: text/plain; name="NOTES_igmpv3.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="NOTES_igmpv3.txt" Notes about the implementation of IGMPv3 in XORP. Authors : ------- Guillaume Leclanche Student work for Télécom Paris (École Nationale Supérieure des Télécommunications). http://www.enst.fr Management by Jean-Louis Rougier, Associate Professor, GET/ENST/INFRES. Contact : ------- guillaume -a- leclanche -d- net RFC used : -------- - RFC 3376 (Cain, et al.; Oct 2002) for IGMPv3 Other software used for help : ---------------------------- igmprt (Abdelkader Lahmadi, Loria, 2001) http://www.loria.fr/~lahmadi/igmpv3-router.html BUGS SEEN IN XORP ELSEWHERE : --------------------------- * XorpTimer::schedule_after is declared but not defined ! REAL NOTES START HERE --------------------- Other files modified : * added 224.0.0.22 and FF02::16 as multicast_all_routers_ssm - libxorp/ipv4.cc - libxorp/ipv4.hh - libxorp/ipv6.cc - libxorp/ipv6.hh - libxorp/ipvx.cc - libxorp/ipvx.hh * modified template for igmp version number allowed - etc/templates/igmp.tp How Classes work : ---------------- Mld6igmpVif::_members list GroupRecord::_sources SourceList SourceList : list SourceRecord GroupRecord -> _sources // The SourceList _mld6igmp_vif // The Interface _group // IPv4/6 address _state // Include or Exclude _group_compatibility_mode // IGMP group version _last_reported_host // The last host that // talked about the group _group_timer _last_member_query_timer _igmpv1_host_present_timer _igmpv2_host_present_timer SourceList -> _group // The Group Record _mld6igmp_vif // The Interface SourceRecord -> _group // The Group Record _mld6igmp_vif // The Interface _source_address // IPv4/6 address In SourceList, operators + * - have been overloaded in order to make the operations described in the RFC, that is : + => union * => intersection - => difference operator = has also been overloaded in order to copy only source records. Protocolary treatment : --------------------- - A message arrives => igmp_process() =>igmp_process_groups() - It's a query => igmp_query_recv() - It's a report => igmp_report_recv() - Groups incoming and their source list are compared to the ones in memory. If it's a new group, we create a INCLUDE{} group and then we compare it. * Reference: igmp_proto.cc:679 - If queries need to be sent => mld6igmp_query_send() (see below) - The Group Timer expires => GroupRecord::group_timer_timeout() Action depends on the state of the group - INCLUDE => do nothing (timer is useless) - EXCLUDE => if sources still have running timer switch to INCLUDE {those sources} => else Destroy the source records and the group - The Source Timer expires => SourceRecord::source_timer_timeout() Whatever the state, disable the (S,G) Then if: - _group state is INCLUDE if there are no other sources destroy the source record and the group else destroy the source record only - _ group state is EXCLUDE There's nothing to do since the expired sources are kept in this mode. - On Startup - Variables are got from the configuration file or use commands - The vif subscribes locally to groups: - ALL_SYSTEMS (224.0.0.1) // To send general queries - ALL_ROUTERS (224.0.0.2) // IGMPv1/2 reports dest ip - ALL_ROUTERS_SSM (224.0.0.22) // IGMPv3 reports dest ip - A general query is sent (group = 0.0.0.0 and SourceList* = 0) - Another general query is scheduled to be sent after [startup_query_interval]. The timer is Query Timer. [_query_timer] - The Query Timer expires - A general query is sent (group = 0.0.0.0 and SourceList* = 0) - Another general query is scheduled to be sent after [startup_query_interval]. The timer is Query Timer. [_query_timer] - Sending a IGMP Membership Query => mld6igmp_query_send() There are 3 versions of this function : - an IGMPv1/2 one, without S, QRV, QQIC, SourceList - a group-specific query one without SourceList - a group-and-source-specific query one You MUST give the protocol version to be used ! If you don't know, just put 0, and the function will try to do its best to find the most suitable version TO BE CHECKED OR TO BE DONE --------------------------- * Not sure about how 1/10s and 1s values are put and got in messages. * Retransmissions need to be scheduled for Group(-and-source) queries * Xorp parses its own queries, should it be done or not ? * Xorp does igmp treatment of special mcast adresses (e.g. .2 & .22), and there indications in the RFC that it shouldn't occur (to be checked) * IT'S NOT STABLE, some crashes may occur, I guess mainly due to memory beeing freed for SourceRecord or GroupRecord when timeouts occur. The fact is that I don't manage to update timers correctly, see below. * MLDv2 is not done at all, and MLDv1 is likely to be quite broken * SourceRecord::update_timer doesn't really update the timer but only starts it or restarts it because I didn't find any way to change the expiry time of the timer without having xorp_igmp crash. * States and timer expirations are not correctly tested and behavior may leave sources undeleted (or groups even). ------=_20050904015624_60524-- From kristian@juniks.net Sun Sep 4 19:09:52 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 4 Sep 2005 20:09:52 +0200 Subject: [Xorp-hackers] Bugzilla #54 Message-ID: <20050904180952.GA4502@juniks.net> I've written a small patch to generate a nicer configuration file header. /* XORP configuration file * * XORP version: 1.1 * XORP file format: 0.1 * date: 2005-09-34 11:34:22 * user: xorp-user * host: xorp-lab1 */ I've setup a new variable in configure.in called XORP_CONFIG_FILE_FORMAT_VERSION.. unfortunately it seems I am not able to properly bootstrap on my system so I cannot verify that this variable is set properly. In my tests I've just #defined it at the top of master_conf_tree.cc I'm not sure at all whether such a variable would be the best way to mark file format version but it's there for now. The patch is at: http://skalman.juniks.net/~ply/xorp/config_header.patch at some positions it includes changes that were made in my patch for #53... Waiting for approval ;) Regards, Kristian From pavlin@icir.org Sun Sep 4 19:14:55 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 04 Sep 2005 11:14:55 -0700 Subject: [Xorp-hackers] Counter and version In-Reply-To: Message from Kristian Larsson of "Thu, 01 Sep 2005 17:21:52 +0200." <20050901152152.GA7097@juniks.net> Message-ID: <200509041814.j84IEtsD094352@possum.icir.org> > I would like to know if the version of > XORP is defined anywhere in the source > code? Yes. It is defined inside "config.h": /* Version number of package */ #define VERSION "1.1" Also, file "VERSION" in the top-level XORP directory contains the string with the version. > And is there some builtin clock in XORP? > I would need a "cron" like function so that > functions could be scheduled within the > rtrmgr. Class EventLoop (libxorp/eventloop.hh) contains a number of methods for creating one-time and periodic timers. In the callback for each timer you can specify the function or method to be called. > BTW, I just saw a bug report regarding > set/create/edit (#172) and would once again > like bring up the discussion. Is it really > necessary to have the create command? > IMHO create just complicates things as it's > functionality could as well be integrated > into the 'set' command. > Why not merge the two? The purpose of "create" is to create parts of the configuration that don't exist (e.g., "create protocols bgp"), while the purpose of "set" it to assign values to (leaf) nodes that are suppose to contain values (e.g., "set protocols bgp local-as 1234"). Strictly speaking, it is possible to merge the functionality of "create" into the "set" command, but by doing so we are going to overload the "set" command itself. Then it could be argued that such overload complicates things by merging two different functionalities into a single command. Furthermore, for someone who is not familiar with the exact internal structure of the configuration tree a command like "set protocols bgp" could mean: Set the value of node "protocols" to "bgp". Opening the door for such (mis)interpretations could create more confusions rather than simplifying things. Pavlin From pavlin@icir.org Sun Sep 4 19:18:24 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 04 Sep 2005 11:18:24 -0700 Subject: [Xorp-hackers] Bugzilla #54 In-Reply-To: Message from Kristian Larsson of "Sun, 04 Sep 2005 00:22:55 +0200." <20050903222255.GA7031@juniks.net> Message-ID: <200509041818.j84IIOxp094449@possum.icir.org> > I've written a small patch to resolve #54. > It acts as "normal" giving an error when trying to > overwrite a file. However if you add 'overwrite' > to the command, > save /home/xorp-user/xorp-config overwrite > it will overwrite the file. > > It's rather untested but on the other hand it's > fairly simple so there's not much that can go > wrong (right? :) ). > The patch can be found at: > http://skalman.juniks.net/~ply/xorp/overwrite.patch Please upload the patch to the above bugzilla entry. Thanks, Pavlin From pavlin@icir.org Sun Sep 4 19:21:24 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 04 Sep 2005 11:21:24 -0700 Subject: [Xorp-hackers] Bugzilla #54 In-Reply-To: Message from Kristian Larsson of "Sun, 04 Sep 2005 20:09:52 +0200." <20050904180952.GA4502@juniks.net> Message-ID: <200509041821.j84ILODH094483@possum.icir.org> > I've written a small patch to generate a nicer > configuration file header. > > /* XORP configuration file > * > * XORP version: 1.1 > * XORP file format: 0.1 > * date: 2005-09-34 11:34:22 > * user: xorp-user > * host: xorp-lab1 > */ > > I've setup a new variable in configure.in called > XORP_CONFIG_FILE_FORMAT_VERSION.. unfortunately it > seems I am not able to properly bootstrap on my > system so I cannot verify that this variable is > set properly. > In my tests I've just #defined it at the top of > master_conf_tree.cc > I'm not sure at all whether such a variable would > be the best way to mark file format version but > it's there for now. > > The patch is at: > http://skalman.juniks.net/~ply/xorp/config_header.patch > at some positions it includes changes that were > made in my patch for #53... Yes, in the past we have been thinking about adding more info to the header of the XORP config files, but so far we didn't get the time to do it ourselves. Again, please upload the above patch to bugzilla entry #53. Thanks, Pavlin From deathdealer@gmx.net Sun Sep 4 19:37:13 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Sun, 4 Sep 2005 20:37:13 +0200 Subject: [Xorp-hackers] show route table ipv4 unicast final Message-ID: <200509041837.j84IbNxo077393@wyvern.icir.org> Hello is it possible to change the output of the show route command, so that it looks more like the following in a "brief" format: ------------ snip ------------- Xorp> show route table ipv4 unicast final 10.0.0.0/8 [rip(120)/11] xx:xx:xx > to 10.0.8.161 via xl0/xl0 10.0.8.0/21 [connected(0)/0] xx:xx:xx > via xl0/xl0 10.0.240.0/24 [connected(0)/0] xx:xx:xx > via xl1/xl1 172.16.0.0/24 [ebgp(20)/0] xx:xx:xx > to 10.0.8.161 via xl0/xl0 ------------ snip ------------- The code snippset below would do this, the format should be interpreted in the way: ------------ snip ------------- Prefix [protocol(ad)/metric] time > to nexthop via interface/vif ------------ snip ------------- I would suggest also to extend "show routes" so it displays by default the current ipv4 routing table. Is the time when the route is installed in the rib/kernel somewhere maintained? file: xorp/rib/tools/show_routes.cc ------------ snip ------------- display_route(const IPNet& net, const A& nexthop, const string& ifname, const string& vifname, const uint32_t metric, const uint32_t admin_distance) { cout << "" << net.str() << "\t"; cout << "[" ; const char* protocol = ad2protocol(admin_distance); if (protocol == 0) { cout << admin_distance; } else { cout << protocol << "(" << admin_distance << ")"; } cout << "/" << metric << "]" << " xx:xx:xx" << endl ; cout << "\t\t> " ; if (admin_distance != 0) cout << "to " << nexthop.str() << " "; if (ifname.empty() == false) cout << "via " << ifname ; if (vifname.empty() == false) cout << "/" << vifname; cout << endl; } ------------ snip ------------- best regards, Patrick Marc Preuss Nordstrasse 28 41569 Rommerskirchen, Germany From kristian@juniks.net Sun Sep 4 20:39:54 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 4 Sep 2005 21:39:54 +0200 Subject: [Xorp-hackers] Bugzilla #54 In-Reply-To: <200509041818.j84IIOxp094449@possum.icir.org> References: <20050903222255.GA7031@juniks.net> <200509041818.j84IIOxp094449@possum.icir.org> Message-ID: <20050904193954.GB4502@juniks.net> On Sun, Sep 04, 2005 at 11:18:24AM -0700, Pavlin Radoslavov wrote: > > I've written a small patch to resolve #54. > > It acts as "normal" giving an error when trying to > > overwrite a file. However if you add 'overwrite' > > to the command, > > save /home/xorp-user/xorp-config overwrite > > it will overwrite the file. > > > > It's rather untested but on the other hand it's > > fairly simple so there's not much that can go > > wrong (right? :) ). > > The patch can be found at: > > http://skalman.juniks.net/~ply/xorp/overwrite.patch > > Please upload the patch to the above bugzilla entry. > I kinda messed up the subjects of my two mails so it got a bit confusing. This patch: http://skalman.juniks.net/~ply/xorp/config_header.patch is for Bugzilla #53. This patch: http://skalman.juniks.net/~ply/xorp/overwrite.patch is for Bugzilla #54. It fixes so no files are overwritten unless you specify so. There is still one 'bug'. When typing: save /home/ply/file the tab completion won't show 'overwrite' as an option. I just noticed this and don't know how to fix it right away. I suppose someone more educated on the xorpsh would know though I will try to find a solution. Also, for you convenience, there's the http://skalman.juniks.net/~ply/xorp/both.patch which includes both of the above and seems to apply cleanly on the latest CVS. Regards, Kristian From pavlin@icir.org Sun Sep 4 21:14:48 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 04 Sep 2005 13:14:48 -0700 Subject: [Xorp-hackers] Bugzilla #54 In-Reply-To: Message from Kristian Larsson of "Sun, 04 Sep 2005 21:39:54 +0200." <20050904193954.GB4502@juniks.net> Message-ID: <200509042014.j84KEmRv095239@possum.icir.org> > On Sun, Sep 04, 2005 at 11:18:24AM -0700, Pavlin Radoslavov wrote: > > > I've written a small patch to resolve #54. > > > It acts as "normal" giving an error when trying to > > > overwrite a file. However if you add 'overwrite' > > > to the command, > > > save /home/xorp-user/xorp-config overwrite > > > it will overwrite the file. > > > > > > It's rather untested but on the other hand it's > > > fairly simple so there's not much that can go > > > wrong (right? :) ). > > > The patch can be found at: > > > http://skalman.juniks.net/~ply/xorp/overwrite.patch > > > > Please upload the patch to the above bugzilla entry. > > > > I kinda messed up the subjects of my two mails so > it got a bit confusing. OK, in any case please upload each patch to the particular bugzilla entry, because bugzilla entries are much easier to track and/or correct compared to email exchanges. You could upload the "both.patch" as well (to both entries). Thanks, Pavlin > This patch: > http://skalman.juniks.net/~ply/xorp/config_header.patch > is for Bugzilla #53. > > This patch: > http://skalman.juniks.net/~ply/xorp/overwrite.patch > is for Bugzilla #54. It fixes so no files are > overwritten unless you specify so. There is still > one 'bug'. When typing: > save /home/ply/file > the tab completion won't show 'overwrite' as an > option. I just noticed this and don't know how to > fix it right away. I suppose someone more educated > on the xorpsh would know though I will try to find > a solution. > > Also, for you convenience, there's the > http://skalman.juniks.net/~ply/xorp/both.patch > which includes both of the above and seems to > apply cleanly on the latest CVS. > > Regards, > Kristian > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian@juniks.net Sun Sep 4 21:15:30 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 4 Sep 2005 22:15:30 +0200 Subject: [Xorp-hackers] Counter and version In-Reply-To: <200509041814.j84IEtsD094352@possum.icir.org> References: <20050901152152.GA7097@juniks.net> <200509041814.j84IEtsD094352@possum.icir.org> Message-ID: <20050904201530.GC4502@juniks.net> On Sun, Sep 04, 2005 at 11:14:55AM -0700, Pavlin Radoslavov wrote: > > I would like to know if the version of > > XORP is defined anywhere in the source > > code? > > Yes. It is defined inside "config.h": > > /* Version number of package */ > #define VERSION "1.1" > > Also, file "VERSION" in the top-level XORP directory contains the > string with the version. > > > And is there some builtin clock in XORP? > > I would need a "cron" like function so that > > functions could be scheduled within the > > rtrmgr. > > Class EventLoop (libxorp/eventloop.hh) contains a number of methods > for creating one-time and periodic timers. In the callback for each > timer you can specify the function or method to be called. > > > BTW, I just saw a bug report regarding > > set/create/edit (#172) and would once again > > like bring up the discussion. Is it really > > necessary to have the create command? > > IMHO create just complicates things as it's > > functionality could as well be integrated > > into the 'set' command. > > Why not merge the two? > > The purpose of "create" is to create parts of the configuration that > don't exist (e.g., "create protocols bgp"), while the purpose of > "set" it to assign values to (leaf) nodes that are suppose to > contain values (e.g., "set protocols bgp local-as 1234"). yupp. > > Strictly speaking, it is possible to merge the functionality of > "create" into the "set" command, but by doing so we are going to > overload the "set" command itself. Then it could be argued that such > overload complicates things by merging two different functionalities > into a single command. Furthermore, for someone who is not familiar > with the exact internal structure of the configuration tree a > command like "set protocols bgp" could mean: > Set the value of node "protocols" to "bgp". The reason I'm asking for this functionality is that I don't want to bother whether a node is created or not. Perhaps this is because I've worked with Juniper before and they lack the create command, perhaps it is just pure laziness. I actually just read through the discussion last time we had it, and you (Pavlin) suggested that the create functionality could be incorporated into the set command but keep the create command as to avoid confusion. "On the other hand, if we keep "create" as is and we change the behavior of "set" so it also creates the intermediate nodes, is this an acceptable solution for you?" - Yes, indeed. > Opening the door for such (mis)interpretations could create more > confusions rather than simplifying things. Confusion is good. If everybody understood Cisco I wouldn't have a job ;) Seriously though, presumably most people using XORP are not "amatuers" but proffesionals who work with routing in their day-to-day job. Given the choice I beleive most would take the "shortcut" by using just the set command as this speeds up things and by keeping the create command as you suggested we keep it simple for our current userbase as well as users new to XORP. Regards, Kristian From kristian@juniks.net Sun Sep 4 21:32:58 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 4 Sep 2005 22:32:58 +0200 Subject: [Xorp-hackers] Counter and version In-Reply-To: <200509041814.j84IEtsD094352@possum.icir.org> References: <20050901152152.GA7097@juniks.net> <200509041814.j84IEtsD094352@possum.icir.org> Message-ID: <20050904203258.GD4502@juniks.net> On Sun, Sep 04, 2005 at 11:14:55AM -0700, Pavlin Radoslavov wrote: > > I would like to know if the version of > > XORP is defined anywhere in the source > > code? > > Yes. It is defined inside "config.h": > > /* Version number of package */ > #define VERSION "1.1" > > Also, file "VERSION" in the top-level XORP directory contains the > string with the version. > > > And is there some builtin clock in XORP? > > I would need a "cron" like function so that > > functions could be scheduled within the > > rtrmgr. > > Class EventLoop (libxorp/eventloop.hh) contains a number of methods > for creating one-time and periodic timers. In the callback for each > timer you can specify the function or method to be called. > > > BTW, I just saw a bug report regarding > > set/create/edit (#172) and would once again > > like bring up the discussion. Is it really > > necessary to have the create command? > > IMHO create just complicates things as it's > > functionality could as well be integrated > > into the 'set' command. > > Why not merge the two? > > The purpose of "create" is to create parts of the configuration that > don't exist (e.g., "create protocols bgp"), while the purpose of > "set" it to assign values to (leaf) nodes that are suppose to > contain values (e.g., "set protocols bgp local-as 1234"). > > Strictly speaking, it is possible to merge the functionality of > "create" into the "set" command, but by doing so we are going to > overload the "set" command itself. Then it could be argued that such > overload complicates things by merging two different functionalities > into a single command. Furthermore, for someone who is not familiar > with the exact internal structure of the configuration tree a > command like "set protocols bgp" could mean: > Set the value of node "protocols" to "bgp". and what would the command "create protocols bgp" mean to a person not familiar? create bgp-process or create bgp instance would be more obvious but the next thing would be a CLI parser which could take normal english; "create a bgp process with AS29345 and setup a peer to 194.36.235.1 and filter out everything but AS3" This is an extreme, my point being that we have to stop somewhere. You have to weigh efficiance against ease of use. We could create a point&click interface but not many routing technicians would like that, I wouldn't at least ;) Let's go with the idea Pavlin had, right? :) > Opening the door for such (mis)interpretations could create more > confusions rather than simplifying things. /Kristian From kristian@juniks.net Sun Sep 4 22:29:15 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 4 Sep 2005 23:29:15 +0200 Subject: [Xorp-hackers] Bugzilla #54 In-Reply-To: <200509042014.j84KEmRv095239@possum.icir.org> References: <20050904193954.GB4502@juniks.net> <200509042014.j84KEmRv095239@possum.icir.org> Message-ID: <20050904212915.GA8273@juniks.net> On Sun, Sep 04, 2005 at 01:14:48PM -0700, Pavlin Radoslavov wrote: > > On Sun, Sep 04, 2005 at 11:18:24AM -0700, Pavlin Radoslavov wrote: > > > > I've written a small patch to resolve #54. > > > > It acts as "normal" giving an error when trying to > > > > overwrite a file. However if you add 'overwrite' > > > > to the command, > > > > save /home/xorp-user/xorp-config overwrite > > > > it will overwrite the file. > > > > > > > > It's rather untested but on the other hand it's > > > > fairly simple so there's not much that can go > > > > wrong (right? :) ). > > > > The patch can be found at: > > > > http://skalman.juniks.net/~ply/xorp/overwrite.patch > > > > > > Please upload the patch to the above bugzilla entry. > > > > > > > I kinda messed up the subjects of my two mails so > > it got a bit confusing. > > > OK, in any case please upload each patch to the particular bugzilla > entry, because bugzilla entries are much easier to track and/or > correct compared to email exchanges. You could upload the > "both.patch" as well (to both entries). Done! *not used to Bugzilla*. > > Thanks, > Pavlin > > > This patch: > > http://skalman.juniks.net/~ply/xorp/config_header.patch > > is for Bugzilla #53. > > > > This patch: > > http://skalman.juniks.net/~ply/xorp/overwrite.patch > > is for Bugzilla #54. It fixes so no files are > > overwritten unless you specify so. There is still > > one 'bug'. When typing: > > save /home/ply/file > > the tab completion won't show 'overwrite' as an > > option. I just noticed this and don't know how to > > fix it right away. I suppose someone more educated > > on the xorpsh would know though I will try to find > > a solution. > > > > Also, for you convenience, there's the > > http://skalman.juniks.net/~ply/xorp/both.patch > > which includes both of the above and seems to > > apply cleanly on the latest CVS. > > > > Regards, > > Kristian > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From kristian@juniks.net Sun Sep 4 22:37:41 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 4 Sep 2005 23:37:41 +0200 Subject: [Xorp-hackers] Bugzilla #54 In-Reply-To: <200509041821.j84ILODH094483@possum.icir.org> References: <20050904180952.GA4502@juniks.net> <200509041821.j84ILODH094483@possum.icir.org> Message-ID: <20050904213741.GA8359@juniks.net> On Sun, Sep 04, 2005 at 11:21:24AM -0700, Pavlin Radoslavov wrote: > > I've written a small patch to generate a nicer > > configuration file header. > > > > /* XORP configuration file > > * > > * XORP version: 1.1 > > * XORP file format: 0.1 > > * date: 2005-09-34 11:34:22 > > * user: xorp-user > > * host: xorp-lab1 > > */ > > > > I've setup a new variable in configure.in called > > XORP_CONFIG_FILE_FORMAT_VERSION.. unfortunately it > > seems I am not able to properly bootstrap on my > > system so I cannot verify that this variable is > > set properly. > > In my tests I've just #defined it at the top of > > master_conf_tree.cc > > I'm not sure at all whether such a variable would > > be the best way to mark file format version but > > it's there for now. > > > > The patch is at: > > http://skalman.juniks.net/~ply/xorp/config_header.patch > > at some positions it includes changes that were > > made in my patch for #53... > > Yes, in the past we have been thinking about adding more info to the > header of the XORP config files, but so far we didn't get the time > to do it ourselves. > > Again, please upload the above patch to bugzilla entry #53. done! > > Thanks, > Pavlin > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Tue Sep 6 15:21:28 2005 From: deathdealer@gmx.net (=?ISO-8859-1?Q?=22Patrick_Preu=DF=22?=) Date: Tue, 6 Sep 2005 16:21:28 +0200 (MEST) Subject: [Xorp-hackers] Bugzilla #161 Message-ID: <29386.1126016488@www6.gmx.net> This is a MIME encapsulated multipart message - please use a MIME-compliant e-mail program to open it. Dies ist eine mehrteilige Nachricht im MIME-Format - bitte verwenden Sie zum Lesen ein MIME-konformes Mailprogramm. --========GMXBoundary293861126016488 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello List, my second try to Post and to help, i have written a small patch for some problems described in bug 161 http://www.xorp.org/bugzilla/show_bug.cgi?id=161 also have made changes to cli/cli_command.cc - fixed in cli_command.cc the line problem after pressing the ? if the comand is executeable needed one more newline. - don't find the point for the tabs Xorp> show route table ipv4 unicast final `final' is ambiguous. Possible completions: <[Enter]> Execute this command brief Show IPv4 winning routes | Pipe through a command Xorp> show route table ipv4 unicast final ? Possible completions: <[Enter]> Execute this command brief Show IPv4 winning routes | Pipe through a command rib/tools/show_routes.cc - build a simple brief for showing the routes (-b) -- best regards Patrick Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl --========GMXBoundary293861126016488 Content-Type: text/x-patch; name="xorp.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xorp.patch" ZGlmZiAtdSAtciB4b3JwLWN2cy1vcmlnL2NsaS9jbGlfY29tbWFuZC5jYyB4b3JwLWN2cy1maXhl ZC9jbGkvY2xpX2NvbW1hbmQuY2MKLS0tIHhvcnAtY3ZzLW9yaWcvY2xpL2NsaV9jb21tYW5kLmNj CTIwMDUtMDktMDYgMTU6MTU6MDEuMDAwMDAwMDAwICswMjAwCisrKyB4b3JwLWN2cy1maXhlZC9j bGkvY2xpX2NvbW1hbmQuY2MJMjAwNS0wOS0wNiAxNjoyMDo0MC4wMDAwMDAwMDAgKzAyMDAKQEAg LTcxOCw3ICs3MTgsNyBAQAogICAgIGlmICgodG9rZW4ubGVuZ3RoKCkgPT0gMCkgJiYgY2FuX2Nv bXBsZXRlKCkpIHsKIAkvLyBUaGUgbGFzdCB0b2tlbiwgYW5kIHRoZXJlIGlzIHNwYWNlIGF0IHRo ZSBlbmQsCiAJLy8gc28gcHJpbnQgdGhlICJkZWZhdWx0IiBoZWxwLgotCXJldF9zdHJpbmcgKz0g Y19mb3JtYXQoIiAgJS0xNXMgJXNcclxuIiwKKwlyZXRfc3RyaW5nICs9IGNfZm9ybWF0KCIgICUt MTVzICVzXHJcblxuIiwKIAkJCSAgICAgICAiPFtFbnRlcl0+IiwgIkV4ZWN1dGUgdGhpcyBjb21t YW5kIik7CiAJcmV0X3ZhbHVlID0gdHJ1ZTsKICAgICB9CmRpZmYgLXUgLXIgeG9ycC1jdnMtb3Jp Zy9ldGMvdGVtcGxhdGVzL3JpYi5jbWRzIHhvcnAtY3ZzLWZpeGVkL2V0Yy90ZW1wbGF0ZXMvcmli LmNtZHMKLS0tIHhvcnAtY3ZzLW9yaWcvZXRjL3RlbXBsYXRlcy9yaWIuY21kcwkyMDA1LTA5LTA2 IDE1OjE1OjAyLjAwMDAwMDAwMCArMDIwMAorKysgeG9ycC1jdnMtZml4ZWQvZXRjL3RlbXBsYXRl cy9yaWIuY21kcwkyMDA1LTA5LTA2IDE2OjIwOjQwLjAwMDAwMDAwMCArMDIwMApAQCAtMTQsNyAr MTQsNDIgQEAKICAgICAgJXRhZzogSEVMUCAiU2hvdyByb3V0ZSB0YWJsZSI7CiB9CiAKK3Nob3cg cm91dGUgdGFibGUgaXB2NCB7CisgICAgICVjb21tYW5kOiAiIiAlaGVscDogSEVMUDsKKyAgICAg JW1vZHVsZTogcmliOworICAgICAldGFnOiBIRUxQICJTaG93IElQdjQgcm91dGVzIjsKK30KKwor c2hvdyByb3V0ZSB0YWJsZSBpcHY0IHVuaWNhc3QgeworICAgICAlY29tbWFuZDogIiIgJWhlbHA6 IEhFTFA7CisgICAgICVtb2R1bGU6IHJpYjsKKyAgICAgJXRhZzogSEVMUCAiU2hvdyBJUHY0IHVu aWNhc3Qgcm91dGVzIjsKK30KKworc2hvdyByb3V0ZSB0YWJsZSBpcHY0IG11bHRpY2FzdCB7Cisg ICAgICVjb21tYW5kOiAiIiAlaGVscDogSEVMUDsKKyAgICAgJW1vZHVsZTogcmliOworICAgICAl dGFnOiBIRUxQICJTaG93IElQdjQgbXVsdGljYXN0IHJvdXRlcyI7Cit9CisKKworc2hvdyByb3V0 ZSB0YWJsZSBpcHY2IHsKKyAgICAgJWNvbW1hbmQ6ICIiICVoZWxwOiBIRUxQOworICAgICAlbW9k dWxlOiByaWI7CisgICAgICV0YWc6IEhFTFAgIlNob3cgSVB2NiByb3V0ZXMiOworfQorCitzaG93 IHJvdXRlIHRhYmxlIGlwdjYgdW5pY2FzdCB7CisgICAgICVjb21tYW5kOiAiIiAlaGVscDogSEVM UDsKKyAgICAgJW1vZHVsZTogcmliOworICAgICAldGFnOiBIRUxQICJTaG93IElQdjYgdW5pY2Fz dCByb3V0ZXMiOworfQogCitzaG93IHJvdXRlIHRhYmxlIGlwdjYgbXVsdGljYXN0IHsKKyAgICAg JWNvbW1hbmQ6ICIiICVoZWxwOiBIRUxQOworICAgICAlbW9kdWxlOiByaWI7CisgICAgICV0YWc6 IEhFTFAgIlNob3cgSVB2NiBtdWx0aWNhc3Qgcm91dGVzIjsKK30KIAogLyoKICAqIENvbm5lY3Rl ZCBzaG93IHJvdXRlIHRhYmxlIGNvbW1hbmRzCkBAIC0xNzUsNiArMjEwLDEzIEBACiAgICAgICV0 YWc6IEhFTFAgIlNob3cgSVB2NCB3aW5uaW5nIHJvdXRlcyI7CiB9CiAKK3Nob3cgcm91dGUgdGFi bGUgaXB2NCB1bmljYXN0IGZpbmFsIGJyaWVmIHsKKyAgICAgJWNvbW1hbmQ6ICJyaWIvdG9vbHMv c2hvd19yb3V0ZXMgLWIgcmlib3V0ICQ0ICQ1IGFsbCIgJWhlbHA6IEhFTFA7CisgICAgICVtb2R1 bGU6IHJpYjsKKyAgICAgJXRhZzogSEVMUCAiU2hvdyBJUHY0IHdpbm5pbmcgcm91dGVzIjsKKwor fQorCiBzaG93IHJvdXRlIHRhYmxlIGlwdjYgdW5pY2FzdCBmaW5hbCB7CiAgICAgICVjb21tYW5k OiAicmliL3Rvb2xzL3Nob3dfcm91dGVzIHJpYmluICQ0ICQ1IGFsbCIgJWhlbHA6IEhFTFA7CiAg ICAgICVtb2R1bGU6IHJpYjsKQEAgLTE4Nyw2ICsyMjksMTIgQEAKICAgICAgJXRhZzogSEVMUCAi U2hvdyBJUHY0IE1SSUIgd2lubmluZyByb3V0ZXMiOwogfQogCitzaG93IHJvdXRlIHRhYmxlIGlw djQgbXVsdGljYXN0IGZpbmFsIGJyaWVmIHsKKyAgICAgJWNvbW1hbmQ6ICJyaWIvdG9vbHMvc2hv d19yb3V0ZXMgLWIgcmliaW4gJDQgJDUgYWxsIiAlaGVscDogSEVMUDsKKyAgICAgJW1vZHVsZTog cmliOworICAgICAldGFnOiBIRUxQICJTaG93IElQdjQgTVJJQiB3aW5uaW5nIHJvdXRlcyI7Cit9 CisKIHNob3cgcm91dGUgdGFibGUgaXB2NiBtdWx0aWNhc3QgZmluYWwgewogICAgICAlY29tbWFu ZDogInJpYi90b29scy9zaG93X3JvdXRlcyByaWJpbiAkNCAkNSBhbGwiICVoZWxwOiBIRUxQOwog ICAgICAlbW9kdWxlOiByaWI7CmRpZmYgLXUgLXIgeG9ycC1jdnMtb3JpZy9yaWIvdG9vbHMvc2hv d19yb3V0ZXMuY2MgeG9ycC1jdnMtZml4ZWQvcmliL3Rvb2xzL3Nob3dfcm91dGVzLmNjCi0tLSB4 b3JwLWN2cy1vcmlnL3JpYi90b29scy9zaG93X3JvdXRlcy5jYwkyMDA1LTA5LTA2IDE1OjE1OjAy LjAwMDAwMDAwMCArMDIwMAorKysgeG9ycC1jdnMtZml4ZWQvcmliL3Rvb2xzL3Nob3dfcm91dGVz LmNjCTIwMDUtMDktMDYgMTY6MjA6NDAuMDAwMDAwMDAwICswMjAwCkBAIC00MCw2ICs0MCw3IEBA CiAvLyBTdHJ1Y3R1cmUgZm9yIGhvbGRpbmcgY29tbWFuZCBsaW5lIG9wdGlvbnMKIAogc3RydWN0 IFNob3dSb3V0ZXNPcHRpb25zIHsKKyAgICBib29sIGJyaWVmOyAgICAgICAgICAgICAgICAgLy8g LWIgKHRydWUpLCAoZmFsc2UpCiAgICAgYm9vbCByaWJpbjsJCQkvLyByaWJpbiAodHJ1ZSksIHJp Ym91dCAoZmFsc2UpCiAgICAgYm9vbCBpcHY0OwkJCS8vIElQdjQgKHRydWUpLCBJUHY2KGZhbHNl KQogICAgIGJvb2wgdW5pY2FzdDsJCS8vIHVuaWNhc3QgKHRydWUpLCBtdWx0aWNhc3QgKGZhbHNl KQpAQCAtNDksNyArNTAsNyBAQAogICAgIHVpbnQxNl90CWZpbmRlcl9wb3J0OwogCiAgICAgaW5s aW5lIFNob3dSb3V0ZXNPcHRpb25zKCkKLQk6IHJpYmluKGZhbHNlKSwgaXB2NCh0cnVlKSwgdW5p Y2FzdCh0cnVlKSwgcHJvdG9jb2woImFsbCIpCisJOiBicmllZihmYWxzZSksIHJpYmluKGZhbHNl KSwgaXB2NCh0cnVlKSwgdW5pY2FzdCh0cnVlKSwgcHJvdG9jb2woImFsbCIpCiAgICAge30KIH07 CiAKQEAgLTEyMCw2ICsxMjEsNDAgQEAKICAgICBjb3V0IDw8IGVuZGw7CiB9CiAKK3RlbXBsYXRl IDx0eXBlbmFtZSBBPgorc3RhdGljIHZvaWQKK2Rpc3BsYXlfcm91dGVfYnJpZWYoY29uc3QgSVBO ZXQ8QT4mIAluZXQsCisJICAgICAgY29uc3QgQSYgCQluZXh0aG9wLAorCSAgICAgIGNvbnN0IHN0 cmluZyYgCWlmbmFtZSwKKwkgICAgICBjb25zdCBzdHJpbmcmIAl2aWZuYW1lLAorCSAgICAgIGNv bnN0IHVpbnQzMl90IAltZXRyaWMsCisJICAgICAgY29uc3QgdWludDMyX3QJYWRtaW5fZGlzdGFu Y2UpCit7CisgICAgY291dCA8PCAiIiA8PCBuZXQuc3RyKCkgPDwgIlx0IjsKKyAgICBjb3V0IDw8 ICJbIiA7CisgICAgY29uc3QgY2hhciogcHJvdG9jb2wgPSBhZDJwcm90b2NvbChhZG1pbl9kaXN0 YW5jZSk7CisgICAgaWYgKHByb3RvY29sID09IDApIHsKKyAgICAgICAgY291dCA8PCBhZG1pbl9k aXN0YW5jZTsKKyAgICB9IGVsc2UgeworICAgICAgICBjb3V0IDw8IHByb3RvY29sIDw8ICIoIiA8 PCBhZG1pbl9kaXN0YW5jZSA8PCAiKSI7CisgICAgfQorICAgIGNvdXQgPDwgIi8iIDw8IG1ldHJp YyA8PCAiXSIgPDwgIiB4eDp4eDp4eCIgPDwgZW5kbCA7CisKKyAgICBjb3V0IDw8ICJcdFx0PiAi IDsKKyAgICBpZiAoYWRtaW5fZGlzdGFuY2UgIT0gMCkKKyAgICAgICAgY291dCA8PCAidG8gIiA8 PCBuZXh0aG9wLnN0cigpIDw8ICIgIjsKKworCisgICAgaWYgKGlmbmFtZS5lbXB0eSgpID09IGZh bHNlKQorICAgICAgICBjb3V0IDw8ICJ2aWEgIiA8PCBpZm5hbWUgOworCisgICAgaWYgKHZpZm5h bWUuZW1wdHkoKSA9PSBmYWxzZSkKKyAgICAgICAgY291dCA8PCAiLyIgPDwgdmlmbmFtZTsKKyAg ICBjb3V0IDw8IGVuZGw7CisKK30KKworCiAvLyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAvLyBDbGFz cyBmb3IgUXVlcnlpbmcgUklCIHJvdXRlcwogCkBAIC00OTgsNyArNTMzLDEyIEBACiAJcmV0dXJu IFhybENtZEVycm9yOjpPS0FZKCk7CiAgICAgfQogCi0gICAgZGlzcGxheV9yb3V0ZShkc3QsIG5l eHRob3AsIGlmbmFtZSwgdmlmbmFtZSwgbWV0cmljLCBhZG1pbl9kaXN0YW5jZSk7CisgICAgaWYg KHRoaXMtPl9vcHRzLmJyaWVmID09IGZhbHNlKSB7CisgICAgCWRpc3BsYXlfcm91dGUoZHN0LCBu ZXh0aG9wLCBpZm5hbWUsIHZpZm5hbWUsIG1ldHJpYywgYWRtaW5fZGlzdGFuY2UpOworICAgIAly ZXR1cm4gWHJsQ21kRXJyb3I6Ok9LQVkoKTsKKyAgICB9IAorCisgICAgZGlzcGxheV9yb3V0ZV9i cmllZihkc3QsIG5leHRob3AsIGlmbmFtZSwgdmlmbmFtZSwgbWV0cmljLCBhZG1pbl9kaXN0YW5j ZSk7CiAgICAgcmV0dXJuIFhybENtZEVycm9yOjpPS0FZKCk7CiB9CiAKQEAgLTY1MCw2ICs2OTAs NyBAQAogCSAgICBzd2l0Y2ggKGNoKSB7CiAJICAgIGNhc2UgJ2InOgogCQlicmllZiA9IHRydWU7 CisJCXNyX29wdHMuYnJpZWYgPSB0cnVlOwogCQlicmVhazsKIAkgICAgY2FzZSAnRic6CiAJCWRv X3J1biA9IHBhcnNlX2ZpbmRlcl9hcmdzKG9wdGFyZywK --========GMXBoundary293861126016488-- From pavlin@icir.org Tue Sep 6 16:30:35 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 06 Sep 2005 08:30:35 -0700 Subject: [Xorp-hackers] Bugzilla #161 In-Reply-To: Message from =?ISO-8859-1?Q?=22Patrick_Preu=DF=22?= of "Tue, 06 Sep 2005 16:21:28 +0200." <29386.1126016488@www6.gmx.net> Message-ID: <200509061530.j86FUZOm026279@possum.icir.org> > i have written a small patch for some problems described in bug 161 > http://www.xorp.org/bugzilla/show_bug.cgi?id=161 As a general advice for all Bugzilla entries related patches, please upload the patch as an attachment to the appropriate bugzilla entry, so it is easier to track it and apply it. Thanks, Pavlin P.S. With apology to everyone who has posted to the xorp-hackers in the last few days and is still waiting for an answer. All emails will be answered within few days or so after some urgent tasks are out of the way. From deathdealer@gmx.net Tue Sep 6 17:47:15 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Tue, 6 Sep 2005 18:47:15 +0200 Subject: WG: [Xorp-hackers] Bugzilla #161 Message-ID: <200509061647.j86GloPw006084@wyvern.icir.org> Hello Many thanks for you answer. I have a question about the time, route tags are they currenly known by the rib if seen nothing so far? Is equal cost and unequal cost load balancing supported or is it planed? Some questions is it possible to get informations from the modules like are they running, how many memory they use how and so one? So I will do some work in this direction, I think it is nessesay to get more information about the router from the cli. And at last I think it is not optimal to determine the protocol from witch a Route was learn by the admin distance, there should be a sepperate field, because in production environment sometimes you have the need to change the ad for a protocol when you transit from a protocol to another. And If xorp Should support more then one vrf, or mpls, more then one ospf daemon there Should be a way to decide from witch we have learned the route. Gruss    Patrick Marc Preuss Nordstrasse 28 41569 Rommerskirchen -----Ursprüngliche Nachricht----- Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im Auftrag von Pavlin Radoslavov Gesendet: Dienstag, 6. September 2005 17:31 An: "Patrick Preuß" Cc: xorp-hackers@icir.org; patrick.preuss@retail-sc.com Betreff: Re: [Xorp-hackers] Bugzilla #161 > i have written a small patch for some problems described in bug 161 > http://www.xorp.org/bugzilla/show_bug.cgi?id=161 As a general advice for all Bugzilla entries related patches, please upload the patch as an attachment to the appropriate bugzilla entry, so it is easier to track it and apply it. Thanks, Pavlin P.S. With apology to everyone who has posted to the xorp-hackers in the last few days and is still waiting for an answer. All emails will be answered within few days or so after some urgent tasks are out of the way. _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Tue Sep 6 18:13:20 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Tue, 6 Sep 2005 19:13:20 +0200 Subject: [Xorp-hackers] reliable static routing Message-ID: <200509061714.j86HEI3H006356@wyvern.icir.org> Hello Has someone thought of reliable static routing, witch means to track the destination next-hop of a route? Second I am not so deep in the code, wath is about static routes, policy s witch uses not the next-hop, They use a router one or more hops away? Gruss Patrick Marc Preuss Nordstrasse 28 41569 Rommerskirchen From kristian@juniks.net Tue Sep 6 21:57:24 2005 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 6 Sep 2005 22:57:24 +0200 Subject: [Xorp-hackers] get to know JUNOS Message-ID: <20050906205714.GA4675@juniks.net> Hi! I've setup a JUNOS box for anyone interested in getting the hang of its CLI. It's not a complete lab environment, just one single box so you're limited to configuring an interface and perhaps setting a few routes... Anyway, if anyone is interested please contact me offlist and I'll hook you up with an account. Regards, Kristian From kristian@juniks.net Wed Sep 7 08:47:53 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 7 Sep 2005 09:47:53 +0200 Subject: WG: [Xorp-hackers] Bugzilla #161 In-Reply-To: <200509061647.j86GloPw006084@wyvern.icir.org> References: <200509061647.j86GloPw006084@wyvern.icir.org> Message-ID: <20050907074752.GA6446@juniks.net> On Tue, Sep 06, 2005 at 06:47:15PM +0200, Patrick Preuss wrote: > Hello > > Many thanks for you answer. > > I have a question about the time, route tags are they currenly known by the > rib if seen nothing so far? > > Is equal cost and unequal cost load balancing supported or is it planed? First of all, the underlaying OS is doing the actual forwarding of packets and it is up to the OS to support several routes to one destination. Most unix based os:s do that today but afaik xorp does not yet support it. Trying to add two routes: create protocols static route4 10.0.0.0/24 next-hop 192.168.77.1 create protocols static route4 10.0.0.0/24 next-hop 192.168.77.2 it will only use the latter. Though this should not be too hard to change. > Some questions is it possible to get informations from the modules like are > they running, how many memory they use how and so one? So I will do some > work in this direction, I think it is nessesay to get more information about > the router from the cli. I don't think it's possible to get this kind of information right now. It'd be great if you could do some work on it! :) > And at last I think it is not optimal to determine the protocol from witch a > Route was learn by the admin distance, there should be a sepperate field, > because in production environment sometimes you have the need to change the > ad for a protocol when you transit from a protocol to another. And If xorp > Should support more then one vrf, or mpls, more then one ospf daemon there > Should be a way to decide from witch we have learned the route. I agree that there should be information from which protocol a route originates from, but isn't there information about this in the current build? Just as you say it's crucial for vrfs since you may want to run more than one process of [insert your favorite routing protocol]. > > Gruss >    Patrick Marc Preuss > Nordstrasse 28 > 41569 Rommerskirchen > > > > -----Ursprüngliche Nachricht----- > Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im > Auftrag von Pavlin Radoslavov > Gesendet: Dienstag, 6. September 2005 17:31 > An: "Patrick Preuß" > Cc: xorp-hackers@icir.org; patrick.preuss@retail-sc.com > Betreff: Re: [Xorp-hackers] Bugzilla #161 > > > i have written a small patch for some problems described in bug 161 > > http://www.xorp.org/bugzilla/show_bug.cgi?id=161 > > As a general advice for all Bugzilla entries related patches, > please upload the patch as an attachment to the appropriate bugzilla > entry, so it is easier to track it and apply it. > > Thanks, > Pavlin > > P.S. With apology to everyone who has posted to the xorp-hackers in > the last few days and is still waiting for an answer. All emails > will be answered within few days or so after some urgent tasks are > out of the way. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian@juniks.net Wed Sep 7 08:56:24 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 7 Sep 2005 09:56:24 +0200 Subject: WG: [Xorp-hackers] Bugzilla #161 In-Reply-To: <200509061647.j86GloPw006084@wyvern.icir.org> References: <200509061647.j86GloPw006084@wyvern.icir.org> Message-ID: <20050907075624.GB6446@juniks.net> On Tue, Sep 06, 2005 at 06:47:15PM +0200, Patrick Preuss wrote: > > > Hello > > Many thanks for you answer. > > I have a question about the time, route tags are they currenly known by the > rib if seen nothing so far? > > Is equal cost and unequal cost load balancing supported or is it planed? > > Some questions is it possible to get informations from the modules like are > they running, how many memory they use how and so one? So I will do some > work in this direction, I think it is nessesay to get more information about > the router from the cli. > > And at last I think it is not optimal to determine the protocol from witch a > > Route was learn by the admin distance, there should be a sepperate field, > because in production environment sometimes you have the need to change the > ad for a protocol when you transit from a protocol to another. And If xorp > Should support more then one vrf, or mpls, more then one ospf daemon there > Should be a way to decide from witch we have learned the route. Sorry for dual posts here but I couldn't confirm this before as I did not have access to a xorp box When doing show route table ipv4 unicast final I see: Xorp> show route table ipv4 unicast final Network 10.0.0.0/24 Nexthop := 192.168.77.1 Metric := 0 Protocol := static Interface := eth0 Vif := eth0 Network 192.168.77.0/24 Nexthop := 192.168.77.90 Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 Isn't that information enough? Regards, Kristian > > Gruss >    Patrick Marc Preuss > Nordstrasse 28 > 41569 Rommerskirchen > > > > -----Ursprüngliche Nachricht----- > Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im > Auftrag von Pavlin Radoslavov > Gesendet: Dienstag, 6. September 2005 17:31 > An: "Patrick Preuß" > Cc: xorp-hackers@icir.org; patrick.preuss@retail-sc.com > Betreff: Re: [Xorp-hackers] Bugzilla #161 > > > i have written a small patch for some problems described in bug 161 > > http://www.xorp.org/bugzilla/show_bug.cgi?id=161 > > As a general advice for all Bugzilla entries related patches, > please upload the patch as an attachment to the appropriate bugzilla > entry, so it is easier to track it and apply it. > > Thanks, > Pavlin > > P.S. With apology to everyone who has posted to the xorp-hackers in > the last few days and is still waiting for an answer. All emails > will be answered within few days or so after some urgent tasks are > out of the way. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Wed Sep 7 11:05:35 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Wed, 7 Sep 2005 12:05:35 +0200 Subject: AW: WG: [Xorp-hackers] Bugzilla #161 In-Reply-To: <20050907075624.GB6446@juniks.net> Message-ID: <200509071005.j87A5mde016670@wyvern.icir.org> Hello Kristian, > Sorry for dual posts here but I couldn't confirm > this before as I did not have access to a xorp box > When doing show route table ipv4 unicast final I > see: > Xorp> show route table ipv4 unicast final > Network 10.0.0.0/24 > Nexthop := 192.168.77.1 > Metric := 0 Protocol := static Interface := eth0 Vif := eth0 > Network 192.168.77.0/24 > Nexthop := 192.168.77.90 > Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 > > Isn't that information enough? Have used or for completing the line, I know there is a problem with both in the current cvs, I've found the point for completion so far It is in the cli_command.cc there are two entrys with for the I have found the formatting line, for the not jet. Regards Patrick Marc From kristian@juniks.net Wed Sep 7 12:36:31 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Wed, 7 Sep 2005 13:36:31 +0200 Subject: WG: [Xorp-hackers] Bugzilla #161 In-Reply-To: <20050907100257.EB66973494@mail.juniks.net> References: <20050907075624.GB6446@juniks.net> <20050907100257.EB66973494@mail.juniks.net> Message-ID: <20050907113631.GA15546@juniks.net> On Wed, Sep 07, 2005 at 12:05:35PM +0200, Patrick Preuss wrote: > Hello Kristian, > > > Sorry for dual posts here but I couldn't confirm > > this before as I did not have access to a xorp box > > When doing show route table ipv4 unicast final I > > see: > > Xorp> show route table ipv4 unicast final > > Network 10.0.0.0/24 > > Nexthop := 192.168.77.1 > > Metric := 0 Protocol := static Interface := eth0 Vif := eth0 > > Network 192.168.77.0/24 > > Nexthop := 192.168.77.90 > > Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 > > > > Isn't that information enough? > > Have used or for completing the line, I know there is a problem > with both in the current cvs, I've found the point for completion so far > It is in the cli_command.cc there are two entrys with for the I > have found the formatting line, for the not jet. gives me an extra blank line Xorp> show route table ipv4 unicast final ? Possible completions: <[Enter]> Execute this command brief Show IPv4 winning routes | Pipe through a command while is missing one : Xorp> show route table ipv4 unicast final `final' is ambiguous. Possible completions: <[Enter]> Execute this command brief Show IPv4 winning routes | Pipe through a command It seems that the missing blank line exist on every node that are both executable and have sub-nodes. Patrick, I checked the code regarding administrative distance and protocol. I now see what you mean and I agree that it's not a pretty solution. There should be something like origin: ospf.0 where ospf.0 would be your first ospf process. Later when we (cause we will :) ) support several routing processes it would just use a different number. Just my $0.02 Regards, Kristian From kristian@juniks.net Wed Sep 7 12:53:00 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 7 Sep 2005 13:53:00 +0200 Subject: [Xorp-hackers] reliable static routing In-Reply-To: <200509061714.j86HEI3H006356@wyvern.icir.org> References: <200509061714.j86HEI3H006356@wyvern.icir.org> Message-ID: <20050907115300.GB15546@juniks.net> On Tue, Sep 06, 2005 at 07:13:20PM +0200, Patrick Preuss wrote: > Hello > > Has someone thought of reliable static routing, witch means to track the > destination next-hop of a route? Someone has probably thought of it but afaik no one has expressed any thoughts of it. I think that there are other priorities right now but as for anything else you could always do implement it yourself ;) I find it quite useful on smaller setups so it'd be real nice to have it in XORP. > Second I am not so deep in the code, wath is about static routes, policy s > witch uses not the next-hop, > They use a router one or more hops away? I'm not sure what you mean...? Regards, Kristian From christophe.devriese@gmail.com Wed Sep 7 19:04:25 2005 From: christophe.devriese@gmail.com (Christophe Devriese) Date: Wed, 7 Sep 2005 20:04:25 +0200 Subject: [Xorp-hackers] get to know JUNOS In-Reply-To: <20050906205714.GA4675@juniks.net> References: <20050906205714.GA4675@juniks.net> Message-ID: <67ec790f05090711041408c14a@mail.gmail.com> ------=_Part_19436_11098867.1126116265085 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'd love one if you can provide it. Thx On 9/6/05, Kristian Larsson wrote: >=20 > Hi! >=20 > I've setup a JUNOS box for anyone interested in > getting the hang of its CLI. > It's not a complete lab environment, just one > single box so you're limited to configuring an > interface and perhaps setting a few routes... > Anyway, if anyone is interested please contact me > offlist and I'll hook you up with an account. >=20 > Regards, > Kristian >=20 >=20 > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > ------=_Part_19436_11098867.1126116265085 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'd love one if you can provide it. Thx

On 9/6/05, Kristian Larsson <kristian@juniks.net> wrote:
Hi!

I've setup a JUNOS box for anyone interested in
getting the h= ang of its CLI.
It's not a complete lab environment, just one
single = box so you're limited to configuring an
interface and perhaps setting a = few routes...
Anyway, if anyone is interested please contact me
offlist and I'll h= ook you up with an account.

Regards,
Kristian


________= _______________________________________
Xorp-hackers mailing list
Xorp-hackers@icir.org
http:= //mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

------=_Part_19436_11098867.1126116265085-- From deathdealer@gmx.net Thu Sep 8 12:30:11 2005 From: deathdealer@gmx.net (=?ISO-8859-1?Q?=22Patrick_Preu=DF=22?=) Date: Thu, 8 Sep 2005 13:30:11 +0200 (MEST) Subject: [Xorp-hackers] reliable static routing References: <20050907115300.GB15546@juniks.net> Message-ID: <9099.1126179011@www83.gmx.net> > > Second I am not so deep in the code, wath is about static routes, policy > s > > witch uses not the next-hop, > > They use a router one or more hops away? > I'm not sure what you mean...? afak the cisco's call it recursive route lookup, so you define a route via a next hop not directly connected. -- best regards Patrick Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner From deathdealer@gmx.net Thu Sep 8 12:41:01 2005 From: deathdealer@gmx.net (=?ISO-8859-1?Q?=22Patrick_Preu=DF=22?=) Date: Thu, 8 Sep 2005 13:41:01 +0200 (MEST) Subject: WG: [Xorp-hackers] Bugzilla #161 Message-ID: <18653.1126179661@www83.gmx.net> This is a MIME encapsulated multipart message - please use a MIME-compliant e-mail program to open it. Dies ist eine mehrteilige Nachricht im MIME-Format - bitte verwenden Sie zum Lesen ein MIME-konformes Mailprogramm. --========GMXBoundary186531126179661 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > --- Ursprüngliche Nachricht --- > Von: 'Kristian Larsson' > An: Patrick Preuss > Kopie: xorp-hackers@xorp.org > Betreff: Re: WG: [Xorp-hackers] Bugzilla #161 > Datum: Wed, 7 Sep 2005 13:36:31 +0200 > > On Wed, Sep 07, 2005 at 12:05:35PM +0200, Patrick Preuss wrote: > > Hello Kristian, > > > > > Sorry for dual posts here but I couldn't confirm > > > this before as I did not have access to a xorp box > > > When doing show route table ipv4 unicast final I > > > see: > > > Xorp> show route table ipv4 unicast final > > > Network 10.0.0.0/24 > > > Nexthop := 192.168.77.1 > > > Metric := 0 Protocol := static Interface := eth0 Vif := eth0 > > > Network 192.168.77.0/24 > > > Nexthop := 192.168.77.90 > > > Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 > > > > > > Isn't that information enough? > > > > Have used or for completing the line, I know there is a > problem > > with both in the current cvs, I've found the point for completion so > far > > It is in the cli_command.cc there are two entrys with for the > I > > have found the formatting line, for the not jet. > > gives me an extra blank line > Xorp> show route table ipv4 unicast final ? > Possible completions: > <[Enter]> Execute this command > > brief Show IPv4 winning routes > | Pipe through a command > > while is missing one : > Xorp> show route table ipv4 unicast final > `final' is ambiguous. > Possible completions: > <[Enter]> Execute this command brief Show IPv4 winning routes > | Pipe through a command > > It seems that the missing blank line exist > on every node that are both executable and > have sub-nodes. > > Patrick, I checked the code regarding administrative > distance and protocol. I now see what you mean and I > agree that it's not a pretty solution. There should be > something like origin: ospf.0 > where ospf.0 would be your first ospf process. Later > when we (cause we will :) ) support several routing > processes it would just use a different number. > Just my $0.02 > > Regards, > Kristian > Hello Kristian, can you try the attactched cli_command.cc should go the dir cli. i think no it should work fine. Regards, Patrick -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl --========GMXBoundary186531126179661 Content-Type: application/octet-stream; name="cli_command.cc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cli_command.cc" Ly8gLSotIGMtYmFzaWMtb2Zmc2V0OiA0OyB0YWItd2lkdGg6IDg7IGluZGVudC10YWJzLW1vZGU6 IHQgLSotCgovLyBDb3B5cmlnaHQgKGMpIDIwMDEtMjAwNSBJbnRlcm5hdGlvbmFsIENvbXB1dGVy IFNjaWVuY2UgSW5zdGl0dXRlCi8vCi8vIFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZy ZWUgb2YgY2hhcmdlLCB0byBhbnkgcGVyc29uIG9idGFpbmluZyBhCi8vIGNvcHkgb2YgdGhpcyBz b2Z0d2FyZSBhbmQgYXNzb2NpYXRlZCBkb2N1bWVudGF0aW9uIGZpbGVzICh0aGUgIlNvZnR3YXJl IikKLy8gdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dCByZXN0cmljdGlvbiwgc3ViamVj dCB0byB0aGUgY29uZGl0aW9ucwovLyBsaXN0ZWQgaW4gdGhlIFhPUlAgTElDRU5TRSBmaWxlLiBU aGVzZSBjb25kaXRpb25zIGluY2x1ZGU6IHlvdSBtdXN0Ci8vIHByZXNlcnZlIHRoaXMgY29weXJp Z2h0IG5vdGljZSwgYW5kIHlvdSBjYW5ub3QgbWVudGlvbiB0aGUgY29weXJpZ2h0Ci8vIGhvbGRl cnMgaW4gYWR2ZXJ0aXNpbmcgcmVsYXRlZCB0byB0aGUgU29mdHdhcmUgd2l0aG91dCB0aGVpciBw ZXJtaXNzaW9uLgovLyBUaGUgU29mdHdhcmUgaXMgcHJvdmlkZWQgV0lUSE9VVCBBTlkgV0FSUkFO VFksIEVYUFJFU1MgT1IgSU1QTElFRC4gVGhpcwovLyBub3RpY2UgaXMgYSBzdW1tYXJ5IG9mIHRo ZSBYT1JQIExJQ0VOU0UgZmlsZTsgdGhlIGxpY2Vuc2UgaW4gdGhhdCBmaWxlIGlzCi8vIGxlZ2Fs bHkgYmluZGluZy4KCiNpZGVudCAiJFhPUlA6IHhvcnAvY2xpL2NsaV9jb21tYW5kLmNjLHYgMS4x OSAyMDA1LzA4LzIzIDAxOjE4OjU5IHBhdmxpbiBFeHAgJCIKCgovLwovLyBDTEkgKENvbW1hbmQt TGluZSBJbnRlcmZhY2UpIGNvbW1hbmRzIHN0cnVjdHVyaW5nIGltcGxlbWVudGF0aW9uCi8vCgoK I2luY2x1ZGUgImNsaV9tb2R1bGUuaCIKI2luY2x1ZGUgImxpYnhvcnAveG9ycC5oIgojaW5jbHVk ZSAibGlieG9ycC94bG9nLmgiCiNpbmNsdWRlICJsaWJ4b3JwL2RlYnVnLmgiCiNpbmNsdWRlICJs aWJ4b3JwL2lwdnguaGgiCiNpbmNsdWRlICJsaWJ4b3JwL3Rva2VuLmhoIgojaW5jbHVkZSAibGli eG9ycC91dGlscy5oaCIKCiNpbmNsdWRlICJjbGlfY29tbWFuZF9waXBlLmhoIgoKCi8vCi8vIEV4 cG9ydGVkIHZhcmlhYmxlcwovLwoKLy8KLy8gTG9jYWwgY29uc3RhbnRzIGRlZmluaXRpb25zCi8v CgovLwovLyBMb2NhbCBzdHJ1Y3R1cmVzL2NsYXNzZXMsIHR5cGVkZWZzIGFuZCBtYWNyb3MKLy8K CgovLwovLyBMb2NhbCB2YXJpYWJsZXMKLy8KCi8vCi8vIExvY2FsIGZ1bmN0aW9ucyBwcm90b3R5 cGVzCi8vCgoKQ2xpQ29tbWFuZDo6Q2xpQ29tbWFuZChDbGlDb21tYW5kICppbml0X3BhcmVudF9j b21tYW5kLAoJCSAgICAgICBjb25zdCBzdHJpbmcmIGluaXRfY29tbWFuZF9uYW1lLAoJCSAgICAg ICBjb25zdCBzdHJpbmcmIGluaXRfY29tbWFuZF9oZWxwKQogICAgOiBfcGFyZW50X2NvbW1hbmQo aW5pdF9wYXJlbnRfY29tbWFuZCksCiAgICAgIF9uYW1lKGluaXRfY29tbWFuZF9uYW1lKSwKICAg ICAgX2hlbHAoaW5pdF9jb21tYW5kX2hlbHApCnsKICAgIGlmIChfcGFyZW50X2NvbW1hbmQgIT0g TlVMTCkKCV9yb290X2NvbW1hbmQgPSBfcGFyZW50X2NvbW1hbmQtPnJvb3RfY29tbWFuZCgpOwog ICAgZWxzZQoJX3Jvb3RfY29tbWFuZCA9IHRoaXM7CiAgICAKICAgIHNldF9hbGxvd19jZChmYWxz ZSwgIiIpOwogICAgc2V0X2Nhbl9waXBlKGZhbHNlKTsJLy8gWFhYOiBkZWZhdWx0CiAgICBzZXRf Y2xpX2NvbW1hbmRfcGlwZShOVUxMKTsKICAgIAogICAgLy8gU2V0IHRoZSBjb21tYW5kLWNvbXBs ZXRpb24gaGVscCBzdHJpbmcKICAgIC8vIFRPRE86IHBhcmFtZXRlcml6ZSB0aGUgaGFyZC1jb2Rl ZCBudW1iZXIKICAgIF9oZWxwX2NvbXBsZXRpb24gPSBjX2Zvcm1hdCgiICUqcyVzXHJcbiIsIChp bnQpKDE1IC0gX25hbWUuc2l6ZSgpKSwgIiAiLAoJCQkJX2hlbHAuY19zdHIoKSk7CgogICAgLy8g WFhYOiBzZXQgdGhlIENMSSBjb21wbGV0aW9uIGZ1bmN0aW9uIHRvIGl0cyBkZWZhdWx0IHZhbHVl CiAgICBzZXRfY2xpX2NvbXBsZXRpb25fZnVuYyhjbGlfYXR0ZW1wdF9jb21tYW5kX2NvbXBsZXRp b25fYnluYW1lKTsKICAgIAogICAgX2hhc19keW5hbWljX2NoaWxkcmVuID0gZmFsc2U7Cn0KCkNs aUNvbW1hbmQ6On5DbGlDb21tYW5kKCkKewogICAgLy8gRGVsZXRlIHJlY3Vyc2l2ZWx5IGFsbCBj aGlsZCBjb21tYW5kcwogICAgZGVsZXRlX3BvaW50ZXJzX2xpc3QoX2NoaWxkX2NvbW1hbmRfbGlz dCk7Cn0KCi8vCi8vIEVuYWJsZS9kaXNhYmxlICJjZCIgdG8gdGhpcyBjb21tYW5kLCBhbmQgc2V0 IHRoZSAiY2QgcHJvbXB0IgovLwp2b2lkCkNsaUNvbW1hbmQ6OnNldF9hbGxvd19jZChib29sIHYs IGNvbnN0IHN0cmluZyYgaW5pdF9jZF9wcm9tcHQpCnsKICAgIF9hbGxvd19jZCA9IHY7CiAgICBp ZiAoaW5pdF9jZF9wcm9tcHQuc2l6ZSgpKQoJX2NkX3Byb21wdCA9IGluaXRfY2RfcHJvbXB0Owp9 CgovLwovLyBSZXR1cm4gJVhPUlBfT0ssIG9uIHN1Y2Nlc3MsIG90aGVyd2lzZSAlWE9SUF9FUlJP UgovLwppbnQKQ2xpQ29tbWFuZDo6YWRkX2NvbW1hbmQoQ2xpQ29tbWFuZCAqY2hpbGRfY29tbWFu ZCkKewogICAgbGlzdDxDbGlDb21tYW5kICo+OjppdGVyYXRvciBpdGVyLCBpbnNlcnRfcG9zOwog ICAgCiAgICBpbnNlcnRfcG9zID0gY2hpbGRfY29tbWFuZF9saXN0KCkuYmVnaW4oKTsKICAgIAog ICAgLy8gQ2hlY2sgaWYgY29tbWFuZCBhbHJlYWR5IGluc3RhbGxlZCwgYXMgd2VsbCBhcyBmaW5k IHRoZQogICAgLy8gcG9zaXRpb24gdG8gaW5zdGFsbCB0aGUgY29tbWFuZCAoYmFzZWQgb24gbGV4 aWNvZ3JhcGhpY2FsIG9yZGVyaW5nKS4KICAgIGZvciAoaXRlciA9IGNoaWxkX2NvbW1hbmRfbGlz dCgpLmJlZ2luKCk7CgkgaXRlciAhPSBjaGlsZF9jb21tYW5kX2xpc3QoKS5lbmQoKTsKCSArK2l0 ZXIpIHsKCUNsaUNvbW1hbmQgKmNsaV9jb21tYW5kID0gKml0ZXI7CglpZiAoY2xpX2NvbW1hbmQt PmlzX3NhbWVfY29tbWFuZChjaGlsZF9jb21tYW5kLT5uYW1lKCkpKSB7CgkgICAgLy8gQ29tbWFu ZCBhbHJlYWR5IGluc3RhbGxlZAoJICAgIFhMT0dfRVJST1IoIkNvbW1hbmQgYWxyZWFkeSBpbnN0 YWxsZWQiKTsKCSAgICByZXR1cm4gKFhPUlBfRVJST1IpOwoJfQoJaWYgKGNsaV9jb21tYW5kLT5u YW1lKCkgPCBjaGlsZF9jb21tYW5kLT5uYW1lKCkpIHsKCSAgICBpbnNlcnRfcG9zID0gaXRlcjsK CSAgICArK2luc2VydF9wb3M7Cgl9CiAgICB9CiAgICAKICAgIGlmIChpbnNlcnRfcG9zID09IGNo aWxkX2NvbW1hbmRfbGlzdCgpLmVuZCgpKQoJX2NoaWxkX2NvbW1hbmRfbGlzdC5wdXNoX2JhY2so Y2hpbGRfY29tbWFuZCk7CiAgICBlbHNlCglfY2hpbGRfY29tbWFuZF9saXN0Lmluc2VydChpbnNl cnRfcG9zLCBjaGlsZF9jb21tYW5kKTsKICAgIGNoaWxkX2NvbW1hbmQtPnNldF9yb290X2NvbW1h bmQodGhpcy0+cm9vdF9jb21tYW5kKCkpOwogICAgCiAgICByZXR1cm4oWE9SUF9PSyk7Cn0KCi8v Ci8vIENyZWF0ZSBhIG5ldyBjb21tYW5kLgovLyBSZXR1cm4gdGhlIG5ldyBjaGlsZCBjb21tYW5k IG9uIHN1Y2Nlc3MsIG90aGVyd2lzZSBOVUxMLgovLyBYWFg6IEJ5IGRlZmF1bHQsIHdlIENBTk5P VCAiY2QiIHRvIHRoaXMgY29tbWFuZC4KLy8gWFhYOiBJZiBAaXNfbXVsdGlsZXZlbF9jb21tYW5k IGlzIHRydWUsIHRoZW4gQGluaXRfY29tbWFuZF9uYW1lIGNhbgovLyBpbmNsdWRlIG1vcmUgdGhh biBvbmUgY29tbWFuZCBsZXZlbHMgaW4gdGhlIG1pZGRsZS4KLy8gRS5nLiAic2hvdyB2ZXJzaW9u IHBpbSIuIEhvd2V2ZXIsIGNvbW1hbmRzICJzaG93IiBhbmQgInNob3cgdmVyc2lvbiIgbXVzdAov LyBoYXZlIGJlZW4gaW5zdGFsbGVkIGZpcnN0LgovLwpDbGlDb21tYW5kICoKQ2xpQ29tbWFuZDo6 YWRkX2NvbW1hbmQoY29uc3Qgc3RyaW5nJiBpbml0X2NvbW1hbmRfbmFtZSwKCQkJY29uc3Qgc3Ry aW5nJiBpbml0X2NvbW1hbmRfaGVscCwKCQkJYm9vbCBpc19tdWx0aWxldmVsX2NvbW1hbmQpCnsK ICAgIENsaUNvbW1hbmQgKnBhcmVudF9jbGlfY29tbWFuZCA9IE5VTEw7CiAgICBDbGlDb21tYW5k ICpjbGlfY29tbWFuZCA9IE5VTEw7CiAgICB2ZWN0b3I8c3RyaW5nPiBjb21tYW5kX3Rva2VuczsK ICAgIHN0cmluZyB0b2tlbjsKICAgIHN0cmluZyB0b2tlbl9saW5lID0gaW5pdF9jb21tYW5kX25h bWU7CiAgICBzdHJpbmcgY29tbWFuZF9uYW1lX3N0cmluZzsKICAgIAogICAgaWYgKGlzX211bHRp bGV2ZWxfY29tbWFuZCkgewoJLy8gQ3JlYXRlIGEgdmVjdG9yIG9mIGFsbCB0YWtlbnMgaW4gdGhl IGNvbW1hbmQKCWZvciAodG9rZW4gPSBwb3BfdG9rZW4odG9rZW5fbGluZSk7CgkgICAgICEgdG9r ZW4uZW1wdHkoKTsKCSAgICAgdG9rZW4gPSBwb3BfdG9rZW4odG9rZW5fbGluZSkpIHsKCSAgICBj b21tYW5kX3Rva2Vucy5wdXNoX2JhY2sodG9rZW4pOwoJfQogICAgfSBlbHNlIHsKCWlmICh0b2tl bl9saW5lLmVtcHR5KCkpCgkgICAgcmV0dXJuIChOVUxMKTsKCWNvbW1hbmRfdG9rZW5zLnB1c2hf YmFjayh0b2tlbl9saW5lKTsKICAgIH0KCiAgICBpZiAoY29tbWFuZF90b2tlbnMuZW1wdHkoKSkK CXJldHVybiAoTlVMTCk7CiAgICBjb21tYW5kX25hbWVfc3RyaW5nID0gY29tbWFuZF90b2tlbnNb Y29tbWFuZF90b2tlbnMuc2l6ZSgpIC0gMV07CiAgICAKICAgIC8vIFRyYXZlcnNlIGFsbCB0b2tl bnMgYW5kIGZpbmQgdGhlIHBhcmVudCBjb21tYW5kIHdoZXJlIHRvIGluc3RhbGwKICAgIC8vIHRo ZSBuZXcgY29tbWFuZAogICAgcGFyZW50X2NsaV9jb21tYW5kID0gdGhpczsKICAgIGZvciAoc2l6 ZV90IGkgPSAwOyBpIDwgY29tbWFuZF90b2tlbnMuc2l6ZSgpIC0gMTsgaSsrKSB7CglwYXJlbnRf Y2xpX2NvbW1hbmQgPSBwYXJlbnRfY2xpX2NvbW1hbmQtPmNvbW1hbmRfZmluZChjb21tYW5kX3Rv a2Vuc1tpXSk7CglpZiAocGFyZW50X2NsaV9jb21tYW5kID09IE5VTEwpCgkgICAgYnJlYWs7CiAg ICB9CiAgICBpZiAocGFyZW50X2NsaV9jb21tYW5kID09IE5VTEwpCglnb3RvIGVycm9yX2xhYmVs X21pc3Npbmc7CiAgICAKICAgIGNsaV9jb21tYW5kID0gbmV3IENsaUNvbW1hbmQocGFyZW50X2Ns aV9jb21tYW5kLAoJCQkJIGNvbW1hbmRfbmFtZV9zdHJpbmcsCgkJCQkgaW5pdF9jb21tYW5kX2hl bHApOwogICAgCiAgICBpZiAocGFyZW50X2NsaV9jb21tYW5kLT5hZGRfY29tbWFuZChjbGlfY29t bWFuZCkgPCAwKSB7CglkZWxldGUgY2xpX2NvbW1hbmQ7Cglnb3RvIGVycm9yX2xhYmVsX2ZhaWxl ZDsKICAgIH0KICAgIAogICAgY2xpX2NvbW1hbmQtPnNldF9hbGxvd19jZChmYWxzZSwgIiIpOwog ICAgCiAgICByZXR1cm4gKGNsaV9jb21tYW5kKTsKICAgIAogZXJyb3JfbGFiZWxfbWlzc2luZzoK ICAgIFhMT0dfRVJST1IoIkVycm9yIGluc3RhbGxpbmcgJyVzJyBvbiBub24tZXhpc3RlbnQgbm9k ZSAnJXMnIiwgCgkgICAgICAgaW5pdF9jb21tYW5kX25hbWUuY19zdHIoKSwKCSAgICAgICAodGhp cy0+bmFtZSgpLnNpemUoKSA+IDApID8gdGhpcy0+bmFtZSgpLmNfc3RyKCkgOiAiPFJPT1Q+Iik7 CiAgICByZXR1cm4gKE5VTEwpOwkJLy8gSW52YWxpZCBwYXRoIHRvIHRoZSBjb21tYW5kCiBlcnJv cl9sYWJlbF9mYWlsZWQ6CiAgICBYTE9HX0VSUk9SKCJFcnJvciBpbnN0YWxsaW5nICclcycgb24g JyVzJyIsIGluaXRfY29tbWFuZF9uYW1lLmNfc3RyKCksCgkgICAgICAgKHRoaXMtPm5hbWUoKS5z aXplKCkgPiAwKSA/IHRoaXMtPm5hbWUoKS5jX3N0cigpIDogIjxST09UPiIpOwogICAgcmV0dXJu IChOVUxMKTsJCS8vIEludmFsaWQgcGF0aCB0byB0aGUgY29tbWFuZAp9CgovLwovLyBDcmVhdGUg YSBjb21tYW5kIGFuZCBhc3NpZ24gYSBwcm9jZXNzaW5nIGNhbGxiYWNrIHRvIGl0LgovLyBSZXR1 cm4gdGhlIG5ldyBjaGlsZCBjb21tYW5kIG9uIHN1Y2Nlc3MsIG90aGVyd2lzZSBOVUxMLgovLwpD bGlDb21tYW5kICoKQ2xpQ29tbWFuZDo6YWRkX2NvbW1hbmQoY29uc3Qgc3RyaW5nJiBpbml0X2Nv bW1hbmRfbmFtZSwKCQkJY29uc3Qgc3RyaW5nJiBpbml0X2NvbW1hbmRfaGVscCwKCQkJYm9vbCBp c19tdWx0aWxldmVsX2NvbW1hbmQsCgkJCWNvbnN0IENMSV9QUk9DRVNTX0NBTExCQUNLJiBpbml0 X2NsaV9wcm9jZXNzX2NhbGxiYWNrKQp7CiAgICBDbGlDb21tYW5kICpjbGlfY29tbWFuZCA9IGFk ZF9jb21tYW5kKGluaXRfY29tbWFuZF9uYW1lLAoJCQkJCSAgaW5pdF9jb21tYW5kX2hlbHAsCgkJ CQkJICBpc19tdWx0aWxldmVsX2NvbW1hbmQpOwogICAgCiAgICBpZiAoY2xpX2NvbW1hbmQgPT0g TlVMTCkKCXJldHVybiAoTlVMTCk7CiAgICBjbGlfY29tbWFuZC0+c2V0X2NsaV9wcm9jZXNzX2Nh bGxiYWNrKGluaXRfY2xpX3Byb2Nlc3NfY2FsbGJhY2spOwogICAgY2xpX2NvbW1hbmQtPnNldF9h bGxvd19jZChmYWxzZSwgIiIpOwogICAgaWYgKCEgaW5pdF9jbGlfcHJvY2Vzc19jYWxsYmFjay5p c19lbXB0eSgpKSB7CgkvLyBYWFg6IGJ5IGRlZmF1bHQsIGVuYWJsZSBwaXBlIHByb2Nlc3Npbmcg aWYgdGhlcmUgaXMgYSBjYWxsYmFjayBmdW5jCgljbGlfY29tbWFuZC0+c2V0X2Nhbl9waXBlKHRy dWUpOwogICAgfQogICAgCiAgICByZXR1cm4gKGNsaV9jb21tYW5kKTsKfQoKLy8KLy8gQ3JlYXRl IGEgY29tbWFuZCBhbmQgYXNzaWduIGEgcHJvY2Vzc2luZyBhbmQgYW4gaW50ZXJydXB0IGNhbGxi YWNrcyB0byBpdC4KLy8gUmV0dXJuIHRoZSBuZXcgY2hpbGQgY29tbWFuZCBvbiBzdWNjZXNzLCBv dGhlcndpc2UgTlVMTC4KLy8KQ2xpQ29tbWFuZCAqCkNsaUNvbW1hbmQ6OmFkZF9jb21tYW5kKGNv bnN0IHN0cmluZyYgaW5pdF9jb21tYW5kX25hbWUsCgkJCWNvbnN0IHN0cmluZyYgaW5pdF9jb21t YW5kX2hlbHAsCgkJCWJvb2wgaXNfbXVsdGlsZXZlbF9jb21tYW5kLAoJCQljb25zdCBDTElfUFJP Q0VTU19DQUxMQkFDSyYgaW5pdF9jbGlfcHJvY2Vzc19jYWxsYmFjaywKCQkJY29uc3QgQ0xJX0lO VEVSUlVQVF9DQUxMQkFDSyYgaW5pdF9jbGlfaW50ZXJydXB0X2NhbGxiYWNrKQp7CiAgICBDbGlD b21tYW5kICpjbGlfY29tbWFuZCA9IGFkZF9jb21tYW5kKGluaXRfY29tbWFuZF9uYW1lLAoJCQkJ CSAgaW5pdF9jb21tYW5kX2hlbHAsCgkJCQkJICBpc19tdWx0aWxldmVsX2NvbW1hbmQsCgkJCQkJ ICBpbml0X2NsaV9wcm9jZXNzX2NhbGxiYWNrKTsKICAgIAogICAgaWYgKGNsaV9jb21tYW5kID09 IE5VTEwpCglyZXR1cm4gKE5VTEwpOwogICAgY2xpX2NvbW1hbmQtPnNldF9jbGlfaW50ZXJydXB0 X2NhbGxiYWNrKGluaXRfY2xpX2ludGVycnVwdF9jYWxsYmFjayk7CiAgICAKICAgIHJldHVybiAo Y2xpX2NvbW1hbmQpOwp9CgovLwovLyBSZXR1cm4gdGhlIG5ldyBjaGlsZCBjb21tYW5kIG9uIHN1 Y2Nlc3MsIG90aGVyd2lzZSBOVUxMLgovLyBTZXR1cCBhIGNvbW1hbmQgd2UgY2FuICJjZCIgdG8u IElmIEBjZF9wcm9tcHQgaXMgbm90LU5VTEwsCi8vIHRoZW4gdGhlIENMSSBwcm9tcHQgd2lsbCBi ZSBzZXQgdG8gQGNkX3Byb21wdDsKLy8gb3RoZXJ3aXNlLCBpdCB3aWxsIHJlbWFpbiB1bmNoYW5n ZWQuCi8vCkNsaUNvbW1hbmQgKgpDbGlDb21tYW5kOjphZGRfY29tbWFuZChjb25zdCBzdHJpbmcm IGluaXRfY29tbWFuZF9uYW1lLAoJCQljb25zdCBzdHJpbmcmIGluaXRfY29tbWFuZF9oZWxwLAoJ CQljb25zdCBzdHJpbmcmIGluaXRfY2RfcHJvbXB0LAoJCQlib29sIGlzX211bHRpbGV2ZWxfY29t bWFuZCkKewogICAgQ2xpQ29tbWFuZCAqY2xpX2NvbW1hbmQgPSBhZGRfY29tbWFuZChpbml0X2Nv bW1hbmRfbmFtZSwKCQkJCQkgIGluaXRfY29tbWFuZF9oZWxwLAoJCQkJCSAgaXNfbXVsdGlsZXZl bF9jb21tYW5kKTsKICAgIAogICAgaWYgKGNsaV9jb21tYW5kID09IE5VTEwpCglyZXR1cm4gKE5V TEwpOwogICAgY2xpX2NvbW1hbmQtPnNldF9hbGxvd19jZCh0cnVlLCBpbml0X2NkX3Byb21wdCk7 CiAgICAKICAgIHJldHVybiAoY2xpX2NvbW1hbmQpOwp9CgoKLy8KLy8gRGVsZXRlIGEgY29tbWFu ZCwgYW5kIGFsbCBzdWItY29tbWFuZHMgYmVsb3cgaXQKLy8gUmV0dXJuOiAlWE9SUF9PSyBvbiBz dWNjZXNzLCBvdGhlcndpc2UgJVhPUlBfRVJST1IKLy8KaW50CkNsaUNvbW1hbmQ6OmRlbGV0ZV9j b21tYW5kKENsaUNvbW1hbmQgKmNoaWxkX2NvbW1hbmQpCnsKICAgIGxpc3Q8Q2xpQ29tbWFuZCAq Pjo6aXRlcmF0b3IgaXRlcjsKICAgIAogICAgaXRlciA9IGZpbmQoX2NoaWxkX2NvbW1hbmRfbGlz dC5iZWdpbigpLAoJCV9jaGlsZF9jb21tYW5kX2xpc3QuZW5kKCksCgkJY2hpbGRfY29tbWFuZCk7 CiAgICBpZiAoaXRlciA9PSBfY2hpbGRfY29tbWFuZF9saXN0LmVuZCgpKQoJcmV0dXJuIChYT1JQ X0VSUk9SKTsKICAgIAogICAgX2NoaWxkX2NvbW1hbmRfbGlzdC5lcmFzZShpdGVyKTsKICAgIGRl bGV0ZSBjaGlsZF9jb21tYW5kOwogICAgCiAgICByZXR1cm4gKFhPUlBfT0spOwp9CgovLwovLyBE ZWxldGUgYSBjb21tYW5kLCBhbmQgYWxsIHN1Yi1jb21tYW5kcyBiZWxvdyBpdAovLyBSZXR1cm46 ICVYT1JQX09LIG9uIHN1Y2Nlc3MsIG90aGVyd2lzZSAlWE9SUF9FUlJPUgovLyBYWFg6IEBkZWxl dGVfY29tbWFuZF9uYW1lIGNhbiBiZSB0aGUgZnVsbCBwYXRoLW5hbWUgZm9yIHRoYXQgY29tbWFu ZAovLwppbnQKQ2xpQ29tbWFuZDo6ZGVsZXRlX2NvbW1hbmQoY29uc3Qgc3RyaW5nJiBkZWxldGVf Y29tbWFuZF9uYW1lKQp7CiAgICBDbGlDb21tYW5kICpwYXJlbnRfY2xpX2NvbW1hbmQgPSBOVUxM OwogICAgQ2xpQ29tbWFuZCAqZGVsZXRlX2NsaV9jb21tYW5kID0gTlVMTDsKICAgIHZlY3Rvcjxz dHJpbmc+IGNvbW1hbmRfdG9rZW5zOwogICAgc3RyaW5nIHRva2VuOwogICAgc3RyaW5nIHRva2Vu X2xpbmUgPSBkZWxldGVfY29tbWFuZF9uYW1lOwogICAgCiAgICAvLyBDcmVhdGUgYSB2ZWN0b3Ig b2YgYWxsIHRha2VucyBpbiB0aGUgY29tbWFuZAogICAgZm9yICh0b2tlbiA9IHBvcF90b2tlbih0 b2tlbl9saW5lKTsKCSAhIHRva2VuLmVtcHR5KCk7CgkgdG9rZW4gPSBwb3BfdG9rZW4odG9rZW5f bGluZSkpIHsKCWNvbW1hbmRfdG9rZW5zLnB1c2hfYmFjayh0b2tlbik7CiAgICB9CiAgICBpZiAo Y29tbWFuZF90b2tlbnMuZW1wdHkoKSkKCXJldHVybiAoWE9SUF9FUlJPUik7CiAgICAKICAgIC8v IFRyYXZlcnNlIGFsbCB0b2tlbnMgYW5kIGZpbmQgdGhlIGNvbW1hbmQgdG8gZGVsZXRlCiAgICBw YXJlbnRfY2xpX2NvbW1hbmQgPSB0aGlzOwogICAgZGVsZXRlX2NsaV9jb21tYW5kID0gTlVMTDsK ICAgIGZvciAoc2l6ZV90IGkgPSAwOyBpIDwgY29tbWFuZF90b2tlbnMuc2l6ZSgpOyBpKyspIHsK CWlmIChkZWxldGVfY2xpX2NvbW1hbmQgIT0gTlVMTCkKCSAgICBwYXJlbnRfY2xpX2NvbW1hbmQg PSBkZWxldGVfY2xpX2NvbW1hbmQ7CglkZWxldGVfY2xpX2NvbW1hbmQgPSBwYXJlbnRfY2xpX2Nv bW1hbmQtPmNvbW1hbmRfZmluZChjb21tYW5kX3Rva2Vuc1tpXSk7CglpZiAoZGVsZXRlX2NsaV9j b21tYW5kID09IE5VTEwpCgkgICAgYnJlYWs7CiAgICB9CiAgICBpZiAoZGVsZXRlX2NsaV9jb21t YW5kID09IE5VTEwpCglnb3RvIGVycm9yX2xhYmVsOwogICAgCiAgICBpZiAocGFyZW50X2NsaV9j b21tYW5kLT5kZWxldGVfY29tbWFuZChkZWxldGVfY2xpX2NvbW1hbmQpIDwgMCkKCWdvdG8gZXJy b3JfbGFiZWw7CiAgICByZXR1cm4gKFhPUlBfT0spOwogICAgCiBlcnJvcl9sYWJlbDoKICAgIFhM T0dfRVJST1IoIkVycm9yIGRlbGV0aW5nICVzIG9uICVzIiwgZGVsZXRlX2NvbW1hbmRfbmFtZS5j X3N0cigpLAoJICAgICAgIHRoaXMtPm5hbWUoKS5jX3N0cigpKTsKICAgIHJldHVybiAoWE9SUF9F UlJPUik7Cn0KCi8vIFJlY3Vyc2l2ZWx5IGRlbGV0ZSBhbGwgdGhlIGNoaWxkcmVuIG9mIHRoaXMg Y29tbWFuZC4Kdm9pZApDbGlDb21tYW5kOjpkZWxldGVfYWxsX2NvbW1hbmRzKCkgCnsKICAgIGxp c3QgPENsaUNvbW1hbmQqPjo6aXRlcmF0b3IgaXRlcjsKICAgIGZvciAoaXRlciA9IF9jaGlsZF9j b21tYW5kX2xpc3QuYmVnaW4oKTsKCSBpdGVyICE9IF9jaGlsZF9jb21tYW5kX2xpc3QuZW5kKCk7 ICsraXRlcikgewoJKCppdGVyKS0+ZGVsZXRlX2FsbF9jb21tYW5kcygpOwoJZGVsZXRlICppdGVy OwogICAgfQogICAgd2hpbGUgKCEgX2NoaWxkX2NvbW1hbmRfbGlzdC5lbXB0eSgpKQoJX2NoaWxk X2NvbW1hbmRfbGlzdC5wb3BfZnJvbnQoKTsKfQoKLyoqCiAqIENsaUNvbW1hbmQ6OmNyZWF0ZV9k ZWZhdWx0X2NsaV9jb21tYW5kczoKICogQDogCiAqIAogKiBDcmVhdGUgdGhlIGRlZmF1bHQgQ0xJ IGNvbW1hbmRzIGF0IGVhY2ggbGV2ZWwgb2YgdGhlIGNvbW1hbmQgdHJlZS4KICogCiAqIFJldHVy biB2YWx1ZTogJVhPUlBfT0sgb24gc3VjY2Vzcywgb3RoZXJ3aXNlICVYT1JQX0VSUk9SLgogKiov CmludApDbGlDb21tYW5kOjpjcmVhdGVfZGVmYXVsdF9jbGlfY29tbWFuZHMoKQp7CiAgICAvLyBU T0RPOiBhZGQgY29tbWFuZHMgbGlrZSAiaGVscCIsICJsaXN0IiAoYWxsIGF2YWlsYWJsZSBzdWJj b21tYW5kcywgZXRjCiAgICAKICAgIHJldHVybiAoWE9SUF9PSyk7Cn0KCi8qKgogKiBDbGlDb21t YW5kOjphZGRfcGlwZXM6CiAqIEA6IAogKiAKICogQ3JlYXRlIGFuZCBhZGQgdGhlIGRlZmF1bHQg Q0xJIHBpcGUgY29tbWFuZHMuCiAqIAogKiBSZXR1cm4gdmFsdWU6ICVYT1JQX09LIG9uIHN1Y2Nl c3MsIG90aGVyd2lzZSAlWE9SUF9FUlJPUi4KICoqLwppbnQKQ2xpQ29tbWFuZDo6YWRkX3BpcGVz KCkKewogICAgQ2xpUGlwZSAqY2xpX3BpcGU7CiAgICBDbGlDb21tYW5kICpjb20wOwogICAgCiAg ICBjb20wID0gbmV3IENsaUNvbW1hbmQodGhpcywgInwiLCAiUGlwZSB0aHJvdWdoIGEgY29tbWFu ZCIpOwogICAgLy8gY29tMCA9IGFkZF9jb21tYW5kKCJ8IiwgIlBpcGUgdGhyb3VnaCBhIGNvbW1h bmQiLCBmYWxzZSk7CiAgICBpZiAoY29tMCA9PSBOVUxMKSB7CglyZXR1cm4gKFhPUlBfRVJST1Ip OwogICAgfQogICAgc2V0X2NsaV9jb21tYW5kX3BpcGUoY29tMCk7CiAgICAKICAgIGNsaV9waXBl ID0gbmV3IENsaVBpcGUoImNvdW50Iik7CiAgICBpZiAoY29tMC0+YWRkX2NvbW1hbmQoY2xpX3Bp cGUpICE9IFhPUlBfT0spIHsKCWRlbGV0ZV9waXBlcygpOwoJcmV0dXJuIChYT1JQX0VSUk9SKTsK ICAgIH0KICAgIGNsaV9waXBlID0gbmV3IENsaVBpcGUoImV4Y2VwdCIpOwogICAgaWYgKGNvbTAt PmFkZF9jb21tYW5kKGNsaV9waXBlKSAhPSBYT1JQX09LKSB7CglkZWxldGVfcGlwZXMoKTsKCXJl dHVybiAoWE9SUF9FUlJPUik7CiAgICB9CiAgICBjbGlfcGlwZSA9IG5ldyBDbGlQaXBlKCJmaW5k Iik7CiAgICBpZiAoY29tMC0+YWRkX2NvbW1hbmQoY2xpX3BpcGUpICE9IFhPUlBfT0spIHsKCWRl bGV0ZV9waXBlcygpOwoJcmV0dXJuIChYT1JQX0VSUk9SKTsKICAgIH0KICAgIGNsaV9waXBlID0g bmV3IENsaVBpcGUoImhvbGQiKTsKICAgIGlmIChjb20wLT5hZGRfY29tbWFuZChjbGlfcGlwZSkg IT0gWE9SUF9PSykgewoJZGVsZXRlX3BpcGVzKCk7CglyZXR1cm4gKFhPUlBfRVJST1IpOwogICAg fQogICAgY2xpX3BpcGUgPSBuZXcgQ2xpUGlwZSgibWF0Y2giKTsKICAgIGlmIChjb20wLT5hZGRf Y29tbWFuZChjbGlfcGlwZSkgIT0gWE9SUF9PSykgewoJZGVsZXRlX3BpcGVzKCk7CglyZXR1cm4g KFhPUlBfRVJST1IpOwogICAgfQogICAgY2xpX3BpcGUgPSBuZXcgQ2xpUGlwZSgibm8tbW9yZSIp OwogICAgaWYgKGNvbTAtPmFkZF9jb21tYW5kKGNsaV9waXBlKSAhPSBYT1JQX09LKSB7CglkZWxl dGVfcGlwZXMoKTsKCXJldHVybiAoWE9SUF9FUlJPUik7CiAgICB9CiAgICBjbGlfcGlwZSA9IG5l dyBDbGlQaXBlKCJyZXNvbHZlIik7CiAgICBpZiAoY29tMC0+YWRkX2NvbW1hbmQoY2xpX3BpcGUp ICE9IFhPUlBfT0spIHsKCWRlbGV0ZV9waXBlcygpOwoJcmV0dXJuIChYT1JQX0VSUk9SKTsKICAg IH0KICAgIGNsaV9waXBlID0gbmV3IENsaVBpcGUoInNhdmUiKTsKICAgIGlmIChjb20wLT5hZGRf Y29tbWFuZChjbGlfcGlwZSkgIT0gWE9SUF9PSykgewoJZGVsZXRlX3BpcGVzKCk7CglyZXR1cm4g KFhPUlBfRVJST1IpOwogICAgfQogICAgY2xpX3BpcGUgPSBuZXcgQ2xpUGlwZSgidHJpbSIpOwog ICAgaWYgKGNvbTAtPmFkZF9jb21tYW5kKGNsaV9waXBlKSAhPSBYT1JQX09LKSB7CglkZWxldGVf cGlwZXMoKTsKCXJldHVybiAoWE9SUF9FUlJPUik7CiAgICB9CiAgICAKICAgIHJldHVybiAoWE9S UF9PSyk7Cn0KCi8qKgogKiBDbGlDb21tYW5kOjpkZWxldGVfcGlwZXM6CiAqIEA6IAogKiAKICog RGVsZXRlIHRoZSBkZWZhdWx0IENMSSBwaXBlIGNvbW1hbmRzLgogKiAKICogUmV0dXJuIHZhbHVl OiAlWE9SUF9PSyBvbiBzdWNjZXNzLCBvdGhlcndpc2UgJVhPUlBfRVJST1IuCiAqKi8KaW50CkNs aUNvbW1hbmQ6OmRlbGV0ZV9waXBlcygpCnsKICAgIGlmIChfY2xpX2NvbW1hbmRfcGlwZSAhPSBO VUxMKQoJZGVsZXRlIF9jbGlfY29tbWFuZF9waXBlOwogICAgCiAgICByZXR1cm4gKFhPUlBfT0sp OwogICAgLy8gcmV0dXJuIChkZWxldGVfY29tbWFuZCgifCIpKTsKfQoKLy8KLy8gQXR0ZW1wdHMg dG8gY29tcGxldGUgdGhlIGN1cnJlbnQgY29tbWFuZC4KLy8gUmV0dXJuOiB0cnVlIGlmIHRoZSBh dHRlbXB0IHdhcyBzdWNjZXNzZnVsLCBvdGhlcndpc2UgZmFsc2UuCi8vCmJvb2wKQ2xpQ29tbWFu ZDo6Y2xpX2F0dGVtcHRfY29tbWFuZF9jb21wbGV0aW9uX2J5bmFtZSh2b2lkICpvYmosCgkJCQkJ CSAgV29yZENvbXBsZXRpb24gKmNwbCwKCQkJCQkJICB2b2lkICpkYXRhLAoJCQkJCQkgIGNvbnN0 IGNoYXIgKmxpbmUsCgkJCQkJCSAgaW50IHdvcmRfZW5kLAoJCQkJCQkgIGxpc3Q8Q2xpQ29tbWFu ZCAqPiYgY2xpX2NvbW1hbmRfbWF0Y2hfbGlzdCkKewogICAgQ2xpQ29tbWFuZCAqY2xpX2NvbW1h bmQgPSByZWludGVycHJldF9jYXN0PENsaUNvbW1hbmQqPihvYmopOwogICAgaW50IHdvcmRfc3Rh cnQgPSAwOwkJLy8gWFhYOiBjb21wbGV0ZSBmcm9tIHRoZSBiZWdpbm5pbmcgb2YgJ2xpbmUnCiAg ICBjb25zdCBjaGFyICp0eXBlX3N1ZmZpeCA9IE5VTEw7CiAgICBjb25zdCBjaGFyICpjb250X3N1 ZmZpeCA9ICIgIjsgLy8gWFhYOiBhIHNwYWNlIGFmdGVyIGEgY29tbWFuZCBpcyBjb21wbGV0ZWQK ICAgIHN0cmluZyB0b2tlbiwgdG9rZW5fbGluZTsKICAgIGNvbnN0IHN0cmluZyBuYW1lX3N0cmlu ZyA9IGNsaV9jb21tYW5kLT5uYW1lKCk7CiAgICBib29sIGlzX2NvbW1hbmRfY29tcGxldGVkOwkv LyAndHJ1ZScgaWYgY29tcGxldGUgY29tbWFuZCB0eXBlZAogICAgCiAgICBpZiAoKGNwbCA9PSBO VUxMKSB8fCAobGluZSA9PSBOVUxMKSB8fCAod29yZF9lbmQgPCAwKSkgewoJcmV0dXJuIChmYWxz ZSk7CiAgICB9CiAgICAKICAgIHRva2VuX2xpbmUgPSBzdHJpbmcobGluZSwgd29yZF9lbmQpOwog ICAgdG9rZW4gPSBwb3BfdG9rZW4odG9rZW5fbGluZSk7CiAgICBpZiAoKCEgY2xpX2NvbW1hbmQt PmlzX3NhbWVfcHJlZml4KHRva2VuKSkKCSYmICghIGNsaV9jb21tYW5kLT5oYXNfdHlwZV9tYXRj aF9jYigpKSkgewoJICAgIHJldHVybiAoZmFsc2UpOwogICAgfQogICAgCiAgICBpZiAodG9rZW5f bGluZS5sZW5ndGgoKQoJJiYgKGlzX3Rva2VuX3NlcGFyYXRvcih0b2tlbl9saW5lWzBdKSB8fCAo dG9rZW4gPT0gInwiKSkpCglpc19jb21tYW5kX2NvbXBsZXRlZCA9IHRydWU7CiAgICBlbHNlCglp c19jb21tYW5kX2NvbXBsZXRlZCA9IGZhbHNlOwogICAgCiAgICAvLyBDaGVjayBpZiBhIHBvdGVu dGlhbCBzdWItcHJlZml4CiAgICBpZiAoISBpc19jb21tYW5kX2NvbXBsZXRlZCkgewoJc3RyaW5n IG5hbWVfY29tcGxldGU7CgoJaWYgKGNsaV9jb21tYW5kLT5oYXNfdHlwZV9tYXRjaF9jYigpKSB7 CgkgICAgbmFtZV9jb21wbGV0ZSA9ICIiOwoJfSBlbHNlIHsKCSAgICBuYW1lX2NvbXBsZXRlID0g bmFtZV9zdHJpbmcuc3Vic3RyKHRva2VuLmxlbmd0aCgpKTsKCSAgICBpZiAoY2xpX2NvbW1hbmQt PmhlbHBfY29tcGxldGlvbigpLnNpemUoKSA+IDApCgkJdHlwZV9zdWZmaXggPSBjbGlfY29tbWFu ZC0+aGVscF9jb21wbGV0aW9uKCkuY19zdHIoKTsKCX0KCQoJLy8gQWRkIHR3byBlbXB0eSBzcGFj ZXMgaW4gZnJvbnQKCXN0cmluZyBsaW5lX3N0cmluZyA9ICIgICI7CglpZiAodG9rZW4uZW1wdHko KSkgewoJICAgIC8vIFhYWDogaWdub3JlIHRoZSByZXN0IG9mIHRoZSBlbXB0eSBzcGFjZXMKCSAg ICB3b3JkX2VuZCA9IDA7Cgl9IGVsc2UgewoJICAgIGxpbmVfc3RyaW5nICs9IGxpbmU7Cgl9Cglj cGxfYWRkX2NvbXBsZXRpb24oY3BsLCBsaW5lX3N0cmluZy5jX3N0cigpLCB3b3JkX3N0YXJ0LCB3 b3JkX2VuZCArIDIsCgkJCSAgIG5hbWVfY29tcGxldGUuY19zdHIoKSwKCQkJICAgdHlwZV9zdWZm aXgsIGNvbnRfc3VmZml4KTsKCWNsaV9jb21tYW5kX21hdGNoX2xpc3QucHVzaF9iYWNrKGNsaV9j b21tYW5kKTsKCXJldHVybiAodHJ1ZSk7CiAgICB9CiAgICAKICAgIC8vIE11c3QgYmUgYSBjb21w bGV0ZSBjb21tYW5kCgogICAgYm9vbCBpc190b2tlbl9tYXRjaCA9IGZhbHNlOwogICAgaWYgKGNs aV9jb21tYW5kLT5oYXNfdHlwZV9tYXRjaF9jYigpKSB7CglzdHJpbmcgZXJybXNnOwoJaXNfdG9r ZW5fbWF0Y2ggPSBjbGlfY29tbWFuZC0+dHlwZV9tYXRjaF9jYigpLT5kaXNwYXRjaCh0b2tlbiwg ZXJybXNnKTsKICAgIH0gZWxzZSB7Cglpc190b2tlbl9tYXRjaCA9IGNsaV9jb21tYW5kLT5pc19z YW1lX2NvbW1hbmQodG9rZW4pOwogICAgfQogICAgaWYgKCEgaXNfdG9rZW5fbWF0Y2gpIHsKCXJl dHVybiAoZmFsc2UpOwogICAgfQogICAgCiAgICBib29sIGlzX2NoaWxkX2NvbXBsZXRpb24gPSBm YWxzZTsKICAgIAogICAgaWYgKGNsaV9jb21tYW5kLT5jYW5fY29tcGxldGUoKQoJJiYgISBoYXNf bW9yZV90b2tlbnModG9rZW5fbGluZSkpIHsKCS8vIEFkZCB0aGUgYXBwcm9wcmlhdGUgY29tcGxl dGlvbiBpbmZvIGlmIHRoZSBjb21tYW5kIGNhbiBiZSBydW4KCXN0cmluZyBsaW5lX3N0cmluZzEg PSAiICA8W0VudGVyXT4gICAgICAgRXhlY3V0ZSB0aGlzIGNvbW1hbmRcciI7CgljcGxfYWRkX2Nv bXBsZXRpb24oY3BsLCBsaW5lX3N0cmluZzEuY19zdHIoKSwgd29yZF9zdGFydCwKCQkJICAgbGlu ZV9zdHJpbmcxLnNpemUoKSwKCQkJICAgIiIsCgkJCSAgIHR5cGVfc3VmZml4LCBjb250X3N1ZmZp eCk7Cglpc19jaGlsZF9jb21wbGV0aW9uID0gdHJ1ZTsKICAgIH0KICAgIAogICAgaWYgKGNsaV9j b21tYW5kLT5jYW5fcGlwZSgpICYmIChjbGlfY29tbWFuZC0+Y2xpX2NvbW1hbmRfcGlwZSgpICE9 IE5VTEwpKSB7CgkvLyBBZGQgdGhlIHBpcGUgY29tcGxldGlvbnMKCWlmIChjbGlfY29tbWFuZC0+ X2NsaV9jb21wbGV0aW9uX2Z1bmMoY2xpX2NvbW1hbmQtPmNsaV9jb21tYW5kX3BpcGUoKSwKCQkJ CQkgICAgICBjcGwsCgkJCQkJICAgICAgZGF0YSwKCQkJCQkgICAgICB0b2tlbl9saW5lLmNfc3Ry KCksCgkJCQkJICAgICAgdG9rZW5fbGluZS5sZW5ndGgoKSwKCQkJCQkgICAgICBjbGlfY29tbWFu ZF9tYXRjaF9saXN0KSkgewoJICAgIGlzX2NoaWxkX2NvbXBsZXRpb24gPSB0cnVlOwoJfQogICAg fQoKICAgIC8vIEFkZCBjb21wbGV0aW9ucyBmb3IgdGhlIHN1Yi1jb21tYW5kcyAoaWYgYW55KQog ICAgbGlzdDxDbGlDb21tYW5kICo+OjppdGVyYXRvciBpdGVyOwogICAgZm9yIChpdGVyID0gY2xp X2NvbW1hbmQtPmNoaWxkX2NvbW1hbmRfbGlzdCgpLmJlZ2luKCk7CgkgaXRlciAhPSBjbGlfY29t bWFuZC0+Y2hpbGRfY29tbWFuZF9saXN0KCkuZW5kKCk7CgkgKytpdGVyKSB7CglDbGlDb21tYW5k ICpjbGlfY29tbWFuZF9jaGlsZCA9ICppdGVyOwoJaWYgKCEgY2xpX2NvbW1hbmRfY2hpbGQtPmhh c19jbGlfY29tcGxldGlvbl9mdW5jKCkpCgkgICAgY29udGludWU7CglpZiAoY2xpX2NvbW1hbmRf Y2hpbGQtPl9jbGlfY29tcGxldGlvbl9mdW5jKGNsaV9jb21tYW5kX2NoaWxkLAoJCQkJCQkgICAg Y3BsLAoJCQkJCQkgICAgZGF0YSwKCQkJCQkJICAgIHRva2VuX2xpbmUuY19zdHIoKSwKCQkJCQkJ ICAgIHRva2VuX2xpbmUubGVuZ3RoKCksCgkJCQkJCSAgICBjbGlfY29tbWFuZF9tYXRjaF9saXN0 KSkgewoJICAgIGlzX2NoaWxkX2NvbXBsZXRpb24gPSB0cnVlOwoJfQogICAgfQogICAgCiAgICBy ZXR1cm4gKGlzX2NoaWxkX2NvbXBsZXRpb24pOwp9CgpDbGlDb21tYW5kICoKQ2xpQ29tbWFuZDo6 Y29tbWFuZF9maW5kKGNvbnN0IHN0cmluZyYgdG9rZW4pCnsKICAgIGxpc3Q8Q2xpQ29tbWFuZCAq Pjo6aXRlcmF0b3IgaXRlcjsKICAgIAogICAgZm9yIChpdGVyID0gY2hpbGRfY29tbWFuZF9saXN0 KCkuYmVnaW4oKTsKCSBpdGVyICE9IGNoaWxkX2NvbW1hbmRfbGlzdCgpLmVuZCgpOwoJICsraXRl cikgewoJQ2xpQ29tbWFuZCAqY2xpX2NvbW1hbmQgPSAqaXRlcjsKCWlmIChjbGlfY29tbWFuZC0+ aGFzX3R5cGVfbWF0Y2hfY2IoKSkgewoJICAgIHN0cmluZyBlcnJtc2c7CgkgICAgaWYgKGNsaV9j b21tYW5kLT50eXBlX21hdGNoX2NiKCktPmRpc3BhdGNoKHRva2VuLCBlcnJtc2cpKQoJCXJldHVy biAoY2xpX2NvbW1hbmQpOwoJICAgIGNvbnRpbnVlOwoJfQoJaWYgKGNsaV9jb21tYW5kLT5pc19z YW1lX2NvbW1hbmQodG9rZW4pKSB7CgkgICAgLy8gWFhYOiBhc3N1bWUgdGhhdCBubyB0d28gc3Vi Y29tbWFuZHMgaGF2ZSB0aGUgc2FtZSBuYW1lCgkgICAgcmV0dXJuIChjbGlfY29tbWFuZCk7Cgl9 CiAgICB9CiAgICAKICAgIHJldHVybiAoTlVMTCk7Cn0KCi8vCi8vIFRlc3QgaWYgdGhlIGNvbW1h bmQgbGluZSBpcyBhIHByZWZpeCBmb3IgYSBtdWx0aS1sZXZlbCBjb21tYW5kLgovLyBOb3RlIHRo YXQgaWYgdGhlcmUgaXMgYW4gZXhhY3QgbWF0Y2gsIHRoZW4gdGhlIHJldHVybiB2YWx1ZSBpcyBm YWxzZS4KLy8KYm9vbApDbGlDb21tYW5kOjppc19tdWx0aV9jb21tYW5kX3ByZWZpeChjb25zdCBz dHJpbmcmIGNvbW1hbmRfbGluZSkKewogICAgc3RyaW5nIHRva2VuOwogICAgc3RyaW5nIHRva2Vu X2xpbmUgPSBjb21tYW5kX2xpbmU7CiAgICBDbGlDb21tYW5kICpwYXJlbnRfY2xpX2NvbW1hbmQg PSB0aGlzOwogICAgQ2xpQ29tbWFuZCAqY2hpbGRfY2xpX2NvbW1hbmQgPSBOVUxMOwoKICAgIGZv ciAodG9rZW4gPSBwb3BfdG9rZW4odG9rZW5fbGluZSk7CgkgISB0b2tlbi5lbXB0eSgpOwoJIHRv a2VuID0gcG9wX3Rva2VuKHRva2VuX2xpbmUpKSB7CgljaGlsZF9jbGlfY29tbWFuZCA9IHBhcmVu dF9jbGlfY29tbWFuZC0+Y29tbWFuZF9maW5kKHRva2VuKTsKCWlmIChjaGlsZF9jbGlfY29tbWFu ZCAhPSBOVUxMKSB7CgkgICAgcGFyZW50X2NsaV9jb21tYW5kID0gY2hpbGRfY2xpX2NvbW1hbmQ7 CgkgICAgY29udGludWU7Cgl9CgoJLy8gVGVzdCBpZiB0aGUgdG9rZW4gaXMgYSBwcmVmaXggZm9y IGEgY2hpbGQgY29tbWFuZAoJbGlzdDxDbGlDb21tYW5kICo+Ojpjb25zdF9pdGVyYXRvciBpdGVy OwoJZm9yIChpdGVyID0gcGFyZW50X2NsaV9jb21tYW5kLT5jaGlsZF9jb21tYW5kX2xpc3QoKS5i ZWdpbigpOwoJICAgICBpdGVyICE9IHBhcmVudF9jbGlfY29tbWFuZC0+Y2hpbGRfY29tbWFuZF9s aXN0KCkuZW5kKCk7CgkgICAgICsraXRlcikgewoJICAgIGNoaWxkX2NsaV9jb21tYW5kID0gKml0 ZXI7CgkgICAgaWYgKGNoaWxkX2NsaV9jb21tYW5kLT5pc19zYW1lX3ByZWZpeCh0b2tlbikpCgkJ cmV0dXJuIHRydWU7Cgl9CgoJYnJlYWs7CiAgICB9CgogICAgcmV0dXJuIChmYWxzZSk7Cn0KCi8v IFRlc3RzIGlmIHRoZSBzdHJpbmcgaW4gQHRva2VuIGNhbiBiZSBhIHByZWZpeCBmb3IgdGhpcyBj b21tYW5kCmJvb2wKQ2xpQ29tbWFuZDo6aXNfc2FtZV9wcmVmaXgoY29uc3Qgc3RyaW5nJiB0b2tl bikKewogICAgc2l6ZV90IHMgPSB0b2tlbi5sZW5ndGgoKTsKICAgIAogICAgaWYgKHMgPiBfbmFt ZS5sZW5ndGgoKSkKCXJldHVybiAoZmFsc2UpOwogICAgCiAgICByZXR1cm4gKHRva2VuLnN1YnN0 cigwLCBzKSA9PSBfbmFtZS5zdWJzdHIoMCwgcykpOwp9CgovLyBUZXN0cyBpZiB0aGUgc3RyaW5n IGluIEB0b2tlbiBtYXRjaGVzIHRoaXMgY29tbWFuZApib29sCkNsaUNvbW1hbmQ6OmlzX3NhbWVf Y29tbWFuZChjb25zdCBzdHJpbmcmIHRva2VuKQp7CiAgICByZXR1cm4gKHRva2VuID09IF9uYW1l KTsKfQoKYm9vbApDbGlDb21tYW5kOjpmaW5kX2NvbW1hbmRfaGVscChjb25zdCBjaGFyICpsaW5l LCBpbnQgd29yZF9lbmQsCgkJCSAgICAgIHN0cmluZyYgcmV0X3N0cmluZykKewogICAgc3RyaW5n IHRva2VuLCB0b2tlbl9saW5lOwogICAgYm9vbCByZXRfdmFsdWUgPSBmYWxzZTsKICAgIGJvb2wg aXNfbm9fc3BhY2VfYXRfZW5kOwogICAgCiAgICBpZiAoKGxpbmUgPT0gTlVMTCkgfHwgKHdvcmRf ZW5kIDwgMCkpIHsKICAgICAgICByZXR1cm4gKGZhbHNlKTsKICAgIH0KICAgIAogICAgdG9rZW5f bGluZSA9IHN0cmluZyhsaW5lLCB3b3JkX2VuZCk7CiAgICB0b2tlbiA9IHBvcF90b2tlbih0b2tl bl9saW5lKTsKCiAgICBpZiAoKCEgaXNfc2FtZV9wcmVmaXgodG9rZW4pKSAmJiAoISBoYXNfdHlw ZV9tYXRjaF9jYigpKSkKCXJldHVybiAoZmFsc2UpOwoKICAgIC8vCiAgICAvLyBUZXN0IGlmIHRo ZSB0b2tlbiBtYXRjaGVzIHRoZSBjb21tYW5kCiAgICAvLwogICAgYm9vbCBpc190b2tlbl9tYXRj aCA9IGZhbHNlOwogICAgaWYgKGhhc190eXBlX21hdGNoX2NiKCkpIHsKCXN0cmluZyBlcnJtc2c7 Cglpc190b2tlbl9tYXRjaCA9IHR5cGVfbWF0Y2hfY2IoKS0+ZGlzcGF0Y2godG9rZW4sIGVycm1z Zyk7CiAgICB9IGVsc2UgewoJaXNfdG9rZW5fbWF0Y2ggPSBpc19zYW1lX2NvbW1hbmQodG9rZW4p OwogICAgfQoKICAgIGlmICh0b2tlbl9saW5lLmxlbmd0aCgpCgkmJiBpc190b2tlbl9zZXBhcmF0 b3IodG9rZW5fbGluZVswXSkKCSYmICghIGlzX3Rva2VuX21hdGNoKSkgewoJLy8gTm90IGEgbWF0 Y2gKCXJldHVybiAoZmFsc2UpOwogICAgfQogICAgCiAgICBpc19ub19zcGFjZV9hdF9lbmQgPSAo dG9rZW5fbGluZS5lbXB0eSgpKSA/ICh0cnVlKSA6IChmYWxzZSk7CiAgICAKICAgIC8vIEdldCB0 aGUgdG9rZW4gZm9yIHRoZSBjaGlsZCdzIGNvbW1hbmQgKGlmIGFueSkKICAgIHRva2VuID0gcG9w X3Rva2VuKHRva2VuX2xpbmUpOwogICAgCiAgICBpZiAoKHRva2VuLmxlbmd0aCgpID09IDApICYm IGlzX25vX3NwYWNlX2F0X2VuZCkgewoJLy8gVGhlIGxhc3QgdG9rZW4sIGFuZCB0aGVyZSBpcyBu byBzcGFjZSwgc28gcHJpbnQgbXkgaGVscC4KCXJldF9zdHJpbmcgKz0gY19mb3JtYXQoIiAgJS0x NXMgJXNcclxuIiwKCQkJICAgICAgIG5hbWUoKS5jX3N0cigpLCBoZWxwKCkuY19zdHIoKSk7Cgly ZXR1cm4gKHRydWUpOwogICAgfQogICAgCiAgICBpZiAoKHRva2VuLmxlbmd0aCgpID09IDApICYm IGNhbl9jb21wbGV0ZSgpKSB7CgkvLyBUaGUgbGFzdCB0b2tlbiwgYW5kIHRoZXJlIGlzIHNwYWNl IGF0IHRoZSBlbmQsCgkvLyBzbyBwcmludCB0aGUgImRlZmF1bHQiIGhlbHAuCglyZXRfc3RyaW5n ICs9IGNfZm9ybWF0KCIgICUtMTVzICVzXHJcbiIsCgkJCSAgICAgICAiPFtFbnRlcl0+IiwgIkV4 ZWN1dGUgdGhpcyBjb21tYW5kIik7CglyZXRfdmFsdWUgPSB0cnVlOwogICAgfQogICAgCiAgICAv LyBOb3QgdGhlIGxhc3QgdG9rZW4sIHNvIHNlYXJjaCBkb3duIGZvciBoZWxwCiAgICBsaXN0PENs aUNvbW1hbmQgKj46Oml0ZXJhdG9yIGl0ZXI7ICAgIAogICAgZm9yIChpdGVyID0gY2hpbGRfY29t bWFuZF9saXN0KCkuYmVnaW4oKTsKCSBpdGVyICE9IGNoaWxkX2NvbW1hbmRfbGlzdCgpLmVuZCgp OwoJICsraXRlcikgewoJQ2xpQ29tbWFuZCAqY2xpX2NvbW1hbmQgPSAqaXRlcjsKCXN0cmluZyB0 bXBfdG9rZW5fbGluZSA9IGNvcHlfdG9rZW4odG9rZW4pICsgdG9rZW5fbGluZTsKCXJldF92YWx1 ZSB8PSBjbGlfY29tbWFuZC0+ZmluZF9jb21tYW5kX2hlbHAodG1wX3Rva2VuX2xpbmUuY19zdHIo KSwKCQkJCQkJICAgIHRtcF90b2tlbl9saW5lLmxlbmd0aCgpLAoJCQkJCQkgICAgcmV0X3N0cmlu Zyk7CiAgICB9CiAgICAKICAgIGlmIChjYW5fcGlwZSgpICYmIChjbGlfY29tbWFuZF9waXBlKCkg IT0gTlVMTCkpIHsKCS8vIEFkZCB0aGUgcGlwZSBjb21wbGV0aW9ucwoJc3RyaW5nIHRtcF90b2tl bl9saW5lID0gY29weV90b2tlbih0b2tlbikgKyB0b2tlbl9saW5lOwoJcmV0X3ZhbHVlIHw9IGNs aV9jb21tYW5kX3BpcGUoKS0+ZmluZF9jb21tYW5kX2hlbHAoCgkgICAgdG1wX3Rva2VuX2xpbmUu Y19zdHIoKSwKCSAgICB0bXBfdG9rZW5fbGluZS5sZW5ndGgoKSwKCSAgICByZXRfc3RyaW5nKTsK ICAgIH0KICAgIAogICAgcmV0dXJuIChyZXRfdmFsdWUpOwp9Cgpib29sCkNsaUNvbW1hbmQ6OmNh bl9jb21wbGV0ZSgpCnsKICAgIGlmIChoYXNfY2xpX3Byb2Nlc3NfY2FsbGJhY2soKSB8fCBhbGxv d19jZCgpKQoJcmV0dXJuIHRydWU7CiAgICByZXR1cm4gZmFsc2U7Cn0KCkNsaUNvbW1hbmQgKgpD bGlDb21tYW5kOjpjbGlfY29tbWFuZF9waXBlKCkKewogICAgaWYgKF9yb290X2NvbW1hbmQgIT0g dGhpcykKCXJldHVybiAoX3Jvb3RfY29tbWFuZC0+Y2xpX2NvbW1hbmRfcGlwZSgpKTsKICAgIGVs c2UKCXJldHVybiAoX2NsaV9jb21tYW5kX3BpcGUpOwp9Cgp2b2lkCkNsaUNvbW1hbmQ6OnNldF9k eW5hbWljX2NoaWxkcmVuX2NhbGxiYWNrKERZTkFNSUNfQ0hJTERSRU5fQ0FMTEJBQ0sgdikKewog ICAgWExPR19BU1NFUlQoIV9nbG9iYWxfbmFtZS5lbXB0eSgpKTsKICAgIF9keW5hbWljX2NoaWxk cmVuX2NhbGxiYWNrID0gdjsKICAgIF9oYXNfZHluYW1pY19jaGlsZHJlbiA9IHRydWU7Cn0KCmJv b2wKQ2xpQ29tbWFuZDo6aGFzX2R5bmFtaWNfcHJvY2Vzc19jYWxsYmFjaygpCnsKICAgIHJldHVy biAoIV9keW5hbWljX3Byb2Nlc3NfY2FsbGJhY2suaXNfZW1wdHkoKSk7Cn0KCmJvb2wKQ2xpQ29t bWFuZDo6aGFzX2R5bmFtaWNfaW50ZXJydXB0X2NhbGxiYWNrKCkKewogICAgcmV0dXJuICghX2R5 bmFtaWNfaW50ZXJydXB0X2NhbGxiYWNrLmlzX2VtcHR5KCkpOwp9Cgpib29sCkNsaUNvbW1hbmQ6 Omhhc19jbGlfcHJvY2Vzc19jYWxsYmFjaygpCnsKICAgIGlmIChfaGFzX2R5bmFtaWNfY2hpbGRy ZW4pIHsKCS8vCgkvLyBGb3JjZSB0aGUgY2hpbGRyZW4gdG8gYmUgZXZhbHVhdGVkLCB3aGljaCBm b3JjZXMgdGhlCgkvLyBjbGlfcHJvY2Vzc19jYWxsYmFjayB0byBiZSBzZXQuCgkvLwoJY2hpbGRf Y29tbWFuZF9saXN0KCk7CiAgICB9CiAgICByZXR1cm4gKCFfY2xpX3Byb2Nlc3NfY2FsbGJhY2su aXNfZW1wdHkoKSk7Cn0KCmJvb2wKQ2xpQ29tbWFuZDo6aGFzX2NsaV9pbnRlcnJ1cHRfY2FsbGJh Y2soKQp7CiAgICByZXR1cm4gKCFfY2xpX2ludGVycnVwdF9jYWxsYmFjay5pc19lbXB0eSgpKTsK fQoKYm9vbApDbGlDb21tYW5kOjpoYXNfdHlwZV9tYXRjaF9jYigpIGNvbnN0CnsKICAgIHJldHVy biAoISBfdHlwZV9tYXRjaF9jYi5pc19lbXB0eSgpKTsKfQoKbGlzdDxDbGlDb21tYW5kICo+JgpD bGlDb21tYW5kOjpjaGlsZF9jb21tYW5kX2xpc3QoKQp7CiAgICBpZiAoX2hhc19keW5hbWljX2No aWxkcmVuKQoJWExPR19BU1NFUlQoX2NoaWxkX2NvbW1hbmRfbGlzdC5lbXB0eSgpKTsKCiAgICAv LyBIYW5kbGUgZHluYW1pYyBjaGlsZHJlbiBnZW5lcmF0aW9uCiAgICBpZiAoX2NoaWxkX2NvbW1h bmRfbGlzdC5lbXB0eSgpICYmIF9oYXNfZHluYW1pY19jaGlsZHJlbikgewoJLy8gTm93IHdlJ3Zl IHJ1biB0aGlzLCB3ZSB3b24ndCBuZWVkIHRvIHJ1biBpdCBhZ2Fpbi4KCV9oYXNfZHluYW1pY19j aGlsZHJlbiA9IGZhbHNlOwoKCS8vIEFkZCBkeW5hbWljIGNoaWxkcmVuCglYTE9HX0FTU0VSVChn bG9iYWxfbmFtZSgpLnNpemUoKSA+IDApOwoJbWFwPHN0cmluZywgQ2xpQ29tbWFuZE1hdGNoPiBk eW5hbWljX2NoaWxkcmVuOwoJbWFwPHN0cmluZywgQ2xpQ29tbWFuZE1hdGNoPjo6aXRlcmF0b3Ig aXRlcjsKCWR5bmFtaWNfY2hpbGRyZW4gPSBfZHluYW1pY19jaGlsZHJlbl9jYWxsYmFjay0+ZGlz cGF0Y2goZ2xvYmFsX25hbWUoKSk7CglDbGlDb21tYW5kICpuZXdfY21kOwoJZm9yIChpdGVyID0g ZHluYW1pY19jaGlsZHJlbi5iZWdpbigpOwoJICAgICBpdGVyICE9IGR5bmFtaWNfY2hpbGRyZW4u ZW5kKCk7CgkgICAgICsraXRlcikgewoJICAgIGNvbnN0IENsaUNvbW1hbmRNYXRjaCYgY2NtID0g aXRlci0+c2Vjb25kOwoJICAgIGNvbnN0IHN0cmluZyYgY29tbWFuZF9uYW1lID0gY2NtLmNvbW1h bmRfbmFtZSgpOwoJICAgIGNvbnN0IHN0cmluZyYgaGVscF9zdHJpbmcgPSBjY20uaGVscF9zdHJp bmcoKTsKCSAgICBib29sIGlzX2V4ZWN1dGFibGUgPSBjY20uaXNfZXhlY3V0YWJsZSgpOwoJICAg IGJvb2wgY2FuX3BpcGUgPSBjY20uY2FuX3BpcGUoKTsKCSAgICBuZXdfY21kID0gYWRkX2NvbW1h bmQoY29tbWFuZF9uYW1lLCBoZWxwX3N0cmluZywgZmFsc2UpOwoJICAgIHN0cmluZyBjaGlsZF9u YW1lID0gZ2xvYmFsX25hbWUoKSArICIgIiArIGNvbW1hbmRfbmFtZTsKCSAgICBuZXdfY21kLT5z ZXRfZ2xvYmFsX25hbWUoY2hpbGRfbmFtZSk7CgkgICAgbmV3X2NtZC0+c2V0X2Nhbl9waXBlKGNh bl9waXBlKTsKCSAgICBuZXdfY21kLT5zZXRfdHlwZV9tYXRjaF9jYihjY20udHlwZV9tYXRjaF9j YigpKTsKCSAgICBuZXdfY21kLT5zZXRfZHluYW1pY19jaGlsZHJlbl9jYWxsYmFjayhfZHluYW1p Y19jaGlsZHJlbl9jYWxsYmFjayk7CgkgICAgbmV3X2NtZC0+c2V0X2R5bmFtaWNfcHJvY2Vzc19j YWxsYmFjayhfZHluYW1pY19wcm9jZXNzX2NhbGxiYWNrKTsKCSAgICBuZXdfY21kLT5zZXRfZHlu YW1pY19pbnRlcnJ1cHRfY2FsbGJhY2soX2R5bmFtaWNfaW50ZXJydXB0X2NhbGxiYWNrKTsKCSAg ICBpZiAoaXNfZXhlY3V0YWJsZSkgewoJCW5ld19jbWQtPnNldF9jbGlfcHJvY2Vzc19jYWxsYmFj ayhfZHluYW1pY19wcm9jZXNzX2NhbGxiYWNrKTsKCQluZXdfY21kLT5zZXRfY2xpX2ludGVycnVw dF9jYWxsYmFjayhfZHluYW1pY19pbnRlcnJ1cHRfY2FsbGJhY2spOwoJICAgIH0KCX0KICAgIH0K CiAgICByZXR1cm4gKF9jaGlsZF9jb21tYW5kX2xpc3QpOyAKfQo= --========GMXBoundary186531126179661-- From kristian@juniks.net Thu Sep 8 16:00:38 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Thu, 8 Sep 2005 17:00:38 +0200 Subject: WG: [Xorp-hackers] Bugzilla #161 In-Reply-To: <18653.1126179661@www83.gmx.net> References: <18653.1126179661@www83.gmx.net> Message-ID: <20050908150038.GC5707@juniks.net> On Thu, Sep 08, 2005 at 01:41:01PM +0200, "Patrick Preuß" wrote: > > --- Ursprüngliche Nachricht --- > > Von: 'Kristian Larsson' > > An: Patrick Preuss > > Kopie: xorp-hackers@xorp.org > > Betreff: Re: WG: [Xorp-hackers] Bugzilla #161 > > Datum: Wed, 7 Sep 2005 13:36:31 +0200 > > > > On Wed, Sep 07, 2005 at 12:05:35PM +0200, Patrick Preuss wrote: > > > Hello Kristian, > > > > > > > Sorry for dual posts here but I couldn't confirm > > > > this before as I did not have access to a xorp box > > > > When doing show route table ipv4 unicast final I > > > > see: > > > > Xorp> show route table ipv4 unicast final > > > > Network 10.0.0.0/24 > > > > Nexthop := 192.168.77.1 > > > > Metric := 0 Protocol := static Interface := eth0 Vif := eth0 > > > > Network 192.168.77.0/24 > > > > Nexthop := 192.168.77.90 > > > > Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 > > > > > > > > Isn't that information enough? > > > > > > Have used or for completing the line, I know there is a > > problem > > > with both in the current cvs, I've found the point for completion so > > far > > > It is in the cli_command.cc there are two entrys with for the > > I > > > have found the formatting line, for the not jet. > > > > gives me an extra blank line > > Xorp> show route table ipv4 unicast final ? > > Possible completions: > > <[Enter]> Execute this command > > > > brief Show IPv4 winning routes > > | Pipe through a command > > > > while is missing one : > > Xorp> show route table ipv4 unicast final > > `final' is ambiguous. > > Possible completions: > > <[Enter]> Execute this command brief Show IPv4 winning routes > > | Pipe through a command > > > > It seems that the missing blank line exist > > on every node that are both executable and > > have sub-nodes. > > > > Patrick, I checked the code regarding administrative > > distance and protocol. I now see what you mean and I > > agree that it's not a pretty solution. There should be > > something like origin: ospf.0 > > where ospf.0 would be your first ospf process. Later > > when we (cause we will :) ) support several routing > > processes it would just use a different number. > > Just my $0.02 > > > > Regards, > > Kristian > > > > Hello Kristian, > > can you try the attactched cli_command.cc should go the dir cli. i think no > it should work fine. Works! Good job. Should be included in the CVS! //Kristian From kristian@juniks.net Sat Sep 10 09:13:37 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 10 Sep 2005 10:13:37 +0200 Subject: [Xorp-hackers] Size of xorps binaries Message-ID: <20050910081337.GC6205@juniks.net> I just noticed after compiling xorp on my Linux laptop the size of the binaries are approximately twice that of the binaries compiled on a FreeBSD machine. Why is this? The xorpsh is just huge - 26MB! And the bgp process weighs in at a hefty 44MB. Could this also be the reason it takes ~30 seconds to start the fea, rib and an ospf process? IMHO that's a very long time. Anything that could be fixed or is it something you just have to accept? //Kristian From Mark Handley Sat Sep 10 14:56:32 2005 From: Mark Handley (Mark Handley) Date: Sat, 10 Sep 2005 14:56:32 +0100 Subject: [Xorp-hackers] Size of xorps binaries In-Reply-To: <20050910081337.GC6205@juniks.net> References: <20050910081337.GC6205@juniks.net> Message-ID: <84a612dd050910065618c33505@mail.gmail.com> ------=_Part_3266_2355960.1126360592582 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think for developers, it's something we probably have to accept. For=20 operational use, the first thing to do is build with the optimiser (to=20 improve speed not size), and strip the binaries (to improve size). This=20 makes a huge difference: echidna.cs.ucl.ac.uk : ls -l xorp_bgp=20 -rwxr-xr-x 1 mjh mjh 34545650 Jul 13 18:10 xorp_bgp echidna.cs.ucl.ac.uk : strip xorp_bgp=20 echidna.cs.ucl.ac.uk : ls -l xorp_bgp -rwxr-xr-x 1 mjh mjh 2840504 Sep 10 14:55 xorp_bgp We've discussed off-and-on over the years using shared libraries. So far,= =20 we've not taken the plunge - it makes some things more complex, but it woul= d=20 probably be essential if you wanted a relatively small memory footprint.=20 More non-embedded uses though, stripping the binaries seems to be=20 sufficient. - Mark On 9/10/05, Kristian Larsson wrote: >=20 > I just noticed after compiling xorp on my Linux > laptop the size of the binaries are approximately > twice that of the binaries compiled on a FreeBSD > machine. Why is this? > The xorpsh is just huge - 26MB! And the bgp > process weighs in at a hefty 44MB. >=20 > Could this also be the reason it takes ~30 seconds > to start the fea, rib and an ospf process? > IMHO that's a very long time. >=20 > Anything that could be fixed or is it something > you just have to accept? >=20 > //Kristian >=20 > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > ------=_Part_3266_2355960.1126360592582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think for developers, it's something we probably have to accept.  For operational use, the first thing to do is build with the optimiser (to improve speed not size), and strip the binaries (to improve size).  This makes a huge difference:

echidna.cs.ucl.ac.uk: ls -l xor= p_bgp
-rwxr-xr-x  1 mjh  mjh  34545650 Jul 13 18:10 xorp_bgp
echidna.cs.ucl.ac.uk: strip xor= p_bgp
echidna.cs.ucl.ac.uk: ls -l xor= p_bgp
-rwxr-xr-x  1 mjh  mjh  2840504 Sep 10 14:55 xorp_bgp


We've discussed off-and-on over the years using shared libraries.  So far, we've not taken the plunge - it makes some things more complex, but it would probably be essential if you wanted a relatively small memory footprint.  More non-embedded uses though, stripping the binaries seems to be sufficient.

 - Mark

On 9/10/05, Kristian Larsson <kristian@juniks.net> wrote:
I just noticed after compiling xorp on my Linux
laptop the size of the b= inaries are approximately
twice that of the binaries compiled on a FreeB= SD
machine. Why is this?
The xorpsh is just huge - 26MB! And the bgp
process weighs in at a hefty 44MB.

Could this also be the reason= it takes ~30 seconds
to start the fea, rib and an ospf process?
IMHO= that's a very long time.

Anything that could be fixed or is it some= thing
you just have to accept?

//Kristian

_____________________= __________________________
Xorp-hackers mailing list
Xorp-hackers@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

------=_Part_3266_2355960.1126360592582-- From atanu@ICSI.Berkeley.EDU Sat Sep 10 17:24:48 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 10 Sep 2005 09:24:48 -0700 Subject: [Xorp-hackers] Size of xorps binaries In-Reply-To: Message from Mark Handley of "Sat, 10 Sep 2005 14:56:32 BST." <84a612dd050910065618c33505@mail.gmail.com> Message-ID: <72079.1126369488@tigger.icir.org> We made an attempt to get shared libraries working last year. If I remember correctly we discovered that some of our code uses static initialization, which prevented the building of shared libraries. It looked like automake requires that all libraries are either shared or static, which meant we couldn't even move incrementally towards shared libraries. Atanu. >>>>> "Mark" == Mark Handley writes: Mark> I think for developers, it's something we probably have to accept.  For Mark> operational use, the first thing to do is build with the optimiser (to improve Mark> speed not size), and strip the binaries (to improve size).  This makes a huge Mark> difference: Mark> [[echidna.cs.ucl.ac.uk]]: ls -l xorp_bgp Mark> -rwxr-xr-x  1 mjh  mjh  34545650 Jul 13 18:10 xorp_bgp Mark> [[echidna.cs.ucl.ac.uk]]: strip xorp_bgp Mark> [[echidna.cs.ucl.ac.uk]]: ls -l xorp_bgp Mark> -rwxr-xr-x  1 mjh  mjh  2840504 Sep 10 14:55 xorp_bgp Mark> We've discussed off-and-on over the years using shared libraries.  So far, Mark> we've not taken the plunge - it makes some things more complex, but it would Mark> probably be essential if you wanted a relatively small memory footprint.  More Mark> non-embedded uses though, stripping the binaries seems to be sufficient. Mark>  - Mark Kristian> On 9/10/05, Kristian Larsson <[[kristian@juniks.net]]> wrote: Kristian> I just noticed after compiling xorp on my Linux Kristian> laptop the size of the binaries are approximately Kristian> twice that of the binaries compiled on a FreeBSD Kristian> machine. Why is this? Kristian> The xorpsh is just huge - 26MB! And the bgp Kristian> process weighs in at a hefty 44MB. Kristian> Could this also be the reason it takes ~30 seconds Kristian> to start the fea, rib and an ospf process? Kristian> IMHO that's a very long time. Kristian> Anything that could be fixed or is it something Kristian> you just have to accept? Kristian> //Kristian Kristian> _______________________________________________ Kristian> Xorp-hackers mailing list Kristian> [[Xorp-hackers@icir.org]] Kristian> [[http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers]] From imipak@yahoo.com Sun Sep 11 00:41:21 2005 From: imipak@yahoo.com (Jonathan Day) Date: Sat, 10 Sep 2005 16:41:21 -0700 (PDT) Subject: [Xorp-hackers] Re: Size of xorps binaries Message-ID: <20050910234121.95411.qmail@web31501.mail.mud.yahoo.com> That does seem excessively large. One person mentioned that automake doesn't support a mix of static and dynamic libraries, but if you have a lower-level automake for each library, and have them cascading, you should be able to get round that. Alternatively, don't link at all and use dlopen() to access the libraries on use. I believe this is how Apache handles DSO objects. Since Apache allows a mix of static and DSO objects, it may be possible to borrow ideas from their configuration code on how to mix-n-match. I'd also check the compiler version. If you're using GCC, the 4.x.y series is known to not optimize nearly as well as the later 3.x.y series. This'll be cured, but it's something to be aware of for right now. Also if you're using GCC, try using -O1 for your flags, then try -Os. After each case, strip the binaries. These use somewhat different optimizations and therefore the code size will likely differ between them. There is absolutely no way to be sure which will be the smaller, for any given program, in advance. You may also want to add -funit-at-a-time to that, as that optimizes over a larger segment of code at a time. If you know your configuration is going to be highly stable, you MAY (absolutely no guarantees on this) be able to eke out a little bit more by -fprofile-generate on the first compile. You then run the program (which will absolutely crawl!) to generate a profile of how the code flows. You then recompile using -fprofile-use, which uses the gathered data to make better choices on how the code should be optimized. If (and only if) you are compiling for an Intel processor, the Intel compiler may be a better bet, precisely because everything is static. (The Intel compiler can produce poorer code than GCC for AMD processors, won't work at all for non-ix86, and isn't guaranteed to produce code GCC will link with.) After all that, you will have one or more of the following: (a) have smaller code (b) have faster code (c) a PhD in Linux compilers Jonathan On 9/10/05, Kristian Larsson wrote: > > I just noticed after compiling xorp on my Linux > laptop the size of the binaries are approximately > twice that of the binaries compiled on a FreeBSD > machine. Why is this? > The xorpsh is just huge - 26MB! And the bgp > process weighs in at a hefty 44MB. > > Could this also be the reason it takes ~30 seconds > to start the fea, rib and an ospf process? > IMHO that's a very long time. > > Anything that could be fixed or is it something > you just have to accept? > > //Kristian > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From John.Weaver@motorola.com Mon Sep 12 17:32:43 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Mon, 12 Sep 2005 11:32:43 -0500 Subject: [Xorp-hackers] Size concerns Message-ID: <0DFC73466514D41186B700508B9510411C2262FA@tx14exm04.ftw.mot.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5B7B7.99E3FEA2 Content-Type: text/plain What is the smallest possible size that I could get to for just PIM and IGMP with the xorpsh? This would be the part that I need to put into the root file system. I would assume this is the 'make install' that I do? I took that directory in /usr/local/xorp and stripped everything. Without bgp and rip I am looking at 210MB, is this right? John ------_=_NextPart_001_01C5B7B7.99E3FEA2 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTUxNSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW PjxTUEFOIGNsYXNzPTc3NDUxMjcxNi0xMjA5MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5X aGF0IGlzIHRoZSBzbWFsbGVzdCANCnBvc3NpYmxlIHNpemUgdGhhdCBJIGNvdWxkIGdldCB0byBm b3IganVzdCBQSU0gYW5kIElHTVAgd2l0aCB0aGUgeG9ycHNoPyZuYnNwOyANClRoaXMgd291bGQg YmUgdGhlIHBhcnQgdGhhdCBJIG5lZWQgdG8gcHV0IGludG8gdGhlIHJvb3QgZmlsZSBzeXN0ZW0u Jm5ic3A7IEkgDQp3b3VsZCBhc3N1bWUgdGhpcyBpcyB0aGUgJ21ha2UgaW5zdGFsbCcgdGhhdCBJ IGRvPyZuYnNwOyBJIHRvb2sgdGhhdCBkaXJlY3RvcnkgDQppbiAvdXNyL2xvY2FsL3hvcnAgYW5k IHN0cmlwcGVkIGV2ZXJ5dGhpbmcuJm5ic3A7IFdpdGhvdXQgYmdwIGFuZCByaXAgSSBhbSANCmxv b2tpbmcgYXQgMjEwTUIsIGlzIHRoaXMgcmlnaHQ/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9Nzc0NTEyNzE2LTEyMDkyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzc0NTEyNzE2LTEy MDkyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9Nzc0NTEyNzE2LTEyMDkyMDA1PjxGT05UIGZhY2U9QXJpYWwg DQpzaXplPTI+Sm9objwvRk9OVD48L1NQQU4+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C5B7B7.99E3FEA2-- From kristian@juniks.net Mon Sep 12 19:27:14 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 12 Sep 2005 20:27:14 +0200 Subject: [Xorp-hackers] Size concerns In-Reply-To: <0DFC73466514D41186B700508B9510411C2262FA@tx14exm04.ftw.mot.com> References: <0DFC73466514D41186B700508B9510411C2262FA@tx14exm04.ftw.mot.com> Message-ID: <20050912182714.GD10482@juniks.net> On Mon, Sep 12, 2005 at 11:32:43AM -0500, Weaver John-JWEAVER1 wrote: > What is the smallest possible size that I could get to for just PIM and IGMP > with the xorpsh? This would be the part that I need to put into the root > file system. I would assume this is the 'make install' that I do? I took > that directory in /usr/local/xorp and stripped everything. Without bgp and > rip I am looking at 210MB, is this right? I just noticed this a little while ago (see my thread last weekish something). Anyway try to strip your binaries; bash; cd /usr/local/xorp/; for xfile in `find . -perm 755`; do strip $xfile; done The usual disclaimer goes for the above.. ;) You should end up with 10% of the original file size. To get even lower you have to do more magic - read the other thread :) Regards, Kristian From John.Weaver@motorola.com Mon Sep 12 19:38:11 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Mon, 12 Sep 2005 13:38:11 -0500 Subject: [Xorp-hackers] Size concerns Message-ID: <0DFC73466514D41186B700508B9510411C2AB10C@tx14exm04.ftw.mot.com> 10% is not going to help out a lot unless my 210MB was wrong. I cannot deal with an executable to put in the root file system that is over 5MB. -----Original Message----- From: Kristian Larsson [mailto:kristian@juniks.net] Sent: Monday, September 12, 2005 1:27 PM To: Weaver John-JWEAVER1 Cc: xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] Size concerns On Mon, Sep 12, 2005 at 11:32:43AM -0500, Weaver John-JWEAVER1 wrote: > What is the smallest possible size that I could get to for just PIM > and IGMP with the xorpsh? This would be the part that I need to put > into the root file system. I would assume this is the 'make install' > that I do? I took that directory in /usr/local/xorp and stripped > everything. Without bgp and rip I am looking at 210MB, is this right? I just noticed this a little while ago (see my thread last weekish something). Anyway try to strip your binaries; bash; cd /usr/local/xorp/; for xfile in `find . -perm 755`; do strip $xfile; done The usual disclaimer goes for the above.. ;) You should end up with 10% of the original file size. To get even lower you have to do more magic - read the other thread :) Regards, Kristian From bms@spc.org Mon Sep 12 19:46:28 2005 From: bms@spc.org (Bruce M Simpson) Date: Mon, 12 Sep 2005 19:46:28 +0100 Subject: [Xorp-hackers] Size concerns In-Reply-To: <0DFC73466514D41186B700508B9510411C2AB10C@tx14exm04.ftw.mot.com> References: <0DFC73466514D41186B700508B9510411C2AB10C@tx14exm04.ftw.mot.com> Message-ID: <20050912184628.GC893@empiric.icir.org> On Mon, Sep 12, 2005 at 01:38:11PM -0500, Weaver John-JWEAVER1 wrote: > 10% is not going to help out a lot unless my 210MB was wrong. I cannot deal > with an executable to put in the root file system that is over 5MB. It would be nice to make the automake and libtool headache go away. My suggestions would be to explore the use of alternative build tools. I would recommend Perforce Software's 'jam' as a starting point. There is an open source project which is cross-platform (Win32 and UNIXen) build with it; gpstk, a toolkit for dealing with realtime GPS data and calculations. But of course the bigger problem, of static C++ constructors, has to be dealt with somehow before shared libraries can be used for the bulk of XORP's code base. BMS From atanu@ICSI.Berkeley.EDU Mon Sep 12 19:55:28 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 12 Sep 2005 11:55:28 -0700 Subject: [Xorp-hackers] Size concerns In-Reply-To: Message from Weaver John-JWEAVER1 of "Mon, 12 Sep 2005 13:38:11 CDT." <0DFC73466514D41186B700508B9510411C2AB10C@tx14exm04.ftw.mot.com> Message-ID: <98179.1126551328@tigger.icir.org> Hi, I installed xorp on a FreeBSD 4.10 using gcc version 2.95.4. I then stripped all the executables. I then removed some old core files from /usr/local/xorp/bin. $ du -sh /usr/local/xorp 50M /usr/local/xorp No single binary is larger than 2M. Atanu. >>>>> "Weaver" == Weaver John writes: Weaver> 10% is not going to help out a lot unless my 210MB was Weaver> wrong. I cannot deal with an executable to put in the root Weaver> file system that is over 5MB. Weaver> -----Original Message----- From: Kristian Larsson Weaver> [mailto:kristian@juniks.net] Sent: Monday, September 12, Weaver> 2005 1:27 PM To: Weaver John-JWEAVER1 Cc: Weaver> xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] Size Weaver> concerns Weaver> On Mon, Sep 12, 2005 at 11:32:43AM -0500, Weaver Weaver> John-JWEAVER1 wrote: >> What is the smallest possible size that I could get to for just >> PIM and IGMP with the xorpsh? This would be the part that I need >> to put into the root file system. I would assume this is the >> 'make install' that I do? I took that directory in >> /usr/local/xorp and stripped everything. Without bgp and rip I >> am looking at 210MB, is this right? Weaver> I just noticed this a little while ago (see my thread last Weaver> weekish something). Anyway try to strip your binaries; Weaver> bash; cd /usr/local/xorp/; for xfile in `find . -perm 755`; Weaver> do strip $xfile; done The usual disclaimer goes for the Weaver> above.. ;) Weaver> You should end up with 10% of the original file size. To get Weaver> even lower you have to do more magic - read the other thread Weaver> :) Weaver> Regards, Kristian Weaver> _______________________________________________ Xorp-hackers Weaver> mailing list Xorp-hackers@icir.org Weaver> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian@juniks.net Mon Sep 12 20:20:25 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 12 Sep 2005 21:20:25 +0200 Subject: [Xorp-hackers] Size concerns In-Reply-To: <98179.1126551328@tigger.icir.org> References: <0DFC73466514D41186B700508B9510411C2AB10C@tx14exm04.ftw.mot.com> <98179.1126551328@tigger.icir.org> Message-ID: <20050912192025.GF10482@juniks.net> Gentoo Linux 2.6.12-r4 gcc 3.3.5-20050130 floffy local # du -sh xorp 631M xorp floffy local # du -sh xorp 38M xorp still, as John says, it's not of much use on an embedded system where you have only a few meggs of available space. //Kristian On Mon, Sep 12, 2005 at 11:55:28AM -0700, Atanu Ghosh wrote: > Hi, > > I installed xorp on a FreeBSD 4.10 using gcc version 2.95.4. I then stripped > all the executables. I then removed some old core files from > /usr/local/xorp/bin. > > $ du -sh /usr/local/xorp > 50M /usr/local/xorp > > No single binary is larger than 2M. > > Atanu. > > >>>>> "Weaver" == Weaver John writes: > > Weaver> 10% is not going to help out a lot unless my 210MB was > Weaver> wrong. I cannot deal with an executable to put in the root > Weaver> file system that is over 5MB. > > Weaver> -----Original Message----- From: Kristian Larsson > Weaver> [mailto:kristian@juniks.net] Sent: Monday, September 12, > Weaver> 2005 1:27 PM To: Weaver John-JWEAVER1 Cc: > Weaver> xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] Size > Weaver> concerns > > Weaver> On Mon, Sep 12, 2005 at 11:32:43AM -0500, Weaver > Weaver> John-JWEAVER1 wrote: > >> What is the smallest possible size that I could get to for just > >> PIM and IGMP with the xorpsh? This would be the part that I need > >> to put into the root file system. I would assume this is the > >> 'make install' that I do? I took that directory in > >> /usr/local/xorp and stripped everything. Without bgp and rip I > >> am looking at 210MB, is this right? > > Weaver> I just noticed this a little while ago (see my thread last > Weaver> weekish something). Anyway try to strip your binaries; > Weaver> bash; cd /usr/local/xorp/; for xfile in `find . -perm 755`; > Weaver> do strip $xfile; done The usual disclaimer goes for the > Weaver> above.. ;) > > Weaver> You should end up with 10% of the original file size. To get > Weaver> even lower you have to do more magic - read the other thread > Weaver> :) > > Weaver> Regards, Kristian > Weaver> _______________________________________________ Xorp-hackers > Weaver> mailing list Xorp-hackers@icir.org > Weaver> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From John.Weaver@motorola.com Tue Sep 13 21:46:55 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Tue, 13 Sep 2005 15:46:55 -0500 Subject: [Xorp-hackers] FW: boot.config problems? Message-ID: <0DFC73466514D41186B700508B9510411C2FAB3D@tx14exm04.ftw.mot.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C5B8A4.46F4FC58 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B8A4.46F4FC58" ------_=_NextPart_001_01C5B8A4.46F4FC58 Content-Type: text/plain I am having problems getting XORP starting up. I think it may be my boot.config? I have 2 interfaces (eth1 and eth2) and am only running PIM and IGMP on those interfaces. I am trying to use the default system config. Is there any debug I can turn on when I try and launch the xorp_rtmgr? Can anyone take a look at this file and let me know if I messed it up? The system I am running it on is kind of like a Power Mac. It is running Yellow Dog on a PPC 750. Everything built fine and the make test passed except for rip as you may remember. Thanks, John ------_=_NextPart_001_01C5B8A4.46F4FC58 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTUxNSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g DQpjbGFzcz02MzUxNzA3MjEtMDgwOTIwMDU+PC9TUEFOPjwvRk9OVD48L0RJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTYzNTE3MDcyMS0wODA5MjAwNT4gSSBhbSBoYXZp bmcgcHJvYmxlbXMgZ2V0dGluZyBYT1JQIHN0YXJ0aW5nIHVwLiZuYnNwOyBJIA0KdGhpbmsgaXQg bWF5IGJlIG15IGJvb3QuY29uZmlnPyZuYnNwOyBJIGhhdmUgMiBpbnRlcmZhY2VzIChldGgxIGFu ZCBldGgyKSBhbmQgYW0gDQpvbmx5IHJ1bm5pbmcgUElNIGFuZCBJR01QIG9uIHRob3NlIGludGVy ZmFjZXMuJm5ic3A7IEkgYW0gdHJ5aW5nIHRvIHVzZSB0aGUgDQpkZWZhdWx0IHN5c3RlbSBjb25m aWcuJm5ic3A7IElzIHRoZXJlIGFueSBkZWJ1ZyBJIGNhbiB0dXJuIG9uIHdoZW4gSSB0cnkgYW5k IA0KbGF1bmNoIHRoZSB4b3JwX3J0bWdyPyZuYnNwOyBDYW4mbmJzcDs8U1BBTiBjbGFzcz02OTUz OTQ1MjAtMTMwOTIwMDU+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPmFueW9uZTwvRk9OVD48L1NQQU4+ IHRha2UgYSBsb29rIGF0IHRoaXMgZmlsZSBhbmQgbGV0IG1lIGtub3cgaWYgSSANCm1lc3NlZCBp dCB1cD8mbmJzcDsgVGhlIHN5c3RlbSBJIGFtIHJ1bm5pbmcgaXQgb24gaXMga2luZCBvZiBsaWtl IGEgUG93ZXIgDQpNYWMuJm5ic3A7IEl0IGlzIHJ1bm5pbmcgWWVsbG93IERvZyBvbiBhIFBQQyA3 NTAuJm5ic3A7IEV2ZXJ5dGhpbmcgYnVpbHQgZmluZSANCmFuZCB0aGUgbWFrZSB0ZXN0IHBhc3Nl ZCBleGNlcHQgZm9yIHJpcCBhcyB5b3UgbWF5IHJlbWVtYmVyLjwvU1BBTj48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NjM1MTcwNzIxLTA4 MDkyMDA1PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPjxTUEFOIA0KY2xhc3M9NjM1MTcwNzIxLTA4MDkyMDA1PlRoYW5rcyw8L1NQQU4+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTYz NTE3MDcyMS0wODA5MjAwNT5Kb2huPC9TUEFOPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C5B8A4.46F4FC58-- ------_=_NextPart_000_01C5B8A4.46F4FC58 Content-Type: application/octet-stream; name="boot.config" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="boot.config" aW50ZXJmYWNlcyB7CiAgICBpbnRlcmZhY2UgZXRoMSB7CglkZXNjcmlwdGlvbjogImRhdGEgaW50 ZXJmYWNlIgoJZGlzYWJsZTogZmFsc2UKCWRlZmF1bHQtc3lzdGVtLWNvbmZpZwogICAgfQogICAg aW50ZXJmYWNlIGV0aDIgewoJZGVzY3JpcHRpb246ICJkYXRhIGludGVyZmFjZSIKCWRpc2FibGU6 IGZhbHNlCglkZWZhdWx0LXN5c3RlbS1jb25maWcKICAgIH0KCiAgICBpbnRlcmZhY2UgZGlzY2Fy ZDAgewoJZGVzY3JpcHRpb246ICJkaXNjYXJkIGludGVyZmFjZSIKCWRpc2FibGU6IGZhbHNlCglk aXNjYXJkOiB0cnVlCgl2aWYgZGlzY2FyZDAgewoJICAgIGRpc2FibGU6IGZhbHNlCgkgICAgYWRk cmVzcyAxMjcuMTI3LjAuMSB7CgkJcHJlZml4LWxlbmd0aDogMzIKCQlkaXNhYmxlOiBmYWxzZQoJ ICAgIH0KCX0KICAgIH0KfQoKZmVhIHsKICAgIHVuaWNhc3QtZm9yd2FyZGluZzQgewoJZGlzYWJs ZTogZmFsc2UKICAgIH0KCn0KCnBsdW1iaW5nIHsKICAgIG1mZWE0IHsKCWRpc2FibGU6IGZhbHNl CglpbnRlcmZhY2UgZXRoMSB7CgkgICAgdmlmIGV0aDEgewoJCWRpc2FibGU6IGZhbHNlCgkgICAg fQoJfQogICAgICAgIGludGVyZmFjZSBldGgyIHsKICAgICAgICAgICAgdmlmIGV0aDIgewogICAg ICAgICAgICBkaXNhYmxlOiBmYWxzZQogICAgICAgICAgICB9CiAgICAgICAgfQoJaW50ZXJmYWNl IHJlZ2lzdGVyX3ZpZiB7CgkgICAgdmlmIHJlZ2lzdGVyX3ZpZiB7CgkJLyogTm90ZTogdGhpcyB2 aWYgc2hvdWxkIGJlIGFsd2F5cyBlbmFibGVkICovCiAgICAgICAgCWRpc2FibGU6IGZhbHNlCgkg ICAgfQoJfQoJdHJhY2VvcHRpb25zIHsKCSAgICBmbGFnIGFsbCB7CgkJZGlzYWJsZTogZmFsc2UK CSAgICB9Cgl9CiAgICB9Cgp9Cgpwcm90b2NvbHMgewogICAgaWdtcCB7CglkaXNhYmxlOiBmYWxz ZQoJaW50ZXJmYWNlIGV0aDEgewoJICAgIHZpZiBldGgxIHsKCQlkaXNhYmxlOiBmYWxzZQoJICAg IH0KCX0KICAgICAgICBpbnRlcmZhY2UgZXRoMiB7CiAgICAgICAgICAgIHZpZiBldGgyIHsKICAg ICAgICAgICAgICAgIGRpc2FibGU6IGZhbHNlCiAgICAgICAgICAgIH0KICAgICAgICB9Cgl0cmFj ZW9wdGlvbnMgewoJICAgIGZsYWcgYWxsIHsKCQlkaXNhYmxlOiBmYWxzZQoJICAgIH0KCX0KICAg IH0KfQoKcHJvdG9jb2xzIHsKICAgIHBpbXNtNCB7CglkaXNhYmxlOiBmYWxzZQoJaW50ZXJmYWNl IGV0aDEgewoJICAgIHZpZiBldGgxIHsKCQlkaXNhYmxlOiBmYWxzZQoJICAgIH0KCX0KICAgICAg ICBpbnRlcmZhY2UgZXRoMiB7CiAgICAgICAgICAgIHZpZiBldGgyIHsKICAgICAgICAgICAgICAg IGRpc2FibGU6IGZhbHNlCiAgICAgICAgICAgIH0KICAgICAgICB9CglpbnRlcmZhY2UgcmVnaXN0 ZXJfdmlmIHsKCSAgICB2aWYgcmVnaXN0ZXJfdmlmIHsKCQkvKiBOb3RlOiB0aGlzIHZpZiBzaG91 bGQgYmUgYWx3YXlzIGVuYWJsZWQgKi8KCQlkaXNhYmxlOiBmYWxzZQoJICAgIH0KCX0KCglib290 c3RyYXAgewoJICAgIGRpc2FibGU6IHRydWUKICAgICAgICBjYW5kLWJzciB7CiAgICAgICAgICAg IHNjb3BlLXpvbmUgMjI0LjAuMC4wLzQgewogICAgICAgICAgICAgICAgaXMtc2NvcGUtem9uZTog ZmFsc2UKICAgICAgICAgICAgICAgIGNhbmQtYnNyLWJ5LXZpZi1uYW1lOiAiZXRoMSIKICAgICAg ICAgICAgICAgIH0KICAgICAgICB9CgoJfQoKCXN3aXRjaC10by1zcHQtdGhyZXNob2xkIHsKCSAg ICAvKiBhcHByb3guIDFLIGJ5dGVzL3MgKDEwS2JwcykgdGhyZXNob2xkICovCgkgICAgZGlzYWJs ZTogZmFsc2UKCSAgICBpbnRlcnZhbC1zZWM6IDEwMAoJICAgIGJ5dGVzOiAxMDI0MDAKCX0KCgl0 cmFjZW9wdGlvbnMgewoJICAgIGZsYWcgYWxsIHsKCQlkaXNhYmxlOiBmYWxzZQoJICAgIH0KCX0K ICAgIH0KCn0KCi8qCiAqIE5vdGU6IGZpYjJtcmliIGlzIG5lZWRlZCBmb3IgbXVsdGljYXN0IG9u bHkgaWYgdGhlIHVuaWNhc3QgcHJvdG9jb2xzCiAqIGRvbid0IHBvcHVsYXRlIHRoZSBNUklCIHdp dGggbXVsdGljYXN0LXNwZWNpZmljIHJvdXRlcy4KICovCnByb3RvY29scyB7CiAgICBmaWIybXJp YiB7CglkaXNhYmxlOiBmYWxzZQogICAgfQp9Cg== ------_=_NextPart_000_01C5B8A4.46F4FC58-- From kristian@juniks.net Tue Sep 13 22:06:40 2005 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 13 Sep 2005 23:06:40 +0200 Subject: [Xorp-hackers] FW: boot.config problems? In-Reply-To: <0DFC73466514D41186B700508B9510411C2FAB3D@tx14exm04.ftw.mot.com> References: <0DFC73466514D41186B700508B9510411C2FAB3D@tx14exm04.ftw.mot.com> Message-ID: <20050913210640.GA21530@juniks.net> You're config file is not named boot.config but rather config.boot and placed in /usr/local/xorp/config.boot, right? Try starting up with -v, you should get some error message. Have you actually used this configuration or is it written by hand? It doesn't contain a xorp header which makes me wonder... You could start xorp and then add little chunks of the config and the commiting to make sure the whole conf is alright. Regards, Kristian On Tue, Sep 13, 2005 at 03:46:55PM -0500, Weaver John-JWEAVER1 wrote: > I am having problems getting XORP starting up. I think it may be my > boot.config? I have 2 interfaces (eth1 and eth2) and am only running PIM > and IGMP on those interfaces. I am trying to use the default system config. > Is there any debug I can turn on when I try and launch the xorp_rtmgr? Can > anyone take a look at this file and let me know if I messed it up? The > system I am running it on is kind of like a Power Mac. It is running Yellow > Dog on a PPC 750. Everything built fine and the make test passed except for > rip as you may remember. > > Thanks, > John From atanu@ICSI.Berkeley.EDU Tue Sep 13 22:09:34 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 13 Sep 2005 14:09:34 -0700 Subject: [Xorp-hackers] FW: boot.config problems? In-Reply-To: Message from Weaver John-JWEAVER1 of "Tue, 13 Sep 2005 15:46:55 CDT." <0DFC73466514D41186B700508B9510411C2FAB3D@tx14exm04.ftw.mot.com> Message-ID: <28586.1126645774@tigger.icir.org> Hi, I took your config file changed eth1 to fxp0 and eth2 to fxp1 on a FreeBSD system and it seemed to run okay. You did start the router manager as root? The "-v" flag to the router manager generates extra debugging. Atanu. >>>>> "Weaver" == Weaver John writes: Weaver> I am having problems getting XORP starting up.  I think it Weaver> may be my boot.config?  I have 2 interfaces (eth1 and eth2) Weaver> and am only running PIM and IGMP on those interfaces.  I am Weaver> trying to use the default system config.  Is there any debug Weaver> I can turn on when I try and launch the xorp_rtmgr?  Weaver> Can anyone take a look at this file and let me know if I Weaver> messed it up?  The system I am running it on is kind of like Weaver> a Power Mac.  It is running Yellow Dog on a PPC 750.  Weaver> Everything built fine and the make test passed except for Weaver> rip as you may remember. Weaver>   Weaver> Thanks, Weaver> John From John.Weaver@motorola.com Tue Sep 13 22:10:56 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Tue, 13 Sep 2005 16:10:56 -0500 Subject: [Xorp-hackers] FW: boot.config problems? Message-ID: <0DFC73466514D41186B700508B9510411C2FABFF@tx14exm04.ftw.mot.com> Someone else changed the name of it and moved it. I am pretty sure it was modified from the original config.boot. I ripped out all the irrelevant stuff for simplicity. I used the -b command to specify this file so hopefully it was picking this one up? When I boot with the -v, can I use -vb or -v -b? John -----Original Message----- From: Kristian Larsson [mailto:kristian@juniks.net] Sent: Tuesday, September 13, 2005 4:07 PM To: Weaver John-JWEAVER1 Cc: xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] FW: boot.config problems? You're config file is not named boot.config but rather config.boot and placed in /usr/local/xorp/config.boot, right? Try starting up with -v, you should get some error message. Have you actually used this configuration or is it written by hand? It doesn't contain a xorp header which makes me wonder... You could start xorp and then add little chunks of the config and the commiting to make sure the whole conf is alright. Regards, Kristian On Tue, Sep 13, 2005 at 03:46:55PM -0500, Weaver John-JWEAVER1 wrote: > I am having problems getting XORP starting up. I think it may be my > boot.config? I have 2 interfaces (eth1 and eth2) and am only running > PIM and IGMP on those interfaces. I am trying to use the default system config. > Is there any debug I can turn on when I try and launch the xorp_rtmgr? > Can anyone take a look at this file and let me know if I messed it up? > The system I am running it on is kind of like a Power Mac. It is > running Yellow Dog on a PPC 750. Everything built fine and the make > test passed except for rip as you may remember. > > Thanks, > John From John.Weaver@motorola.com Tue Sep 13 22:19:39 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Tue, 13 Sep 2005 16:19:39 -0500 Subject: [Xorp-hackers] FW: boot.config problems? Message-ID: <0DFC73466514D41186B700508B9510411C2FAC42@tx14exm04.ftw.mot.com> Yes I am starting it as root. I am at /usr/local/xorp with the config.boot. When I try the xorp_rtrmgr -v it is just hanging? John -----Original Message----- From: atanu@icir.org [mailto:atanu@icir.org] On Behalf Of Atanu Ghosh Sent: Tuesday, September 13, 2005 4:10 PM To: Weaver John-JWEAVER1 Cc: xorp-users@xorp.org; xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] FW: boot.config problems? Hi, I took your config file changed eth1 to fxp0 and eth2 to fxp1 on a FreeBSD system and it seemed to run okay. You did start the router manager as root? The "-v" flag to the router manager generates extra debugging. Atanu. >>>>> "Weaver" == Weaver John writes: Weaver> I am having problems getting XORP starting up.  I think it Weaver> may be my boot.config?  I have 2 interfaces (eth1 and eth2) Weaver> and am only running PIM and IGMP on those interfaces.  I am Weaver> trying to use the default system config.  Is there any debug Weaver> I can turn on when I try and launch the xorp_rtmgr?  Weaver> Can anyone take a look at this file and let me know if I Weaver> messed it up?  The system I am running it on is kind of like Weaver> a Power Mac.  It is running Yellow Dog on a PPC 750.  Weaver> Everything built fine and the make test passed except for Weaver> rip as you may remember. Weaver>   Weaver> Thanks, Weaver> John From kristian@juniks.net Wed Sep 14 06:35:09 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 14 Sep 2005 07:35:09 +0200 Subject: [Xorp-hackers] FW: boot.config problems? In-Reply-To: <0DFC73466514D41186B700508B9510411C2FAD4E@tx14exm04.ftw.mot.com> References: <0DFC73466514D41186B700508B9510411C2FAD4E@tx14exm04.ftw.mot.com> Message-ID: <20050914053509.GC21530@juniks.net> Hmm, it's possible I suppose, but I've had no such problems so far... Have you tried with a non-stripped version? I think you can tell strip to be more careful when removing stuff, but then the binaries won't shrink as much... //Kristian On Tue, Sep 13, 2005 at 04:55:10PM -0500, Weaver John-JWEAVER1 wrote: > I wonder if stripping the whole structure has hosed it? > > -----Original Message----- > From: Kristian Larsson [mailto:kristian@juniks.net] > Sent: Tuesday, September 13, 2005 4:29 PM > To: Weaver John-JWEAVER1 > Subject: Re: [Xorp-hackers] FW: boot.config problems? > > I'm not in front of a xorp router right now so I can't test the config but > since Atanu did that I'm sure it's okey. > > xorp_rtrmgr -v -b should work > > But you're saying it's just hanging!? When does this happen? When using -v > in conjuction with this configuration file? Just using -v? As long as you > are using this config.boot? > > If it's just when using the particular config you should try loading parts > of it. > > Kristian > > On Tue, Sep 13, 2005 at 04:10:56PM -0500, Weaver John-JWEAVER1 wrote: > > Someone else changed the name of it and moved it. I am pretty sure it > > was modified from the original config.boot. I ripped out all the > > irrelevant stuff for simplicity. I used the -b command to specify > > this file so hopefully it was picking this one up? When I boot with > > the -v, can I use -vb or -v -b? > > > > John > > > > -----Original Message----- > > From: Kristian Larsson [mailto:kristian@juniks.net] > > Sent: Tuesday, September 13, 2005 4:07 PM > > To: Weaver John-JWEAVER1 > > Cc: xorp-hackers@xorp.org > > Subject: Re: [Xorp-hackers] FW: boot.config problems? > > > > You're config file is not named boot.config but rather config.boot and > > placed in /usr/local/xorp/config.boot, right? > > > > Try starting up with -v, you should get some error message. > > > > Have you actually used this configuration or is it written by hand? > > It doesn't contain a xorp header which makes me wonder... > > You could start xorp and then add little chunks of the config and the > > commiting to make sure the whole conf is alright. > > > > Regards, > > Kristian > > > > On Tue, Sep 13, 2005 at 03:46:55PM -0500, Weaver John-JWEAVER1 wrote: > > > I am having problems getting XORP starting up. I think it may be my > > > boot.config? I have 2 interfaces (eth1 and eth2) and am only > > > running PIM and IGMP on those interfaces. I am trying to use the > > > default system > > config. > > > Is there any debug I can turn on when I try and launch the xorp_rtmgr? > > > Can anyone take a look at this file and let me know if I messed it up? > > > The system I am running it on is kind of like a Power Mac. It is > > > running Yellow Dog on a PPC 750. Everything built fine and the make > > > test passed except for rip as you may remember. > > > > > > Thanks, > > > John > > From John.Weaver@motorola.com Wed Sep 14 16:40:58 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Wed, 14 Sep 2005 10:40:58 -0500 Subject: [Xorp-hackers] FW: boot.config problems? Message-ID: <0DFC73466514D41186B700508B9510411C34B427@tx14exm04.ftw.mot.com> Just tried the non-stripped version and I get the same thing. I launched it with the -v and still get nothing to print. Has any one ever tried this on the PPC? I am using gcc 3.3.3, autoconf 2.59, and automake 1.8.3. John -----Original Message----- From: Kristian Larsson [mailto:kristian@juniks.net] Sent: Wednesday, September 14, 2005 12:35 AM To: Weaver John-JWEAVER1 Cc: xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] FW: boot.config problems? Hmm, it's possible I suppose, but I've had no such problems so far... Have you tried with a non-stripped version? I think you can tell strip to be more careful when removing stuff, but then the binaries won't shrink as much... //Kristian On Tue, Sep 13, 2005 at 04:55:10PM -0500, Weaver John-JWEAVER1 wrote: > I wonder if stripping the whole structure has hosed it? > > -----Original Message----- > From: Kristian Larsson [mailto:kristian@juniks.net] > Sent: Tuesday, September 13, 2005 4:29 PM > To: Weaver John-JWEAVER1 > Subject: Re: [Xorp-hackers] FW: boot.config problems? > > I'm not in front of a xorp router right now so I can't test the config > but since Atanu did that I'm sure it's okey. > > xorp_rtrmgr -v -b should work > > But you're saying it's just hanging!? When does this happen? When > using -v in conjuction with this configuration file? Just using -v? As > long as you are using this config.boot? > > If it's just when using the particular config you should try loading > parts of it. > > Kristian > > On Tue, Sep 13, 2005 at 04:10:56PM -0500, Weaver John-JWEAVER1 wrote: > > Someone else changed the name of it and moved it. I am pretty sure > > it was modified from the original config.boot. I ripped out all the > > irrelevant stuff for simplicity. I used the -b command to specify > > this file so hopefully it was picking this one up? When I boot with > > the -v, can I use -vb or -v -b? > > > > John > > > > -----Original Message----- > > From: Kristian Larsson [mailto:kristian@juniks.net] > > Sent: Tuesday, September 13, 2005 4:07 PM > > To: Weaver John-JWEAVER1 > > Cc: xorp-hackers@xorp.org > > Subject: Re: [Xorp-hackers] FW: boot.config problems? > > > > You're config file is not named boot.config but rather config.boot > > and placed in /usr/local/xorp/config.boot, right? > > > > Try starting up with -v, you should get some error message. > > > > Have you actually used this configuration or is it written by hand? > > It doesn't contain a xorp header which makes me wonder... > > You could start xorp and then add little chunks of the config and > > the commiting to make sure the whole conf is alright. > > > > Regards, > > Kristian > > > > On Tue, Sep 13, 2005 at 03:46:55PM -0500, Weaver John-JWEAVER1 wrote: > > > I am having problems getting XORP starting up. I think it may be > > > my boot.config? I have 2 interfaces (eth1 and eth2) and am only > > > running PIM and IGMP on those interfaces. I am trying to use the > > > default system > > config. > > > Is there any debug I can turn on when I try and launch the xorp_rtmgr? > > > Can anyone take a look at this file and let me know if I messed it up? > > > The system I am running it on is kind of like a Power Mac. It is > > > running Yellow Dog on a PPC 750. Everything built fine and the > > > make test passed except for rip as you may remember. > > > > > > Thanks, > > > John > > From atanu@ICSI.Berkeley.EDU Fri Sep 16 02:12:27 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 15 Sep 2005 18:12:27 -0700 Subject: [Xorp-hackers] FW: boot.config problems? In-Reply-To: Message from Weaver John-JWEAVER1 of "Wed, 14 Sep 2005 10:40:58 CDT." <0DFC73466514D41186B700508B9510411C34B427@tx14exm04.ftw.mot.com> Message-ID: <84536.1126833147@tigger.icir.org> Hi, We have tested XORP on Linux 2.4 and 2.6 kernels and it seem to work on a Powerbook G4. We haven't tried your particular combination. Its very odd that the router manager doen't print anything. Even without the "-v" flag it should print something. Atanu. >>>>> "Weaver" == Weaver John writes: Weaver> Just tried the non-stripped version and I get the same Weaver> thing. I launched it with the -v and still get nothing to Weaver> print. Has any one ever tried this on the PPC? I am using Weaver> gcc 3.3.3, autoconf 2.59, and automake 1.8.3. Weaver> John Weaver> -----Original Message----- From: Kristian Larsson Weaver> [mailto:kristian@juniks.net] Sent: Wednesday, September 14, Weaver> 2005 12:35 AM To: Weaver John-JWEAVER1 Cc: Weaver> xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] FW: Weaver> boot.config problems? Weaver> Hmm, it's possible I suppose, but I've had no such problems Weaver> so far... Weaver> Have you tried with a non-stripped version? Weaver> I think you can tell strip to be more careful when removing Weaver> stuff, but then the binaries won't shrink as much... Weaver> //Kristian Weaver> On Tue, Sep 13, 2005 at 04:55:10PM -0500, Weaver Weaver> John-JWEAVER1 wrote: >> I wonder if stripping the whole structure has hosed it? >> >> -----Original Message----- From: Kristian Larsson >> [mailto:kristian@juniks.net] Sent: Tuesday, September 13, 2005 >> 4:29 PM To: Weaver John-JWEAVER1 Subject: Re: [Xorp-hackers] FW: >> boot.config problems? >> >> I'm not in front of a xorp router right now so I can't test the >> config but since Atanu did that I'm sure it's okey. >> >> xorp_rtrmgr -v -b should work >> >> But you're saying it's just hanging!? When does this happen? When >> using -v in conjuction with this configuration file? Just using >> -v? As long as you are using this config.boot? >> >> If it's just when using the particular config you should try >> loading parts of it. >> >> Kristian >> >> On Tue, Sep 13, 2005 at 04:10:56PM -0500, Weaver John-JWEAVER1 >> wrote: > Someone else changed the name of it and moved it. I am >> pretty sure > it was modified from the original config.boot. I >> ripped out all the > irrelevant stuff for simplicity. I used the >> -b command to specify > this file so hopefully it was picking >> this one up? When I boot with > the -v, can I use -vb or -v -b? >> > >> > John >> > >> > -----Original Message----- > From: Kristian Larsson >> [mailto:kristian@juniks.net] > Sent: Tuesday, September 13, 2005 >> 4:07 PM > To: Weaver John-JWEAVER1 > Cc: xorp-hackers@xorp.org > >> Subject: Re: [Xorp-hackers] FW: boot.config problems? >> > >> > You're config file is not named boot.config but rather >> config.boot > and placed in /usr/local/xorp/config.boot, right? >> > >> > Try starting up with -v, you should get some error message. >> > >> > Have you actually used this configuration or is it written by >> hand? > It doesn't contain a xorp header which makes me >> wonder... > You could start xorp and then add little chunks of >> the config and > the commiting to make sure the whole conf is >> alright. >> > >> > Regards, > Kristian >> > >> > On Tue, Sep 13, 2005 at 03:46:55PM -0500, Weaver John-JWEAVER1 >> wrote: > > I am having problems getting XORP starting up. I >> think it may be > > my boot.config? I have 2 interfaces (eth1 >> and eth2) and am only > > running PIM and IGMP on those >> interfaces. I am trying to use the > > default system > config. >> > > Is there any debug I can turn on when I try and launch the >> xorp_rtmgr? >> > > Can anyone take a look at this file and let me know if I >> messed it up? >> > > The system I am running it on is kind of like a Power Mac. >> It is > > running Yellow Dog on a PPC 750. Everything built fine >> and the > > make test passed except for rip as you may remember. >> > > >> > > Thanks, > > John >> > Weaver> _______________________________________________ Xorp-hackers Weaver> mailing list Xorp-hackers@icir.org Weaver> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu@ICSI.Berkeley.EDU Fri Sep 16 02:16:04 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 15 Sep 2005 18:16:04 -0700 Subject: [Xorp-hackers] FW: boot.config problems? In-Reply-To: Message from Atanu Ghosh of "Thu, 15 Sep 2005 18:12:27 PDT." <84536.1126833147@tigger.icir.org> Message-ID: <85442.1126833364@tigger.icir.org> Hi, To clarify the Powerbook G4 is running Mac OS X 10.4.2 not Linux. Atanu. >>>>> "Atanu" == Atanu Ghosh writes: Atanu> Hi, We have tested XORP on Linux 2.4 and 2.6 kernels and it Atanu> seem to work on a Powerbook G4. We haven't tried your Atanu> particular combination. Atanu> Its very odd that the router manager doen't print Atanu> anything. Even without the "-v" flag it should print Atanu> something. Atanu> Atanu. >>>>> "Weaver" == Weaver John writes: Weaver> Just tried the non-stripped version and I get the same Weaver> thing. I launched it with the -v and still get nothing to Weaver> print. Has any one ever tried this on the PPC? I am using Weaver> gcc 3.3.3, autoconf 2.59, and automake 1.8.3. Weaver> John Weaver> -----Original Message----- From: Kristian Larsson Weaver> [mailto:kristian@juniks.net] Sent: Wednesday, September 14, Weaver> 2005 12:35 AM To: Weaver John-JWEAVER1 Cc: Weaver> xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] FW: Weaver> boot.config problems? Weaver> Hmm, it's possible I suppose, but I've had no such problems Weaver> so far... Weaver> Have you tried with a non-stripped version? Weaver> I think you can tell strip to be more careful when removing Weaver> stuff, but then the binaries won't shrink as much... Weaver> //Kristian Weaver> On Tue, Sep 13, 2005 at 04:55:10PM -0500, Weaver Weaver> John-JWEAVER1 wrote: >>> I wonder if stripping the whole structure has hosed it? >>> >>> -----Original Message----- From: Kristian Larsson >>> [mailto:kristian@juniks.net] Sent: Tuesday, September 13, 2005 >>> 4:29 PM To: Weaver John-JWEAVER1 Subject: Re: [Xorp-hackers] FW: >>> boot.config problems? >>> >>> I'm not in front of a xorp router right now so I can't test the >>> config but since Atanu did that I'm sure it's okey. >>> >>> xorp_rtrmgr -v -b should work >>> >>> But you're saying it's just hanging!? When does this happen? >>> When using -v in conjuction with this configuration file? Just >>> using -v? As long as you are using this config.boot? >>> >>> If it's just when using the particular config you should try >>> loading parts of it. >>> >>> Kristian >>> >>> On Tue, Sep 13, 2005 at 04:10:56PM -0500, Weaver John-JWEAVER1 >>> wrote: > Someone else changed the name of it and moved it. I am >>> pretty sure > it was modified from the original config.boot. I >>> ripped out all the > irrelevant stuff for simplicity. I used >>> the -b command to specify > this file so hopefully it was >>> picking this one up? When I boot with > the -v, can I use -vb >>> or -v -b? >>> > >>> > John >>> > >>> > -----Original Message----- > From: Kristian Larsson >>> [mailto:kristian@juniks.net] > Sent: Tuesday, September 13, 2005 >>> 4:07 PM > To: Weaver John-JWEAVER1 > Cc: xorp-hackers@xorp.org > >>> Subject: Re: [Xorp-hackers] FW: boot.config problems? >>> > >>> > You're config file is not named boot.config but rather >>> config.boot > and placed in /usr/local/xorp/config.boot, right? >>> > >>> > Try starting up with -v, you should get some error message. >>> > >>> > Have you actually used this configuration or is it written by >>> hand? > It doesn't contain a xorp header which makes me >>> wonder... > You could start xorp and then add little chunks of >>> the config and > the commiting to make sure the whole conf is >>> alright. >>> > >>> > Regards, > Kristian >>> > >>> > On Tue, Sep 13, 2005 at 03:46:55PM -0500, Weaver John-JWEAVER1 >>> wrote: > > I am having problems getting XORP starting up. I >>> think it may be > > my boot.config? I have 2 interfaces (eth1 >>> and eth2) and am only > > running PIM and IGMP on those >>> interfaces. I am trying to use the > > default system > config. >>> > > Is there any debug I can turn on when I try and launch the >>> xorp_rtmgr? >>> > > Can anyone take a look at this file and let me know if I >>> messed it up? >>> > > The system I am running it on is kind of like a Power Mac. >>> It is > > running Yellow Dog on a PPC 750. Everything built >>> fine and the > > make test passed except for rip as you may >>> remember. >>> > > >>> > > Thanks, > > John >>> > Weaver> _______________________________________________ Xorp-hackers Weaver> mailing list Xorp-hackers@icir.org Weaver> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers Atanu> _______________________________________________ Xorp-hackers Atanu> mailing list Xorp-hackers@icir.org Atanu> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ratul@cs.washington.edu Fri Sep 16 07:55:00 2005 From: ratul@cs.washington.edu (Ratul Mahajan) Date: Thu, 15 Sep 2005 23:55:00 -0700 Subject: [Xorp-hackers] loading complete routing tables Message-ID: <432A6C44.1070705@cs.washington.edu> hi - what method do the developers/testers use to load complete routing tables into xorp_bgp? i want to load mrtd table_dumps and updates from routeviews (the dumps have routes from multiple peers). i am wondering what the best (fastest) way is to achieve this. thanks. From deathdealer@gmx.net Fri Sep 16 11:27:41 2005 From: deathdealer@gmx.net (=?ISO-8859-1?Q?=22Patrick_Preu=DF=22?=) Date: Fri, 16 Sep 2005 12:27:41 +0200 (MEST) Subject: [Xorp-hackers] OSPFv2 Peering stays in INIT State on Cisco Message-ID: <7672.1126866461@www64.gmx.net> Hello i have testet the OSPF Code on a Linux Machine over a GRE Interface to a Cisco 7507 and see that the Session stays in the INIT/- State on the Cisco. The XORP tells me the Packet size is not Correct. i have used two different configurations, one you will find attached is w/o setting p2p mode, the other is with p2p and both report the same. i have used quaggar also and there is no problem. i can provide more information if needed. XORP Router: Distribution: Fedora Core 3 Kernel: 2.6.12-1.1376_FC3 Networking: gre or eth Cisco Router: Cisco 7507 IOS: RSP Software (RSP-JK9SV-M), Version 12.3(13) The Tunnel is configured from the OS. Please have a look at Bug 216 http://www.xorp.org/bugzilla/show_bug.cgi?id=216 -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner From Mark Handley Fri Sep 16 12:07:27 2005 From: Mark Handley (Mark Handley) Date: Fri, 16 Sep 2005 12:07:27 +0100 Subject: [Xorp-hackers] OSPFv2 Peering stays in INIT State on Cisco In-Reply-To: <7672.1126866461@www64.gmx.net> References: <7672.1126866461@www64.gmx.net> Message-ID: <84a612dd05091604075a8b2c34@mail.gmail.com> ------=_Part_9183_14004840.1126868847307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Patrick, Thanks for the feedback. Is this from a very recent snapshot? OSPF has been= =20 changing significantly from day-to-day this week - Atanu has made a lot of= =20 progress. I see you're on the xorp-cvs mailing list, so you probably know= =20 this though. For anyone who doesn't know, you can track the changes through cvsweb: http://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/ospf/ Or you can look at the CVS commit messages here: http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/ - Mark On 9/16/05, "Patrick Preu=DF" wrote: >=20 > Hello >=20 > i have testet the OSPF Code on a Linux Machine over a GRE Interface to a > Cisco 7507 and see that the Session stays in the INIT/- State on the=20 > Cisco. >=20 > The XORP tells me the Packet size is not Correct. >=20 > i have used two different configurations, one you will find attached is= =20 > w/o > setting p2p mode, the other is with p2p and both report the same. >=20 > i have used quaggar also and there is no problem. i can provide more > information if needed. >=20 > XORP Router: > Distribution: Fedora Core 3 > Kernel: 2.6.12-1.1376_FC3 >=20 > Networking: gre or eth >=20 > Cisco Router: >=20 > Cisco 7507 > IOS: RSP Software (RSP-JK9SV-M), Version 12.3(13) >=20 > The Tunnel is configured from the OS. >=20 > Please have a look at Bug 216 > http://www.xorp.org/bugzilla/show_bug.cgi?id=3D216 >=20 > -- > best regards > Patrick Marc Preuss > ---------------------------------------------------------------------- > -- >=20 > "...a hundred billion castaways looking for a home." > - Sting "Message in a > Bottle" (1979) >=20 > Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! > Satte Provisionen f=FCr GMX Partner: http://www.gmx.net/de/go/partner > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > ------=_Part_9183_14004840.1126868847307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Patrick,

Thanks for the feedback.  Is this from a very recent snapshot?  OSPF has been changing significantly from day-to-day this week - Atanu has made a lot of progress.   I see you're on the xorp-cvs mailing list, so you probably know this though.

For anyone who doesn't know, you can track the changes through cvsweb:
  http= ://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/ospf/

Or you can look at the CVS commit messages here:
  htt= p://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/

 - Mark

On 9/16/05, "Patrick Preu=DF" <deathdealer@gmx.net> wrote:
Hello

i have testet the OSPF Code on a Linux Machine over a GRE Inte= rface to a
Cisco 7507 and see that the Session stays in the INIT/- State= on the Cisco.

The XORP tells me the Packet size is not Correct.

i have used two different configurations, one you will find attache= d is w/o
setting p2p mode, the other is with p2p and both report the sam= e.

i have used quaggar also and there is no problem. i can provide m= ore
information if needed.

XORP Router:
Distribution: Fedora Core= 3
Kernel: 2.6.12-1.1376_FC3

Networking: gre or eth

Cisco = Router:

Cisco 7507
IOS: RSP Software (RSP-JK9SV-M), Version 12.3 (13)

The Tunnel is configured from the OS.

Please have a look= at Bug 216
http://www.xorp.org/bugzilla/show_bug.cgi?id=3D216

--
best= regards
Patrick Marc Preuss
------------------------------------------------= ----------------------
--

"...a hundred billion castaways l= ooking for a home."
        = ;            &n= bsp;            = ; - Sting "Message in a
Bottle" (1979)

Lust, ein paar Euro = nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f=FCr= GMX Partner: http://www.gmx.n= et/de/go/partner
_______________________________________________
Xorp-hackers mai= ling list
Xorp-hackers@icir.org=
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

------=_Part_9183_14004840.1126868847307-- From deathdealer@gmx.net Fri Sep 16 13:27:01 2005 From: deathdealer@gmx.net (=?ISO-8859-1?Q?=22Patrick_Preu=DF=22?=) Date: Fri, 16 Sep 2005 14:27:01 +0200 (MEST) Subject: [Xorp-hackers] OSPFv2 Peering stays in INIT State on Cisco References: <84a612dd05091604075a8b2c34@mail.gmail.com> Message-ID: <23775.1126873621@www64.gmx.net> Hello Marc, i watching the list for a while and it's good to see how far the OSPF code is grown, thanks Atanu. the lasttime i checked out was today moring around 7:30 Europe/Berlin, i includes version 1.4 of the rib.cmds. a while ago we had here a problem with ospf on our cisco and enterasys equiptment, it might be interesting for a test case, sorry but i don't have the logs any more, the problem was we had begun to configure the router-id on the cisco, so it would be easier to identify the router, so the enterasys become the dr and master state in the lan segement, but the cisco doesn't join because the enterasys does't send the mtu correctly and the second thing was the enterasys had a problem with the sequence numbering. the solution/workaround from cisco was to change the router-id and priority so the cisco will become dr and master. entersys is currently implementing a fix in the firmware. the software version on the enterasys was i think somwhere around E10.0.0.6A, on the ciscos we have IOS versions form 12.3.15 - 12.4.3 in use. -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl From atanu@ICSI.Berkeley.EDU Fri Sep 16 16:53:09 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 16 Sep 2005 08:53:09 -0700 Subject: [Xorp-hackers] loading complete routing tables In-Reply-To: Message from Ratul Mahajan of "Thu, 15 Sep 2005 23:55:00 PDT." <432A6C44.1070705@cs.washington.edu> Message-ID: <37506.1126885989@tigger.icir.org> Hi, We use the test harness to load routes into BGP: Some examples of this are in bgp/harness/test_peering2.sh, test1 and test15 are the most interesting examples. These tests load data from mtrd format files. The tests by default also start the BGP process unless the "-s" argument is used. As an aside the gmake check target runs all these tests. The way that I currently load routes from mrtd files into BGP is to use the bgp/harness/harness.py script. 1) Configure BGP to accept a peering from the test peer. The XORP BGP can be configured to accept connections on ports other than 179 if you want to do everything on a single host. But you will need to edit the script to use a port number other than 179. 2) A number of processes need to be started. I typically use separate xterms. a) The finder process (libxipc/xorp_finder) if there is a router manager running on this host this step is not necessary. b) bgp/harness/coord c) bgp/harness/test_peer -s peer1 3) The harness program can now be used to inject routes or even save routes from the BGP process. Many separate files can be loaded as the session is maintained by the test_peer not the harness program. $ ./test_harness.py -e -p bgp_host -a asnum -b bgp-id -i mtrd_file1 $ ./test_harness.py -p bgp_host -a asnum -b bgp-id -i mtrd_file12 Note the first time "-e" is used to establish the the session the second time the session exists. If you want to see the protocol packets then add "-v" to the list of test_peer arguments. We do not rewrite the contents of the MRTD file so the ASPATH in the file will need to be acceptable to the BGP process. This is the file used by our regression tests: Atanu. >>>>> "Ratul" == Ratul Mahajan writes: Ratul> hi - Ratul> what method do the developers/testers use to load complete Ratul> routing tables into xorp_bgp? Ratul> i want to load mrtd table_dumps and updates from routeviews Ratul> (the dumps have routes from multiple peers). i am wondering Ratul> what the best (fastest) way is to achieve this. Ratul> thanks. _______________________________________________ Ratul> Xorp-hackers mailing list Xorp-hackers@icir.org Ratul> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu@ICSI.Berkeley.EDU Fri Sep 16 18:28:52 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 16 Sep 2005 10:28:52 -0700 Subject: [Xorp-hackers] OSPFv2 Peering stays in INIT State on Cisco In-Reply-To: Message from =?ISO-8859-1?Q?=22Patrick_Preu=DF=22?= of "Fri, 16 Sep 2005 12:27:41 +0200." <7672.1126866461@www64.gmx.net> Message-ID: <60126.1126891732@tigger.icir.org> Hi, I checked in the p2p code last night intending to test it today, you seem to have beaten me to it:-). Sending all the configuration files and especially the ethereal trace was fantastically useful. >From the ethereal trace we can see the the Cisco sent a 60 byte OSPF packet, the OSPF header is reporting 48 bytes. Which is exactly what XORP is reporting. Due to the mismatch we are rejecting the packet. I can't see anything in the spec that requires zero or even garbage padding as in this case. There is often/always a requirement to pad to meet the link requirements but this is a 96 byte frame. A 84 byte frame would have met the 60 byte frame requirement. ---------------------------------------- "Be liberal in what you accept, and conservative in what you send." -- jon RFC-1122 (originates in RFC760) ---------------------------------------- I will attempt to make the code more liberal. Thanks again for the traces. Atanu. >>>>> "Patrick" == Patrick Preu writes: Patrick> Hello i have testet the OSPF Code on a Linux Machine over a Patrick> GRE Interface to a Cisco 7507 and see that the Session Patrick> stays in the INIT/- State on the Cisco. Patrick> The XORP tells me the Packet size is not Correct. Patrick> i have used two different configurations, one you will find Patrick> attached is w/o setting p2p mode, the other is with p2p and Patrick> both report the same. Patrick> i have used quaggar also and there is no problem. i can Patrick> provide more information if needed. Patrick> XORP Router: Distribution: Fedora Core 3 Kernel: Patrick> 2.6.12-1.1376_FC3 Patrick> Networking: gre or eth Patrick> Cisco Router: Patrick> Cisco 7507 IOS: RSP Software (RSP-JK9SV-M), Version Patrick> 12.3(13) Patrick> The Tunnel is configured from the OS. Patrick> Please have a look at Bug 216 Patrick> http://www.xorp.org/bugzilla/show_bug.cgi?id=216 Patrick> -- best regards Patrick Marc Preuss Patrick> ---------------------------------------------------------------------- Patrick> -- Patrick> "...a hundred billion castaways looking for a home." - Patrick> Sting "Message in a Bottle" (1979) Patrick> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, Patrick> ohne Risiko! Satte Provisionen für GMX Partner: Patrick> http://www.gmx.net/de/go/partner Patrick> _______________________________________________ Patrick> Xorp-hackers mailing list Xorp-hackers@icir.org Patrick> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From deathdealer@gmx.net Fri Sep 16 18:45:48 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Fri, 16 Sep 2005 19:45:48 +0200 Subject: AW: [Xorp-hackers] OSPFv2 Peering stays in INIT State on Cisco In-Reply-To: <60126.1126891732@tigger.icir.org> Message-ID: <200509161745.j8GHjnPB046657@wyvern.icir.org> Hello Atanu, No problem, it makes me glad to help. One question is it possible to leave the debugging code in ospf and spend it some finder:// urls so it can be dynamicly turned on like the "debug ip ospf ..." commands on the cisco? Sorry for that but I came from the cisco side the world. I think the same thing happens also on the ethenet with enterasys routers but I will debug it on Monday, this weekend is not so good because we have some changes in our main applications. Next question where do I turn authentication on? Gruss    Patrick Marc Preuss Nordstrasse 28 41569 Rommerskirchen -----Ursprüngliche Nachricht----- Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im Auftrag von Atanu Ghosh Gesendet: Freitag, 16. September 2005 19:29 An: "Patrick Preuß" Cc: xorp-hackers@xorp.org; patrick.preuss@retail-sc.com Betreff: Re: [Xorp-hackers] OSPFv2 Peering stays in INIT State on Cisco Hi, I checked in the p2p code last night intending to test it today, you seem to have beaten me to it:-). Sending all the configuration files and especially the ethereal trace was fantastically useful. >From the ethereal trace we can see the the Cisco sent a 60 byte OSPF packet, the OSPF header is reporting 48 bytes. Which is exactly what XORP is reporting. Due to the mismatch we are rejecting the packet. I can't see anything in the spec that requires zero or even garbage padding as in this case. There is often/always a requirement to pad to meet the link requirements but this is a 96 byte frame. A 84 byte frame would have met the 60 byte frame requirement. ---------------------------------------- "Be liberal in what you accept, and conservative in what you send." -- jon RFC-1122 (originates in RFC760) ---------------------------------------- I will attempt to make the code more liberal. Thanks again for the traces. Atanu. >>>>> "Patrick" == Patrick Preu writes: Patrick> Hello i have testet the OSPF Code on a Linux Machine over a Patrick> GRE Interface to a Cisco 7507 and see that the Session Patrick> stays in the INIT/- State on the Cisco. Patrick> The XORP tells me the Packet size is not Correct. Patrick> i have used two different configurations, one you will find Patrick> attached is w/o setting p2p mode, the other is with p2p and Patrick> both report the same. Patrick> i have used quaggar also and there is no problem. i can Patrick> provide more information if needed. Patrick> XORP Router: Distribution: Fedora Core 3 Kernel: Patrick> 2.6.12-1.1376_FC3 Patrick> Networking: gre or eth Patrick> Cisco Router: Patrick> Cisco 7507 IOS: RSP Software (RSP-JK9SV-M), Version Patrick> 12.3(13) Patrick> The Tunnel is configured from the OS. Patrick> Please have a look at Bug 216 Patrick> http://www.xorp.org/bugzilla/show_bug.cgi?id=216 Patrick> -- best regards Patrick Marc Preuss Patrick> ---------------------------------------------------------------------- Patrick> -- Patrick> "...a hundred billion castaways looking for a home." - Patrick> Sting "Message in a Bottle" (1979) Patrick> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, Patrick> ohne Risiko! Satte Provisionen für GMX Partner: Patrick> http://www.gmx.net/de/go/partner Patrick> _______________________________________________ Patrick> Xorp-hackers mailing list Xorp-hackers@icir.org Patrick> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ratul@cs.washington.edu Fri Sep 16 19:57:17 2005 From: ratul@cs.washington.edu (Ratul Mahajan) Date: Fri, 16 Sep 2005 11:57:17 -0700 Subject: [Xorp-hackers] loading complete routing tables In-Reply-To: <37506.1126885989@tigger.icir.org> References: <37506.1126885989@tigger.icir.org> Message-ID: <432B158D.4050208@cs.washington.edu> atanu - thanks for the response. so i looked at the harness code some time back and came away with the following impressions regarding the current code: - it (harness/Peer::send_dump) does not support mtrd records of type TABLE_DUMP (entire table dumps). it assumes BGP4MP (dumps of routing updates). - it does not support having updates from multiple peers in the same mrtd file (as would be generated by a router with many peers). please correct me if any of the above is wrong. none of it seems insurmountable but i just wanted to ensure that i wasn't missing something easier. thanks. Atanu Ghosh wrote: > Hi, > > We use the test harness to load routes into BGP: > > > Some examples of this are in bgp/harness/test_peering2.sh, test1 and > test15 are the most interesting examples. These tests load data from > mtrd format files. The tests by default also start the BGP process > unless the "-s" argument is used. As an aside the gmake check target > runs all these tests. > > The way that I currently load routes from mrtd files into BGP is to use > the bgp/harness/harness.py script. > > 1) Configure BGP to accept a peering from the test peer. The XORP BGP > can be configured to accept connections on ports other than 179 if you > want to do everything on a single host. But you will need to edit the > script to use a port number other than 179. > > 2) A number of processes need to be started. I typically use separate xterms. > a) The finder process (libxipc/xorp_finder) if there is a router > manager running on this host this step is not necessary. > b) bgp/harness/coord > c) bgp/harness/test_peer -s peer1 > > 3) The harness program can now be used to inject routes or even save > routes from the BGP process. Many separate files can be loaded as the > session is maintained by the test_peer not the harness program. > > $ ./test_harness.py -e -p bgp_host -a asnum -b bgp-id -i mtrd_file1 > $ ./test_harness.py -p bgp_host -a asnum -b bgp-id -i mtrd_file12 > > Note the first time "-e" is used to establish the the session the second > time the session exists. If you want to see the protocol packets then > add "-v" to the list of test_peer arguments. > > We do not rewrite the contents of the MRTD file so the ASPATH in the > file will need to be acceptable to the BGP process. > > This is the file used by our regression tests: > > > Atanu. > > >>>>>>"Ratul" == Ratul Mahajan writes: > > > Ratul> hi - > > Ratul> what method do the developers/testers use to load complete > Ratul> routing tables into xorp_bgp? > > Ratul> i want to load mrtd table_dumps and updates from routeviews > Ratul> (the dumps have routes from multiple peers). i am wondering > Ratul> what the best (fastest) way is to achieve this. > > Ratul> thanks. _______________________________________________ > Ratul> Xorp-hackers mailing list Xorp-hackers@icir.org > Ratul> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Fri Sep 16 21:58:19 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 16 Sep 2005 13:58:19 -0700 Subject: [Xorp-hackers] reliable static routing In-Reply-To: Message from =?ISO-8859-1?Q?=22Patrick_Preu=DF=22?= of "Thu, 08 Sep 2005 13:30:11 +0200." <9099.1126179011@www83.gmx.net> Message-ID: <200509162058.j8GKwJ3e024422@possum.icir.org> > > > > Second I am not so deep in the code, wath is about static routes, policy > > s > > > witch uses not the next-hop, > > > They use a router one or more hops away? > > I'm not sure what you mean...? > > afak the cisco's call it recursive route lookup, so you define a route via a > next hop not directly connected. As far as I can remember, currently the RIB doesn't support recursive next-hop route lookup. Pavlin From Mark Handley Fri Sep 16 22:22:18 2005 From: Mark Handley (Mark Handley) Date: Fri, 16 Sep 2005 22:22:18 +0100 Subject: [Xorp-hackers] loading complete routing tables In-Reply-To: <432B158D.4050208@cs.washington.edu> References: <37506.1126885989@tigger.icir.org> <432B158D.4050208@cs.washington.edu> Message-ID: <84a612dd0509161422444a7af6@mail.gmail.com> ------=_Part_13212_30945670.1126905738292 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > so i looked at the harness code some time back and came away with the > following impressions regarding the current code: > - it (harness/Peer::send_dump) does not support mtrd records of type > TABLE_DUMP (entire table dumps). it assumes BGP4MP (dumps of routing > updates). > - it does not support having updates from multiple peers in the same > mrtd file (as would be generated by a router with many peers). Sounds like these serve different purposes. So far we've wanted to test=20 XORP, including the message parsing, so replaying update messages is good= =20 for this purpose. What you describe is loading a previously stored router state. We could in= =20 principle build such a load function into BGP for testing purposes. As we'r= e=20 event-driven, this would have to be implemented by effectively mapping the= =20 route state into update messages, or we'd not end up with the right metadat= a=20 stored in the routes. But a more tricky problem concerns filters. There's n= o=20 way to load state in after the import filters as we only store routes prior= =20 to filtering. Thus the only way to do a table load for a config file that= =20 was stored from a post-import-filter table dumb would be to load it on a=20 XORP router with *no* import filters in place. This means you can't do it= =20 for a router with EBGP peerings configured, because they must have filters. Thus I can't really see any way to load a table dump into a XORP BGP and en= d=20 upn with the correct behaviour unless that table dump were itself stored=20 from a XORP router, and hence represents pre-filtered routes. Loading a=20 post-filter table dump into a XORP router that had import filters configure= d=20 would end up with the filters being run on the stored data, which simply=20 won't result in the right behaviour. Does this make sense? - Mark ------=_Part_13212_30945670.1126905738292 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
so i looked = at the harness code some time back and came away with the
following impressions regarding the current code:
  - it (harn= ess/Peer::send_dump) does not support mtrd records of type
TABLE_DUMP (e= ntire table dumps). it assumes BGP4MP (dumps of routing
updates).
&nb= sp; - it does not support having updates from multiple peers in the sa= me
mrtd file (as would be generated by a router with many peers).

Sounds like these serve different purposes.  So far we've wanted to  test XORP, including the message parsing, so replaying update messages is good for this purpose.

What you describe is loading a previously stored router state.  We could in principle build such a load function into BGP for testing purposes.  As we're event-driven, this would have to be implemented by effectively mapping the route state into update messages, or we'd  not end up with the right metadata stored in the routes.  But a more tricky problem concerns filters.  There's no way to load state in after the import filters as we only store routes prior to filtering.  Thus the only way to do a table load for a config file that was stored from a post-import-filter table dumb would be to load it on a XORP router with *no* import filters in place.  This means you can't do it for a router with EBGP peerings configured, because they must have filters.

Thus I can't really see any way to load a table dump into a XORP BGP and end upn with the correct behaviour unless that table dump were itself stored from a XORP router, and hence represents pre-filtered routes.  Loading a post-filter table dump into a XORP router that had import filters configured would end up with the filters being run on the stored data, which simply won't result in the right behaviour.

Does this make sense?

 - Mark


------=_Part_13212_30945670.1126905738292-- From Mark Handley Fri Sep 16 22:28:06 2005 From: Mark Handley (Mark Handley) Date: Fri, 16 Sep 2005 22:28:06 +0100 Subject: [Xorp-hackers] reliable static routing In-Reply-To: <200509162058.j8GKwJ3e024422@possum.icir.org> References: <9099.1126179011@www83.gmx.net> <200509162058.j8GKwJ3e024422@possum.icir.org> Message-ID: <84a612dd05091614283db8a131@mail.gmail.com> ------=_Part_13268_21904334.1126906086835 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 9/16/05, Pavlin Radoslavov wrote: >=20 > > > > > > Second I am not so deep in the code, wath is about static routes,= =20 > policy > > > s > > > > witch uses not the next-hop, > > > > They use a router one or more hops away? > > > I'm not sure what you mean...? > > > > afak the cisco's call it recursive route lookup, so you define a route= =20 > via a > > next hop not directly connected. >=20 > As far as I can remember, currently the RIB doesn't support > recursive next-hop route lookup. That's correct - I didn't understand the problem properly when I wrote that= =20 code. We know we need to support this - it's been on our ToDo list for a=20 while.=20 - Mark ------=_Part_13268_21904334.1126906086835 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 9/16/05, Pavlin Radoslavov <pavlin= @icir.org> wrote:
>
> > > Second I am not so deep in the code, wath is about s= tatic routes, policy
> > s
> > > witch uses not the ne= xt-hop,
> > > They use a router one or more hops away?
> = > I'm not sure what you mean...?
>
> afak the cisco's call it recursive route lookup, so you de= fine a route via a
> next hop not directly connected.

As far a= s I can remember, currently the RIB doesn't support
recursive next-hop r= oute lookup.

That's correct - I didn't understand the problem properly when I wrote that code.  We know we need to support this - it's been on our ToDo list for a while.

 - Mark


------=_Part_13268_21904334.1126906086835-- From pavlin@icir.org Fri Sep 16 22:45:29 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 16 Sep 2005 14:45:29 -0700 Subject: [Xorp-hackers] FW: boot.config problems? In-Reply-To: Message from Weaver John-JWEAVER1 of "Wed, 14 Sep 2005 10:40:58 CDT." <0DFC73466514D41186B700508B9510411C34B427@tx14exm04.ftw.mot.com> Message-ID: <200509162145.j8GLjT4Y025672@possum.icir.org> > Just tried the non-stripped version and I get the same thing. I launched it > with the -v and still get nothing to print. Has any one ever tried this on > the PPC? I am using gcc 3.3.3, autoconf 2.59, and automake 1.8.3. As Atanu mentioned already, we can run XORP on PPC with MacOS X, but we haven't tried it on Yellow Dog Linux. Note that in our setup we are using autoconf 2.53 and automake 1.5 (see README). The autoconf/automake tools are notorious for creating various configuration problems between major releases so there could be some configuration issues with using automake 1.8.3 (though they shouldn result in suppressing the printed output). In any case, if you can give us a temporary account on the problematic machine, we can try to track the problem. BTW, in your configuration file you have disabled the bootstrap configuration section and there are no static RPs hence multicast routing probably won't work if there are no Cand-RPs. Such configuration would work only if another PIM-SM router is configured as a Cand-BSR and a Cand-RP. Pavlin > > John > > -----Original Message----- > From: Kristian Larsson [mailto:kristian@juniks.net] > Sent: Wednesday, September 14, 2005 12:35 AM > To: Weaver John-JWEAVER1 > Cc: xorp-hackers@xorp.org > Subject: Re: [Xorp-hackers] FW: boot.config problems? > > Hmm, it's possible I suppose, but I've had no such problems so far... > > Have you tried with a non-stripped version? > > I think you can tell strip to be more careful when removing stuff, but then > the binaries won't shrink as much... > > //Kristian > > On Tue, Sep 13, 2005 at 04:55:10PM -0500, Weaver John-JWEAVER1 wrote: > > I wonder if stripping the whole structure has hosed it? > > > > -----Original Message----- > > From: Kristian Larsson [mailto:kristian@juniks.net] > > Sent: Tuesday, September 13, 2005 4:29 PM > > To: Weaver John-JWEAVER1 > > Subject: Re: [Xorp-hackers] FW: boot.config problems? > > > > I'm not in front of a xorp router right now so I can't test the config > > but since Atanu did that I'm sure it's okey. > > > > xorp_rtrmgr -v -b should work > > > > But you're saying it's just hanging!? When does this happen? When > > using -v in conjuction with this configuration file? Just using -v? As > > long as you are using this config.boot? > > > > If it's just when using the particular config you should try loading > > parts of it. > > > > Kristian > > > > On Tue, Sep 13, 2005 at 04:10:56PM -0500, Weaver John-JWEAVER1 wrote: > > > Someone else changed the name of it and moved it. I am pretty sure > > > it was modified from the original config.boot. I ripped out all the > > > irrelevant stuff for simplicity. I used the -b command to specify > > > this file so hopefully it was picking this one up? When I boot with > > > the -v, can I use -vb or -v -b? > > > > > > John > > > > > > -----Original Message----- > > > From: Kristian Larsson [mailto:kristian@juniks.net] > > > Sent: Tuesday, September 13, 2005 4:07 PM > > > To: Weaver John-JWEAVER1 > > > Cc: xorp-hackers@xorp.org > > > Subject: Re: [Xorp-hackers] FW: boot.config problems? > > > > > > You're config file is not named boot.config but rather config.boot > > > and placed in /usr/local/xorp/config.boot, right? > > > > > > Try starting up with -v, you should get some error message. > > > > > > Have you actually used this configuration or is it written by hand? > > > It doesn't contain a xorp header which makes me wonder... > > > You could start xorp and then add little chunks of the config and > > > the commiting to make sure the whole conf is alright. > > > > > > Regards, > > > Kristian > > > > > > On Tue, Sep 13, 2005 at 03:46:55PM -0500, Weaver John-JWEAVER1 wrote: > > > > I am having problems getting XORP starting up. I think it may be > > > > my boot.config? I have 2 interfaces (eth1 and eth2) and am only > > > > running PIM and IGMP on those interfaces. I am trying to use the > > > > default system > > > config. > > > > Is there any debug I can turn on when I try and launch the xorp_rtmgr? > > > > > Can anyone take a look at this file and let me know if I messed it up? > > > > > The system I am running it on is kind of like a Power Mac. It is > > > > running Yellow Dog on a PPC 750. Everything built fine and the > > > > make test passed except for rip as you may remember. > > > > > > > > Thanks, > > > > John > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu@ICSI.Berkeley.EDU Fri Sep 16 23:37:11 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 16 Sep 2005 15:37:11 -0700 Subject: AW: [Xorp-hackers] OSPFv2 Peering stays in INIT State on Cisco In-Reply-To: Message from "Patrick Preuss" of "Fri, 16 Sep 2005 19:45:48 +0200." <200509161745.j8GHjnPB046657@wyvern.icir.org> Message-ID: <22536.1126910231@tigger.icir.org> Hi, There are trace points in the code that are currently all enabled by default. In the future it will be possible to manipulate them via the xorpsh. You haven't seen any of the trace point output because the hello packets are being rejected. Here is an example of the output when we peer with our Cisco: [ 2005/09/16 15:29:30 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(fxp0/fxp0) Neighbour(x.x.x.x) State(Full) When we get the policy code integrated it should be possible to enable tracing down to LSA granularity. Authentication is not implemented yet, we are focusing on getting multiple areas working. Atanu. >>>>> "Patrick" == Patrick Preuss writes: Patrick> Hello Atanu, No problem, it makes me glad to help. Patrick> One question is it possible to leave the debugging code in Patrick> ospf and spend it some finder:// urls so it can be Patrick> dynamicly turned on like the "debug ip ospf ..." commands Patrick> on the cisco? Sorry for that but I came from the cisco side Patrick> the world. Patrick> I think the same thing happens also on the ethenet with Patrick> enterasys routers but I will debug it on Monday, this Patrick> weekend is not so good because we have some changes in our Patrick> main applications. Patrick> Next question where do I turn authentication on? Patrick> Gruss    Patrick Marc Preuss Nordstrasse 28 41569 Patrick> Rommerskirchen Patrick> -----Ursprüngliche Nachricht----- Von: Patrick> xorp-hackers-admin@icir.org Patrick> [mailto:xorp-hackers-admin@icir.org] Im Auftrag von Atanu Patrick> Ghosh Gesendet: Freitag, 16. September 2005 19:29 An: Patrick> "Patrick Preuß" Cc: xorp-hackers@xorp.org; Patrick> patrick.preuss@retail-sc.com Betreff: Re: [Xorp-hackers] Patrick> OSPFv2 Peering stays in INIT State on Cisco Patrick> Hi, Patrick> I checked in the p2p code last night intending to test it Patrick> today, you seem to have beaten me to it:-). Patrick> Sending all the configuration files and especially the Patrick> ethereal trace was fantastically useful. Patrick> From the ethereal trace we can see the the Cisco sent a 60 Patrick> byte OSPF packet, the OSPF header is reporting 48 Patrick> bytes. Which is exactly what XORP is reporting. Due to the Patrick> mismatch we are rejecting the packet. Patrick> I can't see anything in the spec that requires zero or even Patrick> garbage padding as in this case. There is often/always a Patrick> requirement to pad to meet the link requirements but this Patrick> is a 96 byte frame. A 84 byte frame would have met the 60 Patrick> byte frame requirement. Patrick> ---------------------------------------- "Be liberal in Patrick> what you accept, and conservative in what you send." -- Patrick> jon RFC-1122 (originates in RFC760) Patrick> ---------------------------------------- Patrick> I will attempt to make the code more liberal. Patrick> Thanks again for the traces. Patrick> Atanu. >>>>> "Patrick" == Patrick Preu writes: Patrick> Hello i have testet the OSPF Code on a Linux Machine over a Patrick> GRE Interface to a Cisco 7507 and see that the Session Patrick> stays in the INIT/- State on the Cisco. Patrick> The XORP tells me the Packet size is not Correct. Patrick> i have used two different configurations, one you will find Patrick> attached is w/o setting p2p mode, the other is with p2p and Patrick> both report the same. Patrick> i have used quaggar also and there is no problem. i can Patrick> provide more information if needed. Patrick> XORP Router: Distribution: Fedora Core 3 Kernel: Patrick> 2.6.12-1.1376_FC3 Patrick> Networking: gre or eth Patrick> Cisco Router: Patrick> Cisco 7507 IOS: RSP Software (RSP-JK9SV-M), Version Patrick> 12.3(13) Patrick> The Tunnel is configured from the OS. Patrick> Please have a look at Bug 216 Patrick> http://www.xorp.org/bugzilla/show_bug.cgi?id=216 Patrick> -- best regards Patrick Marc Preuss Patrick> Patrick> ---------------------------------------------------------------------- Patrick> -- Patrick> "...a hundred billion castaways looking for a home." - Patrick> Sting "Message in a Bottle" (1979) Patrick> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, Patrick> ohne Risiko! Satte Provisionen für GMX Partner: Patrick> http://www.gmx.net/de/go/partner Patrick> _______________________________________________ Patrick> Xorp-hackers mailing list Xorp-hackers@icir.org Patrick> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers Patrick> _______________________________________________ Patrick> Xorp-hackers mailing list Xorp-hackers@icir.org Patrick> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers Patrick> _______________________________________________ Patrick> Xorp-hackers mailing list Xorp-hackers@icir.org Patrick> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu@ICSI.Berkeley.EDU Fri Sep 16 23:54:05 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 16 Sep 2005 15:54:05 -0700 Subject: [Xorp-hackers] loading complete routing tables In-Reply-To: Message from Ratul Mahajan of "Fri, 16 Sep 2005 11:57:17 PDT." <432B158D.4050208@cs.washington.edu> Message-ID: <27327.1126911245@tigger.icir.org> Hi, You are absolutely correct, I was thinking about routing updates not the table dumps. The harness code can write table dumps but it can't read them. I think reading a table dump and sending it to a BGP process using a single session should be relatively easy. It won't of course be possible to preserve the fact that the routes originally came from different peers. If you use an IBGP peering it shouldn't even be necessary to modify the aspath. I would add the entry point to bgp/harness/peer.cc:Peer::send_dump. Modify it to support "table" as well as "update". Create an instance of UpdatePacket read the path attributes from the file into the UpdatePacket call encode to get the wire format and you should be done. I look forward to receiving the patch. Atanu. >>>>> "Ratul" == Ratul Mahajan writes: Ratul> atanu - Ratul> thanks for the response. Ratul> so i looked at the harness code some time back and came away with the Ratul> following impressions regarding the current code: Ratul> - it (harness/Peer::send_dump) does not support mtrd records of type Ratul> TABLE_DUMP (entire table dumps). it assumes BGP4MP (dumps of routing Ratul> updates). Ratul> - it does not support having updates from multiple peers in the same Ratul> mrtd file (as would be generated by a router with many peers). Ratul> please correct me if any of the above is wrong. none of it seems Ratul> insurmountable but i just wanted to ensure that i wasn't missing Ratul> something easier. Ratul> thanks. Ratul> Atanu Ghosh wrote: >> Hi, >> We use the test harness to load routes into BGP: >> >> Some examples of this are in bgp/harness/test_peering2.sh, test1 and >> test15 are the most interesting examples. These tests load data from >> mtrd format files. The tests by default also start the BGP process >> unless the "-s" argument is used. As an aside the gmake check target >> runs all these tests. >> The way that I currently load routes from mrtd files into BGP is to >> use >> the bgp/harness/harness.py script. >> 1) Configure BGP to accept a peering from the test peer. The XORP BGP >> can be configured to accept connections on ports other than 179 if you >> want to do everything on a single host. But you will need to edit the >> script to use a port number other than 179. >> 2) A number of processes need to be started. I typically use >> separate xterms. >> a) The finder process (libxipc/xorp_finder) if there is a router >> manager running on this host this step is not necessary. >> b) bgp/harness/coord >> c) bgp/harness/test_peer -s peer1 >> 3) The harness program can now be used to inject routes or even save >> routes from the BGP process. Many separate files can be loaded as the >> session is maintained by the test_peer not the harness program. >> $ ./test_harness.py -e -p bgp_host -a asnum -b bgp-id -i mtrd_file1 >> $ ./test_harness.py -p bgp_host -a asnum -b bgp-id -i mtrd_file12 >> Note the first time "-e" is used to establish the the session the >> second >> time the session exists. If you want to see the protocol packets then >> add "-v" to the list of test_peer arguments. >> We do not rewrite the contents of the MRTD file so the ASPATH in the >> file will need to be acceptable to the BGP process. >> This is the file used by our regression tests: >> >> Atanu. >> >>>>>>> "Ratul" == Ratul Mahajan writes: Ratul> hi - Ratul> what method do the developers/testers use to load complete Ratul> routing tables into xorp_bgp? Ratul> i want to load mrtd table_dumps and updates from >> routeviews Ratul> (the dumps have routes from multiple peers). i am wondering Ratul> what the best (fastest) way is to achieve this. Ratul> thanks. _______________________________________________ Ratul> Xorp-hackers mailing list Xorp-hackers@icir.org Ratul> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers@icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ratul@cs.washington.edu Mon Sep 19 06:23:26 2005 From: ratul@cs.washington.edu (Ratul Mahajan) Date: Sun, 18 Sep 2005 22:23:26 -0700 Subject: [Xorp-hackers] loading complete routing tables In-Reply-To: <84a612dd0509161422444a7af6@mail.gmail.com> References: <37506.1126885989@tigger.icir.org> <432B158D.4050208@cs.washington.edu> <84a612dd0509161422444a7af6@mail.gmail.com> Message-ID: <432E4B4E.3060603@cs.washington.edu> > Does this make sense? yes; i agree that the features i was looking for may not make sense from a functionality testing perspective. i wanted them to compare the performance of xorp and my-xorp (xorp with local modifications) under "realistic" conditions. for realism i wanted to use table_dumps and bgp_updates archived by routeviews. cheers. Mark Handley wrote: > > so i looked at the harness code some time back and came away with the > following impressions regarding the current code: > - it (harness/Peer::send_dump) does not support mtrd records of type > TABLE_DUMP (entire table dumps). it assumes BGP4MP (dumps of routing > updates). > - it does not support having updates from multiple peers in the same > mrtd file (as would be generated by a router with many peers). > > > Sounds like these serve different purposes. So far we've wanted to > test XORP, including the message parsing, so replaying update messages > is good for this purpose. > > What you describe is loading a previously stored router state. We could > in principle build such a load function into BGP for testing purposes. > As we're event-driven, this would have to be implemented by effectively > mapping the route state into update messages, or we'd not end up with > the right metadata stored in the routes. But a more tricky problem > concerns filters. There's no way to load state in after the import > filters as we only store routes prior to filtering. Thus the only way > to do a table load for a config file that was stored from a > post-import-filter table dumb would be to load it on a XORP router with > *no* import filters in place. This means you can't do it for a router > with EBGP peerings configured, because they must have filters. > > Thus I can't really see any way to load a table dump into a XORP BGP and > end upn with the correct behaviour unless that table dump were itself > stored from a XORP router, and hence represents pre-filtered routes. > Loading a post-filter table dump into a XORP router that had import > filters configured would end up with the filters being run on the stored > data, which simply won't result in the right behaviour. > > Does this make sense? > > - Mark > > From Mark Handley Mon Sep 19 18:28:19 2005 From: Mark Handley (Mark Handley) Date: Mon, 19 Sep 2005 18:28:19 +0100 Subject: [Xorp-hackers] Fwd: router worms and International Infrastructure In-Reply-To: <432EEBCF.5090206@linuxbox.org> References: <432EEBCF.5090206@linuxbox.org> Message-ID: <84a612dd05091910281d918a76@mail.gmail.com> ------=_Part_2677_3783867.1127150899188 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline An interesting thread about router worms on bugtraq at the moment (see=20 below) led me to wonder what we can do in XORP beyond what we're already=20 doing to defend against worms that propagate via routing protocols.=20 Obviously diversity is good here, but it seems unlikely that there will eve= r=20 be all that many different codebases out there. Especially not if we're=20 successful :-) Within the XORP architecture we can internally firewall processes, and we'v= e=20 done a little work here at UCL on XRL firewalling, so a process running in = a=20 Xen virtual machine or FreeBSD jail can only make certain XRL calls, and=20 only use certain parameters to these calls. The code isn't ready for=20 primetime, but this sort of internal partitioning is really only step 1. It= =20 should help prevent an infected routing process from infecting other routin= g=20 processes, but it doesn't stop the infected routing process from propagatin= g=20 a worm on to other routers via the same protocol. It seems like we might be able to take this further though. Already we=20 perform some of our networking calls indirectly through the FEA, so routing= =20 protocols don't need root access. It might be possible to add incoming and= =20 outgoing routing protocol firewalls. The incoming routing protocol firewall= =20 would accept incoming routing packets from the FEA, parse them, sanity chec= k=20 them, and then re-code them again back into the original protocol, before= =20 sending them on to the routing process. The hope is that any exploit would= =20 not make it to the routing protocol itself through the decode-and-re-encode= =20 process. A similar firewall in a separate process does the same thing for= =20 outgoing traffic.=20 What about infecting the protocol-specific firewall itself? Well we can=20 XRL-firewall the incoming protocol-specific firewall process, so that it=20 cannot send to the network - it can only receive, and only send on to its= =20 own routing process. Thus even if the firewall gets compromised, it would= =20 then need to separately infect the routing process, and then that would nee= d=20 to separately infect the outgoing firewall, before the worm could spread=20 router-to-router. >From a performance point of view, the actual parsing of routing packets=20 isn't a big deal, compared to everything else that goes on in a routing=20 protocol, so this shouldn't impact performance significantly. Comments? - Mark ---------- Forwarded message ---------- From: Gadi Evron Date: Sep 19, 2005 5:48 PM Subject: router worms and International Infrastructure [was: Re: IOS=20 exploit] To: bugtraq@securityfocus.com The text below is an email I just sent to the North American Network Operators Group. I believe asking for bugtraq's opinion is also critical. Thanks, Gadi. Michael.Dillon@btradianz.com wrote: > Reading through the original Russian posting here >=20 http://www.securitylab.ru/news/240415.php&direction=3Dre&template=3DGeneral= &cp1=3D > It seems that someone has built an IOS worm that > follows an EIGRP vector from router to router. A while back I emailed the following text to a closed mailing list. I figure now that quite a few cats are out of the bag it is time to get more public attention to these issues, as the Bad Guys will very soon start doing just that. Ciscogate by itself ALONE, and now even just a story about worms for Routers is enough for us to be CLEAR that worms will start coming out. We do learn from history. So.. as much as people don't like to talk much on the issues involving the so-called "cooler" stuff that can be done with routers, now is the time to start. Here is one possible and simple vector of attack that I see happening in the future. It goes down-hill from there. I wrote this after the release of "the three vulnerabilities", a few months back. Now we know one wasn't even just a DDoS, and that changes the picture a bit. Begin quoted text ----->>> More on router worms - let's take down the Internet with three public POCs and some open spybot source code. -------------------------------------- People, I have given this some more thought. Let's forget for a second the fact that these vulnerabilities are dangerous on their own (although it's a DoS), and consider what a worm, could cause. If the worm used the vulnerability, it would shoot itself in the leg as when network is down, it can't spread. Now, imagine if a VX-er will use an ancient trick and release the worm, waiting for it to propagate for 2 or 3 days. Then, after that seeding time when the say.. not very successful worm infected only about 30K machines around the world, each infected host will send out 3 "One Packet Killers" as I like to call them to the world. Even if the packet won't pass one router, that one router, along with thousands of others, will die. Further, the latest vulnerabilities are not just for Cisco, there is a "One Packer Killer" for Juniper as well. So, say this isn't a 0-day. Tier-1 and tier-2 ISP's are patched (great mechanism to pass through as these won't filter the packed out if it is headed somewhere else), how many of the rest will be up to date? Let's give the Internet a lot of credit and say.. 60% (yeah right). That leaves us with 30% of the Internet dead, and that's really a bad scenario as someone I know would say. Make each infected system send the one packet spoofed (potentially, not necessarily these vulnerabilities) and it's hell. Make them send it every day, once! And the net will keep dying every day for a while. As a friend suggested, maybe even fragment the packet, and have it re-assembled at the destination, far-away routers (not sure if that will work). These are all basic, actually very basic, techniques, and with the source to exploits and worms freely available.... We keep seeing network equipment vulnerabilities coming out, and it is a lot "cooler" to bring down an ISP with one packet rather than with 1,000,000,000,000,000. I am sure the guys at Cisco gave this some thought, but I don't believe this is getting enough attention generally, and especially not with AV-ers. It should. This may seem like I am hyping the situation, which is well-known. Still well-known or not, secret or not, it's time we prepared better in a broader scale. How? Gadi. ----->>> End quoted text. I would really like to hear some thoughts from the NANOG community on threats such as the one described above. Let us not get into an argument about 0-days and consider how many routers are actually patched the first... day.. week, month? after a vulnerability is released. Also, let us consider the ever decreasing vulnerability-2-exploit time of development. I don't want the above to sound as FUD. My point is not to yell "death of the Internet" but rather to get some people moving on what I believe to be a threat, and considering it on a broader scale is LONG over-due. The cat is out of the bag, as as much as I avoided using "potentially" and "possibly" above to pass my point.. this is just one possible scenario and I believe we need to start getting prepared to better defending the Internet as an International Infrastructure. As I am sure that this will be an interesting discussion, I am also sure this will eventually derail to a pointless argument over an un-related matter, here on NANOG. I'd appreciate if people who are interested would also email me off-list so that we can see how we can perhaps proceed with some activity. Thanks, Gadi Evron. -- Available for consulting: +972-50-5428610 / ge@linuxbox.org. ------=_Part_2677_3783867.1127150899188 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline An interesting thread about router worms on bugtraq at the moment (see below) led me to wonder what we can do in XORP beyond what we're already doing to defend against worms that propagate via routing protocols.  Obviously diversity is good here, but it seems unlikely that there will ever be all that many different codebases out there.  Especially not if we're successful :-)

Within the XORP architecture we can internally firewall processes, and we've done a little work here at UCL on XRL firewalling, so a process running in a Xen virtual machine or FreeBSD jail can only make certain XRL calls, and only use certain parameters to these calls.  The code isn't ready for primetime, but this sort of internal partitioning is really only step 1.  It should help prevent an infected routing process from infecting other routing processes, but it doesn't stop the infected routing process from propagating a worm on to other routers via the same protocol.

It seems like we might be able to take this further though.  Already we perform some of our networking calls indirectly through the FEA, so routing protocols don't need root access.  It might be possible to add incoming and outgoing routing protocol firewalls.  The incoming routing protocol firewall would accept incoming routing packets from the FEA, parse them, sanity check them, and then re-code them again back into the original protocol, before sending them on to the routing process. The hope is that any exploit would not make it to the routing protocol itself through the decode-and-re-encode process.  A similar firewall in a separate process does the same thing for outgoing traffic. 

What about infecting the protocol-specific firewall itself?  Well we can XRL-firewall the incoming protocol-specific firewall process, so that it cannot send to the network - it can only receive, and only send on to its own routing process.  Thus even if the firewall gets compromised, it would then need to separately infect the routing process, and then that would need to separately infect the outgoing firewall, before the worm could spread router-to-router.

>From a performance point of view, the actual parsing of routing packets isn't a big deal, compared to everything else that goes on in a routing protocol, so this shouldn't impact performance significantly.

Comments?

 - Mark

---------- Forwarded message ----------
From: Gadi Evron <ge@linuxbox.org>
Date: Sep 19, 20= 05 5:48 PM
Subject: router worms and International Infrastructure [was: Re: IOS ex= ploit]
To: bugtraq@security= focus.com

The text below is an email I just sent to the N= orth American Network
Operators Group. I believe asking for bugtraq's opinion is also critica= l.

Thanks,

        Ga= di.


Michael.Dill= on@btradianz.com wrote:
> Reading through the original Russian po= sting here
> http://www.securitylab.ru/news/240= 415.php&direction=3Dre&template=3DGeneral&cp1=3D
> It= seems that someone has built an IOS worm that
> follows an EIGRP vector from router to router.

A while back= I emailed the following text to a closed mailing list. I
figure now tha= t quite a few cats are out of the bag it is time to get
more public atte= ntion to these issues, as the Bad Guys will very soon
start doing just that.

Ciscogate by itself ALONE, and now even j= ust a story about worms for
Routers is enough for us to be CLEAR that wo= rms will start coming out.
We do learn from history.

So.. as much= as people don't like to talk much on the issues involving
the so-called "cooler" stuff that can be done with routers, n= ow is the
time to start.

Here is one possible and simple vector o= f attack that I see happening in
the future. It goes down-hill from ther= e.

I wrote this after the release of "the three vulnerabilities&q= uot;, a few
months back. Now we know one wasn't even just a DDoS, and th= at changes
the picture a bit.

Begin quoted text ----->>>

More on router worms - let's take down the Internet with three publ= ic
POCs and some open spybot source code.
---------------------------= -----------

People, I have given this some more thought.

Let's forget for a second the fact that these vulnerabilities are
danger= ous on their own (although it's a DoS), and consider what a worm,
could = cause.

If the worm used the vulnerability, it would shoot itself in = the leg as
when network is down, it can't spread.

Now, imagine if a VX-er w= ill use an ancient trick and release the worm,
waiting for it to propaga= te for 2 or 3 days. Then, after that seeding
time when the say.. not ver= y successful worm infected only about 30K
machines around the world, each infected host will send out 3 "One=
Packet Killers" as I like to call them to the world.

Even i= f the packet won't pass one router, that one router, along with
thousand= s of others, will die.

Further, the latest vulnerabilities are not just for Cisco, there i= s a
"One Packer Killer" for Juniper as well.

So, say th= is isn't a 0-day. Tier-1 and tier-2 ISP's are patched (great
mechanism t= o pass through as these won't filter the packed out if it is
headed somewhere else), how many of the rest will be up to date?
Let's give the Internet a lot of credit and say.. 60% (yeah right).
That leaves us with 30% of the Internet dead, and that's really a bad
scenario as someone I know would say.

Make each infected system send= the one packet spoofed (potentially, not
necessarily these vulnerabilit= ies) and it's hell. Make them send it
every day, once! And the net will = keep dying every day for a while.

As a friend suggested, maybe even fragment the packet, and have it<= br>re-assembled at the destination, far-away routers (not sure if that will=
work).

These are all basic, actually very basic, techniques, and= with the
source to exploits and worms freely available....
We keep seeing net= work equipment vulnerabilities coming out, and it is a
lot "cooler&= quot; to bring down an ISP with one packet rather than with
1,000,000,00= 0,000,000.

I am sure the guys at Cisco gave this some thought, but I don't bel= ieve
this is getting enough attention generally, and especially not with=
AV-ers. It should.

This may seem like I am hyping the situation,= which is well-known. Still
well-known or not, secret or not, it's time we prepared better in a
= broader scale.

How?

     Gadi.

---= -->>> End quoted text.

I would really like to hear some tho= ughts from the NANOG community on
threats such as the one described above. Let us not get into an argumen= t
about 0-days and consider how many routers are actually patched thefirst... day.. week, month? after a vulnerability is released.

Also, let us consider the ever decreasing vulnerability-2-exploit time
o= f development.

I don't want the above to sound as FUD. My point is n= ot to yell "death
of the Internet" but rather to get some peop= le moving on what I believe
to be a threat, and considering it on a broader scale is LONG over-due.=

The cat is out of the bag, as as much as I avoided using "pote= ntially"
and "possibly" above to pass my point.. this is = just one possible
scenario and I believe we need to start getting prepared to better
d= efending the Internet as an International Infrastructure.

As I am su= re that this will be an interesting discussion, I am also sure
this will= eventually derail to a pointless argument over an un-related
matter, here on NANOG.
I'd appreciate if people who are interested w= ould also email me off-list
so that we can see how we can perhaps procee= d with some activity.

Thanks,

     &= nbsp;  Gadi Evron.

--
Available for consulting:
+972-50-5428610 / ge@linuxbox.org.
------=_Part_2677_3783867.1127150899188-- From deathdealer@gmx.net Wed Sep 21 17:21:32 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Wed, 21 Sep 2005 18:21:32 +0200 Subject: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE Message-ID: <200509211622.j8LGM8cL023828@wyvern.icir.org> Hello, When I try to configure an existing or not existing gre interface on FreeBSD 5.4 Release Xorpsh dumps core. The Code is from today morning from cvs, the FreeBSD install is a Fresh install form CD without any patches. Error Message say RTRMGR +1812 conftree unique nodenum failed. I will post the logs tomorrow to bugzilla if needed. regards Patrick Marc Preuss From pavlin@icir.org Wed Sep 21 17:41:52 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 21 Sep 2005 09:41:52 -0700 Subject: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE In-Reply-To: Message from "Patrick Preuss" of "Wed, 21 Sep 2005 18:21:32 +0200." <200509211622.j8LGM8cL023828@wyvern.icir.org> Message-ID: <200509211641.j8LGfqHB067477@possum.icir.org> > When I try to configure an existing or not existing gre interface on > FreeBSD 5.4 Release > Xorpsh dumps core. The Code is from today morning from cvs, the FreeBSD > install is a > Fresh install form CD without any patches. > > Error Message say RTRMGR +1812 conftree unique nodenum failed. > > I will post the logs tomorrow to bugzilla if needed. Yes, please post the commands that lead to this error and the log message. Also, please check whether it is not the same bug as this one: http://www.xorp.org/bugzilla/show_bug.cgi?id=171 We are aware of the issue in bug 171 and hopefully it will be fixed today. Pavlin From deathdealer@gmx.net Thu Sep 22 06:55:22 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Thu, 22 Sep 2005 07:55:22 +0200 Subject: AW: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE In-Reply-To: <200509211641.j8LGfqHB067477@possum.icir.org> Message-ID: <200509220555.j8M5tbRC033903@wyvern.icir.org> Hello Yes thats right it is the same error message I have done: # ifconfig gre0 create # /usr/local/xorp/bin/xorpsh root@xorp# configure XORP> create interfaces interface gre0 Then the error ocurres Gruss    Patrick Marc Preuss Nordstrasse 28 41569 Rommerskirchen -----Ursprüngliche Nachricht----- Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im Auftrag von Pavlin Radoslavov Gesendet: Mittwoch, 21. September 2005 18:42 An: Patrick Preuss Cc: xorp-hackers@xorp.org Betreff: Re: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE > When I try to configure an existing or not existing gre interface on > FreeBSD 5.4 Release > Xorpsh dumps core. The Code is from today morning from cvs, the FreeBSD > install is a > Fresh install form CD without any patches. > > Error Message say RTRMGR +1812 conftree unique nodenum failed. > > I will post the logs tomorrow to bugzilla if needed. Yes, please post the commands that lead to this error and the log message. Also, please check whether it is not the same bug as this one: http://www.xorp.org/bugzilla/show_bug.cgi?id=171 We are aware of the issue in bug 171 and hopefully it will be fixed today. Pavlin _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Thu Sep 22 08:24:27 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 22 Sep 2005 00:24:27 -0700 Subject: AW: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE In-Reply-To: Message from "Patrick Preuss" of "Thu, 22 Sep 2005 07:55:22 +0200." <200509220555.j8M5tbRC033903@wyvern.icir.org> Message-ID: <200509220724.j8M7ORSp093874@possum.icir.org> > Hello > > Yes thats right it is the same error message > > I have done: > > # ifconfig gre0 create > # /usr/local/xorp/bin/xorpsh > root@xorp# configure > XORP> create interfaces interface gre0 > > Then the error ocurres To reproduce the problem with your setup please add your startup XORP configuration file to the bugzilla entry. Pavlin From deathdealer@gmx.net Thu Sep 22 12:49:20 2005 From: deathdealer@gmx.net (=?ISO-8859-1?Q?=22Patrick_Preu=DF=22?=) Date: Thu, 22 Sep 2005 13:49:20 +0200 (MEST) Subject: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE References: <200509220724.j8M7ORSp093874@possum.icir.org> Message-ID: <31966.1127389760@www80.gmx.net> > To reproduce the problem with your setup please add your startup > XORP configuration file to the bugzilla entry. Done! is it possible to exened the rtrmrg is aware of all interfaces in the system preset interfaces and the types of software interfaces witch can configured. most likely the os configured interfaces in the show interfaces marked as unconfigured or as os-unconfigured/xorp-unconfigured or stm. like that. -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner From pavlin@icir.org Tue Sep 27 20:15:43 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 27 Sep 2005 12:15:43 -0700 Subject: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE In-Reply-To: Message from =?ISO-8859-1?Q?=22Patrick_Preu=DF=22?= of "Thu, 22 Sep 2005 13:49:20 +0200." <31966.1127389760@www80.gmx.net> Message-ID: <200509271915.j8RJFheh030090@possum.icir.org> > > To reproduce the problem with your setup please add your startup > > XORP configuration file to the bugzilla entry. > > Done! Just for the record, the bug (#171) is fixed and committed to CVS. Please let me know if it still doesn't work for you. > is it possible to exened the rtrmrg is aware of all interfaces in the system > preset interfaces and the types of software interfaces witch can configured. > most likely the os configured interfaces in the show interfaces marked as > unconfigured or as os-unconfigured/xorp-unconfigured or stm. like that. The rtrmgr doesn't contain (by design) any information about the system itself (or any protocol/module specific information). All it contains is the configuration, the generic methods as defined in the rtrmgr templates to (re)configurure the system whenever the configuration is applied or modified, and the status of each running module. It looks like what you need is the "show interfaces" CLI command to show that information. Yes, it is possible and all that needs to be done is to modify the fea/tools/show_interfaces binary program to show that info. Please add a bugzilla "enhancement" entry with the above request. Thanks, Pavlin From deathdealer@gmx.net Wed Sep 28 07:52:00 2005 From: deathdealer@gmx.net (Patrick Preuss) Date: Wed, 28 Sep 2005 08:52:00 +0200 Subject: AW: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE In-Reply-To: <200509271915.j8RJFheh030090@possum.icir.org> Message-ID: <200509280652.j8S6qHg1025508@wyvern.icir.org> Hello Pavlin, > Just for the record, the bug (#171) is fixed and committed to CVS. Please > let me know if it still doesn't work for you. Thanks I will test it later this day. >> is it possible to exened the rtrmrg is aware of all interfaces in the system >> preset interfaces and the types of software interfaces witch can configured. >> most likely the os configured interfaces in the show interfaces marked as >> unconfigured or as os-unconfigured/xorp-unconfigured or stm. like that. > The rtrmgr doesn't contain (by design) any information about > the system itself (or any protocol/module specific information). All > it contains is the configuration, the generic methods as defined > in the rtrmgr templates to (re)configurure the system whenever the > configuration is applied or modified, and the status of each running > module. > It looks like what you need is the "show interfaces" CLI command to > show that information. Yes, it is possible and all that needs to be > done is to modify the fea/tools/show_interfaces binary program to > show that info. > Please add a bugzilla "enhancement" entry with the above request. Yes I will post something but I would prefer to discuss it in advance. I have though of something like a daemon "xorp_ifmgr" which does this work, and not the show interfaces command, because if you hardcode this into the show command you will have an os specific solution. What is if we have a distributed system, or we run the xorpsh on a different host witch is only aware of the rtrmgr? I think you will have problems in simulating routers. And for the discussion about the interface naming it will be possible to add an system or a convention to abstract the hardware interfaces from the Router so the ifmgr can hold a config, maybe private, witch says eth0 is FastEthernet0 with build in mac of 00:00:00:00:00:01 and is on pci bus 00:01:f, so if a physical interface changes or is added this can be reflected in the config and the running processes. Last point is, it would be nice that the rib/rtrmgr is aware of the kernel routes, so it would be possible to check the actual state of our routing table, like the junipers also do, may be a daemon. Regards, Patrick