From atanu@ICSI.Berkeley.EDU Fri Jul 9 08:08:48 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 09 Jul 2004 00:08:48 -0700 Subject: [Xorp-hackers] Announcing XORP Release 1.0 Message-ID: <98501.1089356928@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.0 Release, which is now available from . The XORP router is now totally configurable through the XORP shell (xorpsh). A quick start guide is available from . Please note that a XORP Live CD is also available. This is a bootable CD that allows you to experiment with XORP without having to build or install it. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.1 release; these are documented in the errata section below. In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users@xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback@xorp.org. - The XORP Team P.S. Release notes and errata are included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.0 (2004/07/08) ========================= ALL: - All the routing processes can now be started and configured via the RTRMGR/XORPSH. LIBXORP: - Addition of support for safe callbacks (e.g., if an object is destroyed, all callbacks that refer to that object are invalidated). LIBXIPC: - Addition of support for event notification if the status of a target changes. LIBFEACLIENT: - Few bug fixes. XRL: - No significant changes. RTRMGR: - Addition of new command-line option "-v" to print verbose information. - Removal of command-line option "-d" that prints default information, because the same information is printed with the "-h" flag. - Addition of support for explicit configuration of the XRL target name of a module. - Addition of support for %help command in the rtrmgr template files. - Addition of support for new methods per module: "startup_method" and "shutdown_method". - Numerous other improvements and bug fixes. XORPSH: - Addition of new command-line option "-v" to print verbose information. - Removal of command-line option "-d" that prints default information, because the same information is printed with the "-h" flag. - Addition of support for help string in the xorpsh operational commands template files. - Addition of support for positional arguments in the xorpsh operational commands template files. - Addition of support to interrupt an operational command. Now if a command is interrupted from the command line by typing Ctrl-C, then the executed binary command itself (and its forked children, if any) is killed. - Numerous other improvements and bug fixes. FEA/MFEA: - Addition of support for propagating the Forwarding Information Base from the underlying system to clients interested in that information. - Addition of support for opening TCP or UDP sockets via the FEA. - Modification to the MFEA to use "libfeaclient" to obtain the interface information from the FEA. - Numerious bug fixes. RIB: - Addition of support for redistributing routes between two internal tables. - Addition of support for obtaining routes directly from some of the internal tables. - Modification to the RIB to use "libfeaclient" to obtain the interface information from the FEA. - Modification to the RIB to use the new RedistTable to propagate the final routes to the FEA and anyone else interested (e.g., PIM-SM). - Few bug fixes. RIP: - Packet forwarding and reception via FEA written for RIPv2 and RIPng. RIPv2 should be usable. BGP: - IPv6 has now been tested with peerings to the 6Bone; unicast and multicast SAFIs. - Route origination is now possible from BGP. - The memory leaks from the previous release have been found and fixed. STATIC_ROUTES: - This is a new module for configuring static routes to the unicast or multicast RIB. MLD/IGMP: - During startup, a primary address is selected per configured interface, and this primary address should be the link-local unicast address of that interface. - New CLI commands: "show igmp interface address" and "show mld interface address" - Resend some of the XRLs (e.g., those who do not carry soft-state such as protocol control messages) if there is an error. - Few bug fixes. PIM-SM: - Updated to support the lastest PIM-SM specification (draft-ietf-pim-sm-v2-new-09.{ps,txt}). - Addition of support for "alternative subnet" configuration such that non-local senders appear as senders connected to the same subnet. It is needed as a work-around solution when there are uni-directional interfaces for sending and receiving traffic (e.g., satellite links). - During startup, a primary address and a domain-wide address are selected per configured interface. The primary address should be the link-local unicast address of that interface, and the domain-wide address should be a domain-wide reachable unicast address. - Resend some of the XRLs (e.g., those who do not carry soft-state such as protocol control messages) if there is an error. - Several bug fixes. FIB2MRIB: - This is a new module for propagating the unicast forwarding information obtained from the underlying system via the FEA to the multicast RIB. CLI: - Addition of support to propagate command interruption (e.g., Ctrl-C) from the CLI to the object that handles the command processing by calling a pre-defined callback. - During startup, if the input is a terminal (e.g., xorpsh), then read the terminal size instead of using the default values. - A bug fix related to the CLI paging output: now it can handle properly lines that are longer than the width of the CLI output terminal. - Several other bug fixes. SNMP: - No significant changes. ------------------------------------------------------------------ XORP ERRATA ALL: - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU machines. The simplest work-around is to rerun gmake or not to use the -j flag. - Building with the optimizer ("./configure --enable-optimize") will cause the build to fail. The build fails because some warnings are generated by the compiler and we treat warnings as fatal. This problem was discovered too late to be fixed for this release. LIBXORP: - No known issues. LIBXIPC: - No known issues. LIBFEACLIENT: - No known issues. XRL: - No known issues. RTRMGR: - There are several known issues, but none of them is considered critical. The list of known issues is available from http://www.xorp.org/bugzilla/query.cgi XORPSH: - A problem was noticed very late in the release process; rather than delay the release we have choosen to document the problem. The xorpsh provides the command line to the XORP router. The router configuration is structured as a tree, for instance configuring a new protocol essentially adds a new node to the tree. Removing a protocol involves deleting a node from the tree. In some cases deleting a node does not remove all the associated state; worse putting the same node back seems to fail in the majority of cases. FEA/MFEA: - On Linux, the following error message may appear during graceful shutdown (if PIM-SM is also running): [ 2004/06/09 14:50:40 ERROR xorp_fea:14359 MFEA +1676 mfea_mrouter.cc get_sg_count ] ioctl(SIOCGETSGCNT, (10.10.10.10 224.0.1.20)) failed: Bad file descriptor The error is harmless and can be ignored. - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show mfea interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the MFEA module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel 2.6.5-1.358), some of the tests may fail (with or without an error message), but no coredump image. Some of those failures can be contributed to a kernel problem. E.g., running "dmesg can show kernel "Oops" messages like: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 02235532 *pde = 00000000 Oops: 0000 [#15] CPU: 0 EIP: 0060:[<02235532>] Not tainted EFLAGS: 00010202 (2.6.5-1.358) EIP is at __dev_get_by_index+0x14/0x2b eax: 022db854 ebx: 1ae7aef8 ecx: 00000001 edx: 00000000 esi: 00000000 edi: 00008910 ebp: fee43e9c esp: 1ae7aef0 ds: 007b es: 007b ss: 0068 Process test_finder_eve (pid: 2026, threadinfo=1ae7a000 task=1406d7b0) Stack: 022365c7 00000000 009caffc 009cc780 0969ef28 fee43edc 00000001 009cc780 0969ef28 fee43ed8 00008910 00000000 00008910 fee43e9c 02236e50 fee43e9c 07aa4e00 3530355b 5d303637 00000000 0227a55b 021536b6 022cfa00 00000001 Call Trace: [<022365c7>] dev_ifname+0x30/0x66 [<02236e50>] dev_ioctl+0x83/0x283 [<0227a55b>] unix_create1+0xef/0xf7 [<021536b6>] alloc_inode+0xf9/0x175 [<0227c090>] unix_ioctl+0x72/0x7b [<022301a5>] sock_ioctl+0x268/0x280 [<0223054f>] sys_socket+0x2a/0x3d [<0214ea0e>] sys_ioctl+0x1f2/0x224 Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME) which itself is called by if_indextoname(3). Currently, there is no known solution of the problem except to use a kernel that does not have the problem (at this stage it is not known whether all 2.6 Linux kernels are affected or only specific versions). It seems that a very similar problem has been reported to the Linux kernel developers, but the problem is still unsolved: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697 RIB: - If an interface address is deleted, the RIB may trigger the following error in the FEA: [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +259 fticonfig_entry_set_rtsock.cc delete_entry ] error writing to routing socket: No such process [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +61 fti_transaction.cc operation_result ] FTI transaction commit failed on DeleteEntry4: net = 172.16.124.0/24 gateway = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +259 This error has no side effects, and can be ignored. - In some rare cases, the RIB may fail to delete an existing route (See http://www.xorp.org/bugzilla/show_bug.cgi?id=62). We are aware of the issue and will attempt to fix it in the near future. RIP: - No known issues. BGP: - Once BGP selects a route it is taking too long to install it in the kernel. - If the RIB bug above (failure to delete an existing route) is triggered by BGP, then the deletion failure error received by BGP from the RIB is considered by BGP as a fatal error. This is not a BGP problem, but a RIB problem that will be fixed after the XORP Release-1.0. STATIC_ROUTES: - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start printing lots of error messages. MLD/IGMP: - If MLD/IGMP is started with a relatively large number of interfaces (e.g., on the order of 20), then it may fail with the following error: [ 2004/06/14 12:58:56 ERROR test_pim:16548 MFEA +666 mfea_proto_comm.cc join_multicast_group ] Cannot join group 224.0.0.2 on vif eth8: No buffer space available The solution is to increase the multicast group membership limit. E.g., to increase the value from 20 (the default) to 200, run as a root: echo 200 > /proc/sys/net/ipv4/igmp_max_memberships - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show igmp interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the MLD/IGMP module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. PIM-SM: - If the kernel does not support PIM-SM, or if PIM-SM is not enabled in the kernel, then running PIM-SM will fail with the following error message: [ 2004/06/12 10:26:41 ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported - On Linux, if the unicast Reverse Path Forwarding information is different from the multicast Reverse Path Forwarding information, the Reverse Path Filtering should be disabled. E.g., as root: echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter OR echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter ... Otherwise, the router will ignore packets if they don't arrive on the reverse-path interface. For more information about Reverse Path Filtering see http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show pim interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the PIM-SM module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. - Very late in the release process a problem was found with scheduling the internal PIM-SM tasks for state dependency tracking. The result of it is that if the router is heavy loaded and if it has lots of multicast routing state, then any change that affects many multicast routing entries (e.g., MRIB changes, etc) in some cases may result in incorrect recomputation of the result multicast routing state. This problem will be fixed in the CVS repository right after the XORP Release-1.0. FIB2MRIB: - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start printing lots of error messages. CLI: - No known issues. SNMP: - On some versions of Linux, there are some bugs in net-snmp versions 5.0.8 and 5.0.9, which prevent dynamic loading from working. See http://www.xorp.org/snmp.html for links to the net-snmp patches that solve the problems. - Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. See http://www.xorp.org/snmp.html for a link to the net-snmp patch that solves the problems. ------------------------------------------------------------------ From M.Handley@cs.ucl.ac.uk Mon Jul 19 23:23:55 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 19 Jul 2004 23:23:55 +0100 Subject: [Xorp-hackers] An Introduction to Writing a XORP Process Message-ID: <93949.1090275835@vulture.xorp.org> I have three students this summer here at UCL working on XORP-related projects. One of them has had no problems whatsoever figuring out how the pieces of XORP fit together, but the other two have had some difficulty. To try and make it easier to get started, I've written a document called "An Introduction to Writing a XORP Process". It attempts to lead the reader through by example how XRL interfaces are defined, the stub compilation process, what the XORP main loop looks like, and how you call XRLs on other processes. My first draft is currently available here: http://nrg.cs.ucl.ac.uk/mjh/tmp/xorpdev101.pdf If it seems like it's useful, it will probably find a more permanent home somewhere else. It's also checked in to CVS in the xorp/docs directory. If you've found yourself in a similar situation to my students, I'd appreciate feedback as to how useful this is, what critical things are missing, and what could be explained better. Cheers, Mark From bms@spc.org Mon Jul 19 23:40:11 2004 From: bms@spc.org (Bruce M Simpson) Date: Mon, 19 Jul 2004 23:40:11 +0100 Subject: [Xorp-hackers] An Introduction to Writing a XORP Process In-Reply-To: <93949.1090275835@vulture.xorp.org> References: <93949.1090275835@vulture.xorp.org> Message-ID: <20040719224011.GO801@empiric.dek.spc.org> On Mon, Jul 19, 2004 at 11:23:55PM +0100, Mark Handley wrote: > To try and make it easier to get started, I've written a document > called "An Introduction to Writing a XORP Process". It attempts to > lead the reader through by example how XRL interfaces are defined, the > stub compilation process, what the XORP main loop looks like, and how > you call XRLs on other processes. Excellent. This is exactly what I need. I'll review this in more depth soon. Many thanks, BMS From adam@hiddennet.net Thu Jul 22 09:40:26 2004 From: adam@hiddennet.net (adam@hiddennet.net) Date: Thu, 22 Jul 2004 09:40:26 +0100 (BST) Subject: [Xorp-hackers] Linux network stack status and vision Message-ID: <53450.213.121.161.106.1090485626.squirrel@213.121.161.106> Hi, http://developer.osdl.org/shemminger/ns2004/ It would seem that prior to the recent linux kernel summit that there was a two day linux networking summit, above is a link to the slides and notes from that summit. I guess it gives us an idea who is doing what and what is planned to be done, perhaps now is time to send ideas or patches to them for the bits that we are missing. Some info about the linux kernel summit is here, BUT this is subscription only content for a week or two after which it becomes open to all. http://lwn.net/Articles/93985/ Adam From atanu@ICSI.Berkeley.EDU Fri Jul 23 00:50:48 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 22 Jul 2004 16:50:48 -0700 Subject: [Xorp-hackers] San Diego IETF Message-ID: <83166.1090540248@tigger.icir.org> Hi, Some of the XORP developers will be at the San Diego IETF, is there any interest in meeting up with us? Atanu. From ray.qiu@gmail.com Sun Jul 25 05:01:29 2004 From: ray.qiu@gmail.com (Ray Qiu) Date: Sat, 24 Jul 2004 21:01:29 -0700 Subject: [Xorp-hackers] XORPSH: command space auto-completion Message-ID: Hi there, I like this project and you guys have done an awesome job. Thanks! It seems that currently the command space auto-completion only works for the first command, because the code looks like this: cli/cli_node_net.cc: if (token.empty() || (multi_command_find(command_line) != NULL)){ unbind space to complete-word ... } It is not handy, because we have to use tab. It seems to work better in the following: // check the last character to see if it is a space, if so unbind space to complete-word. if (token.empty() || (command_line[command_line.length() - 1] == ' ')) { unbind space to complete-word .. } Now space auto-cpmpletion works for sub commands as well. Any thoughts? --Ray From pavlin@icir.org Mon Jul 26 04:52:47 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 25 Jul 2004 20:52:47 -0700 Subject: [Xorp-hackers] XORPSH: command space auto-completion In-Reply-To: Message from Ray Qiu of "Sat, 24 Jul 2004 21:01:29 PDT." Message-ID: <200407260352.i6Q3ql8U094580@possum.icir.org> > Hi there, > > I like this project and you guys have done an awesome job. Thanks! > > It seems that currently the command space auto-completion only works for > the first command, because the code looks like this: > > cli/cli_node_net.cc: > > if (token.empty() || (multi_command_find(command_line) != NULL)){ > unbind space to complete-word > ... > } > > It is not handy, because we have to use tab. > > It seems to work better in the following: > > // check the last character to see if it is a space, if so unbind > space to complete-word. > if (token.empty() || (command_line[command_line.length() - 1] == ' ')) { > unbind space to complete-word > .. > } > > Now space auto-cpmpletion works for sub commands as well. > > Any thoughts? Ray, You are right. Currently, the auto-completion doesn't work for sub-commands. The above solution fixes that, but it doesn't work for some corner cases. E.g., start the test-program cli/test_cli, then use "telnet localhost 12000" and try to enter command "myset foo", where "foo" is a free-style argument. The space auto-completion will prevent you from doing that. I just commited a fix to the cli dorectory that should address the problem. The fix basically replaces method "multi_command_find()" that is used only in the above code with a new (more appropriate) method "is_multi_command_prefix()" that does the right thing. Please let me know if the new code works for you or if you find some other problems. Thanks, Pavlin From ray.qiu@gmail.com Mon Jul 26 08:02:08 2004 From: ray.qiu@gmail.com (Ray Qiu) Date: Mon, 26 Jul 2004 00:02:08 -0700 Subject: [Xorp-hackers] XORPSH: command space auto-completion In-Reply-To: <200407260352.i6Q3ql8U094580@possum.icir.org> References: <200407260352.i6Q3ql8U094580@possum.icir.org> Message-ID: Hi Pavlin, Thanks. Actually after I sent you guys the mail, I found out that my solution was wrong, because it prevent me from typing "show pim xxx", since pim and pim6 both are there in the sub command list. Sorry about that. I will try out your fix. Appreciated. BTW, is anyone currently working on IS-IS? --Ray On Sun, 25 Jul 2004 20:52:47 -0700, Pavlin Radoslavov wrote: > > > > Hi there, > > > > I like this project and you guys have done an awesome job. Thanks! > > > > It seems that currently the command space auto-completion only works for > > the first command, because the code looks like this: > > > > cli/cli_node_net.cc: > > > > if (token.empty() || (multi_command_find(command_line) != NULL)){ > > unbind space to complete-word > > ... > > } > > > > It is not handy, because we have to use tab. > > > > It seems to work better in the following: > > > > // check the last character to see if it is a space, if so unbind > > space to complete-word. > > if (token.empty() || (command_line[command_line.length() - 1] == ' ')) { > > unbind space to complete-word > > .. > > } > > > > Now space auto-cpmpletion works for sub commands as well. > > > > Any thoughts? > > Ray, > > You are right. Currently, the auto-completion doesn't work > for sub-commands. The above solution fixes that, but it doesn't work > for some corner cases. E.g., start the test-program cli/test_cli, > then use "telnet localhost 12000" and try to enter command > "myset foo", where "foo" is a free-style argument. > The space auto-completion will prevent you from doing that. > > I just commited a fix to the cli dorectory that should address the > problem. The fix basically replaces method "multi_command_find()" > that is used only in the above code with a new (more appropriate) > method "is_multi_command_prefix()" that does the right thing. > > Please let me know if the new code works for you or if you find some > other problems. > > Thanks, > Pavlin > > From atanu@ICSI.Berkeley.EDU Mon Jul 26 21:07:06 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 26 Jul 2004 13:07:06 -0700 Subject: [Xorp-hackers] XORPSH: command space auto-completion In-Reply-To: Message from Ray Qiu of "Mon, 26 Jul 2004 00:02:08 PDT." Message-ID: <58766.1090872426@tigger.icir.org> Ray> BTW, is anyone currently working on IS-IS? A small amount of design work has been done on IS-IS but no effort is going into it at the moment. Atanu. From M.Handley@cs.ucl.ac.uk Mon Jul 26 23:14:17 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 26 Jul 2004 23:14:17 +0100 Subject: [Xorp-hackers] XORPSH: command space auto-completion In-Reply-To: Your message of "Mon, 26 Jul 2004 00:02:08 PDT." Message-ID: <11917.1090880057@vulture.xorp.org> >BTW, is anyone currently working on IS-IS? We had originally planned for IS-IS to be next on our agenda for implementation after the 1.0 release, and Atanu had done a certain amount of preliminary design work. However, quite a few people have made it clear to us that for edge-routers, OSPF is much more important. So the current plan is to do a completely new OSPF implementation first, as a replacement for the unsupported OSPF code in the contrib directory. The hope is that some of the new OSPF code can then be re-used for a subsequent IS-IS implementation. If we had someone with time to devote, IS-IS could in fact occur in parallel with OSPF, sharing code as appropriate, but at the moment no-one's signed up for that, and we don't have enough people in the core-team to do both at once. Volunteers anyone? Cheers, Mark From pavlin@icir.org Tue Jul 27 03:37:09 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 26 Jul 2004 19:37:09 -0700 Subject: [Xorp-hackers] An Introduction to Writing a XORP Process In-Reply-To: Message from Mark Handley of "Mon, 19 Jul 2004 23:23:55 BST." <93949.1090275835@vulture.xorp.org> Message-ID: <200407270237.i6R2b9W5078256@possum.icir.org> > > I have three students this summer here at UCL working on XORP-related > projects. One of them has had no problems whatsoever figuring out how > the pieces of XORP fit together, but the other two have had some > difficulty. > > To try and make it easier to get started, I've written a document > called "An Introduction to Writing a XORP Process". It attempts to > lead the reader through by example how XRL interfaces are defined, the > stub compilation process, what the XORP main loop looks like, and how > you call XRLs on other processes. > > My first draft is currently available here: > > http://nrg.cs.ucl.ac.uk/mjh/tmp/xorpdev101.pdf > > If it seems like it's useful, it will probably find a more permanent > home somewhere else. It's also checked in to CVS in the xorp/docs > directory. > > If you've found yourself in a similar situation to my students, I'd > appreciate feedback as to how useful this is, what critical things are > missing, and what could be explained better. Mark, Below are a number of random comments: * At the beginning, it may be useful to have a diagram what a XORP process looks like. E.g., the core of the process that is doing the task, the XRL interface around it, the single eventloop instance, etc. There it may be worth mentioning/repeating that a XORP process is single-threaded. * Somewhere (probably at the end) there should be a section with design guidelines/hints. For example, because the code is no preemptive, no part of the code is allowed to run for a very long time without returning control to the eventloop. Another example would be the guideline that no global state is allowed. * The document is missing several important pieces: - Handling the PROC_* process status that is required for controlling the process via the rtrmgr - An introduction to the ServiceStatus codes (in libxorp/service.hh) which can be used to set the service status on each sub-component. Strictly speaking, using the ServiceStatus codes is not mandatory, but it can simplify significantly a process with several components whose status or behavior depends on each other. - An introduction to the rtrmgr/xorpsh (with regard to adding a new process). For example, what are the requirements for the XORP process so it can be controlled via the rtrmgr (e.g., every process must implement the "common/0.1" XRL interface). Also, information about writing rtrmgr template files and xorpsh operational commands templates. - Information about printing various info: the XLOG_ facility. - Information about supporting default command-line options. E.g., we have defined [-F [:]] as the default command-line options to set the finder name and port number. - Information about the autoconf/automake mechanism. E.g., what a simple Makefile.am should look like, how to modify configure.in and the top-level Makefile.am to add the new module, and when ./bootstrap should be run * If a protocol would be dealing with network interfaces (as most protocols are), then a brief introduction to libfeaclient can be useful (the library to register with the FEA and receive the information updates). * Add a brief intro/mentioning to kdoc and how to generate the kdoc documentation. In general, I like the style of the document which has plenty of examples, code listings and describes things into tiny details. BTW, do you know how easy is to use line numbers in the source code listings similar to the text of Stevens' books (RIP). Myself I am a big fan of his style, and I think the document can be improved even further by using that style as a model. Regards, Pavlin From M.Handley@cs.ucl.ac.uk Tue Jul 27 08:52:56 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 27 Jul 2004 08:52:56 +0100 Subject: [Xorp-hackers] An Introduction to Writing a XORP Process In-Reply-To: Your message of "Mon, 26 Jul 2004 19:37:09 PDT." <200407270237.i6R2b9W5078256@possum.icir.org> Message-ID: <14500.1090914776@vulture.xorp.org> >Below are a number of random comments: Good points - I agree with all of them. This started out as an attempt to orient people in the right direction - really the basics only. Many of your points go beyond the basics, which raises the question of what we want this document to evolve into? Probably you're right - it should evolve into a complete XORP programmers guide over time. I'll try and add material as I find time, but this isn't likely to be for a few weeks. If you want to add material yourself, feel free (by the way, this applies to everyone - if you don't have CVS commit access, send me text or a diff, and I'll include it) Also, do you think this is solid enough now to be linked from the web pages? >In general, I like the style of the document which has plenty of >examples, code listings and describes things into tiny details. >BTW, do you know how easy is to use line numbers in the source code >listings similar to the text of Stevens' books (RIP). Well, all the listings are heavily edited down from the actual code for the sake of space and simplicity (only including the relevant pieces). Would you put the original line numbers in the listings? This would obviously have to be done manually. Cheers, Mark From jonny@jonny.eng.br Tue Jul 27 14:44:13 2004 From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Tue, 27 Jul 2004 10:44:13 -0300 Subject: [Xorp-hackers] An Introduction to Writing a XORP Process In-Reply-To: <14500.1090914776@vulture.xorp.org> References: <14500.1090914776@vulture.xorp.org> Message-ID: <41065C2D.2040306@jonny.eng.br> Mark Handley wrote: >>Below are a number of random comments: > > Good points - I agree with all of them. > > This started out as an attempt to orient people in the > right direction - really the basics only. Many of your points go > beyond the basics, which raises the question of what we want this > document to evolve into? Probably you're right - it should evolve > into a complete XORP programmers guide over time. Let it be both. A starters guide and a full guide. A good chapter distribution could do it. Also, the basics need not be a dummy's guide, of course. >>In general, I like the style of the document which has plenty of >>examples, code listings and describes things into tiny details. >>BTW, do you know how easy is to use line numbers in the source code >>listings similar to the text of Stevens' books (RIP). > > Well, all the listings are heavily edited down from the actual code > for the sake of space and simplicity (only including the relevant > pieces). Would you put the original line numbers in the listings? > This would obviously have to be done manually. The line numbers exist for reference in the text. They need not be the original. Indeed, since the original may change anytime in CVS, they mean nothing. A simple "cat -n" on the simplified text would be enough. Cheers, Jonny From pavlin@icir.org Tue Jul 27 21:02:40 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 27 Jul 2004 13:02:40 -0700 Subject: [Xorp-hackers] An Introduction to Writing a XORP Process In-Reply-To: Message from Mark Handley of "Tue, 27 Jul 2004 08:52:56 BST." <14500.1090914776@vulture.xorp.org> Message-ID: <200407272002.i6RK2eW5085767@possum.icir.org> > This started out as an attempt to orient people in the > right direction - really the basics only. Many of your points go > beyond the basics, which raises the question of what we want this > document to evolve into? Probably you're right - it should evolve > into a complete XORP programmers guide over time. > > I'll try and add material as I find time, but this isn't likely to be > for a few weeks. If you want to add material yourself, feel free (by > the way, this applies to everyone - if you don't have CVS commit > access, send me text or a diff, and I'll include it) Yes, I know this is time consuming. Myself I also will try to add info as I find the time. > Also, do you think this is solid enough now to be linked from the web > pages? My (slight) preference would be to add it when we release 1.1 so in the mean time we can add more info. Regards, Pavlin From pavlin@icir.org Wed Jul 28 04:38:55 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 27 Jul 2004 20:38:55 -0700 Subject: [Xorp-hackers] HEADS UP: ./configure flag name change Message-ID: <200407280338.i6S3ctwK027765@possum.icir.org> By users' request (and because it is the right thing to do), I have replaced the ./configure flag --enable-advanced-mcast-api with --disable-advanced-multicast-api (note the change in the polarity of the flag AND in the name). Previously, the --enable-advanced-mcast-api flag attempted to enable the so-called advanced multicast API in the kernel (for multicast routing purpose), but only if the kernel really supports it. Now the default behavior is that the advanced multicast API will be used if the kernel supports it (auto-detected), but the new flag --disable-advanced-multicast-api can be used to explicitly disable the new API. Pavlin From lqin@sce.carleton.ca Thu Jul 29 18:01:03 2004 From: lqin@sce.carleton.ca (Liang Qin) Date: Thu, 29 Jul 2004 13:01:03 -0400 Subject: [Xorp-hackers] Template file problem Message-ID: <41092D4F.30108@sce.carleton.ca> Hi XORP users, After I moved code from XORP 0.5 to XORP 1.0, and run with ./xorp_rtrmgr -b config.linux I got error message like: ERROR xorp_rtrmgr:4261 RTRMGR +212 main_rtrmgr.cc run ] Shutting down due to an init error: PARSE ERROR {Template File" ......../olp.tp line 3]: syntax error; last symbol parsed was "olp" but I have the same template file works well in XORP 0.5 my olp.tp: protocols { olp { interfaceName: text = "eth1"; ............ } } .............. I noticed some changes in main_rtrmgr.cc, is it the reason? Is there any syntax error in my olp.tp? Thanks! Liang From M.Handley@cs.ucl.ac.uk Thu Jul 29 18:48:14 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 29 Jul 2004 18:48:14 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Template file problem In-Reply-To: Your message of "Thu, 29 Jul 2004 13:01:03 EDT." <41092D4F.30108@sce.carleton.ca> Message-ID: <23690.1091123294@aardvark.cs.ucl.ac.uk> >I got error message like: >ERROR xorp_rtrmgr:4261 RTRMGR +212 main_rtrmgr.cc run ] Shutting down >due to an init error: PARSE ERROR {Template >File" ......../olp.tp line 3]: syntax error; last symbol parsed was "olp" > >but I have the same template file works well in XORP 0.5 > >my olp.tp: >protocols { > olp { > interfaceName: text = "eth1"; > ............ > } >} My apologies for the cryptic error message - rewriting this parser is on my to-do list. I believe the problem is probably the use of the type "text" when it should be "txt". Cheers, Mark From lqin@sce.carleton.ca Thu Jul 29 19:55:14 2004 From: lqin@sce.carleton.ca (Liang Qin) Date: Thu, 29 Jul 2004 14:55:14 -0400 Subject: [Xorp-hackers] Re: [Xorp-users] Template file problem In-Reply-To: <23690.1091123294@aardvark.cs.ucl.ac.uk> References: <23690.1091123294@aardvark.cs.ucl.ac.uk> Message-ID: <41094812.50403@sce.carleton.ca> Thanks Mark! It seems that the template file's format changes a little bit, including %modinfo, isn't it? :-) Another question, after launching XORP by xorp_rtrmgr, I got lots of Error messages: [ERROR xorp_rtrmgr: 4231 RTRMGR +116 userdb.cc add user ] Group "xorp" does not exist on this system, What does it mean? Liang Mark Handley wrote: >>I got error message like: >>ERROR xorp_rtrmgr:4261 RTRMGR +212 main_rtrmgr.cc run ] Shutting down >>due to an init error: PARSE ERROR {Template >>File" ......../olp.tp line 3]: syntax error; last symbol parsed was "olp" >> >>but I have the same template file works well in XORP 0.5 >> >>my olp.tp: >>protocols { >> olp { >> interfaceName: text = "eth1"; >> ............ >> } >>} >> >> > >My apologies for the cryptic error message - rewriting this parser is >on my to-do list. > >I believe the problem is probably the use of the type "text" when it >should be "txt". > >Cheers, > Mark > >_______________________________________________ >Xorp-hackers mailing list >Xorp-hackers@icir.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > From adam@hiddennet.net Thu Jul 29 21:19:38 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Thu, 29 Jul 2004 21:19:38 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Template file problem In-Reply-To: <41094812.50403@sce.carleton.ca> References: <23690.1091123294@aardvark.cs.ucl.ac.uk> <41094812.50403@sce.carleton.ca> Message-ID: <1091132378.8063.5.camel@localhost> Group in this context is the unix group. If a normal user (non root) runs xorpsh and wants to change from the normal mode where you can only view the xorp configuration to the configuration mode where you can configure the router, that user needs to a member of the unix group called "xorp" . For example : bash-2.05b$ cat /etc/group | grep xorp xorp:*:244:adam,eve,snake The users adam, eve, snake and root would be able to configure xorp on the system above by running the xorp shell, xorpsh . Hope this helps Adam On Thu, 2004-07-29 at 14:55 -0400, Liang Qin wrote: > Thanks Mark! > > It seems that the template file's format changes a little bit, including > %modinfo, isn't it? :-) > > Another question, after launching XORP by xorp_rtrmgr, > I got lots of Error messages: > [ERROR xorp_rtrmgr: 4231 RTRMGR +116 userdb.cc add user ] Group "xorp" > does not exist on this system, > > What does it mean? > > > > Liang > > Mark Handley wrote: > > >>I got error message like: > >>ERROR xorp_rtrmgr:4261 RTRMGR +212 main_rtrmgr.cc run ] Shutting down > >>due to an init error: PARSE ERROR {Template > >>File" ......../olp.tp line 3]: syntax error; last symbol parsed was "olp" > >> > >>but I have the same template file works well in XORP 0.5 > >> > >>my olp.tp: > >>protocols { > >> olp { > >> interfaceName: text = "eth1"; > >> ............ > >> } > >>} > >> > >> > > > >My apologies for the cryptic error message - rewriting this parser is > >on my to-do list. > > > >I believe the problem is probably the use of the type "text" when it > >should be "txt". > > > >Cheers, > > Mark > > > >_______________________________________________ > >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 -- Adam Greenhalgh From M.Handley@cs.ucl.ac.uk Thu Jul 29 22:58:30 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 29 Jul 2004 22:58:30 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Template file problem In-Reply-To: Your message of "Thu, 29 Jul 2004 14:55:14 EDT." <41094812.50403@sce.carleton.ca> Message-ID: <32232.1091138310@vulture.xorp.org> >It seems that the template file's format changes a little bit, including >%modinfo, isn't it? :-) Yes, it did change. CVS indicates it changed on May 18th, when we aligned all the types in the template file with the types in the XRLs because the mismatch was confusing. The changes that were made were: ipv4_prefix -> ipv4net ipv6_prefix -> ipv6net uint -> u32 int -> i32 text -> txt This should have been discussed on xorp-hackers, but back then we were still learning about which things to discuss on which mailing list. Sorry about that. >Another question, after launching XORP by xorp_rtrmgr, >I got lots of Error messages: >[ERROR xorp_rtrmgr: 4231 RTRMGR +116 userdb.cc add user ] Group "xorp" >does not exist on this system, > >What does it mean? Adam summarised this quite well. Basically xorpsh currently has a crude form of user permissions: if you're in the Unix xorp group, you can enter configuration mode. If not, then you can't. In the long run, this crude permissions scheme should be replaced by a more fine-grain access control mechanism, configurable through the CLI. But it's probably best to see how things are really used in practice before we figure out what the real requirements are for access control. - Mark From adam@hiddennet.net Fri Jul 30 08:38:47 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Fri, 30 Jul 2004 08:38:47 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Template file problem In-Reply-To: <32232.1091138310@vulture.xorp.org> References: <32232.1091138310@vulture.xorp.org> Message-ID: <1091173127.11870.7.camel@localhost> On Thu, 2004-07-29 at 22:58 +0100, Mark Handley wrote: > > Adam summarised this quite well. Basically xorpsh currently has a > crude form of user permissions: if you're in the Unix xorp group, you > can enter configuration mode. If not, then you can't. > > In the long run, this crude permissions scheme should be replaced by a > more fine-grain access control mechanism, configurable through the > CLI. But it's probably best to see how things are really used in > practice before we figure out what the real requirements are for > access control. > Thoughts, comments and ideas from users about what users would find useful are always welcome. So if you have an idea about how something should be say. Adam From edrt@citiz.net Fri Jul 30 12:24:59 2004 From: edrt@citiz.net (edrt) Date: Fri, 30 Jul 2004 19:24:59 +0800 Subject: [Xorp-hackers] xorpsh startup message Message-ID: <200407301122.i6UBMFbV078687@wyvern.icir.org> Hi All, I have installed XORP on 6 nodes to test PIMSM. When XORP-1.0RC was released, I upgraded all the nodes from XORP-0.5 to XORP-1.0RC. After some testing, I thought I found a bug and reported it to Pavlin. Followed his advice, I tried to upgrade all the nodes to the latest cvs code. When upgrading the nodes, I found the problem lies in I forgot to upgrade some of the nodes to XORP-1.0RC when testing. (The problem already fixed in XORP-1.0RC.) I propose to add BUILD_HOST, BUILD_DATE information to xorpsh startup message to help administrator/developer to detect this kind of multiple revision system managment problem. And Pavlin suggested to post on the mailing list to gather more requests/ideas on what additional useful information should be added to xorpsh startup message. So, pls throw suggestions to this mail thread :) Thanks Eddy From pavlin@icir.org Fri Jul 30 17:45:03 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 30 Jul 2004 09:45:03 -0700 Subject: [Xorp-hackers] xorpsh startup message In-Reply-To: Message from "edrt" of "Fri, 30 Jul 2004 19:24:59 +0800." <200407301122.i6UBMFbV078687@wyvern.icir.org> Message-ID: <200407301645.i6UGj3wK048683@possum.icir.org> > I propose to add BUILD_HOST, BUILD_DATE information to xorpsh startup message > to help administrator/developer to detect this kind of multiple revision system managment XORP_VERSION is another thing that comes to mind. If we want to take it further, every XORP process should be able to return this information by XRL. Thus, within xorpsh a command like "show version" can print such info for all running XORP processes. Any other suggestions? Pavlin From adam@hiddennet.net Fri Jul 30 17:59:00 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Fri, 30 Jul 2004 17:59:00 +0100 Subject: [Xorp-hackers] xorpsh startup message In-Reply-To: <200407301645.i6UGj3wK048683@possum.icir.org> References: <200407301645.i6UGj3wK048683@possum.icir.org> Message-ID: <1091206740.8013.3.camel@localhost> I like the xrl idea, I think the printing of this type of information should be on the premise that if you want the information you ask for it rather than being given it by default. How useful would it be for debugging would it be if "show system_info" were to return information about the local machine and the configure options used to build xorp ? Adam On Fri, 2004-07-30 at 09:45 -0700, Pavlin Radoslavov wrote: > > I propose to add BUILD_HOST, BUILD_DATE information to xorpsh startup message > > to help administrator/developer to detect this kind of multiple revision system managment > > XORP_VERSION is another thing that comes to mind. If we want to take > it further, every XORP process should be able to return this > information by XRL. Thus, within xorpsh a command like > "show version" can print such info for all running XORP processes. > > Any other suggestions? > > Pavlin > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Adam Greenhalgh