From ss at comp.lancs.ac.uk Mon Feb 7 07:10:12 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Mon, 07 Feb 2011 15:10:12 +0000 Subject: [Xorp-hackers] Using results from one XRL to respond to another Message-ID: <4D500B54.6030707@comp.lancs.ac.uk> Hi, I've just started looking at some XORP code, with a view to fixing a certain problem. We have three XORP processes, A, B and C. A invokes a method on B. To provide the results of this call, B must call C, and use the results of this 'nested' call. AFAICT, a client makes XRL method calls asynchronously, i.e. it has to set up a local callback object for each call, pass that object along with the call's in-arguments, and then pass control (back) to the event loop. The event loop eventually picks up the response, unmarshalls it, and invokes the callback object with the out-arguments. In contrast, servers must respond synchronously. The server implements a regular C++ method with both in and out parameters. By the time it returns, it must have determined the out values. So if a server method needs to make an XRL call, and use the results of that call to respond to its own caller, it must set up a callback object to be passed with its own call, and return to the event loop in order to receive the results it asked for. Yet it must have those results before it returns to the event loop, because they are needed to determine the results to be passed to its own caller, which have to be set before returning to the event loop. This surely isn't so unusual that it's never come up before. Is there a standard idiom for dealing with it? If not, I can see several alternatives: 1. Change the interface on B so that A must have its own interface, and A must specify a method on it to be called when B finally gets the results of the nested call. 2. Before B returns to the event loop, it invokes the event loop repeatedly until its own callback is serviced. Perhaps this is the recommended idiom...? 3. Redesign the code generator so that the Xrl*TargetBase class contains methods to be provided by the implementation that receive the in-args plus a call-back for the out-args. Option 3 is likely to require more time than we have available to deal with this problem. Option 2 assumes that the event loop is re-entrant; the event loop will be calling the application code, which will call the event loop. Is that safe? Is it guaranteed by specification? I think it would also have some potentially unwelcome side effects. Option 1 is inconvenient for us, but probably the quickest option if (2) is not possible. Thanks, Steven From greearb at candelatech.com Mon Feb 7 07:52:02 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 07 Feb 2011 07:52:02 -0800 Subject: [Xorp-hackers] Using results from one XRL to respond to another In-Reply-To: <4D500B54.6030707@comp.lancs.ac.uk> References: <4D500B54.6030707@comp.lancs.ac.uk> Message-ID: <4D501522.4090807@candelatech.com> On 02/07/2011 07:10 AM, Steven Simpson wrote: > Hi, > > I've just started looking at some XORP code, with a view to fixing a > certain problem. We have three XORP processes, A, B and C. A invokes a > method on B. To provide the results of this call, B must call C, and > use the results of this 'nested' call. > > AFAICT, a client makes XRL method calls asynchronously, i.e. it has to > set up a local callback object for each call, pass that object along > with the call's in-arguments, and then pass control (back) to the event > loop. The event loop eventually picks up the response, unmarshalls it, > and invokes the callback object with the out-arguments. > > In contrast, servers must respond synchronously. The server implements > a regular C++ method with both in and out parameters. By the time it > returns, it must have determined the out values. > > So if a server method needs to make an XRL call, and use the results of > that call to respond to its own caller, it must set up a callback object > to be passed with its own call, and return to the event loop in order to > receive the results it asked for. Yet it must have those results before > it returns to the event loop, because they are needed to determine the > results to be passed to its own caller, which have to be set before > returning to the event loop. > > This surely isn't so unusual that it's never come up before. Is there a > standard idiom for dealing with it? If not, I can see several alternatives: > > 1. Change the interface on B so that A must have its own interface, > and A must specify a method on it to be called when B finally gets > the results of the nested call. > 2. Before B returns to the event loop, it invokes the event loop > repeatedly until its own callback is serviced. Perhaps this is > the recommended idiom...? > 3. Redesign the code generator so that the Xrl*TargetBase class > contains methods to be provided by the implementation that receive > the in-args plus a call-back for the out-args. > > Option 3 is likely to require more time than we have available to deal > with this problem. > > Option 2 assumes that the event loop is re-entrant; the event loop will > be calling the application code, which will call the event loop. Is > that safe? Is it guaranteed by specification? I think it would also > have some potentially unwelcome side effects. > > Option 1 is inconvenient for us, but probably the quickest option if (2) > is not possible. Maybe have the initial response be 'working-on-it', and then pass the info back with a separate XRL command when the command is completed? Make copies of any data you need from the original XRL, including some sort of key so that the requestor can recognize the real response when it finally comes. Thanks, Ben > > Thanks, > > Steven > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Mon Feb 7 07:58:42 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Mon, 07 Feb 2011 15:58:42 +0000 Subject: [Xorp-hackers] Using results from one XRL to respond to another In-Reply-To: <4D501522.4090807@candelatech.com> References: <4D500B54.6030707@comp.lancs.ac.uk> <4D501522.4090807@candelatech.com> Message-ID: <4D5016B2.3010102@comp.lancs.ac.uk> On 07/02/11 15:52, Ben Greear wrote: > On 02/07/2011 07:10 AM, Steven Simpson wrote: >> 1. Change the interface on B so that A must have its own interface, >> and A must specify a method on it to be called when B finally >> gets >> the results of the nested call. > > Maybe have the initial response be 'working-on-it', and then pass the > info > back with a separate XRL command when the command is completed? Make > copies of any data you need from the original XRL, including some sort of > key so that the requestor can recognize the real response when it finally > comes. Yes, I think that's basically what I mean by option 1. I'm just checking that I'm not missing an easier option. Thanks, Steven -- From ss at comp.lancs.ac.uk Mon Feb 21 08:05:07 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Mon, 21 Feb 2011 16:05:07 +0000 Subject: [Xorp-hackers] Remote finder: XRLs, or local ports? Message-ID: <4D628D33.6070600@comp.lancs.ac.uk> Hello again, In our project, we need one router to invoke XRLs on another. Can it be done? I've seen two protocols mentioned: 'finder' and 'stcp'. It seems that stcp is typically the raw method, where the target is a host and port. Meanwhile, finder takes a string target, and this is used to resolve the finder: XRL into an stcp: one. The finder also seems to do some access control. Right so far, I hope...? One option for us is simply to get the host-port of one process S across to another C, so that C can call S with stcp. C will also have to provide a callback XRL, also stcp. Both processes therefore need to get their port numbers to form stcp XRLs, but we can't seem to find a way for the nodes (as Xrl*TargetBases) to obtain such details. Is it possible with the current API? Is there an alternative way to do it with the finder, e.g. by finder://local-target-name at remote-host/...? We'd hope that this would also allow us to continue using the finder's access control. Thanks, Steven -- From ss at comp.lancs.ac.uk Wed Feb 23 03:51:40 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Wed, 23 Feb 2011 11:51:40 +0000 Subject: [Xorp-hackers] Remote finder: XRLs, or local ports? In-Reply-To: <4D628D33.6070600@comp.lancs.ac.uk> References: <4D628D33.6070600@comp.lancs.ac.uk> Message-ID: <4D64F4CC.6070504@comp.lancs.ac.uk> On 21/02/11 16:05, Steven Simpson wrote: > One option for us is simply to get the host-port of one process S across > to another C, so that C can call S with stcp. C will also have to > provide a callback XRL, also stcp. Both processes therefore need to get > their port numbers to form stcp XRLs, but we can't seem to find a way > for the nodes (as Xrl*TargetBases) to obtain such details. Is it > possible with the current API? Okay, we've seen how to do this. First, we have to run xorp_rtrmgr with XORP_PF=t to ensure that STCP is used. As our node starts up, it has to talk to an external resolver to report its address. It inherits from XrlStdRouter (which inherits from XrlRouter), which has been initialized by this time, including the creation of at least one XrlPFListener registered with the XrlRouter. All our node needs to do now is iterate over the protected _listeners member inherited from XrlRouter, and get out the results of protocol() (e.g. "stcp") and address() (e.g. "127.0.0.1:1234"). These are sent to the resolver (e.g. as "stcp://127.0.0.1:1234"), which will discard items it can't use ("unix:...."), and translate 127.0.0.1 to the remote address of the calling connection. This method will allow us to progress, but the remote finder:// option might still be useful to us, btw, if there's an answer to that. Cheers! -- From B32946 at freescale.com Thu Feb 24 07:02:16 2011 From: B32946 at freescale.com (Vunnava Kesava Srinivas-B32946) Date: Thu, 24 Feb 2011 15:02:16 +0000 Subject: [Xorp-hackers] XORP With PIMSMv6??? Message-ID: <9D8289DE2B23FA4EBC165B4CFB3718660B3379@039-SN1MPN1-004.039d.mgd.msft.net> Hi All, We have a requirement to bring up XORP with PIMSM6. After creating the Configuration File ; started the xorp_rtrmgr. The issue that the daemon is throwing is ; "mfea_mrouter.cc start_mtr ] setsockopt(MRT6_INIT,1) failed: Protocol not available". I am seeing this message for other daemons also. Ex: xorp_pimsm6. After some discussions; I came to know that Kernel itself should support IPv6 Multicast Routing in order to make the pimsm6 running. I thought of compiling the kernel [2.6.32] with IPv6-Multicast Routing support . while doing this I came across IPv6 Multicast routing with PIM-SM2 Support is also provided in Kernel. My Question is in order to make xorp-pimsm6 working; Do I need to compile the Kernel with just Multicast routing OR Multicast routing with pimsm6. Also please suggest if any other ways to make the xorp-pimsm6 running!!! -Thanks in Advance, VKS. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110224/b8c95997/attachment.html From greearb at candelatech.com Thu Feb 24 09:32:14 2011 From: greearb at candelatech.com (Ben Greear) Date: Thu, 24 Feb 2011 09:32:14 -0800 Subject: [Xorp-hackers] XORP With PIMSMv6??? In-Reply-To: <9D8289DE2B23FA4EBC165B4CFB3718660B3379@039-SN1MPN1-004.039d.mgd.msft.net> References: <9D8289DE2B23FA4EBC165B4CFB3718660B3379@039-SN1MPN1-004.039d.mgd.msft.net> Message-ID: <4D66961E.2000607@candelatech.com> On 02/24/2011 07:02 AM, Vunnava Kesava Srinivas-B32946 wrote: > Hi All, > > We have a requirement to bring up XORP with PIMSM6. After creating the > Configuration File ; started the xorp_rtrmgr. > > The issue that the daemon is throwing is ; ?mfea_mrouter.cc start_mtr ] > setsockopt(MRT6_INIT,1) failed: Protocol not available?. I am seeing > this message for other daemons also. Ex: xorp_pimsm6. > > After some discussions; I came to know that Kernel itself should support > IPv6 Multicast Routing in order to make the pimsm6 running. > > I thought of compiling the kernel [2.6.32] with IPv6-Multicast Routing > support . while doing this I came across IPv6 Multicast routing with > PIM-SM2 Support is also provided in Kernel. > > My Question is in order to make xorp-pimsm6 working; Do I need to > compile the Kernel with just Multicast routing OR Multicast routing with > pimsm6. Also please suggest if any other ways to make the xorp-pimsm6 > running!!! I think you should enable it. I have these enabled in my kernels: grep PIM ct-x32.cfg CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_IPV6_PIMSM_V2=y You might try a more modern kernel as well. Thanks, Ben > > -Thanks in Advance, > > VKS. > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Feb 25 12:43:31 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 25 Feb 2011 12:43:31 -0800 Subject: [Xorp-hackers] Windows build of xorp.ct for testing. Message-ID: <4D681473.4070701@candelatech.com> I have done no testing on this, but the xorp_rtrmg.exe will at least launch enough to complain about config files. Basically, I reverted the patch from 2009 that removed win32 support and hacked on it till it would compile under mingw. http://www.candelatech.com/~greearb/xorp_win32.zip If anyone gives this a try, I'm interested in knowing how it works (or not). I'll push the code to xorp.ct after I get some testing completed and make sure that I didn't obviously break xorp under Linux. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Feb 25 13:31:09 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 25 Feb 2011 13:31:09 -0800 Subject: [Xorp-hackers] Windows build of xorp.ct for testing. In-Reply-To: <4D681473.4070701@candelatech.com> References: <4D681473.4070701@candelatech.com> Message-ID: <4D681F9D.90608@candelatech.com> On 02/25/2011 12:43 PM, Ben Greear wrote: > I have done no testing on this, but the xorp_rtrmg.exe will > at least launch enough to complain about config files. > > Basically, I reverted the patch from 2009 that removed > win32 support and hacked on it till it would compile > under mingw. > > http://www.candelatech.com/~greearb/xorp_win32.zip > > If anyone gives this a try, I'm interested in knowing > how it works (or not). > > I'll push the code to xorp.ct after I get some testing > completed and make sure that I didn't obviously break > xorp under Linux. Ahh, looks like I have some more work to do...it looks in the wrong place for templates, etc... Will post when I get that fixed.. Thanks, Ben > > Thanks, > Ben > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Feb 25 15:51:53 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 25 Feb 2011 15:51:53 -0800 Subject: [Xorp-hackers] Windows build of xorp.ct for testing. In-Reply-To: <4D681F9D.90608@candelatech.com> References: <4D681473.4070701@candelatech.com> <4D681F9D.90608@candelatech.com> Message-ID: <4D684099.3090702@candelatech.com> On 02/25/2011 01:31 PM, Ben Greear wrote: > On 02/25/2011 12:43 PM, Ben Greear wrote: >> I have done no testing on this, but the xorp_rtrmg.exe will >> at least launch enough to complain about config files. >> >> Basically, I reverted the patch from 2009 that removed >> win32 support and hacked on it till it would compile >> under mingw. >> >> http://www.candelatech.com/~greearb/xorp_win32.zip >> >> If anyone gives this a try, I'm interested in knowing >> how it works (or not). >> >> I'll push the code to xorp.ct after I get some testing >> completed and make sure that I didn't obviously break >> xorp under Linux. > > Ahh, looks like I have some more work to do...it looks > in the wrong place for templates, etc... > > Will post when I get that fixed.. Ok, it's working better now. OSPF starts, but I haven't tested if it actually talks with other OSPF servers, etc. File is at same location: http://www.candelatech.com/~greearb/xorp_win32.zip Here's how I started it: To run xorp on windows: * Unzip it somewhere * Change to the xorp/sbin directory * Start router-mgr: set XORP_PF=t set XORP_ROOT=.. xorp_rtrmgr.exe -c config.boot.t xt -t ..\share\xorp\templates -m ..\lib\xorp\bin * In another window, start xorpsh: set XORP_PF=t set XORP_ROOT=.. xorpsh Here's a sample config file (Original courtesy of Asif @ iQor) C:\xorp_win32\xorp\sbin>more c:\config.boot.txt interfaces { interface "Local Area Connection 7" { disable: false vif "Local Area Connection 7" { disable: false address 10.2.46.190 { prefix-length: 24 broadcast: 10.2.46.255 disable: false } } } interface "Local Area Connection 6" { disable: false vif "Local Area Connection 6" { disable: false address 10.4.5.6 { prefix-length: 24 disable: false } } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id : 10.2.46.190 area 0.0.0.0 { interface "Local Area Connection 7" { vif "Local Area Connection 7" { address 10.2.46.190 { hello-interval: 1 router-dead-interval: 4 } } } interface "Local Area Connection 6" { vif "Local Area Connection 6" { address 10.4.5.6 { } } } } } } Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Feb 25 16:17:50 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 25 Feb 2011 16:17:50 -0800 Subject: [Xorp-hackers] Windows build of xorp.ct for testing. In-Reply-To: <4D684099.3090702@candelatech.com> References: <4D681473.4070701@candelatech.com> <4D681F9D.90608@candelatech.com> <4D684099.3090702@candelatech.com> Message-ID: <4D6846AE.1010205@candelatech.com> On 02/25/2011 03:51 PM, Ben Greear wrote: > On 02/25/2011 01:31 PM, Ben Greear wrote: >> On 02/25/2011 12:43 PM, Ben Greear wrote: >>> I have done no testing on this, but the xorp_rtrmg.exe will >>> at least launch enough to complain about config files. >>> >>> Basically, I reverted the patch from 2009 that removed >>> win32 support and hacked on it till it would compile >>> under mingw. >>> >>> http://www.candelatech.com/~greearb/xorp_win32.zip >>> >>> If anyone gives this a try, I'm interested in knowing >>> how it works (or not). >>> >>> I'll push the code to xorp.ct after I get some testing >>> completed and make sure that I didn't obviously break >>> xorp under Linux. >> >> Ahh, looks like I have some more work to do...it looks >> in the wrong place for templates, etc... >> >> Will post when I get that fixed.. > > Ok, it's working better now. OSPF starts, but I haven't > tested if it actually talks with other OSPF servers, etc. I did a quick test with OSPF, and it talks to another xorp on Linux and exchanges routes. So, I think it's somewhat usable now... Thanks, Ben > > File is at same location: > http://www.candelatech.com/~greearb/xorp_win32.zip > > > Here's how I started it: > > To run xorp on windows: > > * Unzip it somewhere > * Change to the xorp/sbin directory > * Start router-mgr: > set XORP_PF=t > set XORP_ROOT=.. > xorp_rtrmgr.exe -c config.boot.t xt -t ..\share\xorp\templates -m ..\lib\xorp\bin > > * In another window, start xorpsh: > set XORP_PF=t > set XORP_ROOT=.. > xorpsh > > Here's a sample config file (Original courtesy of Asif @ iQor) > > C:\xorp_win32\xorp\sbin>more c:\config.boot.txt > > interfaces { > interface "Local Area Connection 7" { > disable: false > vif "Local Area Connection 7" { > disable: false > address 10.2.46.190 { > prefix-length: 24 > broadcast: 10.2.46.255 > disable: false > } > } > } > interface "Local Area Connection 6" { > disable: false > vif "Local Area Connection 6" { > disable: false > address 10.4.5.6 { > prefix-length: 24 > disable: false > } > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > ospf4 { > router-id : 10.2.46.190 > area 0.0.0.0 { > interface "Local Area Connection 7" { > vif "Local Area Connection 7" { > address 10.2.46.190 { > hello-interval: 1 > router-dead-interval: 4 > } > } > } > interface "Local Area Connection 6" { > vif "Local Area Connection 6" { > address 10.4.5.6 { > } > } > } > } > > } > } > > > Thanks, > Ben > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From rps at maine.edu Sat Feb 26 20:41:33 2011 From: rps at maine.edu (Ray Soucy) Date: Sat, 26 Feb 2011 23:41:33 -0500 Subject: [Xorp-hackers] XORP 1.7 update Message-ID: I know that a lot of talk on list has been surrounding XORP.CT, but I was wondering what the state of the official XORP project is. There was activity up until mid-2010 and then everything just stopped. After preparing build notes for 1.6 today, I started looking through the list archive and saw some discussion about 1.7. I did a svn checkout of the project as it stands on sf.net, but there hasn't been much activity there either. Is the project still using sf.net, or has it migrated to something else? I see a few changes in 1.7 that stand out without digging into the commit logs or source yet: * The build system has changed to scons * XORP is now using Boost in a few places * Directory structure for installed system has been cleaned up a bit, xorp_rtrmgr and xorpsh now in xorp/sbin rather than xorp/bin, etc * Some clean-up is needed with sockets in /var/tmp Are there any other big changes or are these mostly the highlights? I was pretty surprised that the current SVN checkout is in a state that actually builds, and without the need to patch anything to get around GCC 4 changes. The only hang-up I ran into was with trying to run xorpsh as any user but root. XORP creates its socket files as root:root with only owner write permissions. When xorpsh is run by a non-root user it's unable to get access to them. I think the sane thing would be to make them group writable and set the group to xorp, or perhaps change xorpsh so that the "root" user, rather than the "xorp" user has access to enter configuration mode. I adjusted my rc script for XORP to sleep for 1 second after starting xorp_rtrmgr, then do a chmod 775 and a chown root:xorp on /var/tmp/xrl.* which seems to work. I'll need to play with it more to see if these files ever get created or removed after the initial startup. I also noticed they were adding up, so I have a rm /var/tmp/xrl.* at the end of the stop function. Aside from adjusting to those changes, everything I've tested so far seems to be working. I added instructions for the 1.7 build to http://www.soucy.org/xorp/ along side the 1.6 ones I put up today. In the archives I saw some exchanges a few months ago about a 1.7 release. How far is that from happening (if at all), and what needs to be done before it does? I think the thing that's holding the project down right now is that from the outside it appears to be dead. It's been a while since a new release, and that certainly makes people avoid the project. The current releases are in a state that makes it hard for new users to pick XORP up and give it a spin with a reasonable chance of success. If we can get the user numbers up, the developer numbers will follow. P.S. Is Mark still alive? -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From greearb at candelatech.com Mon Feb 28 22:08:52 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 28 Feb 2011 22:08:52 -0800 Subject: [Xorp-hackers] RFC: New VLAN api for xorp.ct Message-ID: <4D6C8D74.9090602@candelatech.com> Here is a patch I cooked up to deal with automatically creating/deleting VLANs, while treating them as real interfaces. This is totally un-tested (it does compile on Linux, at least). Comments welcome. I hope to test it in the next few days. http://www.candelatech.com/~greearb/0001-vlans-Treat-vlans-as-primary-interfaces.patch Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com