From ghazanhaider@yahoo.com Thu Dec 2 00:01:38 2004 From: ghazanhaider@yahoo.com (Ghazan Haider) Date: Wed, 1 Dec 2004 16:01:38 -0800 (PST) Subject: [Xorp-hackers] Status of XORP Message-ID: <20041202000138.51062.qmail@web50606.mail.yahoo.com> I have been trying to compile Quagga for my setup until I ran into Xorp today. How usable and reliable is Xorp compared to Gated, Quagga and Zebra? The module status page says various modules are complete or almost complete. Does it mean it has recently been 'completed' but not tested so still Alpha, or complete as in just install it on a server, drop the server in a network and there you go? Where does it stand compared to the other three? (sure give me biased opnions but informed ones). With Quagga, I've been trying to compile it on a minimal Linux system for my 7 sparcstations, so I could boot them as tftpboot image, which may not be over 8mb. Elsewhere on this mailinglist I saw the installed base of XORP was 38MB. What goes into 38MB since projects like these have no 'content' and its all binaries? The Linux kernel is 2MB at best with all that functionality... Lastly has anyone compiled XORP for embedded systems? I saw two threads regarding ramspace, but none regarding diskspace. Is it reasonable to compile XORP for sparc, and expect all the binaries and libraries to be less than 5mb? __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From edrt@citiz.net Thu Dec 2 01:11:11 2004 From: edrt@citiz.net (edrt) Date: Thu, 2 Dec 2004 9:11:11 +0800 Subject: [Xorp-hackers] Status of XORP Message-ID: <200412020114.iB21EYeU068029@wyvern.icir.org> > >Lastly has anyone compiled XORP for embedded systems? > FYI, I compiled XORP on some embedded platforms. With MFEA+IGMP+PIM+Libxxx (all components shared the library in the same address space), the image is about 6M. Starting all the components (without learning any route/group) consume another 2M ramspace. Regards Eddy From ghazanhaider@yahoo.com Thu Dec 2 01:41:27 2004 From: ghazanhaider@yahoo.com (Ghazan Haider) Date: Wed, 1 Dec 2004 17:41:27 -0800 (PST) Subject: [Xorp-hackers] Status of XORP In-Reply-To: <200412020114.iB21EYeU068029@wyvern.icir.org> Message-ID: <20041202014127.77943.qmail@web50603.mail.yahoo.com> Thanks. I started compiling it on an Ultra5 (debian linux). Seems to be going well, but it wont do OSPFD, I'll try to force that somehow. Wont need the multicast protocols nor ipv6, only RIP2, OSPF and BGP4. Is there a way to statically compile? I didnt find a list of autoconf arguments except --disable-ipv6 which I used. I'm trying to avoid libc, busybox is static in the image. --- edrt wrote: > > > >Lastly has anyone compiled XORP for embedded > systems? > > > > FYI, I compiled XORP on some embedded platforms. > With MFEA+IGMP+PIM+Libxxx (all components shared the > library in > the same address space), the image is about 6M. > Starting all > the components (without learning any route/group) > consume another 2M > ramspace. > > > Regards > Eddy > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From atanu@ICSI.Berkeley.EDU Thu Dec 2 02:21:27 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 01 Dec 2004 18:21:27 -0800 Subject: [Xorp-hackers] Status of XORP In-Reply-To: Message from Ghazan Haider of "Wed, 01 Dec 2004 17:41:27 PST." <20041202014127.77943.qmail@web50603.mail.yahoo.com> Message-ID: <90916.1101954087@tigger.icir.org> Hi, Ghazan> I started compiling it on an Ultra5 (debian linux). Seems Ghazan> to be going well, but it wont do OSPFD, I'll try to force Ghazan> that somehow. Wont need the multicast protocols nor ipv6, Ghazan> only RIP2, OSPF and BGP4. We have never tried building on an Ultra5 (debian linux) system. XORP does build on Redhat Linux. We have never tried building on an Ultra5, we don't expect any byte order problems as we have run our regression tests on a PowerPC running Mac OS X. I wouldn't expect the OSPF to build; the OSPF is a port of John Moy's OSPF and only builds on FreeBSD. We are in the process of writing our own OSPF that we expect to have available 1st Quarter next year. Ghazan> Is there a way to statically compile? I didnt find a list of Ghazan> autoconf arguments except --disable-ipv6 which I used. I'm Ghazan> trying to avoid libc, busybox is static in the image. I'm not sure that I understand your question static compilation is the default. Atanu. From edrt@citiz.net Thu Dec 2 02:30:40 2004 From: edrt@citiz.net (edrt) Date: Thu, 2 Dec 2004 10:30:40 +0800 Subject: [Xorp-hackers] Status of XORP Message-ID: <200412020233.iB22XreU068899@wyvern.icir.org> > >Is there a way to statically compile? I didnt find a >list of autoconf arguments except --disable-ipv6 which >I used. I'm trying to avoid libc, busybox is static in >the image. > I actually port the selected source code to the target platform, not using autoconf to select component & building system. - Eddy From atanu@ICSI.Berkeley.EDU Thu Dec 2 03:05:55 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 01 Dec 2004 19:05:55 -0800 Subject: [Xorp-hackers] Status of XORP In-Reply-To: Message from Ghazan Haider of "Wed, 01 Dec 2004 16:01:38 PST." <20041202000138.51062.qmail@web50606.mail.yahoo.com> Message-ID: <11888.1101956755@tigger.icir.org> Hi, Ghazan> How usable and reliable is Xorp compared to Gated, Quagga Ghazan> and Zebra? The module status page says various modules are Ghazan> complete or almost complete. Does it mean it has recently Ghazan> been 'completed' but not tested so still Alpha, or complete Ghazan> as in just install it on a server, drop the server in a Ghazan> network and there you go? Where does it stand compared to Ghazan> the other three? (sure give me biased opnions but informed Ghazan> ones). XORP is the newest of the available options. My understanding is that Gated in longer under active development. Quagga is still under active development being newer than XORP it currently has more features. XORP provides multicast routing which is not available in Quagga/Zebra. We considered multicast and IPv6 to be as important as IPv4. The completed components have been tested and you will find regression tests (gmake check) in the source tree. All the IPv6 (Unicast and Multicast) and some of the IPv4 connectivity for our site will be going through a XORP router very soon. We have in the past run all of the XORP traffic through a XORP router and are about to again. Obviously there may still be problems but we are confident enough to run the code ourselves. Ghazan> With Quagga, I've been trying to compile it on a minimal Ghazan> Linux system for my 7 sparcstations, so I could boot them as Ghazan> tftpboot image, which may not be over 8mb. Elsewhere on this Ghazan> mailinglist I saw the installed base of XORP was 38MB. What Ghazan> goes into 38MB since projects like these have no 'content' Ghazan> and its all binaries? The Linux kernel is 2MB at best with Ghazan> all that functionality... A number of factors account for the large amount of disk space that is consumed. The binaries themselves are not stripped and with debugging information they can take a lot of disk space. Also we used to in the past build all the regression test binaries, we have a lot of regression tests. We are experimenting with shared libraries to try and reduce the memory footprint. Ghazan> Lastly has anyone compiled XORP for embedded systems? I saw Ghazan> two threads regarding ramspace, but none regarding Ghazan> diskspace. Is it reasonable to compile XORP for sparc, and Ghazan> expect all the binaries and libraries to be less than 5mb? I believe this has been answered. Atanu. From jmorillo@ac.upc.edu Thu Dec 2 15:39:08 2004 From: jmorillo@ac.upc.edu (=?iso-8859-1?q?Juli=E1n=20David=20=20Morillo=20Pozo?=) Date: Thu, 2 Dec 2004 16:39:08 +0100 Subject: [Xorp-hackers] FEA for Click Message-ID: <200412021639.08234.jmorillo@ac.upc.edu> Hi, I saw in the cvsweb that the XORP team (more precisely Pavlin) is working on the FEA for Click... when do you think there will be a working FEA for Click? (Maybe the implementation is working at the moment, but I saw many changes in the last days/hours). Thanks a lot. -- ============================================= Juli嫕 David Morillo Pozo PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnical University of Catalonia (UPC) Phone: +34-934017182 Fax: +34-934017055 URL: http://people.ac.upc.edu/jmorillo ============================================= From atanu@ICSI.Berkeley.EDU Fri Dec 3 21:55:44 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 03 Dec 2004 13:55:44 -0800 Subject: [Xorp-hackers] FEA for Click In-Reply-To: Message from =?iso-8859-1?q?Juli=E1n=20David=20=20Morillo=20Pozo?= of "Thu, 02 Dec 2004 16:39:08 +0100." <200412021639.08234.jmorillo@ac.upc.edu> Message-ID: <71354.1102110944@tigger.icir.org> Hi, Currently XORP will work with user space Click. In the next few days XORP should work with an in-kernel Click. Atanu. >>>>> "Juli嫕" == Juli嫕 David Morillo Pozo writes: Juli嫕> Hi, I saw in the cvsweb that the XORP team (more precisely Juli嫕> Pavlin) is working on the FEA for Click... when do you think Juli嫕> there will be a working FEA for Click? (Maybe the Juli嫕> implementation is working at the moment, but I saw many Juli嫕> changes in the last days/hours). Juli嫕> Thanks a lot. -- Juli嫕> ============================================= Juli嫕 David Juli嫕> Morillo Pozo PhD Student - Computer Networking Group Juli嫕> Department of Computer Architecture (DAC) Polytechnical Juli嫕> University of Catalonia (UPC) Phone: +34-934017182 Fax: Juli嫕> +34-934017055 URL: http://people.ac.upc.edu/jmorillo Juli嫕> ============================================= Juli嫕> _______________________________________________ Xorp-hackers Juli嫕> mailing list Xorp-hackers@icir.org Juli嫕> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Fri Dec 3 22:17:23 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Dec 2004 14:17:23 -0800 Subject: [Xorp-hackers] FEA for Click In-Reply-To: Message from =?iso-8859-1?q?Juli=E1n=20David=20=20Morillo=20Pozo?= of "Thu, 02 Dec 2004 16:39:08 +0100." <200412021639.08234.jmorillo@ac.upc.edu> Message-ID: <200412032217.iB3MHNqB006673@possum.icir.org> > I saw in the cvsweb that the XORP team (more precisely Pavlin) is working on > the FEA for Click... when do you think there will be a working FEA for Click? > (Maybe the implementation is working at the moment, but I saw many changes in > the last days/hours). Julian, I just committed the last major Click-related missing piece, so right now the FEA should work for both user-level and kernel-level Click. There are still few things that need polishing, but those will be addressed within few days or so. If you decide to give it a try now, make sure that your fea/click_socket.cc file is at least version 1.11, because the anon CVS repository is updated approx. once an hour or so. Currently, there is no documentation, but the sample config file below can be a starting point to play with. Basically, the model is: 1. You enable either "kernel-click" or "user-click" in your XORP configuration file. 2. If you want XORP to install the kernel-Click related stuff (the loading of the kernel modules, and the mounting of the Click file system), then make sure that "instal-on-startup" is set to true, that "kernel-click-modules" contains the list of ':' - separated files with the kernel modules, and that "mount-directory" points to the right place. Otherwise, just make sure that "mount-directory" is set properly. 3. If you want XORP to start the user-level binary for you (recommended), then make sure that "command-execute-on-startup" is set to true. 4. In all cases, make sure that "click-config-generator-file" points to an executable that can be used to generate the Click configuration on-the-fly. This executable should take XORP configuration as an input, and should generate the Click configuration that the FEA will install into Click. File xorp/fea/xorp_fea_click_config_generator is a sample AWK script that does this already, so it can be a starting point. Note that currently the above script parses only the "interfaces" XORP configuraton section. Of course, you can use any other implementation you want. The only assumptions that the XORP FEA has about the result Click configuration are that: (a) the forwarding table element is named "_xorp_rt" (b) the above element has two handlers "add" and "remove" for adding and removing the forwarding entries, and the configuration format for those handers is: add/remove For example, see element LinearIPLookup. (c) The mapping between the network interface name to the corresponding outgoing port on the _xorp_rt element starts from 0, and is ordered by the interface name. E.g., eth0 -> _xorp_rt[0], eth5 -> _xorp_rt[1], tun1 -> _xorp_rt[2], and so-on. Again, there are still few things that need polishing, and other things may change a bit, but the basic stuff should work now. If you give it a try, please let us know if you run into problems or if you have any suggestions for improvements/etc. Thanks, Pavlin interfaces { interface eth2 { description: "control interface" vif eth2 { address 10.2.0.4 { prefix-length: 24 broadcast: 10.255.255.255 } } } interface eth4 { description: "control interface" vif eth4 { address 10.7.0.1 { prefix-length: 24 broadcast: 10.255.255.255 } } } } fea { enable-unicast-forwarding4: true /* enable-unicast-forwarding6: true */ click { enabled: true click-config-generator-file: "/user/local/xorp/fea/xorp_fea_click_config_generator" kernel-click { enabled: true install-on-startup: true kernel-click-modules: "/path/to/proclikefs.o:/path/to/click.o" mount-directory: "/click" } user-click { enabled: false command-file: "/usr/local/bin/click" command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/dev/null" } } } protocols { static { route4 10.10.0.0/16 { nexthop: 10.2.0.2 } route4 10.20.0.0/16 { nexthop: 10.7.0.7 } } } From hoerdt@clarinet.u-strasbg.fr Sat Dec 4 12:04:52 2004 From: hoerdt@clarinet.u-strasbg.fr (Hoerdt Mickael) Date: Sat, 04 Dec 2004 13:04:52 +0100 Subject: [Xorp-hackers] MFEA for Click In-Reply-To: <200412032217.iB3MHNqB006673@possum.icir.org> References: <200412032217.iB3MHNqB006673@possum.icir.org> Message-ID: <41B1A7E4.1090401@clarinet.u-strasbg.fr> Hi, I would like to know the detailled status about the IPv4/IPv6 Click Multicast Forwarding Engine Abstraction : I have seen that it is in the TODO list in the MIT web site, but could someone tell me when he expect that to be integrated in the Xorp project and is there active development on it ? Regards, Hoerdt Mickael From pavlin@icir.org Sun Dec 5 19:39:31 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 05 Dec 2004 11:39:31 -0800 Subject: [Xorp-hackers] MFEA for Click In-Reply-To: Message from Hoerdt Mickael of "Sat, 04 Dec 2004 13:04:52 +0100." <41B1A7E4.1090401@clarinet.u-strasbg.fr> Message-ID: <200412051939.iB5JdVLf024592@possum.icir.org> > I would like to know the detailled status about the IPv4/IPv6 Click > Multicast Forwarding Engine > Abstraction : I have seen that it is in the TODO list in the MIT web > site, but could someone > tell me when he expect that to be integrated in the Xorp project and is > there active development > on it ? Hoerdt, Several people had expressed interest in the past to develop multicast support for Click, but so far nothing really happened (or at least I am not aware of any progress). Due to shortage of internal resources, we (the XORP project) cannot do the Click multicast support by ourselves hence we have to wait until somebody else takes over the task and implements it. Obviously, the MFEA support for Click (which is orthogonal from the unicast FEA support) cannot happen before Click itself supports multicast. For those of you who are looking for a design + implementation oriented project, note that the multicast support for Click is a task that is completely unexplored, so they can have lots of fun with the design. Of course, to do the task right, you would have to be familiar with both Click and multicast, so this can be an excellent opportunity to become an expert in both areas. If someone is willing to take over the multicast Click implementation, we (XORP) will be glad to collaborate on the subject (design, API, etc). Only serious inquiries please :) Thanks, Pavlin From xbr@info.ucl.ac.be Fri Dec 10 13:38:06 2004 From: xbr@info.ucl.ac.be (Xavier Brouckaert) Date: Fri, 10 Dec 2004 14:38:06 +0100 Subject: [Xorp-hackers] FEA for Click In-Reply-To: <200412032217.iB3MHNqB006673@possum.icir.org> References: <200412032217.iB3MHNqB006673@possum.icir.org> Message-ID: <1102685886.19115.33.camel@bush> --=-KJACK35fQ1FEQ9vH3cW2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pavlin, > If you give it a try, please let us know if you run into problems or > if you have any suggestions for improvements/etc. OK, I gave it a try and here are my problems when I want to use xorp combined with user-level click: There is no feedback that a click configuration file generated by the awk script is wrong. The side effect is that the control socket isn't listening, so I see "Could not open user-level Click socket: Connection refused." and xorp stops. Then, I ran the awk script alone on the xorp config you kindly gave in your email (that I modified to use user-level click). I launched click with the configuration and I saw these syntax errors: 1) no mac address in arpresponder/arpquerier 2) no mtu in ipfragmenter 3) from_device =3D Null and Null isn't a click element After having read the awk script, I made these modifications to my xorp config : 1) I added "mac : 1.1.1.1.1.1" and "mac : 2.2.2.2.2.2" in the interfaces clauses 2) I added "mtu : 1500" also in the interfaces clause 3) I added "enabled: true" in the vif sections. After that, awk produces a script that click prefers but there is still one problem : there are FromDevice(..) and ToDevice(..) elements that can't exist in a user-level click configuration. I'm blocked here. How do you do ? Thanks, Xavier --=-KJACK35fQ1FEQ9vH3cW2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBuaa90wy6WJnsH5oRAgGDAKCgcLc6Ym3SqTH8NgBQDCgHrAUYXwCgrJZA jzf8gnRrchRjIN7lu77SGT4= =427z -----END PGP SIGNATURE----- --=-KJACK35fQ1FEQ9vH3cW2-- From xbr@info.ucl.ac.be Fri Dec 10 13:45:05 2004 From: xbr@info.ucl.ac.be (Xavier Brouckaert) Date: Fri, 10 Dec 2004 14:45:05 +0100 Subject: [Xorp-hackers] FEA for Click In-Reply-To: <1102685886.19115.33.camel@bush> References: <200412032217.iB3MHNqB006673@possum.icir.org> <1102685886.19115.33.camel@bush> Message-ID: <1102686305.19115.35.camel@bush> --=-eM26PCyUkAncQkFBcGIF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > After that, awk produces a script that click prefers but there is still > one problem : there are FromDevice(..) and ToDevice(..) elements that > can't exist in a user-level click configuration. Oups, sorry, I remove what I said : it is possible to have FromDevice and ToDevice in user-level click configurations. Sorry, --=20 Xavier Brouckaert UCL --=-eM26PCyUkAncQkFBcGIF Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBuahg0wy6WJnsH5oRAi9yAKCYWPuSeLGay2NFVEB+sB7qr8DUywCgsBDC 8qvOtfgQJrQZPEDUyN2NySg= =T4Wh -----END PGP SIGNATURE----- --=-eM26PCyUkAncQkFBcGIF-- From pavlin@icir.org Fri Dec 10 18:39:44 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 10 Dec 2004 10:39:44 -0800 Subject: [Xorp-hackers] FEA for Click In-Reply-To: Message from Xavier Brouckaert of "Fri, 10 Dec 2004 14:38:06 +0100." <1102685886.19115.33.camel@bush> Message-ID: <200412101839.iBAIdid9081245@possum.icir.org> Xavier, > OK, I gave it a try and here are my problems when I want to use xorp > combined with user-level click: > > There is no feedback that a click configuration file generated by the > awk script is wrong. The side effect is that the control socket isn't > listening, so I see "Could not open user-level Click socket: Connection > refused." and xorp stops. How do you start user-level Click? Do you let XORP start the click binary with /dev/null as the startup-config-file, or do you specify your own startup-config-file ? If it is the former, XORP does verify the result of every configuration it writes into Click. If it is the latter, that particular file is basically used as the "-f config_file" argument to start user-level Click, so it is up to the user to verify that the Click config file is correct. > Then, I ran the awk script alone on the xorp config you kindly gave in > your email (that I modified to use user-level click). I launched click > with the configuration and I saw these syntax errors: > 1) no mac address in arpresponder/arpquerier > 2) no mtu in ipfragmenter Yes, even though the AWK script is intended to run on XORP configuration, it expects that each interface's configuration contains info about its MAC address and MTU. I will modify the AWK script to return an error if that info is missing. > 3) from_device =3D Null and Null isn't a click element Do you mean here "Null" or "NullDevice"? If a vif is not enabled, then the script will use element "NullDevice" which is a valid Click element. > After having read the awk script, I made these modifications to my xorp > config : > 1) I added "mac : 1.1.1.1.1.1" and "mac : 2.2.2.2.2.2" in the interfaces > clauses > 2) I added "mtu : 1500" also in the interfaces clause > 3) I added "enabled: true" in the vif sections. BTW, it appears to me that first you are running the AWK script by hand on the XORP configuration, and then you use the result Click config file to start Click itself. Yes, you could do it this way, but then indeed you have to specify "mac" and "mtu" in your XORP config file. If you let XORP do all the job for you, it will take care of the mac and mtu and you can get away without adding them to your XORP config file. About the "enabled" flag, it is a bug in the AWK script to assume that a vif is disabled if the "enabled: true" statement is missing. I will fix this shortly. Thanks, Pavlin From pavlin@icir.org Sat Dec 11 11:01:38 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 11 Dec 2004 03:01:38 -0800 Subject: [Xorp-hackers] FEA for Click In-Reply-To: Message from Pavlin Radoslavov of "Fri, 10 Dec 2004 10:39:44 PST." <200412101839.iBAIdid9081245@possum.icir.org> Message-ID: <200412111101.iBBB1c2t026469@possum.icir.org> > > Then, I ran the awk script alone on the xorp config you kindly gave in > > your email (that I modified to use user-level click). I launched click > > with the configuration and I saw these syntax errors: > > 1) no mac address in arpresponder/arpquerier > > 2) no mtu in ipfragmenter > > Yes, even though the AWK script is intended to run on XORP > configuration, it expects that each interface's configuration > contains info about its MAC address and MTU. > I will modify the AWK script to return an error if that info is > missing. > > After having read the awk script, I made these modifications to my xorp > > config : > > 1) I added "mac : 1.1.1.1.1.1" and "mac : 2.2.2.2.2.2" in the interfaces > > clauses > > 2) I added "mtu : 1500" also in the interfaces clause > > 3) I added "enabled: true" in the vif sections. > About the "enabled" flag, it is a bug in the AWK script to assume > that a vif is disabled if the "enabled: true" statement is > missing. I will fix this shortly. FYI, I just committed the above fixes (and few other) to the awk script, so now it should be more robust. Please let me know if you find any other errors. Thanks, Pavlin From xbr@info.ucl.ac.be Tue Dec 14 15:48:14 2004 From: xbr@info.ucl.ac.be (Xavier Brouckaert) Date: Tue, 14 Dec 2004 16:48:14 +0100 Subject: [Xorp-hackers] Segmentation fault at startup Message-ID: <1103039294.3419.19.camel@bush> --=-FTiZO6iJI/hST6mJUM4i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear XORP developers, I'm unable to run XORP with a CVS compiled today. I get this : $ sudo /home/xbr/intel/bin/xorp_rtrmgr -b config2.boot -v [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Boot file :=3D config2.boot [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Templates directory :=3D /home/xbr/intel/etc/templates [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Xrl targets directory :=3D /home/xbr/intel/xrl/targets [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Execute Xrls :=3D true [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Restart failed processes :=3D false [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Print verbose information :=3D true [ 2004/12/14 16:44:36 INFO xorp_rtrmgr:4834 RTRMGR +134 master_conf_tree.cc execute ] Changed modules: interfaces, fea [ 2004/12/14 16:44:36 TRACE xorp_rtrmgr RTRMGR ] New module: interfaces (/home/xbr/intel/fea/xorp_fea) Segmentation fault (core dumped) (gdb) bt #0 0xb7da174e in mallopt () from /lib/tls/libc.so.6 #1 0xb7da08c3 in malloc () from /lib/tls/libc.so.6 #2 0xb7eb8979 in __builtin_new () from /usr/lib/libstdc ++-libc6.2-2.so.3 #3 0x0808b341 in TaskManager::add_module (this=3D0x8411cb4, module_command=3D@0x83955e0) at task.cc:1247 #4 0x08075bf0 in MasterConfigTree::module_config_start (this=3D0x8411c50, module_name=3D@0x83fa640, result=3D@0xbfff8de4) at master_conf_tree.cc:955 #5 0x08073122 in MasterConfigTree::commit_changes_pass2 (this=3D0x8411c50) at master_conf_tree.cc:501 #6 0x080705ed in MasterConfigTree::execute (this=3D0x8411c50) at master_conf_tree.cc:137 #7 0x0806ff85 in MasterConfigTree::MasterConfigTree (this=3D0x8411c50, config_file=3D@0x82b4520, tt=3D0x82c03c0, mmgr=3D@0xbfffcdf8, xclient=3D@0xbfffcdec, global_do_exec=3Dtrue, verbose=3Dfalse) at master_conf_tree.cc:73 #8 0x0806c2d5 in Rtrmgr::run (this=3D0xbfffeed8) at main_rtrmgr.cc:311 #9 0x0806d8a0 in main (argc=3D3, argv=3D0xbfffefa4) at main_rtrmgr.cc:550 I tried on two linux x86 machines without success (both debian). I also tried with gcc-2.95 instead of gcc-3.3. My config2.boot is reduced to a minimum : interfaces { =20 interface eth1 { description: "eth1" enabled: true /* default-system-config */ vif eth1 { enabled: true address 10.2.0.2 { prefix-length: 24 broadcast: 10.0.0.255 enabled: true } } } } =20 fea { enable-unicast-forwarding4: true } =20 My configure argurment is "--prefix $HOME/intel" I'm not using anything weird and I haven't modified the code. Any idea ? Do I have a broken libc6 ? ------ Sidenote: when doing "make clean", fea/xorp_click_config_generator is deleted because it is considered as a binary program in the Makefile. So, I've got to "cvs up" before rebuilding the XORP tree...=20 ------ Thanks, --=20 Xavier Brouckaert UCL --=-FTiZO6iJI/hST6mJUM4i Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBvws+0wy6WJnsH5oRAl1OAJ47kGBl0dhGPi7m0gTxuaO1UdxXDgCfTfPg KoB+aYSZvXWFESpDmJMqvSw= =xmP4 -----END PGP SIGNATURE----- --=-FTiZO6iJI/hST6mJUM4i-- From pavlin@icir.org Tue Dec 14 22:51:30 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 14 Dec 2004 14:51:30 -0800 Subject: [Xorp-hackers] Segmentation fault at startup In-Reply-To: Message from Xavier Brouckaert of "Tue, 14 Dec 2004 16:48:14 +0100." <1103039294.3419.19.camel@bush> Message-ID: <200412142251.iBEMpUr7013783@possum.icir.org> > I'm unable to run XORP with a CVS compiled today. I get this : > > $ sudo /home/xbr/intel/bin/xorp_rtrmgr -b config2.boot -v > [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Boot > file :=3D config2.boot > [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Templates > directory :=3D /home/xbr/intel/etc/templates > [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Xrl targets > directory :=3D /home/xbr/intel/xrl/targets > [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Execute > Xrls :=3D true > [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Restart failed > processes :=3D false > [ 2004/12/14 16:44:35 TRACE xorp_rtrmgr RTRMGR ] Print verbose > information :=3D true > [ 2004/12/14 16:44:36 INFO xorp_rtrmgr:4834 RTRMGR +134 > master_conf_tree.cc execute ] Changed modules: interfaces, fea > [ 2004/12/14 16:44:36 TRACE xorp_rtrmgr RTRMGR ] New module: interfaces > (/home/xbr/intel/fea/xorp_fea) > Segmentation fault (core dumped) Xavier, Thanks for the bug report. The problem was in our side with some of the recent commits. Apparently, the code was working fine on FreeBSD, but was failing on Linux. After some investigation, we committed a temporary fix (from internal design's point of view) to the CVS repository, so now the code should be working. A better fix should follow in the future, but from user's perspective this should be invisible. Sorry about that. Occasionally, staying up-to-date with the most recent code has its downsides... > ------ > Sidenote: when doing "make clean", fea/xorp_click_config_generator is > deleted because it is considered as a binary program in the Makefile. > So, I've got to "cvs up" before rebuilding the XORP tree...=20 This one is fixed too. Thanks, Pavlin From xbr@info.ucl.ac.be Wed Dec 15 07:58:08 2004 From: xbr@info.ucl.ac.be (Xavier Brouckaert) Date: Wed, 15 Dec 2004 08:58:08 +0100 Subject: [Xorp-hackers] Segmentation fault at startup In-Reply-To: <200412142251.iBEMpUr7013783@possum.icir.org> References: <200412142251.iBEMpUr7013783@possum.icir.org> Message-ID: <1103097488.12166.9.camel@bush> --=-Y8SxO00877tiLwOrM/QG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Thanks for the bug report. The problem was in our side with some of > the recent commits. Apparently, the code was working fine on > FreeBSD, but was failing on Linux. > After some investigation, we committed a temporary fix (from > internal design's point of view) to the CVS repository, > so now the code should be working. A better fix should follow in the > future, but from user's perspective this should be invisible. Great! > Sorry about that. Occasionally, staying up-to-date with the most > recent code has its downsides... I need the experimental features so it's normal to have this sort of problems. Luckily, XORP devs debug their code faster than light ;-) > > ------ > > Sidenote: when doing "make clean", fea/xorp_click_config_generator is > > deleted because it is considered as a binary program in the Makefile. > > So, I've got to "cvs up" before rebuilding the XORP tree...=3D20 >=20 > This one is fixed too. Great too !=20 Thank you, --=20 Xavier Brouckaert UCL --=-Y8SxO00877tiLwOrM/QG Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBv+6Q0wy6WJnsH5oRAqLjAKCae2AHYH/c1N16ypLbyKh9YQFBAwCgnqmk Zf7teeiGJsVxtTRmc5mqw2o= =i0Lx -----END PGP SIGNATURE----- --=-Y8SxO00877tiLwOrM/QG-- From xbr@info.ucl.ac.be Wed Dec 15 12:57:01 2004 From: xbr@info.ucl.ac.be (Xavier Brouckaert) Date: Wed, 15 Dec 2004 13:57:01 +0100 Subject: [Xorp-hackers] How to have a click + xorp compatible configuration ? Message-ID: <1103115422.12749.57.camel@bush> --=-d5Et/T/OYBj1BdfgjaDz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pavlin, Now that XORP CVS runs again, I'm retrying to use click and before writing my own config files, I'd like to run yours successfully (the one you gave in a previous email). What I'm facing is that I can't have a xorp configuration that is both xorp and click compatible. My configuration is like this currently : interfaces { interface eth0 { description: "control interface" vif eth0 { address 10.2.0.4 { prefix-length: 24 broadcast: 10.255.255.255 } } mac: 1:1:1:1:1:1 mtu: 1500 } interface eth1 { description: "control interface" vif eth1 { address 10.7.0.1 { prefix-length: 24 broadcast: 10.255.255.255 } } mac: 2:2:2:2:2:2 mtu: 1500 } } fea { enable-unicast-forwarding4: true /* enable-unicast-forwarding6: true */ click { enabled: true click-config-generator-file: "/home/xbr/intel/fea/xorp_fea_click_config_generator" kernel-click { enabled: false install-on-startup: false kernel-click-modules: "/path/to/proclikefs.o:/path/to/click.o" mount-directory: "/click" } user-click { enabled: true command-file: "/home/xbr/intel/bin/click" command-extra-arguments: "-R -p 13000" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/dev/null" } } } protocols { static { route4 10.10.0.0/16 { nexthop: 10.2.0.2 } route4 10.20.0.0/16 { nexthop: 10.7.0.7 } } } The difference with yours are : - I use user-click instead of kernel-click - I added the mtu and mac in both interfaces sections xorp_fea_click_config_generator processes this configuration nicely and gives a correct click configuration. =20 However, when I run "xorp_rtrmgr -b config.xorp", XORP doesn't like the new mtu and mac syntax and I get : [ 2004/12/15 13:43:28 ERROR xorp_rtrmgr:206 RTRMGR +357 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config File /hosthome/config.xorp, line 10]: syntax error; Last symbol parsed was "10.255.255.255" I can't remove the mtu and mac, else xorp_fea_click_config_generator will complain... What's the trick ? Thanks, --=20 Xavier Brouckaert UCL --=-d5Et/T/OYBj1BdfgjaDz Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBwDSd0wy6WJnsH5oRAixtAJ91QHJXxwLVjxSEhwQw8A1WiGUaDgCgo0XU IkS6PdBt0oENK61vrBqQA9A= =f1sk -----END PGP SIGNATURE----- --=-d5Et/T/OYBj1BdfgjaDz-- From pavlin@icir.org Wed Dec 15 13:46:40 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 15 Dec 2004 05:46:40 -0800 Subject: [Xorp-hackers] How to have a click + xorp compatible configuration ? In-Reply-To: Message from Xavier Brouckaert of "Wed, 15 Dec 2004 13:57:01 +0100." <1103115422.12749.57.camel@bush> Message-ID: <200412151346.iBFDkeYs089943@possum.icir.org> Xavier, > Now that XORP CVS runs again, I'm retrying to use click and before > writing my own config files, I'd like to run yours successfully (the one > you gave in a previous email). What I'm facing is that I can't have a > xorp configuration that is both xorp and click compatible. > > My configuration is like this currently : > interfaces { > interface eth0 { > description: "control interface" > vif eth0 { > address 10.2.0.4 { > prefix-length: 24 > broadcast: 10.255.255.255 > } > } > mac: 1:1:1:1:1:1 Try to use 01:01:01:01:01:01 instead. It appears that currently the parser doesn't accept the former format. This should be fixed shortly. Though, I just did a quick test, and explicitly setting the MAC address in the XORP configuration may trigger another bug (unless eth0 is down). Hence, for the time being I'd recommend that you don't specify the mac and mtu inside the XORP configuration, and let the FEA deal with that. After the above two problems are fixed, then you can add them back safely. > user-click { > enabled: true > command-file: "/home/xbr/intel/bin/click" > command-extra-arguments: "-R -p 13000" Note that you shouldn't add "-p 13000" to the extra arguments. The FEA itself will supply the "-p " arguments. If the -p flag is supplied twice, then the "click" binary will fail to start. Thanks, Pavlin > command-execute-on-startup: true > control-address: 127.0.0.1 > control-socket-port: 13000 > startup-config-file: "/dev/null" > } > } > } From rafael.guimaraes@ac.upc.edu Wed Dec 15 16:19:37 2004 From: rafael.guimaraes@ac.upc.edu (Rafael Paoliello Guimaraes) Date: Wed, 15 Dec 2004 17:19:37 +0100 Subject: [Xorp-hackers] Problems migrating a routing protocol... Message-ID: <41C06419.7060602@ac.upc.edu> Hello, I am currently migrating a routing process to XORP and I am facing some problems that I do not know how to solve, so I though that maybe somebody could help me... What I did was to change as little as possible the original implementation of the routing process. So, what I did is to create a thread that is responsible to interfacing between my routing process and XORP. It registers the protocol within XORP and keeps the eventloop. The only change in the original routing process (besides creating this new thread) is in the add/del routes functions. Now, these functions send the route to be added/deleted to the new thread through a pipe. The thread processes this route and adds or deletes the route in XORP by calling the appropriate XRL. In fact, this thread is almost the equal to static_routes. The only difference is that it receives routes to add/delete from the pipe. Well, this is what I have done so far and, I think it should work fine, but for some reason, it doesn't. Below you can see the report from the router manager. The first occurence is during the registration of the new protocol (do I have to change anything in the RIB so that it knows about this new protocol?). [ 2004/12/15 16:47:09 ERROR xorp_rib:2140 RIB +132 rib.cc admin_distance ] Administrative distance of "test" unknown. Then, when I add a new route (unicast) , it seems to send the XRL correctly, but the callback is never called... success = _xrl_rib_client.send_add_interface_route4( _rib_target.c_str(), TestNode::protocol_name(), true /* unicast */, false /* multicast */, test_route.network().get_ipv4net(), test_route.nexthop().get_ipv4(), test_route.ifname(), test_route.vifname(), test_route.metric(), callback(this, &XrlTestNode::send_rib_route_change_cb)); Some seconds after this, I get the following report in the router manager: [ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2004/12/15 16:47:46 INFO xorp_rib RIB ] Received death event for protocol test shutting down ------- OriginTable: test IGP next table = Redist:test It seems to me that the RIB tries to call the callback function I have sent in the send_add_interface_route4 call, but for some reason it times-out. And finally, the router manager thinks that my routing protocol died, but in fact it keeps running as nothing has happened. Does anybody have any idea of what could be happening? Why the RIB can not call the callback function? Cheers, -- =========================================== Rafael Paoliello Guimaraes PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnic University of Catalonia (UPC) Phone: +34-934017187 Fax: +34-934017055 URL: http://people.ac.upc.es/rpaoliel =========================================== From rafael.guimaraes@ac.upc.edu Wed Dec 15 16:11:45 2004 From: rafael.guimaraes@ac.upc.edu (Rafael Paoliello Guimaraes) Date: Wed, 15 Dec 2004 17:11:45 +0100 Subject: [Xorp-hackers] Problems migrating a routing protocol... Message-ID: <41C06241.5030800@ac.upc.es> Hello, I am currently migrating a routing process to XORP and I am facing some problems that I do not know how to solve, so I though that maybe somebody could help me... What I did was to change as little as possible the original implementation of the routing process. So, what I did is to create a thread that is responsible to interfacing between my routing process and XORP. It registers the protocol within XORP and keeps the eventloop. The only change in the original routing process (besides creating this new thread) is in the add/del routes functions. Now, these functions send the route to be added/deleted to the new thread through a pipe. The thread processes this route and adds or deletes the route in XORP by calling the appropriate XRL. In fact, this thread is almost the equal to static_routes. The only difference is that it receives routes to add/delete from the pipe. Well, this is what I have done so far and, I think it should work fine, but for some reason, it doesn't. Below you can see the report from the router manager. The first occurence is during the registration of the new protocol (do I have to change anything in the RIB so that it knows about this new protocol?). [ 2004/12/15 16:47:09 ERROR xorp_rib:2140 RIB +132 rib.cc admin_distance ] Administrative distance of "test" unknown. Then, when I add a new route (unicast) , it seems to send the XRL correctly, but the callback is never called... success = _xrl_rib_client.send_add_interface_route4( _rib_target.c_str(), TestNode::protocol_name(), true /* unicast */, false /* multicast */, test_route.network().get_ipv4net(), test_route.nexthop().get_ipv4(), test_route.ifname(), test_route.vifname(), test_route.metric(), callback(this, &XrlTestNode::send_rib_route_change_cb)); Some seconds after this, I get the following report in the router manager: [ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2004/12/15 16:47:46 INFO xorp_rib RIB ] Received death event for protocol test shutting down ------- OriginTable: test IGP next table = Redist:test It seems to me that the RIB tries to call the callback function I have sent in the send_add_interface_route4 call, but for some reason it times-out. And finally, the router manager thinks that my routing protocol died, but in fact it keeps running as nothing has happened. Does anybody have any idea of what could be happening? Why the RIB can not call the callback function? Cheers, -- =========================================== Rafael Paoliello Guimaraes PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnic University of Catalonia (UPC) Phone: +34-934017187 Fax: +34-934017055 URL: http://people.ac.upc.es/rpaoliel =========================================== From pavlin@icir.org Wed Dec 15 23:30:25 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 15 Dec 2004 15:30:25 -0800 Subject: [Xorp-hackers] Problems migrating a routing protocol... In-Reply-To: Message from Rafael Paoliello Guimaraes of "Wed, 15 Dec 2004 17:11:45 +0100." <41C06241.5030800@ac.upc.es> Message-ID: <200412152330.iBFNUPm3097970@possum.icir.org> Rafael, > I am currently migrating a routing process to XORP and I am facing some > problems that I do not know how to solve, so I though that maybe > somebody could help me... What I did was to change as little as possible > the original implementation of the routing process. So, what I did is to > create a thread that is responsible to interfacing between my routing > process and XORP. It registers the protocol within XORP and keeps the > eventloop. The only change in the original routing process (besides > creating this new thread) is in the add/del routes functions. Now, these > functions send the route to be added/deleted to the new thread through a > pipe. The thread processes this route and adds or deletes the route in > XORP by calling the appropriate XRL. In fact, this thread is almost the > equal to static_routes. The only difference is that it receives routes > to add/delete from the pipe. > > Well, this is what I have done so far and, I think it should work fine, > but for some reason, it doesn't. > > Below you can see the report from the router manager. The first > occurence is during the registration of the new protocol (do I have to > change anything in the RIB so that it knows about this new protocol?). > > [ 2004/12/15 16:47:09 ERROR xorp_rib:2140 RIB +132 rib.cc > admin_distance ] Administrative distance of "test" unknown. You can get rid of the above error by adding the appropriate line to constructor RIB::RIB() inside rib.cc : _admin_distances["your_protocol_name"] = ; Unfortunately, currently all protocol admin distances are hard-coded inside rib.cc. This should be fixed in the future. Though, I believe the above error message is not related to the next error... > > Then, when I add a new route (unicast) , it seems to send the XRL > correctly, but the callback is never called... > > success = _xrl_rib_client.send_add_interface_route4( > _rib_target.c_str(), > TestNode::protocol_name(), > true /* unicast */, > false /* multicast */, > test_route.network().get_ipv4net(), > test_route.nexthop().get_ipv4(), > test_route.ifname(), > test_route.vifname(), > test_route.metric(), > callback(this, > &XrlTestNode::send_rib_route_change_cb)); > > Some seconds after this, I get the following report in the router manager: > > [ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 > finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 > finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2004/12/15 16:47:46 INFO xorp_rib RIB ] Received death event for > protocol test shutting down ------- > OriginTable: test > IGP > next table = Redist:test > > It seems to me that the RIB tries to call the callback function I have > sent in the send_add_interface_route4 call, but for some reason it > times-out. And finally, the router manager thinks that my routing > protocol died, but in fact it keeps running as nothing has happened. > Does anybody have any idea of what could be happening? Why the RIB can > not call the callback function? It looks to me that the XORP eventloop in your process is not running properly, hence your process doesn't respond to the FINDER periodic probes, and it fails to process the XRL result from the RIB response. When you integrate the XORP eventloop in your process, make sure that this eventloop is run promptly. Regards, Pavlin From pavlin@icir.org Wed Dec 15 23:51:05 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 15 Dec 2004 15:51:05 -0800 Subject: [Xorp-hackers] How to have a click + xorp compatible configuration ? In-Reply-To: Message from Pavlin Radoslavov of "Wed, 15 Dec 2004 05:46:40 PST." <200412151346.iBFDkeYs089943@possum.icir.org> Message-ID: <200412152351.iBFNp5et098123@possum.icir.org> > > Now that XORP CVS runs again, I'm retrying to use click and before > > writing my own config files, I'd like to run yours successfully (the one > > you gave in a previous email). What I'm facing is that I can't have a > > xorp configuration that is both xorp and click compatible. > > > > My configuration is like this currently : > > interfaces { > > interface eth0 { > > description: "control interface" > > vif eth0 { > > address 10.2.0.4 { > > prefix-length: 24 > > broadcast: 10.255.255.255 > > } > > } > > mac: 1:1:1:1:1:1 > > Try to use 01:01:01:01:01:01 instead. > It appears that currently the parser doesn't accept the former > format. This should be fixed shortly. > Though, I just did a quick test, and explicitly setting the MAC > address in the XORP configuration may trigger another bug (unless > eth0 is down). > > Hence, for the time being I'd recommend that you don't specify the > mac and mtu inside the XORP configuration, and let the FEA deal with > that. After the above two problems are fixed, then you can add them > back safely. Now both problems are fixed, so you should be able to add the Mac address in either format. Thanks, Pavlin From M.Handley@cs.ucl.ac.uk Thu Dec 16 08:57:44 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 16 Dec 2004 08:57:44 +0000 Subject: [Xorp-hackers] Problems migrating a routing protocol... In-Reply-To: Your message of "Wed, 15 Dec 2004 17:19:37 +0100." <41C06419.7060602@ac.upc.edu> Message-ID: <78365.1103187464@vulture.xorp.org> >Some seconds after this, I get the following report in the router manager: > >[ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 >finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out >[ 2004/12/15 16:47:46 ERROR xorp_rtrmgr:2116 FINDER +85 >finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out >[ 2004/12/15 16:47:46 INFO xorp_rib RIB ] Received death event for >protocol test shutting down ------- >OriginTable: test >IGP >next table = Redist:test > >It seems to me that the RIB tries to call the callback function I have >sent in the send_add_interface_route4 call, but for some reason it >times-out. And finally, the router manager thinks that my routing >protocol died, but in fact it keeps running as nothing has happened. >Does anybody have any idea of what could be happening? Why the RIB can >not call the callback function? The most likely problem is that the eventloop isn't getting control frequently enough. If your process is single-threaded, then the eventloop needs to be at the heart of the process. Normally the main execution loop should look something like: while (!_done) { _eventloop.run(); } Then everything else is a call back from a registered timer or a event handler. You then need to make sure that all event handlers do return, and that they all return withing a second or so. If you need an event handler to take longer than that, then there are techniques we use, but I won't go in to detail on those here unless you think that might be the problem. But it sounds like your code actually has a separate thread for the XORP IPC handling. So long as that thread is running, and has a main execution loop something like the one above, then things *should* work right. The error: >[ 2004/12/15 16:47:46 INFO xorp_rib RIB ] Received death event for >protocol test shutting down ------- indicates that the XORP finder has decided your process is dead, and has then told the run. The XRL library code sends keepalives to the finder, so probably the finder didn't get a keepalive. If your process is still alive and active, then this is almost always because the eventloop didn't get executed for more than 30 seconds or so, or the XrlRouter you created to maintain the link with the finder has been deleted. Cheers, Mark From pavlin@icir.org Fri Dec 17 06:24:26 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 16 Dec 2004 22:24:26 -0800 Subject: [Xorp-hackers] HEADS UP: FEA Click configuration changes Message-ID: <200412170624.iBH6OQtv069328@possum.icir.org> Important only for those who use XORP + Click. Recently there have been few improvements to the FEA Click support. The major change is that now the FEA supports the enabling of both kernel-level and user-level Click (which is perfectly legitimate). As a result of that change, now the XORP FEA/Click configuration syntax is slightly different from the example that was sent to the mailing list about a week ago. OLD CONFIG: fea { ... click { ... click-config-generator-file: "/path/to/config_generator" } ... } NEW CONFIG: fea { ... click { ... kernel-click { ... kernel-click-config-generator-file: "/path/to/kernel_config_generator" } user-click { ... user-click-config-generator-file: "/path/to/user_config_generator" } } .... } For completness, below I am including an example with the new syntax. The example is available also from xorp/rtrmgr/config.boot.sample Regards, Pavlin /* * XORP Click FEA configuration example */ fea { enable-unicast-forwarding4: true /* enable-unicast-forwarding6: true */ click { enabled: true /* * Note: If both kernel-click and user-click are enabled, then * typically kernel-click-config-generator-file and * user-click-config-generator-file should point to different * generator files. Otherwise, a single common generator * wouldn't know whether to generate configuration for kernel-level * Click or for user-level Click. */ kernel-click { enabled: false install-on-startup: true kernel-click-modules: "/path/to/proclikefs.o:/path/to/click.o" /* XXX: On FreeBSD we need only module click.ko */ /* kernel-click-modules: "/path/to/click.ko" */ mount-directory: "/click" kernel-click-config-generator-file: "/user/local/xorp/fea/xorp_fea_click_config_generator" } user-click { enabled: true command-file: "/usr/local/bin/click" /* * Note: don't add "-p " as an extra argument, because it * will conflict with the FEA's addition of the same argument. */ command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/dev/null" user-click-config-generator-file: "/user/local/xorp/fea/xorp_fea_click_config_generator" } } } From gernot.schmied@chello.at Fri Dec 17 11:39:48 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Fri, 17 Dec 2004 12:39:48 +0100 Subject: [Xorp-hackers] HEADS UP: FEA Click configuration changes In-Reply-To: <200412170624.iBH6OQtv069328@possum.icir.org> References: <200412170624.iBH6OQtv069328@possum.icir.org> Message-ID: <41C2C584.5080904@chello.at> Pavlin Radoslavov wrote: > Important only for those who use XORP + Click. > > Recently there have been few improvements to the FEA Click support. > The major change is that now the FEA supports the enabling of both > kernel-level and user-level Click (which is perfectly legitimate). > > As a result of that change, now the XORP FEA/Click configuration > syntax is slightly different from the example that was sent to the > mailing list about a week ago. > > OLD CONFIG: > fea { > ... > click { > ... > click-config-generator-file: "/path/to/config_generator" > } > ... > } > > NEW CONFIG: > fea { > ... > click { > ... > kernel-click { > ... > kernel-click-config-generator-file: "/path/to/kernel_config_generator" > } > user-click { > ... > user-click-config-generator-file: "/path/to/user_config_generator" > } > } > .... > } > > > For completness, below I am including an example with the new > syntax. The example is available also from > xorp/rtrmgr/config.boot.sample > > Regards, > Pavlin > > > /* > * XORP Click FEA configuration example > */ > fea { > enable-unicast-forwarding4: true > /* enable-unicast-forwarding6: true */ > > click { > enabled: true > > /* > * Note: If both kernel-click and user-click are enabled, then > * typically kernel-click-config-generator-file and > * user-click-config-generator-file should point to different > * generator files. Otherwise, a single common generator > * wouldn't know whether to generate configuration for kernel-level > * Click or for user-level Click. > */ > kernel-click { > enabled: false > install-on-startup: true > kernel-click-modules: "/path/to/proclikefs.o:/path/to/click.o" > /* XXX: On FreeBSD we need only module click.ko */ > /* kernel-click-modules: "/path/to/click.ko" */ > mount-directory: "/click" > kernel-click-config-generator-file: "/user/local/xorp/fea/xorp_fea_click_config_generator" > } > > user-click { > enabled: true > command-file: "/usr/local/bin/click" > /* > * Note: don't add "-p " as an extra argument, because it > * will conflict with the FEA's addition of the same argument. > */ > command-extra-arguments: "-R" > command-execute-on-startup: true > control-address: 127.0.0.1 > control-socket-port: 13000 > startup-config-file: "/dev/null" > user-click-config-generator-file: "/user/local/xorp/fea/xorp_fea_click_config_generator" > } > } > } > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > Hi Pavlin, Sounds like a lot of cool new features for XORP 1.1 (or will it be 2.0?). Do you folks already have a vague idea about the next release date of XORP, would be interesten in hearing what's happening on the OSPF and multicast arena (IGMPv3, MLDv2, ...) and the planned features until then. By the way, any progress on the AMD64 front? Any success stories so far for compiling it on AMD64? It still fails miserably on my machine :-(. Merry Xmas from Vienna, Gernot From atanu@ICSI.Berkeley.EDU Sat Dec 18 02:11:52 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 17 Dec 2004 18:11:52 -0800 Subject: [Xorp-hackers] HEADS UP: FEA Click configuration changes In-Reply-To: Message from "Gernot W. Schmied" of "Fri, 17 Dec 2004 12:39:48 +0100." <41C2C584.5080904@chello.at> Message-ID: <39355.1103335912@tigger.icir.org> Gernot> Sounds like a lot of cool new features for XORP 1.1 (or will Gernot> it be 2.0?). Do you folks already have a vague idea about Gernot> the next release date of XORP, would be interesten in Gernot> hearing what's happening on the OSPF and multicast arena Gernot> (IGMPv3, MLDv2, ...) and the planned features until then. Gernot> By the way, any progress on the AMD64 front? Any success Gernot> stories so far for compiling it on AMD64? It still fails Gernot> miserably on my machine :-(. Our intention is to roll a 1.1-RC in mid January. We are working on OSPF its not yet clear if it will make it into the 1.1-RC. We will be working on IGMPv3 and MLDv2 in the background. We don't have any AMD64 systems if you would like to give us an account on your machine we can take a look. Atanu. From gernot.schmied@chello.at Sat Dec 18 12:35:39 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Sat, 18 Dec 2004 13:35:39 +0100 Subject: [Xorp-hackers] HEADS UP: FEA Click configuration changes In-Reply-To: <39355.1103335912@tigger.icir.org> References: <39355.1103335912@tigger.icir.org> Message-ID: <41C4241B.602@chello.at> Atanu Ghosh wrote: > Gernot> Sounds like a lot of cool new features for XORP 1.1 (or will > Gernot> it be 2.0?). Do you folks already have a vague idea about > Gernot> the next release date of XORP, would be interesten in > Gernot> hearing what's happening on the OSPF and multicast arena > Gernot> (IGMPv3, MLDv2, ...) and the planned features until then. > Gernot> By the way, any progress on the AMD64 front? Any success > Gernot> stories so far for compiling it on AMD64? It still fails > Gernot> miserably on my machine :-(. > > Our intention is to roll a 1.1-RC in mid January. > > We are working on OSPF its not yet clear if it will make it into the > 1.1-RC. We will be working on IGMPv3 and MLDv2 in the background. > > We don't have any AMD64 systems if you would like to give us an account > on your machine we can take a look. > > Atanu. Hi Atanu, Thank you for the reply. Unfortunately my AMD64 system is a production system with very sensible data, so I can't grant access to that system. As soon as I have another system in the lab up and running I'll give you access for sure. I am very eager to get my hands on the 1.1 version, 1.0 is running very satisfying so far, great job, nice architecture. Merry Xmas to California, Gernot From gernot.schmied@chello.at Mon Dec 20 20:34:56 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Mon, 20 Dec 2004 21:34:56 +0100 Subject: [Xorp-hackers] Compile failure on FreeBSD 5.3 Message-ID: <41C73770.5090308@chello.at> Just want to report this compile failure on FreeBSD 5.3/Intel P4. g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qua l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-20 -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo './'`mfea_proto_comm .cc mfea_proto_comm.cc: In member function `int ProtoComm::proto_socket_write(uint16 _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)': mfea_proto_comm.cc:1521: error: cannot bind packed field `ip->ip::ip_src' to `in _addr&' mfea_proto_comm.cc:1522: error: cannot bind packed field `ip->ip::ip_dst' to `in _addr&' gmake[3]: *** [mfea_proto_comm.o] Error 1 gmake[3]: Leaving directory `/usr/local/src/xorp-1.0/fea' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/local/src/xorp-1.0/fea' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/xorp-1.0' gmake: *** [all] Error 2 Regards, Gernot From Vlad GALU Tue Dec 21 05:25:35 2004 From: Vlad GALU (Vlad GALU) Date: Tue, 21 Dec 2004 07:25:35 +0200 Subject: [Xorp-hackers] Re: [Xorp-users] Compile failure on FreeBSD 5.3 In-Reply-To: <41C73770.5090308@chello.at> References: <41C73770.5090308@chello.at> Message-ID: <79722fad0412202125519552a4@mail.gmail.com> On Mon, 20 Dec 2004 21:34:56 +0100, Gernot W. Schmied wrote: > Just want to report this compile failure on FreeBSD 5.3/Intel P4. > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qua > l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > -ftemplate-depth-20 > -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo > './'`mfea_proto_comm > .cc > mfea_proto_comm.cc: In member function `int > ProtoComm::proto_socket_write(uint16 > _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)': > mfea_proto_comm.cc:1521: error: cannot bind packed field > `ip->ip::ip_src' to `in > _addr&' > mfea_proto_comm.cc:1522: error: cannot bind packed field > `ip->ip::ip_dst' to `in > _addr&' Do a cast. It worked for me. > gmake[3]: *** [mfea_proto_comm.o] Error 1 > gmake[3]: Leaving directory `/usr/local/src/xorp-1.0/fea' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/usr/local/src/xorp-1.0/fea' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/usr/local/src/xorp-1.0' > gmake: *** [all] Error 2 > > Regards, > Gernot > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From atanu@ICSI.Berkeley.EDU Tue Dec 21 19:36:41 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 21 Dec 2004 11:36:41 -0800 Subject: [Xorp-hackers] Re: [Xorp-users] Compile failure on FreeBSD 5.3 In-Reply-To: Message from Vlad GALU of "Tue, 21 Dec 2004 07:25:35 +0200." <79722fad0412202125519552a4@mail.gmail.com> Message-ID: <98300.1103657801@tigger.icir.org> This problem is fixed in the source tree: The final solution that we choose was to go through an intermediate structure rather than a cast. In our defense FreeBSD 5.3 was not available when we made the 1.0 release earlier this year. Atanu. >>>>> "Vlad" == Vlad GALU writes: Vlad> On Mon, 20 Dec 2004 21:34:56 +0100, Gernot W. Schmied Vlad> wrote: >> Just want to report this compile failure on FreeBSD 5.3/Intel P4. >> >> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings >> -Wcast-qua >> l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual >> -ftemplate-depth-20 >> -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo >> './'`mfea_proto_comm >> .cc >> mfea_proto_comm.cc: In member function `int >> ProtoComm::proto_socket_write(uint16 >> _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)': >> mfea_proto_comm.cc:1521: error: cannot bind packed field >> `ip->ip::ip_src' to `in >> _addr&' >> mfea_proto_comm.cc:1522: error: cannot bind packed field >> `ip->ip::ip_dst' to `in >> _addr&' Vlad> Do a cast. It worked for me. >> gmake[3]: *** [mfea_proto_comm.o] Error 1 >> gmake[3]: Leaving directory `/usr/local/src/xorp-1.0/fea' >> gmake[2]: *** [all-recursive] Error 1 >> gmake[2]: Leaving directory `/usr/local/src/xorp-1.0/fea' >> gmake[1]: *** [all-recursive] Error 1 >> gmake[1]: Leaving directory `/usr/local/src/xorp-1.0' >> gmake: *** [all] Error 2 >> >> Regards, >> Gernot >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users@xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> Vlad> -- Vlad> If it's there, and you can see it, it's real. Vlad> If it's not there, and you can see it, it's virtual. Vlad> If it's there, and you can't see it, it's transparent. Vlad> If it's not there, and you can't see it, you erased it. Vlad> _______________________________________________ Vlad> Xorp-hackers mailing list Vlad> Xorp-hackers@icir.org Vlad> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From gernot.schmied@chello.at Tue Dec 21 19:55:59 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Tue, 21 Dec 2004 20:55:59 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Compile failure on FreeBSD 5.3 In-Reply-To: <98300.1103657801@tigger.icir.org> References: <98300.1103657801@tigger.icir.org> Message-ID: <41C87FCF.407@chello.at> Atanu Ghosh wrote: > This problem is fixed in the source tree: > > > The final solution that we choose was to go through an intermediate > structure rather than a cast. > > In our defense FreeBSD 5.3 was not available when we made the 1.0 > release earlier this year. > > Atanu. > > >>>>>>"Vlad" == Vlad GALU writes: > > > Vlad> On Mon, 20 Dec 2004 21:34:56 +0100, Gernot W. Schmied > Vlad> wrote: > >> Just want to report this compile failure on FreeBSD 5.3/Intel P4. > >> > >> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > >> -Wcast-qua > >> l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > >> -ftemplate-depth-20 > >> -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo > >> './'`mfea_proto_comm > >> .cc > >> mfea_proto_comm.cc: In member function `int > >> ProtoComm::proto_socket_write(uint16 > >> _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)': > >> mfea_proto_comm.cc:1521: error: cannot bind packed field > >> `ip->ip::ip_src' to `in > >> _addr&' > >> mfea_proto_comm.cc:1522: error: cannot bind packed field > >> `ip->ip::ip_dst' to `in > >> _addr&' > > Vlad> Do a cast. It worked for me. > > >> gmake[3]: *** [mfea_proto_comm.o] Error 1 > >> gmake[3]: Leaving directory `/usr/local/src/xorp-1.0/fea' > >> gmake[2]: *** [all-recursive] Error 1 > >> gmake[2]: Leaving directory `/usr/local/src/xorp-1.0/fea' > >> gmake[1]: *** [all-recursive] Error 1 > >> gmake[1]: Leaving directory `/usr/local/src/xorp-1.0' > >> gmake: *** [all] Error 2 > >> > >> Regards, > >> Gernot > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users@xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> > > > Vlad> -- > Vlad> If it's there, and you can see it, it's real. > Vlad> If it's not there, and you can see it, it's virtual. > Vlad> If it's there, and you can't see it, it's transparent. > Vlad> If it's not there, and you can't see it, you erased it. > Vlad> _______________________________________________ > Vlad> Xorp-hackers mailing list > Vlad> Xorp-hackers@icir.org > Vlad> 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 > Ok, Thanks to all the feedback, now another compile failure popped up within PIM. I'll give the CVS code a try and report back how things are going on FreeBSD 5.3. Regards, Gernot From atanu@ICSI.Berkeley.EDU Tue Dec 21 20:17:23 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 21 Dec 2004 12:17:23 -0800 Subject: [Xorp-hackers] Re: [Xorp-users] Compile failure on FreeBSD 5.3 In-Reply-To: Message from "Gernot W. Schmied" of "Tue, 21 Dec 2004 20:55:59 +0100." <41C87FCF.407@chello.at> Message-ID: <7106.1103660243@tigger.icir.org> I would recommend building directly from the CVS archive. There have been many compilation and big fixes. I believe that the current tree has built on 5.3. The downside is that the documentation may not fully match the latest code. Atanu. >>>>> "Gernot" == Gernot W Schmied writes: Gernot> Atanu Ghosh wrote: >> This problem is fixed in the source tree: >> >> The final solution that we choose was to go through an intermediate >> structure rather than a cast. >> In our defense FreeBSD 5.3 was not available when we made the 1.0 >> release earlier this year. >> Atanu. >> >>>>>>> "Vlad" == Vlad GALU writes: Vlad> On Mon, 20 Dec 2004 21:34:56 +0100, Gernot W. Schmied Vlad> wrote: >> >> Just want to report this compile failure on FreeBSD 5.3/Intel P4. >> >> >> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall >> -Wwrite-strings >> >> -Wcast-qua >> >> l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual >> >> -ftemplate-depth-20 >> >> -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo >> >> './'`mfea_proto_comm >> >> .cc >> >> mfea_proto_comm.cc: In member function `int >> >> ProtoComm::proto_socket_write(uint16 >> >> _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)': >> >> mfea_proto_comm.cc:1521: error: cannot bind packed field >> >> `ip->ip::ip_src' to `in >> >> _addr&' >> >> mfea_proto_comm.cc:1522: error: cannot bind packed field >> >> `ip->ip::ip_dst' to `in >> >> _addr&' Vlad> Do a cast. It worked for me. >> >> gmake[3]: *** [mfea_proto_comm.o] Error 1 >> >> gmake[3]: Leaving directory `/usr/local/src/xorp-1.0/fea' >> >> gmake[2]: *** [all-recursive] Error 1 >> >> gmake[2]: Leaving directory `/usr/local/src/xorp-1.0/fea' >> >> gmake[1]: *** [all-recursive] Error 1 >> >> gmake[1]: Leaving directory `/usr/local/src/xorp-1.0' >> >> gmake: *** [all] Error 2 >> >> >> Regards, >> >> Gernot >> >> _______________________________________________ >> >> Xorp-users mailing list >> >> Xorp-users@xorp.org >> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> >> Vlad> -- Vlad> If it's there, and you can see it, it's real. Vlad> If it's not there, and you can see it, it's virtual. Vlad> If it's there, and you can't see it, it's transparent. Vlad> If it's not there, and you can't see it, you erased it. Vlad> _______________________________________________ Vlad> Xorp-hackers mailing list Vlad> Xorp-hackers@icir.org Vlad> 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 >> Gernot> Ok, Gernot> Thanks to all the feedback, now another compile failure popped up Gernot> within PIM. I'll give the CVS code a try and report back how things Gernot> are going on FreeBSD 5.3. Gernot> Regards, Gernot> Gernot Gernot> _______________________________________________ Gernot> Xorp-hackers mailing list Gernot> Xorp-hackers@icir.org Gernot> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From gernot.schmied@chello.at Tue Dec 21 22:10:30 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Tue, 21 Dec 2004 23:10:30 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Compile failure on FreeBSD 5.3 In-Reply-To: <7106.1103660243@tigger.icir.org> References: <7106.1103660243@tigger.icir.org> Message-ID: <41C89F56.6010809@chello.at> Hi Atanu, I can confirm that the CVS archive compiles nicely on FreeBSD 5.3 Intel P4. Thanks, Gernot Atanu Ghosh wrote: > I would recommend building directly from the CVS archive. There have > been many compilation and big fixes. I believe that the current tree has > built on 5.3. The downside is that the documentation may not fully > match the latest code. > > Atanu. > > >>>>>>"Gernot" == Gernot W Schmied writes: > > > Gernot> Atanu Ghosh wrote: > >> This problem is fixed in the source tree: > >> > >> The final solution that we choose was to go through an intermediate > >> structure rather than a cast. > >> In our defense FreeBSD 5.3 was not available when we made the 1.0 > >> release earlier this year. > >> Atanu. > >> > >>>>>>> "Vlad" == Vlad GALU writes: > Vlad> On Mon, 20 Dec 2004 21:34:56 +0100, Gernot W. Schmied > Vlad> wrote: > >> >> Just want to report this compile failure on FreeBSD 5.3/Intel P4. > >> >> >> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall > >> -Wwrite-strings > >> >> -Wcast-qua > >> >> l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > >> >> -ftemplate-depth-20 > >> >> -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo > >> >> './'`mfea_proto_comm > >> >> .cc > >> >> mfea_proto_comm.cc: In member function `int > >> >> ProtoComm::proto_socket_write(uint16 > >> >> _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)': > >> >> mfea_proto_comm.cc:1521: error: cannot bind packed field > >> >> `ip->ip::ip_src' to `in > >> >> _addr&' > >> >> mfea_proto_comm.cc:1522: error: cannot bind packed field > >> >> `ip->ip::ip_dst' to `in > >> >> _addr&' > Vlad> Do a cast. It worked for me. > >> >> gmake[3]: *** [mfea_proto_comm.o] Error 1 > >> >> gmake[3]: Leaving directory `/usr/local/src/xorp-1.0/fea' > >> >> gmake[2]: *** [all-recursive] Error 1 > >> >> gmake[2]: Leaving directory `/usr/local/src/xorp-1.0/fea' > >> >> gmake[1]: *** [all-recursive] Error 1 > >> >> gmake[1]: Leaving directory `/usr/local/src/xorp-1.0' > >> >> gmake: *** [all] Error 2 > >> >> >> Regards, > >> >> Gernot > >> >> _______________________________________________ > >> >> Xorp-users mailing list > >> >> Xorp-users@xorp.org > >> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> >> Vlad> -- > Vlad> If it's there, and you can see it, it's real. > Vlad> If it's not there, and you can see it, it's virtual. > Vlad> If it's there, and you can't see it, it's transparent. > Vlad> If it's not there, and you can't see it, you erased it. > Vlad> _______________________________________________ > Vlad> Xorp-hackers mailing list > Vlad> Xorp-hackers@icir.org > Vlad> 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 > >> > > Gernot> Ok, > > Gernot> Thanks to all the feedback, now another compile failure popped up > Gernot> within PIM. I'll give the CVS code a try and report back how things > Gernot> are going on FreeBSD 5.3. > > Gernot> Regards, > Gernot> Gernot > Gernot> _______________________________________________ > Gernot> Xorp-hackers mailing list > Gernot> Xorp-hackers@icir.org > Gernot> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From =?UTF-8?Q?B=C3=A2k=C4=B1r_EMRE?= Wed Dec 22 15:37:30 2004 From: =?UTF-8?Q?B=C3=A2k=C4=B1r_EMRE?= (=?UTF-8?Q?B=C3=A2k=C4=B1r_EMRE?=) Date: Wed, 22 Dec 2004 17:37:30 +0200 Subject: [Xorp-hackers] About call_xrl Message-ID: <20bf8edd041222073732c7c86f@mail.gmail.com> We're trying to develop a web interface for XORP using PHP. We're considering "call_xrl" as a bridge to the router. We would like to be able to configure the router and view its status by sending XRLs. Is "call_xrl" suitable for us? Any help (and comment) will be appreciated.. B璽k覺r Emre Senior Student at Kocaeli University From atanu@ICSI.Berkeley.EDU Wed Dec 22 23:06:03 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 22 Dec 2004 15:06:03 -0800 Subject: [Xorp-hackers] About call_xrl In-Reply-To: Message from =?UTF-8?Q?B=C3=A2k=C4=B1r_EMRE?= of "Wed, 22 Dec 2004 17:37:30 +0200." <20bf8edd041222073732c7c86f@mail.gmail.com> Message-ID: <59568.1103756763@tigger.icir.org> Hi, The "call_xrl" will allow you to call any XRL. Some of our XRL interfaces involve registering an interface to callback. The "call_xrl" will not help with such a case. I think some of the commands to extract routing tables may require callbacks. The xorpsh uses external programs to print the state of the router. Check in the "etc/templates" directory all files ending in ".cmds". You could consider using these commands and not calling the XRLs directly. The router manager controls the processes that make up a XORP router. The "xorpsh" is used to change the state of the router, which it does by interacting with the router manager. If you use XRLs directly to control processes then the router manager will have a different view of the state of the router. Anyone using the "xorpsh" will see a possibly inconsistent view. This would be unfortunate as it should be possible to use both the web and "xorpsh" interface to control the router. A not very elegant solution may be to run a xorpsh at the end of a pipe and send it commands. You could also consider modifying the xorpsh to take a command to execute on the command line, rather like the "-c" flag that the shell (sh(1)) takes. We would be interested in the patches if you were to do this. I hope this helps. Atanu. >>>>> "B璽k覺r" == B璽k覺r EMRE writes: B璽k覺r> We're trying to develop a web interface for XORP using PHP. We're B璽k覺r> considering "call_xrl" as a bridge to the router. We would like to be B璽k覺r> able to configure the router and view its status by sending XRLs. Is B璽k覺r> "call_xrl" suitable for us? Any help (and comment) will be B璽k覺r> appreciated.. B璽k覺r> B璽k覺r Emre B璽k覺r> Senior Student at Kocaeli University B璽k覺r> _______________________________________________ B璽k覺r> Xorp-hackers mailing list B璽k覺r> Xorp-hackers@icir.org B璽k覺r> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From bms@spc.org Thu Dec 23 00:45:46 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 23 Dec 2004 00:45:46 +0000 Subject: [Xorp-hackers] Re: [Xorp-users] Compile failure on FreeBSD 5.3 In-Reply-To: <7106.1103660243@tigger.icir.org> References: <41C87FCF.407@chello.at> <7106.1103660243@tigger.icir.org> Message-ID: <20041223004546.GA684@empiric.icir.org> On Tue, Dec 21, 2004 at 12:17:23PM -0800, Atanu Ghosh wrote: > I would recommend building directly from the CVS archive. There have > been many compilation and big fixes. I believe that the current tree has > built on 5.3. The downside is that the documentation may not fully > match the latest code. I can confirm that at least the XRL infrastructure and FEA build OK on FreeBSD 5.3, as this is where I developed the packet filter code. BMS From cj@coe.psu.ac.th Sat Dec 25 12:31:20 2004 From: cj@coe.psu.ac.th (Chatchai JANTARAPRIM) Date: Sat, 25 Dec 2004 19:31:20 +0700 (ICT) Subject: [Xorp-hackers] Compile Xorp-1.0 failed on Debian Linux In-Reply-To: <200412251225.iBPCP18f028631@fruitcake.ICSI.Berkeley.EDU> References: <200412251225.iBPCP18f028631@fruitcake.ICSI.Berkeley.EDU> Message-ID: Hi, I try to compile xorp-1.0 on Debian Linux machine, but got this error: make[3]: Entering directory `/home/netop-cj/workplace/build/xorp-1.0/mibs' source='bgp4_mib_1657_bgpversion.cc' object='bgp4_mib_1657_bgpversion.o' libtool=no \ depfile='.deps/bgp4_mib_1657_bgpversion.Po' tmpdepfile='.deps/bgp4_mib_1657_bgpversion.TPo' \ depmode=gcc3 /bin/sh ../config/depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. `net-snmp-config --cflags` -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-20 -c -o bgp4_mib_1657_bgpversion.o `test -f bgp4_mib_1657_bgpversion.cc || echo './'`bgp4_mib_1657_bgpversion.cc /usr/local/include/net-snmp/agent/agent_handler.h:238: warning: inline function `void* netsnmp_request_get_list_data(netsnmp_request_info*, const char*)' used but never defined /usr/local/include/net-snmp/agent/agent_handler.h:221: warning: inline function `netsnmp_delegated_cache* netsnmp_handler_check_cache(netsnmp_delegated_cache*)' used but never defined /usr/local/include/net-snmp/agent/agent_handler.h:217: warning: inline function `netsnmp_delegated_cache* netsnmp_create_delegated_cache(netsnmp_mib_handler*, netsnmp_handler_registration*, netsnmp_agent_request_info*, netsnmp_request_info*, void*)' used but never defined make[3]: *** [bgp4_mib_1657_bgpversion.o] Error 1 make[3]: Leaving directory `/home/netop-cj/workplace/build/xorp-1.0/mibs' make[2]: *** [all-recursive] Error 1 I'm new to xorp. So, could you please give me a direction or document that I can solve this problem. Thanks, cj From adam@hiddennet.net Sat Dec 25 12:49:11 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Sat, 25 Dec 2004 12:49:11 +0000 Subject: [Xorp-hackers] Compile Xorp-1.0 failed on Debian Linux In-Reply-To: References: <200412251225.iBPCP18f028631@fruitcake.ICSI.Berkeley.EDU> Message-ID: <1103978952.9382.3.camel@localhost> My first suggestion is to try checking out xorp from cvs and build check that. Many things have changed since xorp-1.0 , a 1.1 release is on the cards for 1st quarter 2005. http://www.xorp.org/cvs.html Adam On Sat, 2004-12-25 at 19:31 +0700, Chatchai JANTARAPRIM wrote: > Hi, > I try to compile xorp-1.0 on Debian Linux machine, but got this > error: > > make[3]: Entering directory `/home/netop-cj/workplace/build/xorp-1.0/mibs' > source='bgp4_mib_1657_bgpversion.cc' object='bgp4_mib_1657_bgpversion.o' libtool=no \ > depfile='.deps/bgp4_mib_1657_bgpversion.Po' tmpdepfile='.deps/bgp4_mib_1657_bgpversion.TPo' \ > depmode=gcc3 /bin/sh ../config/depcomp \ > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. `net-snmp-config --cflags` -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes > -Woverloaded-virtual -ftemplate-depth-20 -c -o bgp4_mib_1657_bgpversion.o `test -f bgp4_mib_1657_bgpversion.cc || echo './'`bgp4_mib_1657_bgpversion.cc > /usr/local/include/net-snmp/agent/agent_handler.h:238: warning: inline function > `void* netsnmp_request_get_list_data(netsnmp_request_info*, const char*)' > used but never defined > /usr/local/include/net-snmp/agent/agent_handler.h:221: warning: inline function > `netsnmp_delegated_cache* > netsnmp_handler_check_cache(netsnmp_delegated_cache*)' used but never > defined > /usr/local/include/net-snmp/agent/agent_handler.h:217: warning: inline function > `netsnmp_delegated_cache* > netsnmp_create_delegated_cache(netsnmp_mib_handler*, > netsnmp_handler_registration*, netsnmp_agent_request_info*, > netsnmp_request_info*, void*)' used but never defined > make[3]: *** [bgp4_mib_1657_bgpversion.o] Error 1 > make[3]: Leaving directory `/home/netop-cj/workplace/build/xorp-1.0/mibs' > make[2]: *** [all-recursive] Error 1 > > I'm new to xorp. So, could you please give me a direction or document > that I can solve this problem. > > Thanks, > cj > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ongbh@ispworkshop.com Tue Dec 28 08:00:36 2004 From: ongbh@ispworkshop.com (Ong Beng Hui) Date: Tue, 28 Dec 2004 16:00:36 +0800 Subject: [Xorp-hackers] xorp on FreeBSD 5.3 on Sparc64 Message-ID: <41D112A4.8040701@ispworkshop.com> Hi, Has anyone tried to compile xorp on FreeBSD 5.3 on Sparc64 ? Got this error... make[3]: Entering directory `/usr/local/src/xorp/libxorp' source='asyncio.cc' object='asyncio.lo' libtool=yes \ depfile='.deps/asyncio.Plo' tmpdepfile='.deps/asyncio.TPlo' \ depmode=gcc3 /usr/local/bin/bash ../config/depcomp \ /usr/local/bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o asyncio.lo `test -f asyncio.cc || echo './'`asyncio.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c asyncio.cc -MT asyncio.lo -MD -MP -MF .deps/asyncio.TPlo -o asyncio.o asyncio.cc: In member function `void AsyncFileWriter::write(int, SelectorMask)': asyncio.cc:255: warning: int format, different type arg (arg 2) make[3]: *** [asyncio.lo] Error 1 make[3]: Leaving directory `/usr/local/src/xorp/libxorp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/xorp/libxorp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/xorp' make: *** [all] Error 2 bash-2.04# any tips for a fix ? xorp is from CVS. From ongbh@ispworkshop.com Wed Dec 29 07:02:02 2004 From: ongbh@ispworkshop.com (Ong Beng Hui) Date: Wed, 29 Dec 2004 15:02:02 +0800 Subject: [Xorp-hackers] xorp on FreeBSD 5.3 on Sparc64 Message-ID: <41D2566A.2070402@ispworkshop.com> -------- Original Message -------- Subject: [Fwd: xorp on FreeBSD 5.3 on Sparc64] Date: Wed, 29 Dec 2004 09:45:32 +0800 From: Ong Beng Hui To: xorp-users@xorp.org -------- Original Message -------- Subject: xorp on FreeBSD 5.3 on Sparc64 Date: Tue, 28 Dec 2004 16:00:36 +0800 From: Ong Beng Hui To: xorp-hackers@xorp.org Hi, Has anyone tried to compile xorp on FreeBSD 5.3 on Sparc64 ? Got this error... make[3]: Entering directory `/usr/local/src/xorp/libxorp' source='asyncio.cc' object='asyncio.lo' libtool=yes \ depfile='.deps/asyncio.Plo' tmpdepfile='.deps/asyncio.TPlo' \ depmode=gcc3 /usr/local/bin/bash ../config/depcomp \ /usr/local/bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o asyncio.lo `test -f asyncio.cc || echo './'`asyncio.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c asyncio.cc -MT asyncio.lo -MD -MP -MF .deps/asyncio.TPlo -o asyncio.o asyncio.cc: In member function `void AsyncFileWriter::write(int, SelectorMask)': asyncio.cc:255: warning: int format, different type arg (arg 2) make[3]: *** [asyncio.lo] Error 1 make[3]: Leaving directory `/usr/local/src/xorp/libxorp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/xorp/libxorp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/xorp' make: *** [all] Error 2 bash-2.04# any tips for a fix ? xorp is from CVS. From ongbh@ispworkshop.com Wed Dec 29 07:17:20 2004 From: ongbh@ispworkshop.com (Ong Beng Hui) Date: Wed, 29 Dec 2004 15:17:20 +0800 Subject: [Xorp-hackers] test posting Message-ID: <41D25A00.6000500@ispworkshop.com> Sorry, having problem posting to the list. Test From atanu@ICSI.Berkeley.EDU Wed Dec 29 22:39:28 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 29 Dec 2004 14:39:28 -0800 Subject: [Xorp-hackers] test - please ignore Message-ID: <40154.1104359968@tigger.icir.org> From atanu@ICSI.Berkeley.EDU Wed Dec 29 23:42:49 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 29 Dec 2004 15:42:49 -0800 Subject: [Xorp-hackers] mailman was down Message-ID: <53841.1104363769@tigger.icir.org> Hi, Our mailing list server was down for the last four days. Some spam email confused it enough, to stop it forwarding any email. Hopefully its fixed now. Atanu.