From jiangxin.hu at crc.gc.ca  Fri Jun  1 06:39:47 2012
From: jiangxin.hu at crc.gc.ca (Jiangxin Hu)
Date: Fri, 1 Jun 2012 09:39:47 -0400
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network routing
Message-ID: <20120601133756.B7D946B2912@mailhub.crc.ca>

Hi All,
 
Attached a patch for XORP 1.8.5 to support wireless mesh network routing.
 
The problem of XORP for wireless mesh network is routes in wireless mesh
netwrok are host routes, which means the next hop of a route is not in the
same sub-net of the interface. For example, in a wireless mesh network which
has two nodes, node 1 eth0 configured to 10.0.0.1/32 and node 2 eth0
configured to 192.168.0.1/32.
For node 1, the route -- destination net: 192.168.0.1/32 next hop:
192.168.0.1/32 interface: eth0 is a valid route.
 
Currently, there is only one wireless routing protocol (OLSR) integreated in
XORP which hit by the problem. But there are many people developing other
wireless routing protocols for XORP now and will face this problem.
 
Jiangxin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120601/9d7fcbed/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorp_wireless.zip
Type: application/x-zip-compressed
Size: 6559 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120601/9d7fcbed/attachment.bin 

From greearb at candelatech.com  Fri Jun  1 10:16:02 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 10:16:02 -0700
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <20120601133756.B7D946B2912@mailhub.crc.ca>
References: <20120601133756.B7D946B2912@mailhub.crc.ca>
Message-ID: <4FC8F8D2.3080101@candelatech.com>

On 06/01/2012 06:39 AM, Jiangxin Hu wrote:
> Hi All,
> Attached a patch for XORP 1.8.5 to support wireless mesh network routing.
> The problem of XORP for wireless mesh network is routes in wireless mesh netwrok are host routes, which means the next hop of a route is not in the same sub-net
> of the interface. For example, in a wireless mesh network which has two nodes, node 1 eth0 configured to 10.0.0.1/32 and node 2 eth0 configured to 192.168.0.1/32.
> For node 1, the route -- destination net: 192.168.0.1/32 next hop: 192.168.0.1/32 interface: eth0 is a valid route.
> Currently, there is only one wireless routing protocol (OLSR) integreated in XORP which hit by the problem. But there are many people developing other wireless
> routing protocols for XORP now and will face this problem.
> Jiangxin

Thank you for the patch!

I have a few comments before I apply this.

First, I believe it would be possible to want this feature enabled on
non-wireless interfaces, so maybe instead of having a 'wireless' attribute,
we could call it something like 'allow-disconnected-routes' or something like that.

And maybe we should just always allow those routes to be added and not even bother
with all the framework to set the flag?

At least some of the changes do not appear directly related to the 'wireless'
flag.  Maybe there was some cleanup included?  If so, it would be nice if that
were a separate patch.

Finally, please submit patches in unified format 'diff -u'.  It's even nicer
if you can use 'git format-patch'.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From aidan at highrise.ca  Fri Jun  1 10:42:12 2012
From: aidan at highrise.ca (Aidan Van Dyk)
Date: Fri, 1 Jun 2012 13:42:12 -0400
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <4FC8F8D2.3080101@candelatech.com>
References: <20120601133756.B7D946B2912@mailhub.crc.ca>
	<4FC8F8D2.3080101@candelatech.com>
Message-ID: <CAC_2qU9sv-OEPfaKvPFEALmjN8v0eUD00t_jsGEOR7ZSGzV2iA@mail.gmail.com>

On Fri, Jun 1, 2012 at 1:16 PM, Ben Greear <greearb at candelatech.com> wrote:

> Thank you for the patch!
>
> I have a few comments before I apply this.
>
> First, I believe it would be possible to want this feature enabled on
> non-wireless interfaces, so maybe instead of having a 'wireless' attribute,
> we could call it something like 'allow-disconnected-routes' or something like that.

Agreed.

> And maybe we should just always allow those routes to be added and not even bother
> with all the framework to set the flag?

Or maybe even let the module/client adding the route to specify if a
host-route is allowed?  That would require a modificatin (or addition)
to the route XRLs.

a.


-- 
Aidan Van Dyk ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Create like a god,
aidan at highrise.ca ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? command like a king,
http://www.highrise.ca/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? work like a slave.


From greearb at candelatech.com  Fri Jun  1 10:47:25 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 10:47:25 -0700
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <CAC_2qU9sv-OEPfaKvPFEALmjN8v0eUD00t_jsGEOR7ZSGzV2iA@mail.gmail.com>
References: <20120601133756.B7D946B2912@mailhub.crc.ca>
	<4FC8F8D2.3080101@candelatech.com>
	<CAC_2qU9sv-OEPfaKvPFEALmjN8v0eUD00t_jsGEOR7ZSGzV2iA@mail.gmail.com>
Message-ID: <4FC9002D.9090304@candelatech.com>

On 06/01/2012 10:42 AM, Aidan Van Dyk wrote:
> On Fri, Jun 1, 2012 at 1:16 PM, Ben Greear<greearb at candelatech.com>  wrote:
>
>> Thank you for the patch!
>>
>> I have a few comments before I apply this.
>>
>> First, I believe it would be possible to want this feature enabled on
>> non-wireless interfaces, so maybe instead of having a 'wireless' attribute,
>> we could call it something like 'allow-disconnected-routes' or something like that.
>
> Agreed.
>
>> And maybe we should just always allow those routes to be added and not even bother
>> with all the framework to set the flag?
>
> Or maybe even let the module/client adding the route to specify if a
> host-route is allowed?  That would require a modificatin (or addition)
> to the route XRLs.

I am just not sure it is worth the extra work.  If modules are adding bad
routes, then that is their bug, and I think it should be fixed there.

We can just let FEA do as its told unless the request is obviously
and forever wrong.  It seems adding host routes like this is not
always wrong..so can just relax that check.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Fri Jun  1 10:49:17 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 10:49:17 -0700
Subject: [Xorp-hackers] Anyone working on IGMP Proxy or
	Static-Multicast-Routes for Xorp?
Message-ID: <4FC9009D.4060805@candelatech.com>

I've had a request from a customer to add those features to xorp, and plan to start looking
at it soon.  If anyone else is working on this, please let me know..maybe we
can pool efforts.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From tom.kuhn at ngc.com  Fri Jun  1 11:53:34 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Fri, 1 Jun 2012 18:53:34 +0000
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>

Hi group!

I ham not an expert in Linux or cross compiling, but, with  a lot of help from the BUILD_NOTES file,  I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL, ncurses, and libpcab prior to cross compiling XORP.  I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj directory I see the /mip64-octeon-linux-gnu folder.  I assume that is everything that I need to put on my platform, but it is a whopping 632MB!  That seems a little large.  What am I missing.   Flags? debug?  Here is what I set:

scons build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-sstrip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib \


Tom Kuhn

Northrop Grumman Information Systems
11474 Corporate Blvd., Suite 120
Orlando, Fl 32817
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120601/6a6fd3aa/attachment.html 

From greearb at candelatech.com  Fri Jun  1 11:57:39 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 11:57:39 -0700
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
Message-ID: <4FC910A3.2040103@candelatech.com>

On 06/01/2012 11:53 AM, Kuhn, Thomas J (IS) wrote:
> Hi group!
>
> I ham not an expert in Linux or cross compiling, but, with a lot of help from the BUILD_NOTES file, I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL,
> ncurses, and libpcab prior to cross compiling XORP. I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj
> directory I see the /mip64-octeon-linux-gnu folder. I assume that is everything that I need to put on my platform, but it is a whopping 632MB! That seems a
> little large. What am I missing. Flags? debug? Here is what I set:
>
> scons build=mips64-octeon-linux-gnu \
>
> STRIP=mips64-octeon-linux-gnu-sstrip \
>
> CC=mips64-octeon-linux-gnu-gcc \
>
> CXX=mips64-octeon-linux-gnu-g++ \
>
> CFLAGS=-I/home/build/octeon-staging/include \
>
> CXXFLAGS=-I/home/build/octeon-staging/include \
>
> LINKFLAGS=-L/home/build/octeon-staging/lib \

Do the install step.  I think that strips by default..and if not,
you can manually do a strip on all of the installed files.  That should
get it down to a much more manageable size...

Thanks,
Ben

>
> *Tom Kuhn*
>
> *Northrop Grumman Information Systems*
> 11474 Corporate Blvd., Suite 120
> Orlando, Fl 32817
> Office: (407) 737-4953
> Cell: (407) 721-0628
> tom.kuhn at ngc.com <mailto:tom.kuhn at ngc.com>
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From jiangxin.hu at crc.gc.ca  Fri Jun  1 12:07:58 2012
From: jiangxin.hu at crc.gc.ca (Jiangxin Hu)
Date: Fri, 1 Jun 2012 15:07:58 -0400
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <4FC8F8D2.3080101@candelatech.com>
Message-ID: <20120601190609.D3AEC6B28BA@mailhub.crc.ca>

>> First, I believe it would be possible to want this feature enabled on
non-wireless interfaces, so maybe instead of having >> a 'wireless'
attribute, we could call it something like 'allow-disconnected-routes' or
something like that.
>> And maybe we should just always allow those routes to be added and not
even bother with all the framework to set the flag?

Agree if we allow such routes for wired network. I don't know it is
meaningful for wired network or not.

>> At least some of the changes do not appear directly related to the
'wireless'
>> flag.  Maybe there was some cleanup included?  If so, it would be nice if
that were a separate patch.

There are two things in the code changes:
1. the parameter 'wireless' (fea, ifmgr, mirror, etc.)
2. the execution part (fea, rib)
   in order to insert such route into kernel, the add route function call
must declare such route as scope-link type route
   also, theoretically, the route -- destination net: 192.168.0.0/24 next
hop: 192.168.0.1 interface: eth0 is a valid route
   for node 1 configure such as eth0:10.0.0.1/24. however, I don't think any
wireless routing protocol generated such rotue now.

* This work is done on Fedora core 16, so other system may not work.
* 'wireless' parameter is for interface only, any vif under the interface
will be treated as wireless vif

Jiangxin

-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 01, 2012 1:16 PM
To: Jiangxin Hu
Cc: xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
routing

On 06/01/2012 06:39 AM, Jiangxin Hu wrote:
> Hi All,
> Attached a patch for XORP 1.8.5 to support wireless mesh network routing.
> The problem of XORP for wireless mesh network is routes in wireless 
> mesh netwrok are host routes, which means the next hop of a route is not
in the same sub-net of the interface. For example, in a wireless mesh
network which has two nodes, node 1 eth0 configured to 10.0.0.1/32 and node
2 eth0 configured to 192.168.0.1/32.
> For node 1, the route -- destination net: 192.168.0.1/32 next hop:
192.168.0.1/32 interface: eth0 is a valid route.
> Currently, there is only one wireless routing protocol (OLSR) 
> integreated in XORP which hit by the problem. But there are many people
developing other wireless routing protocols for XORP now and will face this
problem.
> Jiangxin

Thank you for the patch!

I have a few comments before I apply this.

First, I believe it would be possible to want this feature enabled on
non-wireless interfaces, so maybe instead of having a 'wireless' attribute,
we could call it something like 'allow-disconnected-routes' or something
like that.

And maybe we should just always allow those routes to be added and not even
bother with all the framework to set the flag?

At least some of the changes do not appear directly related to the
'wireless'
flag.  Maybe there was some cleanup included?  If so, it would be nice if
that were a separate patch.

Finally, please submit patches in unified format 'diff -u'.  It's even nicer
if you can use 'git format-patch'.

Thanks,
Ben


--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Fri Jun  1 12:11:55 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 12:11:55 -0700
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <20120601190609.D3AEC6B28BA@mailhub.crc.ca>
References: <20120601190609.D3AEC6B28BA@mailhub.crc.ca>
Message-ID: <4FC913FB.4090503@candelatech.com>

On 06/01/2012 12:07 PM, Jiangxin Hu wrote:
>>> First, I believe it would be possible to want this feature enabled on
> non-wireless interfaces, so maybe instead of having>>  a 'wireless'
> attribute, we could call it something like 'allow-disconnected-routes' or
> something like that.
>>> And maybe we should just always allow those routes to be added and not
> even bother with all the framework to set the flag?
>
> Agree if we allow such routes for wired network. I don't know it is
> meaningful for wired network or not.
>
>>> At least some of the changes do not appear directly related to the
> 'wireless'
>>> flag.  Maybe there was some cleanup included?  If so, it would be nice if
> that were a separate patch.
>
> There are two things in the code changes:
> 1. the parameter 'wireless' (fea, ifmgr, mirror, etc.)
> 2. the execution part (fea, rib)
>     in order to insert such route into kernel, the add route function call
> must declare such route as scope-link type route
>     also, theoretically, the route -- destination net: 192.168.0.0/24 next
> hop: 192.168.0.1 interface: eth0 is a valid route
>     for node 1 configure such as eth0:10.0.0.1/24. however, I don't think any
> wireless routing protocol generated such rotue now.

I think any interface can be used in a mesh, even if it is mostly
wireless devices in the real world.  If the routing protocol
thinks a route should be added, and the kernel doesn't complain,
I see no reason for FEA to complain...

> * This work is done on Fedora core 16, so other system may not work.
> * 'wireless' parameter is for interface only, any vif under the interface
> will be treated as wireless vif

Would you care to re-do the patch so that you just change FEA to
always allow these types of routes, and skip adding the new
interface flag (and all the related xrl stuff)?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From jiangxin.hu at crc.gc.ca  Fri Jun  1 12:18:51 2012
From: jiangxin.hu at crc.gc.ca (Jiangxin Hu)
Date: Fri, 1 Jun 2012 15:18:51 -0400
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <4FC913FB.4090503@candelatech.com>
Message-ID: <20120601191702.37F116B2912@mailhub.crc.ca>

OK. Actually I did that first before adding the interface flag.

Jiangxin

-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 01, 2012 3:12 PM
To: Jiangxin Hu
Cc: xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
routing

On 06/01/2012 12:07 PM, Jiangxin Hu wrote:
>>> First, I believe it would be possible to want this feature enabled 
>>> on
> non-wireless interfaces, so maybe instead of having>>  a 'wireless'
> attribute, we could call it something like 'allow-disconnected-routes' 
> or something like that.
>>> And maybe we should just always allow those routes to be added and 
>>> not
> even bother with all the framework to set the flag?
>
> Agree if we allow such routes for wired network. I don't know it is 
> meaningful for wired network or not.
>
>>> At least some of the changes do not appear directly related to the
> 'wireless'
>>> flag.  Maybe there was some cleanup included?  If so, it would be 
>>> nice if
> that were a separate patch.
>
> There are two things in the code changes:
> 1. the parameter 'wireless' (fea, ifmgr, mirror, etc.) 2. the 
> execution part (fea, rib)
>     in order to insert such route into kernel, the add route function 
> call must declare such route as scope-link type route
>     also, theoretically, the route -- destination net: 192.168.0.0/24 
> next
> hop: 192.168.0.1 interface: eth0 is a valid route
>     for node 1 configure such as eth0:10.0.0.1/24. however, I don't 
> think any wireless routing protocol generated such rotue now.

I think any interface can be used in a mesh, even if it is mostly wireless
devices in the real world.  If the routing protocol thinks a route should be
added, and the kernel doesn't complain, I see no reason for FEA to
complain...

> * This work is done on Fedora core 16, so other system may not work.
> * 'wireless' parameter is for interface only, any vif under the 
> interface will be treated as wireless vif

Would you care to re-do the patch so that you just change FEA to always
allow these types of routes, and skip adding the new interface flag (and all
the related xrl stuff)?

Thanks,
Ben


--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From igorm at etf.rs  Fri Jun  1 12:17:55 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 1 Jun 2012 21:17:55 +0200
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <4FC8F8D2.3080101@candelatech.com>
References: <20120601133756.B7D946B2912@mailhub.crc.ca>
	<4FC8F8D2.3080101@candelatech.com>
Message-ID: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>

> First, I believe it would be possible to want this feature enabled on
> non-wireless interfaces, so maybe instead of having a 'wireless' attribute,
> we could call it something like 'allow-disconnected-routes' or something like that.
>

Agreed++


@Jiangxin I have few comments on the patch:

1. Style and indetitation should be fixed - consult
https://github.com/greearb/xorp.ct/blob/master/xorp/devnotes/coding-style.txt
2.
---
***************
*** 843,848 ****
--- 844,857 ----
  		debug_msg("**directly connected route found for nexthop\n");
  		break;
  	    }
+ 	    int    family = re->net().af();
+ 	    IPNextHop<A> *np = (IPNextHop<A> *)re->nexthop();
+ 	    if (IPvX::ZERO(family) == np->addr() ||
+ 		(re->net()).contains(np->addr())) {
+ 		tryWireless = true;
+ //XLOG_INFO("**** find wireless route %s  %s  %s    for         %s
%s", vif->str().c_str(),(re->net()).str().c_str(),(np->addr()).str().c_str(),net.str().c_str(),
nexthop_addr.str().c_str());
+ 		break;
+ 	    }
  	}

  	//
---
Instead of using IPvX::ZERO(family) You can use A::ZERO(). Rib is
templatized after all.

When You don't something You should delete it, not comment it out.

Also I didn't quite understand what do You wand to do here:

+ 	    if (IPvX::ZERO(family) == np->addr() ||
+ 		(re->net()).contains(np->addr())) {
+ 		tryWireless = true;

Why is this a special case? Didn't you say the problem is when the
nexthop route isn't from the same subnet as vif? I think that it's
quite ok that route have the nexthop isn't from it's subnet, if this
isn't a direct nexthop.

3.
---
--- 865,916 ----
  	break;
      } while (false);

!     if (vif == NULL && !tryWireless) {
  	debug_msg("**not directly connected route found for nexthop\n");
  	//
  	// XXX: If the route came from an IGP, then we must have
  	// a directly-connected interface toward the next-hop router.
  	//
  	if (protocol->protocol_type() == IGP) {
!
!             if (tryWireless || net.contains(nexthop_addr)) {

----> You wouldn't be here if tryWireless was true, why do you check it again?


!             // need find correct vif
! 		tryWireless = true;
!             }
!
! 	    else {
! 	        XLOG_ERROR("Attempting to add IGP route to table \"%s\" "
  		       "(prefix %s next-hop %s): no directly connected "
  		       "interface toward the next-hop router",
  		       tablename.c_str(), net.str().c_str(),
  		       nexthop_addr.str().c_str());
! 	        return XORP_ERROR;
! 	    }
  	}
      }

      if (vif != NULL) {
  	nexthop = find_or_create_peer_nexthop(nexthop_addr);
      } else {
! 	if (tryWireless) {
! 	    map<string, RibVif*>::iterator iter;
!
! 	    for (iter = _vifs.begin(); iter != _vifs.end(); ++iter) {
!         	vif = iter->second;
!         	if (! vif->is_underlying_vif_up())
!             	    continue;           // XXX: ignore vifs that are not up
! 		if (_rib_manager.is_wireless_if(vif->ifname()))
! 		    break;;

--> double ;


! 	    }
! 	    nexthop = find_or_create_peer_nexthop(nexthop_addr);

--> what if you can find the "wireless" route and you had to make
external nexthop?

! 	}
! 	else
! 	    nexthop = find_or_create_external_nexthop(nexthop_addr);
      }
---

BR
Igor


From igorm at etf.rs  Fri Jun  1 12:20:55 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 1 Jun 2012 21:20:55 +0200
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
References: <20120601133756.B7D946B2912@mailhub.crc.ca>
	<4FC8F8D2.3080101@candelatech.com>
	<CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
Message-ID: <CAFdo_mUwakeKCcKzGp=rqO9=pwveM5_GvPKQqpfpJGUO4bLYvg@mail.gmail.com>

Sorry for the typos :)


> When You don't something You should delete it, not comment it out.
>

When You don't need something You should delete it, not comment it out.

>
> --> what if you can find the "wireless" route and you had to make
> external nexthop?
>

 --> what if you can't  find the "wireless" route and you had to make
 external nexthop?

BR
Igor


From igorm at etf.rs  Fri Jun  1 12:24:52 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 1 Jun 2012 21:24:52 +0200
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
In-Reply-To: <4FC910A3.2040103@candelatech.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<4FC910A3.2040103@candelatech.com>
Message-ID: <CAFdo_mV+cPh-06ct__TcS-2azwgGmj7rC9agmh_d24hq5VBStw@mail.gmail.com>

Also add flag

debug=no

BR
Igor


From tom.kuhn at ngc.com  Fri Jun  1 12:26:30 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Fri, 1 Jun 2012 19:26:30 +0000
Subject: [Xorp-hackers] EXT :Re:  Cross Compiled XORP is quite large
In-Reply-To: <CAFdo_mV+cPh-06ct__TcS-2azwgGmj7rC9agmh_d24hq5VBStw@mail.gmail.com>
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E811674@XMBVAG73.northgrum.com>

Thank you. 


Tom Kuhn
407-721-0628 (Cell)

----- Original Message -----
From: Igor Maravi? [mailto:igorm at etf.rs]
Sent: Friday, June 01, 2012 02:24 PM
To: Ben Greear <greearb at candelatech.com>
Cc: Kuhn, Thomas J (IS); xorp-hackers at icir.org <xorp-hackers at icir.org>
Subject: EXT :Re: [Xorp-hackers] Cross Compiled XORP is quite large

Also add flag

debug=no

BR
Igor


From jiangxin.hu at crc.gc.ca  Fri Jun  1 12:54:38 2012
From: jiangxin.hu at crc.gc.ca (Jiangxin Hu)
Date: Fri, 1 Jun 2012 15:54:38 -0400
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
Message-ID: <20120601195250.136D26B28BA@mailhub.crc.ca>

I am new to XORP and routing protocols so there may be some mis-understand
on handle routes. 

See my comments below.

Jiangxin

-----Original Message-----
From: Igor Maravic [mailto:igorm at etf.rs] 
Sent: Friday, June 01, 2012 3:18 PM
To: Ben Greear
Cc: Jiangxin Hu; xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
routing

> First, I believe it would be possible to want this feature enabled on 
> non-wireless interfaces, so maybe instead of having a 'wireless' 
> attribute, we could call it something like 'allow-disconnected-routes' or
something like that.
>

Agreed++


@Jiangxin I have few comments on the patch:

1. Style and indetitation should be fixed - consult
https://github.com/greearb/xorp.ct/blob/master/xorp/devnotes/coding-style.tx
t

This is a work related task so I did it in hurry. Will check the style.

2.
---
***************
*** 843,848 ****
--- 844,857 ----
  		debug_msg("**directly connected route found for nexthop\n");
  		break;
  	    }
+ 	    int    family = re->net().af();
+ 	    IPNextHop<A> *np = (IPNextHop<A> *)re->nexthop();
+ 	    if (IPvX::ZERO(family) == np->addr() ||
+ 		(re->net()).contains(np->addr())) {
+ 		tryWireless = true;
+ //XLOG_INFO("**** find wireless route %s  %s  %s    for         %s
%s",
vif->str().c_str(),(re->net()).str().c_str(),(np->addr()).str().c_str(),net.
str().c_str(),
nexthop_addr.str().c_str());
+ 		break;
+ 	    }
  	}

  	//
---
Instead of using IPvX::ZERO(family) You can use A::ZERO(). Rib is
templatized after all.

I am not very faimily with XORP, I just copy IPvX::ZERO(family) from other
place and it works. That's the best I can do at that time.

When You don't something You should delete it, not comment it out.

Also I didn't quite understand what do You wand to do here:

+ 	    if (IPvX::ZERO(family) == np->addr() ||
+ 		(re->net()).contains(np->addr())) {
+ 		tryWireless = true;

Why is this a special case? Didn't you say the problem is when the nexthop
route isn't from the same subnet as vif? I think that it's quite ok that
route have the nexthop isn't from it's subnet, if this isn't a direct
nexthop.

The problem is the nexthop is a direct nexthop but not from it's subnet.
Here is the guess if such case happens, we need to check wheter it is a
route for a wireless interface. The actual check is not here.



3.
---
--- 865,916 ----
  	break;
      } while (false);

!     if (vif == NULL && !tryWireless) {
  	debug_msg("**not directly connected route found for nexthop\n");
  	//
  	// XXX: If the route came from an IGP, then we must have
  	// a directly-connected interface toward the next-hop router.
  	//
  	if (protocol->protocol_type() == IGP) { !
!             if (tryWireless || net.contains(nexthop_addr)) {

----> You wouldn't be here if tryWireless was true, why do you check it
again?

Right, I forget reomve it.

!             // need find correct vif
! 		tryWireless = true;
!             }
!
! 	    else {
! 	        XLOG_ERROR("Attempting to add IGP route to table \"%s\" "
  		       "(prefix %s next-hop %s): no directly connected "
  		       "interface toward the next-hop router",
  		       tablename.c_str(), net.str().c_str(),
  		       nexthop_addr.str().c_str());
! 	        return XORP_ERROR;
! 	    }
  	}
      }

      if (vif != NULL) {
  	nexthop = find_or_create_peer_nexthop(nexthop_addr);
      } else {
! 	if (tryWireless) {
! 	    map<string, RibVif*>::iterator iter;
!
! 	    for (iter = _vifs.begin(); iter != _vifs.end(); ++iter) {
!         	vif = iter->second;
!         	if (! vif->is_underlying_vif_up())
!             	    continue;           // XXX: ignore vifs that are not up
! 		if (_rib_manager.is_wireless_if(vif->ifname()))
! 		    break;;

--> double ;
It is not double, it try to find a wireless vif for the route if addroute()
does not specify a vifname.

! 	    }
! 	    nexthop = find_or_create_peer_nexthop(nexthop_addr);

--> what if you can find the "wireless" route and you had to make
external nexthop?

It will lead to an error just like original XORP, the error will be "no
direct connected interface ..." I guess.

! 	}
! 	else
! 	    nexthop = find_or_create_external_nexthop(nexthop_addr);
      }
---

BR
Igor


From igorm at etf.rs  Fri Jun  1 13:33:27 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 1 Jun 2012 22:33:27 +0200
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <20120601195250.136D26B28BA@mailhub.crc.ca>
References: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
	<20120601195250.136D26B28BA@mailhub.crc.ca>
Message-ID: <CAFdo_mX-YmGeA9uf9LwKM5o7rAXQpwaY1-ZYUZNV808s=ZNDow@mail.gmail.com>

>
> It will lead to an error just like original XORP, the error will be "no
> direct connected interface ..." I guess.
>

Well the BGP doesn't agree. With your changes route resolution for BGP
will be broken.

I think that better solution would be to add function that forces
adding of direct route. Something like add_connected_route.

Then You should think a way to call that function from OLSR, and all
other protocols that need such route resolution.

BR
Igor


From greearb at candelatech.com  Fri Jun  1 13:36:54 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 13:36:54 -0700
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <CAFdo_mX-YmGeA9uf9LwKM5o7rAXQpwaY1-ZYUZNV808s=ZNDow@mail.gmail.com>
References: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
	<20120601195250.136D26B28BA@mailhub.crc.ca>
	<CAFdo_mX-YmGeA9uf9LwKM5o7rAXQpwaY1-ZYUZNV808s=ZNDow@mail.gmail.com>
Message-ID: <4FC927E6.6020008@candelatech.com>

On 06/01/2012 01:33 PM, Igor Maravi? wrote:
>>
>> It will lead to an error just like original XORP, the error will be "no
>> direct connected interface ..." I guess.
>>
>
> Well the BGP doesn't agree. With your changes route resolution for BGP
> will be broken.
>
> I think that better solution would be to add function that forces
> adding of direct route. Something like add_connected_route.
>
> Then You should think a way to call that function from OLSR, and all
> other protocols that need such route resolution.

Igor:  Why should we ever restrict adding the connected routes?

It seems to me that if the routing protocol wants it added, fea
should just do so.  But maybe I'm missing something?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From igorm at etf.rs  Fri Jun  1 14:09:11 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 1 Jun 2012 23:09:11 +0200
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <4FC927E6.6020008@candelatech.com>
References: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
	<20120601195250.136D26B28BA@mailhub.crc.ca>
	<CAFdo_mX-YmGeA9uf9LwKM5o7rAXQpwaY1-ZYUZNV808s=ZNDow@mail.gmail.com>
	<4FC927E6.6020008@candelatech.com>
Message-ID: <CAFdo_mUexh7o89stT=r293-Y8p4vmtey-NXCMGU3jB=DqkMMFA@mail.gmail.com>

> Igor: ?Why should we ever restrict adding the connected routes?
>
> It seems to me that if the routing protocol wants it added, fea
> should just do so. ?But maybe I'm missing something?
>

When the route comes to the RIB, if it isn't recognized as direct
route, RIB assumes that this route is external one.
This happens with BGP routes, because their nexthop is external.

Because of that it will try to resolve the nexthop for that route with
existing IGP routes.

The BGP routes can't be resolved, if this behavior is overridden.

Thus I think that the best solution would be if the OLSR would tell
the RIB to add directly connected route.
This will resolve the problem of RIB recognizing OLSR routes as external.
My proposition is to add function add_direct_route, that would be
called via xrl from OLSR, the same way as add_route is called now. But
that function would be in any doubt if it should resolve route as
external or not.

Maybe it is possible to check if route is resolved for wireless link,
or not, from the add_route function, without braking the BGP route
resolution,
but I think that would stress out a performance dramatically. This is
due the fact that before resolving any BGP route it would pass through
all vifs to check if they are wireless or not (according to Jiangxin
patch)

BR
Igor


From greearb at candelatech.com  Fri Jun  1 14:41:29 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 14:41:29 -0700
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <CAFdo_mUexh7o89stT=r293-Y8p4vmtey-NXCMGU3jB=DqkMMFA@mail.gmail.com>
References: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
	<20120601195250.136D26B28BA@mailhub.crc.ca>
	<CAFdo_mX-YmGeA9uf9LwKM5o7rAXQpwaY1-ZYUZNV808s=ZNDow@mail.gmail.com>
	<4FC927E6.6020008@candelatech.com>
	<CAFdo_mUexh7o89stT=r293-Y8p4vmtey-NXCMGU3jB=DqkMMFA@mail.gmail.com>
Message-ID: <4FC93709.5010703@candelatech.com>

On 06/01/2012 02:09 PM, Igor Maravi? wrote:
>> Igor:  Why should we ever restrict adding the connected routes?
>>
>> It seems to me that if the routing protocol wants it added, fea
>> should just do so.  But maybe I'm missing something?
>>
>
> When the route comes to the RIB, if it isn't recognized as direct
> route, RIB assumes that this route is external one.
> This happens with BGP routes, because their nexthop is external.
>
> Because of that it will try to resolve the nexthop for that route with
> existing IGP routes.
>
> The BGP routes can't be resolved, if this behavior is overridden.
>
> Thus I think that the best solution would be if the OLSR would tell
> the RIB to add directly connected route.
> This will resolve the problem of RIB recognizing OLSR routes as external.
> My proposition is to add function add_direct_route, that would be
> called via xrl from OLSR, the same way as add_route is called now. But
> that function would be in any doubt if it should resolve route as
> external or not.
>
> Maybe it is possible to check if route is resolved for wireless link,
> or not, from the add_route function, without braking the BGP route
> resolution,
> but I think that would stress out a performance dramatically. This is
> due the fact that before resolving any BGP route it would pass through
> all vifs to check if they are wireless or not (according to Jiangxin
> patch)

Ok, I haven't looked at this stuff in a while (and perhaps never in
great detail), so a new method: add_direct_route seems good to me.

Better than changing behaviour based on an interface flag I think.

Thanks,
Ben

>
> BR
> Igor


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From oleg.kodel at elbitsystems.com  Sat Jun  2 23:32:36 2012
From: oleg.kodel at elbitsystems.com (Kodel Oleg)
Date: Sun, 3 Jun 2012 06:32:36 +0000
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
Message-ID: <BE94B268236FE042B3A18AE3BF8AA68E227AD5EA@MXHFA01.esl.corp.elbit.co.il>

I'm working with same toolchain and I get 19M (also little large, but not 600M).



From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Kuhn, Thomas J (IS)
Sent: Friday, June 01, 2012 9:54 PM
To: xorp-hackers at icir.org
Subject: [Xorp-hackers] Cross Compiled XORP is quite large

Hi group!

I ham not an expert in Linux or cross compiling, but, with  a lot of help from the BUILD_NOTES file,  I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL, ncurses, and libpcab prior to cross compiling XORP.  I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj directory I see the /mip64-octeon-linux-gnu folder.  I assume that is everything that I need to put on my platform, but it is a whopping 632MB!  That seems a little large.  What am I missing.   Flags? debug?  Here is what I set:

scons build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-sstrip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib \


Tom Kuhn

Northrop Grumman Information Systems
11474 Corporate Blvd., Suite 120
Orlando, Fl 32817
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>


The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120603/a0120322/attachment.html 

From greearb at candelatech.com  Sun Jun  3 11:44:41 2012
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 03 Jun 2012 11:44:41 -0700
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
In-Reply-To: <BE94B268236FE042B3A18AE3BF8AA68E227AD5EA@MXHFA01.esl.corp.elbit.co.il>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<BE94B268236FE042B3A18AE3BF8AA68E227AD5EA@MXHFA01.esl.corp.elbit.co.il>
Message-ID: <4FCBB099.5040705@candelatech.com>

On 06/02/2012 11:32 PM, Kodel Oleg wrote:
> I'm working with same toolchain and I get 19M (also little large, but not 600M).

There are some compile flags that disable various things that can make
xorp smaller (assuming you don't need those various things).

See the results of:

scons --help

for details.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From tom.kuhn at ngc.com  Mon Jun  4 05:23:26 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Mon, 4 Jun 2012 12:23:26 +0000
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
In-Reply-To: <BE94B268236FE042B3A18AE3BF8AA68E227AD5EA@MXHFA01.esl.corp.elbit.co.il>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<BE94B268236FE042B3A18AE3BF8AA68E227AD5EA@MXHFA01.esl.corp.elbit.co.il>
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E811A32@XMBVAG73.northgrum.com>

Thanks!  What flags are you setting?


Tom Kuhn
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>

From: Kodel Oleg [mailto:oleg.kodel at elbitsystems.com]
Sent: Sunday, June 03, 2012 2:33 AM
To: Kuhn, Thomas J (IS); xorp-hackers at icir.org
Subject: EXT :RE: Cross Compiled XORP is quite large


I'm working with same toolchain and I get 19M (also little large, but not 600M).



From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Kuhn, Thomas J (IS)
Sent: Friday, June 01, 2012 9:54 PM
To: xorp-hackers at icir.org
Subject: [Xorp-hackers] Cross Compiled XORP is quite large

Hi group!

I ham not an expert in Linux or cross compiling, but, with  a lot of help from the BUILD_NOTES file,  I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL, ncurses, and libpcab prior to cross compiling XORP.  I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj directory I see the /mip64-octeon-linux-gnu folder.  I assume that is everything that I need to put on my platform, but it is a whopping 632MB!  That seems a little large.  What am I missing.   Flags? debug?  Here is what I set:

scons build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-sstrip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib \


Tom Kuhn

Northrop Grumman Information Systems
11474 Corporate Blvd., Suite 120
Orlando, Fl 32817
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>


sensitive information.  Unauthorized interception of this e-mail may constitute
a violation of law. If you are not the intended recipient, you are hereby
notified that any review, dissemination, distribution or duplication of this
communication is strictly prohibited. You are also asked to contact the sender
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120604/d1e6c108/attachment.html 

From tom.kuhn at ngc.com  Mon Jun  4 09:04:28 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Mon, 4 Jun 2012 16:04:28 +0000
Subject: [Xorp-hackers] EXT :Re:  Cross Compiled XORP is quite large
In-Reply-To: <4FC910A3.2040103@candelatech.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<4FC910A3.2040103@candelatech.com>
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E811B8D@XMBVAG73.northgrum.com>

After some further experimentation, I am currently doing the following:

cd /usr/local/xorp

scons --clean prefix='/home/build/octeon-staging/' \
STRIP=mips64-octeon-linux-gnu-strip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
RANLIB=mips64-octeon-linux-gnu-ranlib \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib \

scons debug=no strip=yes enable_tests=yes prefix='/home/build/octeon-staging/' build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-strip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
RANLIB=mips64-octeon-linux-gnu-ranlib \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib \

#scons install prefix='/home/build/octeon-staging/'

I do get everything to build, and the size of the directory is down to 146MB.  I am a little confused by the Install vs. the build.  The install seems to do the build all over, and stopping because of some error that it can not find something or other.  I can not remember what it was now, but it did start installing binaries into the prefix directory, but never finished.  Do I need to run install or is setting strip=yes enough?  


Tom Kuhn 
Office: (407) 737-4953 
Cell: (407) 721-0628 
tom.kuhn at ngc.com 


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 01, 2012 2:58 PM
To: Kuhn, Thomas J (IS)
Cc: xorp-hackers at icir.org
Subject: EXT :Re: [Xorp-hackers] Cross Compiled XORP is quite large

On 06/01/2012 11:53 AM, Kuhn, Thomas J (IS) wrote:
> Hi group!
>
> I ham not an expert in Linux or cross compiling, but, with a lot of help from the BUILD_NOTES file, I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL,
> ncurses, and libpcab prior to cross compiling XORP. I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj
> directory I see the /mip64-octeon-linux-gnu folder. I assume that is everything that I need to put on my platform, but it is a whopping 632MB! That seems a
> little large. What am I missing. Flags? debug? Here is what I set:
>
> scons build=mips64-octeon-linux-gnu \
>
> STRIP=mips64-octeon-linux-gnu-sstrip \
>
> CC=mips64-octeon-linux-gnu-gcc \
>
> CXX=mips64-octeon-linux-gnu-g++ \
>
> CFLAGS=-I/home/build/octeon-staging/include \
>
> CXXFLAGS=-I/home/build/octeon-staging/include \
>
> LINKFLAGS=-L/home/build/octeon-staging/lib \

Do the install step.  I think that strips by default..and if not,
you can manually do a strip on all of the installed files.  That should
get it down to a much more manageable size...

Thanks,
Ben

>
> *Tom Kuhn*
>
> *Northrop Grumman Information Systems*
> 11474 Corporate Blvd., Suite 120
> Orlando, Fl 32817
> Office: (407) 737-4953
> Cell: (407) 721-0628
> tom.kuhn at ngc.com <mailto:tom.kuhn at ngc.com>
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Mon Jun  4 09:09:07 2012
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 04 Jun 2012 09:09:07 -0700
Subject: [Xorp-hackers] EXT :Re:  Cross Compiled XORP is quite large
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E811B8D@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<4FC910A3.2040103@candelatech.com>
	<79D1420E63043F44B2039BA7A8A7A2441E811B8D@XMBVAG73.northgrum.com>
Message-ID: <4FCCDDA3.2080909@candelatech.com>

On 06/04/2012 09:04 AM, Kuhn, Thomas J (IS) wrote:
> After some further experimentation, I am currently doing the following:
>
> cd /usr/local/xorp
>
> scons --clean prefix='/home/build/octeon-staging/' \
> STRIP=mips64-octeon-linux-gnu-strip \
> CC=mips64-octeon-linux-gnu-gcc \
> CXX=mips64-octeon-linux-gnu-g++ \
> RANLIB=mips64-octeon-linux-gnu-ranlib \
> CFLAGS=-I/home/build/octeon-staging/include \
> CXXFLAGS=-I/home/build/octeon-staging/include \
> LINKFLAGS=-L/home/build/octeon-staging/lib \
>
> scons debug=no strip=yes enable_tests=yes prefix='/home/build/octeon-staging/' build=mips64-octeon-linux-gnu \
> STRIP=mips64-octeon-linux-gnu-strip \
> CC=mips64-octeon-linux-gnu-gcc \
> CXX=mips64-octeon-linux-gnu-g++ \
> RANLIB=mips64-octeon-linux-gnu-ranlib \
> CFLAGS=-I/home/build/octeon-staging/include \
> CXXFLAGS=-I/home/build/octeon-staging/include \
> LINKFLAGS=-L/home/build/octeon-staging/lib \
>
> #scons install prefix='/home/build/octeon-staging/'
>
> I do get everything to build, and the size of the directory is down to 146MB.  I am a little confused by the Install vs. the build.  The install seems to do the build all over, and stopping because of some error that it can not find something or other.  I can not remember what it was now, but it did start installing binaries into the prefix directory, but never finished.  Do I need to run install or is setting strip=yes enough?

Make sure you run the 'install' argument with all the same flags and FOO=X arguments.
That *should* make it not do any extra re-compile on the install phase.

I think the strip only happens during the install phase (too busy to look
right now)...

Thanks,
Ben

>
>
> Tom Kuhn
> Office: (407) 737-4953
> Cell: (407) 721-0628
> tom.kuhn at ngc.com
>
>
> -----Original Message-----
> From: Ben Greear [mailto:greearb at candelatech.com]
> Sent: Friday, June 01, 2012 2:58 PM
> To: Kuhn, Thomas J (IS)
> Cc: xorp-hackers at icir.org
> Subject: EXT :Re: [Xorp-hackers] Cross Compiled XORP is quite large
>
> On 06/01/2012 11:53 AM, Kuhn, Thomas J (IS) wrote:
>> Hi group!
>>
>> I ham not an expert in Linux or cross compiling, but, with a lot of help from the BUILD_NOTES file, I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL,
>> ncurses, and libpcab prior to cross compiling XORP. I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj
>> directory I see the /mip64-octeon-linux-gnu folder. I assume that is everything that I need to put on my platform, but it is a whopping 632MB! That seems a
>> little large. What am I missing. Flags? debug? Here is what I set:
>>
>> scons build=mips64-octeon-linux-gnu \
>>
>> STRIP=mips64-octeon-linux-gnu-sstrip \
>>
>> CC=mips64-octeon-linux-gnu-gcc \
>>
>> CXX=mips64-octeon-linux-gnu-g++ \
>>
>> CFLAGS=-I/home/build/octeon-staging/include \
>>
>> CXXFLAGS=-I/home/build/octeon-staging/include \
>>
>> LINKFLAGS=-L/home/build/octeon-staging/lib \
>
> Do the install step.  I think that strips by default..and if not,
> you can manually do a strip on all of the installed files.  That should
> get it down to a much more manageable size...
>
> Thanks,
> Ben
>
>>
>> *Tom Kuhn*
>>
>> *Northrop Grumman Information Systems*
>> 11474 Corporate Blvd., Suite 120
>> Orlando, Fl 32817
>> Office: (407) 737-4953
>> Cell: (407) 721-0628
>> tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>
>>
>>
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From igorm at etf.rs  Mon Jun  4 09:27:17 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Mon, 4 Jun 2012 18:27:17 +0200
Subject: [Xorp-hackers] EXT :Re: Cross Compiled XORP is quite large
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E811B8D@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<4FC910A3.2040103@candelatech.com>
	<79D1420E63043F44B2039BA7A8A7A2441E811B8D@XMBVAG73.northgrum.com>
Message-ID: <CAFdo_mU=z7Q5CZ7CpxBt3t_F3h1V-f0Q5OBDM+E_0mJ2rTF1LA@mail.gmail.com>

When you give the command scons ... binaries are all build in
BUILD_DIR. That BUILD_DIR by default is in

YOUR_XORP_DIR/xorp/obj/your_os_name_architecture

When you give the command all binaries are built in install dir. They
are built from the scratch because You're using different flags for
those two cases.
So, I think this should be your command:

scons install debug=no strip=yes enable_tests=yes
prefix='/home/build/octeon-staging/' build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-strip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
RANLIB=mips64-octeon-linux-gnu-ranlib \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib \

BR
Igor

PS. Lot of tests aren't built at all when You use the flag
enable_tests=yes. If that isn't some kind of secret, could You tell me
what You're trying to test. I enabled building the RIB tests, and I
should push the patch to the list...

2012/6/4 Kuhn, Thomas J (IS) <tom.kuhn at ngc.com>:
> After some further experimentation, I am currently doing the following:
>
> cd /usr/local/xorp
>
> scons --clean prefix='/home/build/octeon-staging/' \
> STRIP=mips64-octeon-linux-gnu-strip \
> CC=mips64-octeon-linux-gnu-gcc \
> CXX=mips64-octeon-linux-gnu-g++ \
> RANLIB=mips64-octeon-linux-gnu-ranlib \
> CFLAGS=-I/home/build/octeon-staging/include \
> CXXFLAGS=-I/home/build/octeon-staging/include \
> LINKFLAGS=-L/home/build/octeon-staging/lib \
>
> scons debug=no strip=yes enable_tests=yes prefix='/home/build/octeon-staging/' build=mips64-octeon-linux-gnu \
> STRIP=mips64-octeon-linux-gnu-strip \
> CC=mips64-octeon-linux-gnu-gcc \
> CXX=mips64-octeon-linux-gnu-g++ \
> RANLIB=mips64-octeon-linux-gnu-ranlib \
> CFLAGS=-I/home/build/octeon-staging/include \
> CXXFLAGS=-I/home/build/octeon-staging/include \
> LINKFLAGS=-L/home/build/octeon-staging/lib \
>
> #scons install prefix='/home/build/octeon-staging/'
>
> I do get everything to build, and the size of the directory is down to 146MB. ?I am a little confused by the Install vs. the build. ?The install seems to do the build all over, and stopping because of some error that it can not find something or other. ?I can not remember what it was now, but it did start installing binaries into the prefix directory, but never finished. ?Do I need to run install or is setting strip=yes enough?
>
>
> Tom Kuhn
> Office: (407) 737-4953
> Cell: (407) 721-0628
> tom.kuhn at ngc.com
>
>
> -----Original Message-----
> From: Ben Greear [mailto:greearb at candelatech.com]
> Sent: Friday, June 01, 2012 2:58 PM
> To: Kuhn, Thomas J (IS)
> Cc: xorp-hackers at icir.org
> Subject: EXT :Re: [Xorp-hackers] Cross Compiled XORP is quite large
>
> On 06/01/2012 11:53 AM, Kuhn, Thomas J (IS) wrote:
>> Hi group!
>>
>> I ham not an expert in Linux or cross compiling, but, with a lot of help from the BUILD_NOTES file, I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL,
>> ncurses, and libpcab prior to cross compiling XORP. I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj
>> directory I see the /mip64-octeon-linux-gnu folder. I assume that is everything that I need to put on my platform, but it is a whopping 632MB! That seems a
>> little large. What am I missing. Flags? debug? Here is what I set:
>>
>> scons build=mips64-octeon-linux-gnu \
>>
>> STRIP=mips64-octeon-linux-gnu-sstrip \
>>
>> CC=mips64-octeon-linux-gnu-gcc \
>>
>> CXX=mips64-octeon-linux-gnu-g++ \
>>
>> CFLAGS=-I/home/build/octeon-staging/include \
>>
>> CXXFLAGS=-I/home/build/octeon-staging/include \
>>
>> LINKFLAGS=-L/home/build/octeon-staging/lib \
>
> Do the install step. ?I think that strips by default..and if not,
> you can manually do a strip on all of the installed files. ?That should
> get it down to a much more manageable size...
>
> Thanks,
> Ben
>
>>
>> *Tom Kuhn*
>>
>> *Northrop Grumman Information Systems*
>> 11474 Corporate Blvd., Suite 120
>> Orlando, Fl 32817
>> Office: (407) 737-4953
>> Cell: (407) 721-0628
>> tom.kuhn at ngc.com <mailto:tom.kuhn at ngc.com>
>>
>>
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From tom.kuhn at ngc.com  Mon Jun  4 11:40:21 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Mon, 4 Jun 2012 18:40:21 +0000
Subject: [Xorp-hackers] Install error
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E811CAE@XMBVAG73.northgrum.com>

I have cross compiled XORP and am performing an install. The install gets part wat through and then gives the following error on args.sh.  Can anyone assist?

Install file: "bgp/harness/args.sh" as "/home/build/octeon-staging/bgp/harness/args.sh"Chmod("/home/build/octeon-staging/bgp/harness/args.sh", 0755)mips64-octeon-linux-gnu-strip /home/build/octeon-staging/bgp/harness/args.shmips64-octeon-linux-gnu-strip:/home/build/octeon-staging/bgp/harness/args.sh: File format not recognizedscons: *** [/home/build/octeon-staging/bgp/harness/args.sh] Error 1scons: building terminated because of errors


Tom Kuhn
407-721-0628 (Cell)


From greearb at candelatech.com  Mon Jun  4 11:46:30 2012
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 04 Jun 2012 11:46:30 -0700
Subject: [Xorp-hackers] Install error
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E811CAE@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811CAE@XMBVAG73.northgrum.com>
Message-ID: <4FCD0286.4000907@candelatech.com>

On 06/04/2012 11:40 AM, Kuhn, Thomas J (IS) wrote:
> I have cross compiled XORP and am performing an install. The install gets part wat through and then gives the following error on args.sh.  Can anyone assist?
>
> Install file: "bgp/harness/args.sh" as "/home/build/octeon-staging/bgp/harness/args.sh"Chmod("/home/build/octeon-staging/bgp/harness/args.sh", 0755)mips64-octeon-linux-gnu-strip /home/build/octeon-staging/bgp/harness/args.shmips64-octeon-linux-gnu-strip:/home/build/octeon-staging/bgp/harness/args.sh: File format not recognizedscons: *** [/home/build/octeon-staging/bgp/harness/args.sh] Error 1scons: building terminated because of errors

Hmmm, you might have to wrap your strip executable in a shell script that always returns success.

Or, don't strip on install via scons, but after the install is complete, manually
strip everything in the install dir and just ignore the errors about not being able
to strip .sh files and similar.

Something like:

find /usr/local/xorp -name "*" -print|xargs my-strip-exe

Thanks,
Ben

>
>
> Tom Kuhn
> 407-721-0628 (Cell)
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From noreply at github.com  Mon Jun  4 17:07:13 2012
From: noreply at github.com (GitHub)
Date: Mon, 04 Jun 2012 17:07:13 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct]
Message-ID: <4fcd4db1bb904_12d21635af048028@sh2.rs.github.com.mail>

  Branch: refs/tags/lf-5.2.5
  Home:   https://github.com/greearb/xorp.ct


From oleg.kodel at elbitsystems.com  Mon Jun  4 23:05:38 2012
From: oleg.kodel at elbitsystems.com (Kodel Oleg)
Date: Tue, 5 Jun 2012 06:05:38 +0000
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E811A32@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<BE94B268236FE042B3A18AE3BF8AA68E227AD5EA@MXHFA01.esl.corp.elbit.co.il>
	<79D1420E63043F44B2039BA7A8A7A2441E811A32@XMBVAG73.northgrum.com>
Message-ID: <BE94B268236FE042B3A18AE3BF8AA68E32FB502E@MXHFA01.esl.corp.elbit.co.il>

#!/bin/sh
scons j=2 build=mips64-octeon-linux-gnu \
disable_ipv6=yes enable_tests=no disable_fw=yes strip=yes \
disable_tracelogs=yes disable_infologs=yes disable_otherlogs=yes optimize=size debug=no \
STRIP=mips64-octeon-linux-gnu-strip CC=mips64-octeon-linux-gnu-gcc CXX=mips64-octeon-linux-gnu-g++ \
LINKFLAGS=-L/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl/lib \
CFLAGS=-I/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl \
CXXFLAGS=-I/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl $1

Use it with "build" or "install".

N.B. Somebody working on decrease of the installation size?
It is critical on embedded devices.

Oleg

From: Kuhn, Thomas J (IS) [mailto:tom.kuhn at ngc.com]
Sent: Monday, June 04, 2012 3:23 PM
To: Kodel Oleg; xorp-hackers at icir.org
Subject: RE: Cross Compiled XORP is quite large

Thanks!  What flags are you setting?


Tom Kuhn
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>

From: Kodel Oleg [mailto:oleg.kodel at elbitsystems.com]
Sent: Sunday, June 03, 2012 2:33 AM
To: Kuhn, Thomas J (IS); xorp-hackers at icir.org
Subject: EXT :RE: Cross Compiled XORP is quite large


I'm working with same toolchain and I get 19M (also little large, but not 600M).



From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Kuhn, Thomas J (IS)
Sent: Friday, June 01, 2012 9:54 PM
To: xorp-hackers at icir.org
Subject: [Xorp-hackers] Cross Compiled XORP is quite large

Hi group!

I ham not an expert in Linux or cross compiling, but, with  a lot of help from the BUILD_NOTES file,  I recently cross compiled (mip64-octeon-linux-gnu) OpenSSL, ncurses, and libpcab prior to cross compiling XORP.  I then cross compiled XORP. Everything seems to have gone on without a hitch, but when I look in the /obj directory I see the /mip64-octeon-linux-gnu folder.  I assume that is everything that I need to put on my platform, but it is a whopping 632MB!  That seems a little large.  What am I missing.   Flags? debug?  Here is what I set:

scons build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-sstrip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib \


Tom Kuhn

Northrop Grumman Information Systems
11474 Corporate Blvd., Suite 120
Orlando, Fl 32817
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>


sensitive information.  Unauthorized interception of this e-mail may constitute
a violation of law. If you are not the intended recipient, you are hereby
notified that any review, dissemination, distribution or duplication of this
communication is strictly prohibited. You are also asked to contact the sender
by reply email and immediately destroy all copies of the original message.

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120605/78c278da/attachment.html 

From tom.kuhn at ngc.com  Tue Jun  5 05:23:10 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Tue, 5 Jun 2012 12:23:10 +0000
Subject: [Xorp-hackers] EXT :Re:  Install error
In-Reply-To: <4FCD0286.4000907@candelatech.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811CAE@XMBVAG73.northgrum.com>
	<4FCD0286.4000907@candelatech.com>
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E811F21@XMBVAG73.northgrum.com>

Thanks,  

That seemed to work.  I will also try out some of the flags mentioned by Kodel Oleg too.



Tom Kuhn 
Office: (407) 737-4953 
Cell: (407) 721-0628 
tom.kuhn at ngc.com 


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Monday, June 04, 2012 2:47 PM
To: Kuhn, Thomas J (IS)
Cc: 'xorp-hackers at icir.org'
Subject: EXT :Re: [Xorp-hackers] Install error

On 06/04/2012 11:40 AM, Kuhn, Thomas J (IS) wrote:
> I have cross compiled XORP and am performing an install. The install gets part wat through and then gives the following error on args.sh.  Can anyone assist?
>
> Install file: "bgp/harness/args.sh" as "/home/build/octeon-staging/bgp/harness/args.sh"Chmod("/home/build/octeon-staging/bgp/harness/args.sh", 0755)mips64-octeon-linux-gnu-strip /home/build/octeon-staging/bgp/harness/args.shmips64-octeon-linux-gnu-strip:/home/build/octeon-staging/bgp/harness/args.sh: File format not recognizedscons: *** [/home/build/octeon-staging/bgp/harness/args.sh] Error 1scons: building terminated because of errors

Hmmm, you might have to wrap your strip executable in a shell script that always returns success.

Or, don't strip on install via scons, but after the install is complete, manually
strip everything in the install dir and just ignore the errors about not being able
to strip .sh files and similar.

Something like:

find /usr/local/xorp -name "*" -print|xargs my-strip-exe

Thanks,
Ben

>
>
> Tom Kuhn
> 407-721-0628 (Cell)
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From tom.kuhn at ngc.com  Tue Jun  5 06:49:32 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Tue, 5 Jun 2012 13:49:32 +0000
Subject: [Xorp-hackers] EXT :Re:  Install error
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E811F21@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811CAE@XMBVAG73.northgrum.com>
	<4FCD0286.4000907@candelatech.com>
	<79D1420E63043F44B2039BA7A8A7A2441E811F21@XMBVAG73.northgrum.com>
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E81206E@XMBVAG73.northgrum.com>

When attempting to run xorp_rtrmgr, I get the following error...

[ 1970/01/01 23:28:20.702437 ERROR xorp_rtrmgr:962 RTRMGR rtrmgr/main_rtrmgr.cc:275 run ] Shutting down due to an init error: Error reading config directory /home/build/octeon-staging//share/xorp/templates: No such file or directory

I notice that it is trying to look into the install directory that I specified when doing the scons install (and there is an extra "/" in there too).  Unfortunately, I was installing to a staging directory.  Do I need to do a scons install to /usr/local?


Tom Kuhn 
Office: (407) 737-4953 
Cell: (407) 721-0628 
tom.kuhn at ngc.com 


-----Original Message-----
From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Kuhn, Thomas J (IS)
Sent: Tuesday, June 05, 2012 8:23 AM
To: Ben Greear
Cc: 'xorp-hackers at icir.org'
Subject: Re: [Xorp-hackers] EXT :Re: Install error

Thanks,  

That seemed to work.  I will also try out some of the flags mentioned by Kodel Oleg too.



Tom Kuhn 
Office: (407) 737-4953 
Cell: (407) 721-0628 
tom.kuhn at ngc.com 


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Monday, June 04, 2012 2:47 PM
To: Kuhn, Thomas J (IS)
Cc: 'xorp-hackers at icir.org'
Subject: EXT :Re: [Xorp-hackers] Install error

On 06/04/2012 11:40 AM, Kuhn, Thomas J (IS) wrote:
> I have cross compiled XORP and am performing an install. The install gets part wat through and then gives the following error on args.sh.  Can anyone assist?
>
> Install file: "bgp/harness/args.sh" as "/home/build/octeon-staging/bgp/harness/args.sh"Chmod("/home/build/octeon-staging/bgp/harness/args.sh", 0755)mips64-octeon-linux-gnu-strip /home/build/octeon-staging/bgp/harness/args.shmips64-octeon-linux-gnu-strip:/home/build/octeon-staging/bgp/harness/args.sh: File format not recognizedscons: *** [/home/build/octeon-staging/bgp/harness/args.sh] Error 1scons: building terminated because of errors

Hmmm, you might have to wrap your strip executable in a shell script that always returns success.

Or, don't strip on install via scons, but after the install is complete, manually
strip everything in the install dir and just ignore the errors about not being able
to strip .sh files and similar.

Something like:

find /usr/local/xorp -name "*" -print|xargs my-strip-exe

Thanks,
Ben

>
>
> Tom Kuhn
> 407-721-0628 (Cell)
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
Xorp-hackers mailing list
Xorp-hackers at icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From greearb at candelatech.com  Tue Jun  5 08:57:53 2012
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 05 Jun 2012 08:57:53 -0700
Subject: [Xorp-hackers] EXT :Re:  Install error
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E81206E@XMBVAG73.northgrum.com>
References: <79D1420E63043F44B2039BA7A8A7A2441E811CAE@XMBVAG73.northgrum.com>
	<4FCD0286.4000907@candelatech.com>
	<79D1420E63043F44B2039BA7A8A7A2441E811F21@XMBVAG73.northgrum.com>
	<79D1420E63043F44B2039BA7A8A7A2441E81206E@XMBVAG73.northgrum.com>
Message-ID: <4FCE2C81.5060304@candelatech.com>

On 06/05/2012 06:49 AM, Kuhn, Thomas J (IS) wrote:
> When attempting to run xorp_rtrmgr, I get the following error...
>
> [ 1970/01/01 23:28:20.702437 ERROR xorp_rtrmgr:962 RTRMGR rtrmgr/main_rtrmgr.cc:275 run ] Shutting down due to an init error: Error reading config directory /home/build/octeon-staging//share/xorp/templates: No such file or directory
>
> I notice that it is trying to look into the install directory that I specified when doing the scons install (and there is an extra "/" in there too).  Unfortunately, I was installing to a staging directory.  Do I need to do a scons install to /usr/local?

There are some command-line args to xorp_rtrmgr and probably some environment variables
that can specify the template and other locations.  But, I always just install to /usr/local
to make things simple.

xorp_rtrmgr --help

will give you some suggestions I think.

Thanks,
Ben

>
>
> Tom Kuhn
> Office: (407) 737-4953
> Cell: (407) 721-0628
> tom.kuhn at ngc.com
>
>
> -----Original Message-----
> From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Kuhn, Thomas J (IS)
> Sent: Tuesday, June 05, 2012 8:23 AM
> To: Ben Greear
> Cc: 'xorp-hackers at icir.org'
> Subject: Re: [Xorp-hackers] EXT :Re: Install error
>
> Thanks,
>
> That seemed to work.  I will also try out some of the flags mentioned by Kodel Oleg too.
>
>
>
> Tom Kuhn
> Office: (407) 737-4953
> Cell: (407) 721-0628
> tom.kuhn at ngc.com
>
>
> -----Original Message-----
> From: Ben Greear [mailto:greearb at candelatech.com]
> Sent: Monday, June 04, 2012 2:47 PM
> To: Kuhn, Thomas J (IS)
> Cc: 'xorp-hackers at icir.org'
> Subject: EXT :Re: [Xorp-hackers] Install error
>
> On 06/04/2012 11:40 AM, Kuhn, Thomas J (IS) wrote:
>> I have cross compiled XORP and am performing an install. The install gets part wat through and then gives the following error on args.sh.  Can anyone assist?
>>
>> Install file: "bgp/harness/args.sh" as "/home/build/octeon-staging/bgp/harness/args.sh"Chmod("/home/build/octeon-staging/bgp/harness/args.sh", 0755)mips64-octeon-linux-gnu-strip /home/build/octeon-staging/bgp/harness/args.shmips64-octeon-linux-gnu-strip:/home/build/octeon-staging/bgp/harness/args.sh: File format not recognizedscons: *** [/home/build/octeon-staging/bgp/harness/args.sh] Error 1scons: building terminated because of errors
>
> Hmmm, you might have to wrap your strip executable in a shell script that always returns success.
>
> Or, don't strip on install via scons, but after the install is complete, manually
> strip everything in the install dir and just ignore the errors about not being able
> to strip .sh files and similar.
>
> Something like:
>
> find /usr/local/xorp -name "*" -print|xargs my-strip-exe
>
> Thanks,
> Ben
>
>>
>>
>> Tom Kuhn
>> 407-721-0628 (Cell)
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Tue Jun  5 09:00:20 2012
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 05 Jun 2012 09:00:20 -0700
Subject: [Xorp-hackers] Cross Compiled XORP is quite large
In-Reply-To: <BE94B268236FE042B3A18AE3BF8AA68E32FB502E@MXHFA01.esl.corp.elbit.co.il>
References: <79D1420E63043F44B2039BA7A8A7A2441E811588@XMBVAG73.northgrum.com>
	<BE94B268236FE042B3A18AE3BF8AA68E227AD5EA@MXHFA01.esl.corp.elbit.co.il>
	<79D1420E63043F44B2039BA7A8A7A2441E811A32@XMBVAG73.northgrum.com>
	<BE94B268236FE042B3A18AE3BF8AA68E32FB502E@MXHFA01.esl.corp.elbit.co.il>
Message-ID: <4FCE2D14.7070907@candelatech.com>

On 06/04/2012 11:05 PM, Kodel Oleg wrote:
> #!/bin/sh
>
> scons j=2 build=mips64-octeon-linux-gnu \
>
> disable_ipv6=yes enable_tests=no disable_fw=yes strip=yes \
>
> disable_tracelogs=yes disable_infologs=yes disable_otherlogs=yes optimize=size debug=no \
>
> STRIP=mips64-octeon-linux-gnu-strip CC=mips64-octeon-linux-gnu-gcc CXX=mips64-octeon-linux-gnu-g++ \
>
> LINKFLAGS=-L/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl/lib \
>
> CFLAGS=-I/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl \
>
> CXXFLAGS=-I/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl $1
>
> Use it with "build" or "install".
>
> N.B. Somebody working on decrease of the installation size?
>
> It is critical on embedded devices.

I and some others did some work in this direction a year or two ago.  Got it down
to around 10MB when logging and many of the other features were disabled.  I
am sure that there is more that could be done..and patches will be considered
if anyone makes any progress...

But, I ship my products on 40GB SSDs, so it's not so important to me
so I'm unlikely to spend much time writing these types of patches.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From tom.kuhn at ngc.com  Tue Jun  5 12:10:26 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Tue, 5 Jun 2012 19:10:26 +0000
Subject: [Xorp-hackers] EXT :Re:  Cross Compiled XORP is quite large
In-Reply-To: <4FCE2D14.7070907@candelatech.com>
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E812376@XMBVAG73.northgrum.com>

Thanks!



Tom Kuhn
407-721-0628 (Cell)

----- Original Message -----
From: Ben Greear [mailto:greearb at candelatech.com]
Sent: Tuesday, June 05, 2012 11:00 AM
To: Kodel Oleg <oleg.kodel at elbitsystems.com>
Cc: Kuhn, Thomas J (IS); xorp-hackers at icir.org <xorp-hackers at icir.org>
Subject: EXT :Re: [Xorp-hackers] Cross Compiled XORP is quite large

On 06/04/2012 11:05 PM, Kodel Oleg wrote:
> #!/bin/sh
>
> scons j=2 build=mips64-octeon-linux-gnu \
>
> disable_ipv6=yes enable_tests=no disable_fw=yes strip=yes \
>
> disable_tracelogs=yes disable_infologs=yes disable_otherlogs=yes optimize=size debug=no \
>
> STRIP=mips64-octeon-linux-gnu-strip CC=mips64-octeon-linux-gnu-gcc CXX=mips64-octeon-linux-gnu-g++ \
>
> LINKFLAGS=-L/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl/lib \
>
> CFLAGS=-I/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl \
>
> CXXFLAGS=-I/opt/OCTEON-SDK_2.0.0/tools-gcc-4.3/mips64-octeon-linux-gnu/sys-root/usr/include/openssl $1
>
> Use it with "build" or "install".
>
> N.B. Somebody working on decrease of the installation size?
>
> It is critical on embedded devices.

I and some others did some work in this direction a year or two ago.  Got it down
to around 10MB when logging and many of the other features were disabled.  I
am sure that there is more that could be done..and patches will be considered
if anyone makes any progress...

But, I ship my products on 40GB SSDs, so it's not so important to me
so I'm unlikely to spend much time writing these types of patches.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From noreply at github.com  Tue Jun  5 20:44:35 2012
From: noreply at github.com (GitHub)
Date: Tue, 05 Jun 2012 20:44:35 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] 9c9053: fea: Remove const-ness
 from netlink objects.
Message-ID: <4fced223b591d_289d1871ae411411d@sh2.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: 9c9053ff92ba66697747fb24c5f238dfb157a3db
      https://github.com/greearb/xorp.ct/commit/9c9053ff92ba66697747fb24c5f238dfb157a3db
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-06-05 (Tue, 05 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/control_socket/netlink_socket.cc
    M xorp/fea/data_plane/control_socket/netlink_socket.hh
    M xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc
    M xorp/fea/data_plane/control_socket/netlink_socket_utilities.hh
    M xorp/fea/data_plane/control_socket/windows_rtm_pipe.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_get_netlink_socket.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_get_netlink_socket.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_dummy.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_dummy.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_iphelper.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_iphelper.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_netlink_socket.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_netlink_socket.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_table_get_netlink_socket.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_dummy.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_dummy.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_iphelper.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_iphelper.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_netlink_socket.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_netlink_socket.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_rtmv2.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_rtmv2.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_table_parse_netlink_socket.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.hh
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_dummy.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_dummy.hh
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_iphelper.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_iphelper.hh
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_netlink_socket.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_netlink_socket.hh
    M xorp/fea/fibconfig_entry_observer.hh
    M xorp/fea/fibconfig_table_observer.hh
    M xorp/fea/ifconfig_observer.hh
    M xorp/libxorp/utils.hh

  Log Message:
  -----------
  fea:  Remove const-ness from netlink objects.

The truth is, netlink API doesn't take const arguments,
so it was all being cast away down in the code that
mattered.  This wouldn't compile on F17, so just remove
it all and make it non-const.

Signed-off-by: Ben Greear <greearb at candelatech.com>


  Commit: d856e1232fcf7dd916c671bf7403dbe2b2270c01
      https://github.com/greearb/xorp.ct/commit/d856e1232fcf7dd916c671bf7403dbe2b2270c01
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-06-05 (Tue, 05 Jun 2012)

  Changed paths:
    M xorp/bgp/path_attribute.cc
    M xorp/bgp/path_attribute.hh
    M xorp/bgp/update_attrib.hh

  Log Message:
  -----------
  bgp: Fix const related warnings.

These errors caused build failures on Fedora 17.

Signed-off-by: Ben Greear <greearb at candelatech.com>


  Commit: ca3909053cbe294e45edf7fde44979e008b7c08f
      https://github.com/greearb/xorp.ct/commit/ca3909053cbe294e45edf7fde44979e008b7c08f
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-06-05 (Tue, 05 Jun 2012)

  Changed paths:
    M xorp/fea/mfea_mrouter.cc

  Log Message:
  -----------
  mfea:  Fix compilation errors on Fedora 17.

The latest compiler did not like assigning a reference
to a member of a packed struct.  Use pointers instead.

Signed-off-by: Ben Greear <greearb at candelatech.com>


Compare: https://github.com/greearb/xorp.ct/compare/1359103...ca39090

From igorm at etf.rs  Wed Jun  6 03:08:33 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Wed, 6 Jun 2012 12:08:33 +0200
Subject: [Xorp-hackers] C++11
Message-ID: <CAFdo_mXQqLy2-C5JnvigefSZAr66Smc0s53GKizpFewNh5aNSw@mail.gmail.com>

Hi Ben,
I was wondering how do you feel about supporting C++11 in Xorp code?
BR
Igor


From greearb at candelatech.com  Wed Jun  6 08:56:42 2012
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 06 Jun 2012 08:56:42 -0700
Subject: [Xorp-hackers] C++11
In-Reply-To: <CAFdo_mXQqLy2-C5JnvigefSZAr66Smc0s53GKizpFewNh5aNSw@mail.gmail.com>
References: <CAFdo_mXQqLy2-C5JnvigefSZAr66Smc0s53GKizpFewNh5aNSw@mail.gmail.com>
Message-ID: <4FCF7DBA.6080602@candelatech.com>

On 06/06/2012 03:08 AM, Igor Maravi? wrote:
> Hi Ben,
> I was wondering how do you feel about supporting C++11 in Xorp code?
> BR
> Igor

I want to make sure it still compiles on old compilers, at least.  Back to
Fedora 8 days (about 4-5 years ago).

I don't know anything about C++11..is there anything that would actually
make xorp better/easier in it?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Wed Jun  6 11:39:16 2012
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 06 Jun 2012 11:39:16 -0700
Subject: [Xorp-hackers] Bug in the 64-bit floating point xrl-atom logic on
	windows (mingw)
Message-ID: <4FCFA3D4.3050407@candelatech.com>

I see this warning when cross-compiling for windows (using ./win32_pkg.bash):

libxipc/xrl_atom.cc: In member function 'const std::string XrlAtom::value() const':
libxipc/xrl_atom.cc:635: warning: unknown conversion type character 'A' in format
libxipc/xrl_atom.cc:635: warning: too many arguments for format

Maybe XORP_PRIAFP64 isn't properly defined when compiling with mingw?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From noreply at github.com  Wed Jun  6 11:49:23 2012
From: noreply at github.com (GitHub)
Date: Wed, 06 Jun 2012 11:49:23 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] 1648fa: fea: Complete removal of
	AlignData logic.
Message-ID: <4fcfa6332f18a_36d2f95aec1843fd@sh2.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: 1648fa0126a1a3e1a64f84e5e739db0c5edb2598
      https://github.com/greearb/xorp.ct/commit/1648fa0126a1a3e1a64f84e5e739db0c5edb2598
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-06-06 (Wed, 06 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/control_socket/routing_socket.cc
    M xorp/fea/data_plane/control_socket/windows_rtm_pipe.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_parse_routing_socket.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_table_parse_routing_socket.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_parse_routing_socket.cc
    M xorp/libxorp/utils.hh

  Log Message:
  -----------
  fea:  Complete removal of AlignData logic.

I don't think it ever really worked anyway.
This fixes cross-compile on mingw (windows exe).

Signed-off-by: Ben Greear <greearb at candelatech.com>




From noreply at github.com  Wed Jun  6 13:48:33 2012
From: noreply at github.com (GitHub)
Date: Wed, 06 Jun 2012 13:48:33 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] 958848: fea: Fix compile on BSD.
Message-ID: <4fcfc2217f367_354bf68aec442a@sh2.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: 958848ea8302b234d1ab41ee5cb07eb114f7b5d0
      https://github.com/greearb/xorp.ct/commit/958848ea8302b234d1ab41ee5cb07eb114f7b5d0
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-04-25 (Wed, 25 Apr 2012)

  Changed paths:
    M xorp/fea/data_plane/control_socket/routing_socket.cc
    M xorp/fea/data_plane/control_socket/routing_socket.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_routing_socket.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_observer_routing_socket.hh
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_parse_routing_socket.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_routing_socket.cc
    M xorp/fea/data_plane/fibconfig/fibconfig_table_observer_routing_socket.hh
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_routing_socket.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_observer_routing_socket.hh
    M xorp/fea/data_plane/ifconfig/ifconfig_parse_routing_socket.cc

  Log Message:
  -----------
  fea:  Fix compile on BSD.

More fallout from the un-const-ness in the fea logic.

Signed-off-by: Ben Greear <greearb at candelatech.com>




From ss at comp.lancs.ac.uk  Wed Jun  6 14:34:25 2012
From: ss at comp.lancs.ac.uk (Steven Simpson)
Date: Wed, 06 Jun 2012 22:34:25 +0100
Subject: [Xorp-hackers] Bug in the 64-bit floating point xrl-atom logic
	on windows (mingw)
In-Reply-To: <4FCFA3D4.3050407@candelatech.com>
References: <4FCFA3D4.3050407@candelatech.com>
Message-ID: <4FCFCCE1.3070705@comp.lancs.ac.uk>

Hi Ben,

On 06/06/12 19:39, Ben Greear wrote:
> I see this warning when cross-compiling for windows (using 
> ./win32_pkg.bash):
>
> libxipc/xrl_atom.cc: In member function 'const std::string 
> XrlAtom::value() const':
> libxipc/xrl_atom.cc:635: warning: unknown conversion type character 
> 'A' in format
> libxipc/xrl_atom.cc:635: warning: too many arguments for format
>
> Maybe XORP_PRIAFP64 isn't properly defined when compiling with mingw?

Hmm, I think I went for hex float format because it looked like it would 
be more likely to scan back in with the same value, and it might be more 
compact.  However, it's a bit of C99 I forgot was in there.

It should be alright to switch to XORP_PRIGFP64, which will give a 
decimal notation.

There's an option to try to detect "%A" support at compile time, but if 
someone is using string representation to transfer an XRL, and the 
receiver doesn't have support for hex float representation, it might 
fail to parse at the other end.  So it's probably safer to stick to "%G".

Note that scanning already uses XORP_SCNgFP64 (xrl_atom.cc:227), and in 
any case, scanf accepts any format regardless of whether you specify a, 
g, etc.  So there shouldn't be any changes necessary there.

Regards,

Steven


From oleg.kodel at elbitsystems.com  Wed Jun  6 23:52:20 2012
From: oleg.kodel at elbitsystems.com (Kodel Oleg)
Date: Thu, 7 Jun 2012 06:52:20 +0000
Subject: [Xorp-hackers] XORP stable version
In-Reply-To: <4FCFA3D4.3050407@candelatech.com>
References: <4FCFA3D4.3050407@candelatech.com>
Message-ID: <BE94B268236FE042B3A18AE3BF8AA68E32FB7A88@MXHFA01.esl.corp.elbit.co.il>

Hi Ben.
Is the current version of git is stable?
When do you planning to announce an official version?

Thanks
Oleg

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.


From greearb at candelatech.com  Thu Jun  7 08:54:34 2012
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 07 Jun 2012 08:54:34 -0700
Subject: [Xorp-hackers] XORP stable version
In-Reply-To: <BE94B268236FE042B3A18AE3BF8AA68E32FB7A88@MXHFA01.esl.corp.elbit.co.il>
References: <4FCFA3D4.3050407@candelatech.com>
	<BE94B268236FE042B3A18AE3BF8AA68E32FB7A88@MXHFA01.esl.corp.elbit.co.il>
Message-ID: <4FD0CEBA.90306@candelatech.com>

On 06/06/2012 11:52 PM, Kodel Oleg wrote:
> Hi Ben.
> Is the current version of git is stable?
> When do you planning to announce an official version?

Well, it should work just fine..but could use more testing.
I just committed some changes to fea yesterday, and haven't had
time to test it yet.  From a bug-report just posted, it looks
like I messed something up.  Hope to have it fixed shortly.

I'll probably do another release in a month or two..sooner
if someone has a reason.

Thanks,
Ben

>
> Thanks
> Oleg
>
> The information in this e-mail transmission contains proprietary and business
> sensitive information.  Unauthorized interception of this e-mail may constitute
> a violation of law. If you are not the intended recipient, you are hereby
> notified that any review, dissemination, distribution or duplication of this
> communication is strictly prohibited. You are also asked to contact the sender
> by reply email and immediately destroy all copies of the original message.


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Thu Jun  7 09:14:36 2012
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 07 Jun 2012 09:14:36 -0700
Subject: [Xorp-hackers] XORP stable version
In-Reply-To: <4FD0CEBA.90306@candelatech.com>
References: <4FCFA3D4.3050407@candelatech.com>
	<BE94B268236FE042B3A18AE3BF8AA68E32FB7A88@MXHFA01.esl.corp.elbit.co.il>
	<4FD0CEBA.90306@candelatech.com>
Message-ID: <4FD0D36C.7020907@candelatech.com>

On 06/07/2012 08:54 AM, Ben Greear wrote:
> On 06/06/2012 11:52 PM, Kodel Oleg wrote:
>> Hi Ben.
>> Is the current version of git is stable?
>> When do you planning to announce an official version?
>
> Well, it should work just fine..but could use more testing.
> I just committed some changes to fea yesterday, and haven't had
> time to test it yet.  From a bug-report just posted, it looks
> like I messed something up.  Hope to have it fixed shortly.

I can reproduce crashes in fea here, on the latest git tree, so
should have it fixed shortly.

This is on standard x86-32.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From noreply at github.com  Thu Jun  7 10:43:50 2012
From: noreply at github.com (GitHub)
Date: Thu, 07 Jun 2012 10:43:50 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] b7ec5d: fea: Fix netlink crash
 introduced in recent commi...
Message-ID: <4fd0e856ae6d8_608d1209ae45938@sh3.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: b7ec5d79d9ff805186226a7c1815a1bf65add1e6
      https://github.com/greearb/xorp.ct/commit/b7ec5d79d9ff805186226a7c1815a1bf65add1e6
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-06-07 (Thu, 07 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/control_socket/netlink_socket.cc

  Log Message:
  -----------
  fea:  Fix netlink crash introduced in recent commits.

Used wrong buffer when assigning 'mh'.

Signed-off-by: Ben Greear <greearb at candelatech.com>




From greearb at candelatech.com  Thu Jun  7 10:44:15 2012
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 07 Jun 2012 10:44:15 -0700
Subject: [Xorp-hackers] XORP stable version
In-Reply-To: <4FD0D36C.7020907@candelatech.com>
References: <4FCFA3D4.3050407@candelatech.com>
	<BE94B268236FE042B3A18AE3BF8AA68E32FB7A88@MXHFA01.esl.corp.elbit.co.il>
	<4FD0CEBA.90306@candelatech.com> <4FD0D36C.7020907@candelatech.com>
Message-ID: <4FD0E86F.1010506@candelatech.com>

On 06/07/2012 09:14 AM, Ben Greear wrote:
> On 06/07/2012 08:54 AM, Ben Greear wrote:
>> On 06/06/2012 11:52 PM, Kodel Oleg wrote:
>>> Hi Ben.
>>> Is the current version of git is stable?
>>> When do you planning to announce an official version?
>>
>> Well, it should work just fine..but could use more testing.
>> I just committed some changes to fea yesterday, and haven't had
>> time to test it yet.  From a bug-report just posted, it looks
>> like I messed something up.  Hope to have it fixed shortly.
>
> I can reproduce crashes in fea here, on the latest git tree, so
> should have it fixed shortly.
>
> This is on standard x86-32.

Should be fixed now...please let me know if you see any other
problems.

Thanks,
Ben

>
> Thanks,
> Ben
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From igorm at etf.rs  Fri Jun  8 06:42:47 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 8 Jun 2012 15:42:47 +0200
Subject: [Xorp-hackers] C++11
In-Reply-To: <4FCF7DBA.6080602@candelatech.com>
References: <CAFdo_mXQqLy2-C5JnvigefSZAr66Smc0s53GKizpFewNh5aNSw@mail.gmail.com>
	<4FCF7DBA.6080602@candelatech.com>
Message-ID: <CAFdo_mWUm5m5=jqBhLDt2igMnpfbkb5JiysCS=muqJamsZuW0w@mail.gmail.com>

Sorry for the late reply...

I'm really sure if it is going to compile on Fedora 8. What is the
earliest version of gcc that you wish to support?

It has a lot of fancy new functionalities :)
The most noticeable are standardized threading support, variadic
templates (templates with variable number of arguments), lambda
expressions (small inline functions written directly in to the code),
move semantics (rvalue references), auto keyword, smart pointers...

XorpCallback class could be written as variadic template - that would
reduced the code size drastically, and it would be more readable.
Move semantics have large impact on performances.
With lambda expressions and auto keyword code could be written to be
more readable.
etc...

BR
Igor

2012/6/6 Ben Greear <greearb at candelatech.com>:
> On 06/06/2012 03:08 AM, Igor Maravi? wrote:
>>
>> Hi Ben,
>> I was wondering how do you feel about supporting C++11 in Xorp code?
>> BR
>> Igor
>
>
> I want to make sure it still compiles on old compilers, at least. ?Back to
> Fedora 8 days (about 4-5 years ago).
>
> I don't know anything about C++11..is there anything that would actually
> make xorp better/easier in it?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>


From igorm at etf.rs  Fri Jun  8 06:50:48 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 8 Jun 2012 15:50:48 +0200
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <4FC93709.5010703@candelatech.com>
References: <CAFdo_mVfDVFgZCrHk9wy9OL9hXPKCpw+5ZvH1ZGCwAjSu=kadg@mail.gmail.com>
	<20120601195250.136D26B28BA@mailhub.crc.ca>
	<CAFdo_mX-YmGeA9uf9LwKM5o7rAXQpwaY1-ZYUZNV808s=ZNDow@mail.gmail.com>
	<4FC927E6.6020008@candelatech.com>
	<CAFdo_mUexh7o89stT=r293-Y8p4vmtey-NXCMGU3jB=DqkMMFA@mail.gmail.com>
	<4FC93709.5010703@candelatech.com>
Message-ID: <CAFdo_mW9vkOntr9Fm09kAULCAkf_3KtDNQQiUQGb-LY+gR8FHg@mail.gmail.com>

Going through the code I found function:

add_interface_route in RIB's xrl. With that function, route is
directly added to the specified interface, no questions asked.

If the OLSR would use that function it could add route as directly
connected without any problem. Because I don't know any thing much
about OLSR,
I have to ask this - Does the route should be added to the interface
from which it received advertisement?

If that is the case, interface name could be propagated through the
code, and instead of calling send_add_route, OLSR could call
send_add_interface_route, with appropriate vif name.
BR
Igor

2012/6/1 Ben Greear <greearb at candelatech.com>:
> On 06/01/2012 02:09 PM, Igor Maravi? wrote:
>>>
>>> Igor: ?Why should we ever restrict adding the connected routes?
>>>
>>> It seems to me that if the routing protocol wants it added, fea
>>> should just do so. ?But maybe I'm missing something?
>>>
>>
>> When the route comes to the RIB, if it isn't recognized as direct
>> route, RIB assumes that this route is external one.
>> This happens with BGP routes, because their nexthop is external.
>>
>> Because of that it will try to resolve the nexthop for that route with
>> existing IGP routes.
>>
>> The BGP routes can't be resolved, if this behavior is overridden.
>>
>> Thus I think that the best solution would be if the OLSR would tell
>> the RIB to add directly connected route.
>> This will resolve the problem of RIB recognizing OLSR routes as external.
>> My proposition is to add function add_direct_route, that would be
>> called via xrl from OLSR, the same way as add_route is called now. But
>> that function would be in any doubt if it should resolve route as
>> external or not.
>>
>> Maybe it is possible to check if route is resolved for wireless link,
>> or not, from the add_route function, without braking the BGP route
>> resolution,
>> but I think that would stress out a performance dramatically. This is
>> due the fact that before resolving any BGP route it would pass through
>> all vifs to check if they are wireless or not (according to Jiangxin
>> patch)
>
>
> Ok, I haven't looked at this stuff in a while (and perhaps never in
> great detail), so a new method: add_direct_route seems good to me.
>
> Better than changing behaviour based on an interface flag I think.
>
> Thanks,
> Ben
>
>>
>> BR
>> Igor
>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>


From greearb at candelatech.com  Fri Jun  8 09:15:19 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 08 Jun 2012 09:15:19 -0700
Subject: [Xorp-hackers] C++11
In-Reply-To: <CAFdo_mWUm5m5=jqBhLDt2igMnpfbkb5JiysCS=muqJamsZuW0w@mail.gmail.com>
References: <CAFdo_mXQqLy2-C5JnvigefSZAr66Smc0s53GKizpFewNh5aNSw@mail.gmail.com>
	<4FCF7DBA.6080602@candelatech.com>
	<CAFdo_mWUm5m5=jqBhLDt2igMnpfbkb5JiysCS=muqJamsZuW0w@mail.gmail.com>
Message-ID: <4FD22517.8050608@candelatech.com>

On 06/08/2012 06:42 AM, Igor Maravi? wrote:
> Sorry for the late reply...
>
> I'm really sure if it is going to compile on Fedora 8. What is the
> earliest version of gcc that you wish to support?
>
> It has a lot of fancy new functionalities :)
> The most noticeable are standardized threading support, variadic
> templates (templates with variable number of arguments), lambda
> expressions (small inline functions written directly in to the code),
> move semantics (rvalue references), auto keyword, smart pointers...
>
> XorpCallback class could be written as variadic template - that would
> reduced the code size drastically, and it would be more readable.
> Move semantics have large impact on performances.
> With lambda expressions and auto keyword code could be written to be
> more readable.
> etc...

Fedora 8 is using gcc 4.1.2.

As clever as the new features might be, I think we should hold off for
at least a few years.  And, I still think that a well written object
hierarchy is the way to go for XorpCallbacks instead of using templates.

I don't ever want to add threads to Xorp...it is hard enough to debug a
multi-process construct..adding threads on top of that would make it
even more difficult.

Smart pointers might be useful, but in my opinion, smart-pointers often
just paper over design bugs where people never could figure out exactly
how the life-time of objects should be managed.  Truth is, I have more
issues with memory leaks when writing java code than in c & c++ :P

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From jiangxin.hu at crc.gc.ca  Fri Jun  8 11:12:28 2012
From: jiangxin.hu at crc.gc.ca (Jiangxin Hu)
Date: Fri, 8 Jun 2012 14:12:28 -0400
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <CAFdo_mW9vkOntr9Fm09kAULCAkf_3KtDNQQiUQGb-LY+gR8FHg@mail.gmail.com>
Message-ID: <20120608181312.2AC6C6B2980@mailhub.crc.ca>

The restriction for subnetwork still there even you use add_interface_route
function. 

The protocol should specify which interface a route go for. The current
XORP-OLSR does not do this.

By the way, I found to delete a wireless route also has problem. 

Jiangxin

-----Original Message-----
From: Igor Maravic [mailto:igorm at etf.rs] 
Sent: Friday, June 08, 2012 9:51 AM
To: Ben Greear
Cc: Jiangxin Hu; xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
routing

Going through the code I found function:

add_interface_route in RIB's xrl. With that function, route is directly
added to the specified interface, no questions asked.

If the OLSR would use that function it could add route as directly connected
without any problem. Because I don't know any thing much about OLSR, I have
to ask this - Does the route should be added to the interface from which it
received advertisement?

If that is the case, interface name could be propagated through the code,
and instead of calling send_add_route, OLSR could call
send_add_interface_route, with appropriate vif name.
BR
Igor

2012/6/1 Ben Greear <greearb at candelatech.com>:
> On 06/01/2012 02:09 PM, Igor Maravic wrote:
>>>
>>> Igor: ?Why should we ever restrict adding the connected routes?
>>>
>>> It seems to me that if the routing protocol wants it added, fea 
>>> should just do so. ?But maybe I'm missing something?
>>>
>>
>> When the route comes to the RIB, if it isn't recognized as direct 
>> route, RIB assumes that this route is external one.
>> This happens with BGP routes, because their nexthop is external.
>>
>> Because of that it will try to resolve the nexthop for that route 
>> with existing IGP routes.
>>
>> The BGP routes can't be resolved, if this behavior is overridden.
>>
>> Thus I think that the best solution would be if the OLSR would tell 
>> the RIB to add directly connected route.
>> This will resolve the problem of RIB recognizing OLSR routes as external.
>> My proposition is to add function add_direct_route, that would be 
>> called via xrl from OLSR, the same way as add_route is called now. 
>> But that function would be in any doubt if it should resolve route as 
>> external or not.
>>
>> Maybe it is possible to check if route is resolved for wireless link, 
>> or not, from the add_route function, without braking the BGP route 
>> resolution, but I think that would stress out a performance 
>> dramatically. This is due the fact that before resolving any BGP 
>> route it would pass through all vifs to check if they are wireless or 
>> not (according to Jiangxin
>> patch)
>
>
> Ok, I haven't looked at this stuff in a while (and perhaps never in 
> great detail), so a new method: add_direct_route seems good to me.
>
> Better than changing behaviour based on an interface flag I think.
>
> Thanks,
> Ben
>
>>
>> BR
>> Igor
>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>



From igorm at etf.rs  Mon Jun 11 01:29:50 2012
From: igorm at etf.rs (igorm at etf.rs)
Date: Mon, 11 Jun 2012 10:29:50 +0200
Subject: [Xorp-hackers] [PATCH] xorp: policy: Fix usage of network{4,
	6}-lists
In-Reply-To: <igorm@etf.rs>
References: <igorm@etf.rs>
Message-ID: <1339403390-9287-1-git-send-email-igorm@etf.rs>

From: Igor Maravic <igorm at etf.rs>

Add '~' as string distguisher, instead of ' '.
Also add posible completions to policy template.

Reported-by: Jens Dackenberg <jens.devel at gmail.com>
Signed-off-by: Igor Maravic <igorm at etf.rs>
---
 xorp/etc/templates/policy.tp  |   30 ++++++++++++++++++++++++++++--
 xorp/policy/common/element.cc |    4 ++--
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/xorp/etc/templates/policy.tp b/xorp/etc/templates/policy.tp
index 5e01975..b48bcaa 100644
--- a/xorp/etc/templates/policy.tp
+++ b/xorp/etc/templates/policy.tp
@@ -340,8 +340,21 @@ policy {
 
 	    modifier {
 		%help: short "Set prefix modifier";
+		%allow: $(@) ":" %help: "Exact";
+		%allow: $(@) "==" %help: "Exact";
+		%allow: $(@) "exact" %help: "Exact";
+		%allow: $(@) "!=" %help: "Not";
+		%allow: $(@) "not" %help: "Not";
+		%allow: $(@) ">=" %help: "Or shorter";
+		%allow: $(@) "orshorter" %help: "Or shorter";
+		%allow: $(@) ">" %help: "Shorter";
+		%allow: $(@) "shorter" %help: "Shorter";
+		%allow: $(@) "<" %help: "Longer";
+		%allow: $(@) "longer" %help: "Longer";
+		%allow: $(@) "<=" %help: "Or longer";
+		%allow: $(@) "orlonger" %help: "Or longer";
 		%set: xrl "$(policy.targetname)/policy/0.1/delete_from_set?type:txt=set_ipv4net&set:txt=$(network4-list.@)&element:txt=$(network.@)";
-		%set: xrl "$(policy.targetname)/policy/0.1/add_to_set?type:txt=set_ipv4net&set:txt=$(network4-list.@)&element:txt=$(network.@) $(@)";
+		%set: xrl "$(policy.targetname)/policy/0.1/add_to_set?type:txt=set_ipv4net&set:txt=$(network4-list.@)&element:txt=$(network.@)~$(@)";
 		%delete: xrl "$(policy.targetname)/policy/0.1/delete_from_set?type:txt=set_ipv4net&set:txt=$(network4-list.@)&element:txt=$(network.@)";
 		%delete: xrl "$(policy.targetname)/policy/0.1/add_to_set?type:txt=set_ipv4net&set:txt=$(network4-list.@)&element:txt=$(network.@)";
 	    }
@@ -366,8 +379,21 @@ policy {
 
 	    modifier {
 		%help: short "Set prefix modifier";
+		%allow: $(@) ":" %help: "Exact";
+		%allow: $(@) "==" %help: "Exact";
+		%allow: $(@) "exact" %help: "Exact";
+		%allow: $(@) "!=" %help: "Not";
+		%allow: $(@) "not" %help: "Not";
+		%allow: $(@) ">=" %help: "Or shorter";
+		%allow: $(@) "orshorter" %help: "Or shorter";
+		%allow: $(@) ">" %help: "Shorter";
+		%allow: $(@) "shorter" %help: "Shorter";
+		%allow: $(@) "<" %help: "Longer";
+		%allow: $(@) "longer" %help: "Longer";
+		%allow: $(@) "<=" %help: "Or longer";
+		%allow: $(@) "orlonger" %help: "Or longer";
 		%set: xrl "$(policy.targetname)/policy/0.1/delete_from_set?type:txt=set_ipv6net&set:txt=$(network6-list.@)&element:txt=$(network.@)";
-		%set: xrl "$(policy.targetname)/policy/0.1/add_to_set?type:txt=set_ipv6net&set:txt=$(network6-list.@)&element:txt=$(network.@) $(@)";
+		%set: xrl "$(policy.targetname)/policy/0.1/add_to_set?type:txt=set_ipv6net&set:txt=$(network6-list.@)&element:txt=$(network.@)~$(@)";
 		%delete: xrl "$(policy.targetname)/policy/0.1/delete_from_set?type:txt=set_ipv6net&set:txt=$(network6-list.@)&element:txt=$(network.@)";
 		%delete: xrl "$(policy.targetname)/policy/0.1/add_to_set?type:txt=set_ipv6net&set:txt=$(network6-list.@)&element:txt=$(network.@)";
 	    }
diff --git a/xorp/policy/common/element.cc b/xorp/policy/common/element.cc
index 2d9523f..a09a417 100644
--- a/xorp/policy/common/element.cc
+++ b/xorp/policy/common/element.cc
@@ -140,7 +140,7 @@ ElemNet<A>::ElemNet(const char* str) : Element(_hash), _net(NULL),
     // parse modifier
     string in = str;
 
-    const char* p = strchr(str, ' ');
+    const char* p = strchr(str, '~');
     if (p) {
 	in = in.substr(0, p - str);
 
@@ -189,7 +189,7 @@ ElemNet<A>::str() const
     string str = _net->str();
 
     if (_mod != MOD_NONE) {
-	str += " ";
+	str += "~";
 	str += mod_to_str(_mod);
     }
 
-- 
1.7.5.4


From igorm at etf.rs  Tue Jun 12 00:31:13 2012
From: igorm at etf.rs (igorm at etf.rs)
Date: Tue, 12 Jun 2012 09:31:13 +0200
Subject: [Xorp-hackers] [PATCH] xorp: rib: test: Enable profiling with
	callgrind
In-Reply-To: <igorm@etf.rs>
References: <igorm@etf.rs>
Message-ID: <1339486273-5915-1-git-send-email-igorm@etf.rs>

From: Igor Maravic <igorm at etf.rs>

Code should be pretified, maybe we can include some if defs,
checks if valgrind exists, reading of number of cycles
from argumetns...

Only for test purposes. To test it, just enter the accurate location of commands
in this line:
ifstream file("/home/igor/Work/xorp.ct/xorp/obj/x86_64-unknown-linux-gnu/rib/tests/commands");
---
 xorp/rib/tests/SConscript         |    5 +++
 xorp/rib/tests/test_rib_direct.cc |   64 ++++++++++++++++++++++++-------------
 xorp/rib/tests/test_rib_xrls.cc   |    5 +++
 3 files changed, 52 insertions(+), 22 deletions(-)

diff --git a/xorp/rib/tests/SConscript b/xorp/rib/tests/SConscript
index d2af49d..989c896 100644
--- a/xorp/rib/tests/SConscript
+++ b/xorp/rib/tests/SConscript
@@ -22,6 +22,11 @@ Import("env")
 
 env = env.Clone()
 
+#enable profiling with callgrind
+if not env['disable_werror']:
+	env['CFLAGS'].remove('-Werror')
+	env['CXXFLAGS'].remove('-Werror')
+
 env.AppendUnique(CPPPATH = [
 	'#',
 	'$BUILDDIR',
diff --git a/xorp/rib/tests/test_rib_direct.cc b/xorp/rib/tests/test_rib_direct.cc
index 5554b2d..0cfa403 100644
--- a/xorp/rib/tests/test_rib_direct.cc
+++ b/xorp/rib/tests/test_rib_direct.cc
@@ -35,6 +35,8 @@
 #include "rib.hh"
 #include "dummy_register_server.hh"
 
+#include <valgrind/callgrind.h>
+
 
 bool verbose = false;
 
@@ -71,8 +73,9 @@ RibParser::RibParser(RIB<IPv4>& rib)
 }
 
 static void
-parser_main()
+parser_main(int loops)
 {
+
     EventLoop eventloop;
 
     // Finder Server
@@ -81,36 +84,46 @@ parser_main()
 
     // Rib Server component
     XrlStdRouter xrl_std_router_rib(eventloop, "rib", fs.addr(), fs.port());
-
+    CALLGRIND_START_INSTRUMENTATION;
     //
     // The RIB manager
     //
     RibManager rib_manager(eventloop, xrl_std_router_rib, "fea");
     rib_manager.enable();
 
-    RIB<IPv4> rib(UNICAST, rib_manager, eventloop);
-    DummyRegisterServer register_server;
-
-    rib.initialize(register_server);
-
-    wait_until_xrl_router_is_ready(eventloop, xrl_std_router_rib);
-
-    RibParser parser(rib);
-
-    string cmd;
-    int line = 0;
-    while (feof(stdin) == 0) {
-	getline(cin, cmd);
-	if (feof(stdin) != 0)
-	    break;
-	line++;
-	printf("%d: %s\n", line, cmd.c_str());
-	parser.parse(cmd);
+    for (int i = 0; i < loops; i++) {
+	RIB<IPv4> rib(UNICAST, rib_manager, eventloop);
+	DummyRegisterServer register_server;
+
+	rib.initialize(register_server);
+
+	wait_until_xrl_router_is_ready(eventloop, xrl_std_router_rib);
+
+	RibParser parser(rib);
+	cout << "Pass number " << i << endl;
+	ifstream file("/home/igor/Work/xorp.ct/xorp/obj/x86_64-unknown-linux-gnu/rib/tests/commands");
+	if (!file) {
+	    cerr << "Error opening file " << endl;
+
+	    return;
+	}
+	string cmd;
+	int line = 0;
+	while (!file.eof()) {
+	    getline(file, cmd);
+	    if (file.eof())
+		break;
+	    line++;
+	    //cout << line << ": " << cmd << endl;
+	    parser.parse(cmd);
+	}
     }
+    CALLGRIND_STOP_INSTRUMENTATION;
+    CALLGRIND_DUMP_STATS;
 }
 
 int
-main (int /* argc */, char* argv[])
+main (int argc, char* argv[])
 {
     //
     // Initialize and start xlog
@@ -122,9 +135,16 @@ main (int /* argc */, char* argv[])
     xlog_add_default_output();
     xlog_start();
 
+    int loops = 1;
+    if (argc > 1) {
+	loops = atoi(argv[1]);
+    }
+    if (loops <= 0)
+	loops = 1;
+
     XorpUnexpectedHandler x(xorp_unexpected_handler);
     try {
-	parser_main();
+	parser_main(loops);
     } catch (...) {
 	xorp_catch_standard_exceptions();
     }
diff --git a/xorp/rib/tests/test_rib_xrls.cc b/xorp/rib/tests/test_rib_xrls.cc
index 4bae5f1..174bf81 100644
--- a/xorp/rib/tests/test_rib_xrls.cc
+++ b/xorp/rib/tests/test_rib_xrls.cc
@@ -36,6 +36,8 @@
 #include "dummy_register_server.hh"
 #include "xrl_target.hh"
 
+#include <valgrind/callgrind.h>
+
 
 bool verbose = false;
 
@@ -70,6 +72,7 @@ public:
 static void
 parser_main()
 {
+    CALLGRIND_START_INSTRUMENTATION;
     EventLoop eventloop;
 
     // Finder Server
@@ -114,6 +117,8 @@ parser_main()
 	    eventloop.run();
 	XLOG_ASSERT(cv == SUCCESS);
     }
+    CALLGRIND_STOP_INSTRUMENTATION;
+    CALLGRIND_DUMP_STATS;
 }
 
 int
-- 
1.7.5.4


From igorm at etf.rs  Tue Jun 12 01:17:20 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Tue, 12 Jun 2012 10:17:20 +0200
Subject: [Xorp-hackers] XORP crash
Message-ID: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>

Hi, Xorp can't pull the interface configuration because of the netlink errors.
Here is the log:

---

[ 2012/06/12 10:16:03.259783  INFO xorp_rtrmgr:8843 RTRMGR
rtrmgr/main_rtrmgr.cc:754 main ]
Host Information:
Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l

[ 2012/06/12 10:16:03.336184  WARNING xorp_rtrmgr:8843 RTRMGR
rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
[ 2012/06/12 10:16:03.646075  INFO xorp_rtrmgr:8843 RTRMGR
rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
firewall, fea
[ 2012/06/12 10:16:03.646973  INFO xorp_rtrmgr:8843 RTRMGR
rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
(xorp_fea)
[ 2012/06/12 10:16:03.648187  WARNING xorp_rtrmgr:8843 XrlFinderTarget
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
callback_finder_0_2_resolve_xrl ] Handling method for
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
"fea" does not exist or is not enabled.
[ 2012/06/12 10:16:03.648427  WARNING xorp_rtrmgr:8843 RTRMGR
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
Resolve failed  retries: 0  max_retries: 30
[ 2012/06/12 10:16:04.652692  WARNING xorp_fea:8848 FEA
fea/data_plane/control_socket/netlink_socket_utilities.cc:300
get_rtattr ] get_rtattr() failed: AF_NETLINK deficit in rtattr: 100
rta_len remaining
[ 2012/06/12 10:16:04.652820  ERROR xorp_fea:8848 FEA
fea/data_plane/control_socket/netlink_socket_utilities.cc:439
nlm_get_to_fte_cfg ] nlm_get_to_fte_cfg() failed: unrecognized
AF_NETLINK route type: 0
[ 2012/06/12 10:16:04.653077  INFO xorp_fea:8848 MFEA
fea/mfea_node.cc:295 enable ] MFEA enabled
[ 2012/06/12 10:16:04.653285  INFO xorp_fea:8848 MFEA
fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 2012/06/12 10:16:04.653679  INFO xorp_fea:8848 MFEA
fea/mfea_node_cli.cc:92 start ] CLI started
[ 2012/06/12 10:16:04.653700  INFO xorp_fea:8848 MFEA
fea/mfea_node.cc:295 enable ] MFEA enabled
[ 2012/06/12 10:16:04.653713  INFO xorp_fea:8848 MFEA
fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 2012/06/12 10:16:04.653812  INFO xorp_fea:8848 MFEA
fea/mfea_node_cli.cc:92 start ] CLI started
[ 2012/06/12 10:16:04.669216  WARNING xorp_fea:8848 FEA
fea/ifconfig.cc:818 pull_config ] ERROR:  pull_config_one for
interface: eth2 failed: -1
[ 2012/06/12 10:16:04.669270  WARNING xorp_fea:8848 FEA
fea/ifconfig.cc:821 pull_config ] ERROR:  Could not find interface:
eth2 after pull_config_one.
[ 2012/06/12 10:16:04.672861  WARNING xorp_fea:8848 FEA
fea/ifconfig.cc:818 pull_config ] ERROR:  pull_config_one for
interface: vmnet1 failed: -1
[ 2012/06/12 10:16:04.672908  WARNING xorp_fea:8848 FEA
fea/ifconfig.cc:821 pull_config ] ERROR:  Could not find interface:
vmnet1 after pull_config_one.
[ 2012/06/12 10:16:04.673882  INFO xorp_rtrmgr:8843 RTRMGR
rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
(xorp_fea)
[ 2012/06/12 10:16:04.675443  INFO xorp_rtrmgr:8843 RTRMGR
rtrmgr/module_manager.cc:101 execute ] Executing module: fea
(xorp_fea)
[ 2012/06/12 10:16:04.677276  INFO xorp_rtrmgr:8843 RTRMGR
rtrmgr/task.cc:2242 run_task ] No more tasks to run


From igorm at etf.rs  Tue Jun 12 02:04:40 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Tue, 12 Jun 2012 11:04:40 +0200
Subject: [Xorp-hackers] XORP crash
In-Reply-To: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
References: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
Message-ID: <CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>

Ben,
this is the log that I get without your patches:

---
XORP 1.8.6-WIP BuildInfo:
git version: c01d327 built: Tue Jun 12 10:31:33 CEST 2012
By: igor on machine: Linux igor 3.2.0-mpls-no-dbg+ x86_64 x86_64
Recent git changes:
c01d3271 UNDER CONSTRUCTION
c603fc64 xorp: policy: Fix usage of network{4,6}-lists
97d46f39 xorp: rib: Fixed register test

[ 2012/06/12 11:01:22.464462  INFO xorp_rtrmgr:13663 RTRMGR
rtrmgr/main_rtrmgr.cc:754 main ]
Host Information:
Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l

[ 2012/06/12 11:01:22.539270  WARNING xorp_rtrmgr:13663 RTRMGR
rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
[ 2012/06/12 11:01:22.851778  INFO xorp_rtrmgr:13663 RTRMGR
rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
firewall, fea
[ 2012/06/12 11:01:22.852664  INFO xorp_rtrmgr:13663 RTRMGR
rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
(xorp_fea)
[ 2012/06/12 11:01:22.854012  WARNING xorp_rtrmgr:13663
XrlFinderTarget
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
callback_finder_0_2_resolve_xrl ] Handling method for
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
"fea" does not exist or is not enabled.
[ 2012/06/12 11:01:22.854253  WARNING xorp_rtrmgr:13663 RTRMGR
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
Resolve failed  retries: 0  max_retries: 30
[ 2012/06/12 11:01:23.858789  INFO xorp_fea:13668 MFEA
fea/mfea_node.cc:295 enable ] MFEA enabled
[ 2012/06/12 11:01:23.858921  INFO xorp_fea:13668 MFEA
fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 2012/06/12 11:01:23.859318  INFO xorp_fea:13668 MFEA
fea/mfea_node_cli.cc:92 start ] CLI started
[ 2012/06/12 11:01:23.859333  INFO xorp_fea:13668 MFEA
fea/mfea_node.cc:295 enable ] MFEA enabled
[ 2012/06/12 11:01:23.859345  INFO xorp_fea:13668 MFEA
fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 2012/06/12 11:01:23.859441  INFO xorp_fea:13668 MFEA
fea/mfea_node_cli.cc:92 start ] CLI started
[ 2012/06/12 11:01:23.874869  WARNING xorp_fea:13668 FEA
fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149
try_read_config_one ] NOTE:  Netlink get single network device works
on this system.
[ 2012/06/12 11:01:23.880360  WARNING xorp_fea:13668 FEA
fea/ifconfig.cc:818 pull_config ] ERROR:  pull_config_one for
interface: vmnet1 failed: -1
[ 2012/06/12 11:01:23.880411  WARNING xorp_fea:13668 FEA
fea/ifconfig.cc:821 pull_config ] ERROR:  Could not find interface:
vmnet1 after pull_config_one.
[ 2012/06/12 11:01:23.968857  INFO xorp_rtrmgr:13663 RTRMGR
rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
(xorp_fea)
[ 2012/06/12 11:01:23.970999  INFO xorp_rtrmgr:13663 RTRMGR
rtrmgr/module_manager.cc:101 execute ] Executing module: fea
(xorp_fea)
[ 2012/06/12 11:01:23.973557  INFO xorp_rtrmgr:13663 RTRMGR
rtrmgr/task.cc:2242 run_task ] No more tasks to run

---

vmnet1 isn't present, and because of that it couldn't be found on system.

This is my config:
---
interfaces {
        interface "eth2" {
                disable: false
                default-system-config
        }
        interface "vmnet1" {
                disable: false
                default-system-config
        }
}
fea {
        unicast-forwarding4 {
                disable: false
        }
}
---
BR
Igor


From igorm at etf.rs  Tue Jun 12 05:25:22 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Tue, 12 Jun 2012 14:25:22 +0200
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <20120608181312.2AC6C6B2980@mailhub.crc.ca>
References: <CAFdo_mW9vkOntr9Fm09kAULCAkf_3KtDNQQiUQGb-LY+gR8FHg@mail.gmail.com>
	<20120608181312.2AC6C6B2980@mailhub.crc.ca>
Message-ID: <CAFdo_mWx4txsKgSyt8=_LJN933pKA8r3QFg4f9Z=Vdu7CbKBtw@mail.gmail.com>

I've just tested. There is NO restriction when adding interface route.
I even wrote the tests to confirm that.
Also You can test my claim by adding interface route via static routes!
Only there is a catch.

If your neighboring router have address 192.168.3.1, and you want to
have all routes for 192.168.3.0/24 go via
that router, you first have to add 192.168.3.1/32 interface route, and
after that to add 192.168.3.0/24 route.
This is configuration to do that.
---
protocols {
        static {
            interface-route 192.168.3.1/32 {
                next-hop-interface: "eth2"
                next-hop-vif: "eth2"
            }
            interface-route 192.168.3.0/32 {
                next-hop-interface: "eth2"
                next-hop-vif: "eth2"
                next-hop-router: 192.168.3.1
            }
        }
    }
---

There was a problem with registering those routes in fea, but I fixed
that problem. I'm sending that patch to the list. Patches for enabling
rib test, you can find on my github.
BR
Igor

2012/6/8 Jiangxin Hu <jiangxin.hu at crc.gc.ca>:
> The restriction for subnetwork still there even you use add_interface_route
> function.
>
> The protocol should specify which interface a route go for. The current
> XORP-OLSR does not do this.
>
> By the way, I found to delete a wireless route also has problem.
>
> Jiangxin
>
> -----Original Message-----
> From: Igor Maravic [mailto:igorm at etf.rs]
> Sent: Friday, June 08, 2012 9:51 AM
> To: Ben Greear
> Cc: Jiangxin Hu; xorp-hackers at icir.org
> Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
> routing
>
> Going through the code I found function:
>
> add_interface_route in RIB's xrl. With that function, route is directly
> added to the specified interface, no questions asked.
>
> If the OLSR would use that function it could add route as directly connected
> without any problem. Because I don't know any thing much about OLSR, I have
> to ask this - Does the route should be added to the interface from which it
> received advertisement?
>
> If that is the case, interface name could be propagated through the code,
> and instead of calling send_add_route, OLSR could call
> send_add_interface_route, with appropriate vif name.
> BR
> Igor
>
> 2012/6/1 Ben Greear <greearb at candelatech.com>:
>> On 06/01/2012 02:09 PM, Igor Maravic wrote:
>>>>
>>>> Igor: ?Why should we ever restrict adding the connected routes?
>>>>
>>>> It seems to me that if the routing protocol wants it added, fea
>>>> should just do so. ?But maybe I'm missing something?
>>>>
>>>
>>> When the route comes to the RIB, if it isn't recognized as direct
>>> route, RIB assumes that this route is external one.
>>> This happens with BGP routes, because their nexthop is external.
>>>
>>> Because of that it will try to resolve the nexthop for that route
>>> with existing IGP routes.
>>>
>>> The BGP routes can't be resolved, if this behavior is overridden.
>>>
>>> Thus I think that the best solution would be if the OLSR would tell
>>> the RIB to add directly connected route.
>>> This will resolve the problem of RIB recognizing OLSR routes as external.
>>> My proposition is to add function add_direct_route, that would be
>>> called via xrl from OLSR, the same way as add_route is called now.
>>> But that function would be in any doubt if it should resolve route as
>>> external or not.
>>>
>>> Maybe it is possible to check if route is resolved for wireless link,
>>> or not, from the add_route function, without braking the BGP route
>>> resolution, but I think that would stress out a performance
>>> dramatically. This is due the fact that before resolving any BGP
>>> route it would pass through all vifs to check if they are wireless or
>>> not (according to Jiangxin
>>> patch)
>>
>>
>> Ok, I haven't looked at this stuff in a while (and perhaps never in
>> great detail), so a new method: add_direct_route seems good to me.
>>
>> Better than changing behaviour based on an interface flag I think.
>>
>> Thanks,
>> Ben
>>
>>>
>>> BR
>>> Igor
>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc ?http://www.candelatech.com
>>
>


From igorm at etf.rs  Tue Jun 12 05:26:58 2012
From: igorm at etf.rs (igorm at etf.rs)
Date: Tue, 12 Jun 2012 14:26:58 +0200
Subject: [Xorp-hackers] [PATCH] xorp: fea: data_plane: fibconfig: Fix using
	of rtmsg scope parameter
In-Reply-To: <igorm@etf.rs>
References: <igorm@etf.rs>
Message-ID: <1339504018-20459-1-git-send-email-igorm@etf.rs>

From: Igor Maravic <igorm at etf.rs>

When the route doesn't have the specified gateway or nexthop it's scope should be link(RT_SCOPE_LINK).
Otherwise it should be global(RT_SCOPE_UNIVERSE).

Referenced from iproute2.

Signed-off-by: Igor Maravic <igorm at etf.rs>
---
 .../fibconfig_entry_set_netlink_socket.cc          |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc b/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
index 5437cf0..b367469 100644
--- a/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
+++ b/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
@@ -201,7 +201,7 @@ FibConfigEntrySetNetlinkSocket::add_entry(const FteX& fte)
     rtmsg->rtm_src_len = 0;
     rtmsg->rtm_tos = 0;
     rtmsg->rtm_protocol = RTPROT_XORP;		// Mark this as a XORP route
-    rtmsg->rtm_scope = RT_SCOPE_UNIVERSE;
+    rtmsg->rtm_scope = RT_SCOPE_LINK;
     rtmsg->rtm_type = RTN_UNICAST;
     rtmsg->rtm_flags = RTM_F_NOTIFY;
 
@@ -248,6 +248,7 @@ FibConfigEntrySetNetlinkSocket::add_entry(const FteX& fte)
 	data = static_cast<uint8_t*>(RTA_DATA(rtattr));
 	fte.nexthop().copy_out(data);
 	nlh->nlmsg_len = NLMSG_ALIGN(nlh->nlmsg_len) + rta_len;
+	rtmsg->rtm_scope = RT_SCOPE_UNIVERSE;
     }
 
     // Get the interface index, if it exists
-- 
1.7.5.4


From jiangxin.hu at crc.gc.ca  Tue Jun 12 07:11:22 2012
From: jiangxin.hu at crc.gc.ca (Jiangxin Hu)
Date: Tue, 12 Jun 2012 10:11:22 -0400
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <CAFdo_mWx4txsKgSyt8=_LJN933pKA8r3QFg4f9Z=Vdu7CbKBtw@mail.gmail.com>
Message-ID: <20120612141230.0AC7F6B2980@mailhub.crc.ca>


When the route doesn't have the specified gateway or nexthop it's scope
should be link(RT_SCOPE_LINK).
Otherwise it should be global(RT_SCOPE_UNIVERSE).

This is the problem in original XORP. Also how to tell XORP that there is no
nexthop in the following function call? 
 
bool XrlRibV0p1Client::send_add_interface_route4 	( 	const char *
dst_xrl_target_name,
		const string &  	protocol,
		const bool &  	unicast,
		const bool &  	multicast,
		const IPv4Net &  	network,
		const IPv4 &  	nexthop,
		const string &  	ifname,
		const string &  	vifname,
		const uint32_t &  	metric,
		const XrlAtomList &  	policytags,
		const AddInterfaceRoute4CB &  	cb 
	) 	

Jiangxin

-----Original Message-----
From: Igor Maravic [mailto:igorm at etf.rs] 
Sent: Tuesday, June 12, 2012 8:25 AM
To: Jiangxin Hu
Cc: Ben Greear; xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
routing

I've just tested. There is NO restriction when adding interface route.
I even wrote the tests to confirm that.
Also You can test my claim by adding interface route via static routes!
Only there is a catch.

If your neighboring router have address 192.168.3.1, and you want to have
all routes for 192.168.3.0/24 go via that router, you first have to add
192.168.3.1/32 interface route, and after that to add 192.168.3.0/24 route.
This is configuration to do that.
---
protocols {
        static {
            interface-route 192.168.3.1/32 {
                next-hop-interface: "eth2"
                next-hop-vif: "eth2"
            }
            interface-route 192.168.3.0/32 {
                next-hop-interface: "eth2"
                next-hop-vif: "eth2"
                next-hop-router: 192.168.3.1
            }
        }
    }
---

There was a problem with registering those routes in fea, but I fixed that
problem. I'm sending that patch to the list. Patches for enabling rib test,
you can find on my github.
BR
Igor

2012/6/8 Jiangxin Hu <jiangxin.hu at crc.gc.ca>:
> The restriction for subnetwork still there even you use 
> add_interface_route function.
>
> The protocol should specify which interface a route go for. The 
> current XORP-OLSR does not do this.
>
> By the way, I found to delete a wireless route also has problem.
>
> Jiangxin
>
> -----Original Message-----
> From: Igor Maravic [mailto:igorm at etf.rs]
> Sent: Friday, June 08, 2012 9:51 AM
> To: Ben Greear
> Cc: Jiangxin Hu; xorp-hackers at icir.org
> Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network 
> routing
>
> Going through the code I found function:
>
> add_interface_route in RIB's xrl. With that function, route is 
> directly added to the specified interface, no questions asked.
>
> If the OLSR would use that function it could add route as directly 
> connected without any problem. Because I don't know any thing much 
> about OLSR, I have to ask this - Does the route should be added to the 
> interface from which it received advertisement?
>
> If that is the case, interface name could be propagated through the 
> code, and instead of calling send_add_route, OLSR could call 
> send_add_interface_route, with appropriate vif name.
> BR
> Igor
>
> 2012/6/1 Ben Greear <greearb at candelatech.com>:
>> On 06/01/2012 02:09 PM, Igor Maravic wrote:
>>>>
>>>> Igor: ?Why should we ever restrict adding the connected routes?
>>>>
>>>> It seems to me that if the routing protocol wants it added, fea 
>>>> should just do so. ?But maybe I'm missing something?
>>>>
>>>
>>> When the route comes to the RIB, if it isn't recognized as direct 
>>> route, RIB assumes that this route is external one.
>>> This happens with BGP routes, because their nexthop is external.
>>>
>>> Because of that it will try to resolve the nexthop for that route 
>>> with existing IGP routes.
>>>
>>> The BGP routes can't be resolved, if this behavior is overridden.
>>>
>>> Thus I think that the best solution would be if the OLSR would tell 
>>> the RIB to add directly connected route.
>>> This will resolve the problem of RIB recognizing OLSR routes as
external.
>>> My proposition is to add function add_direct_route, that would be 
>>> called via xrl from OLSR, the same way as add_route is called now.
>>> But that function would be in any doubt if it should resolve route 
>>> as external or not.
>>>
>>> Maybe it is possible to check if route is resolved for wireless 
>>> link, or not, from the add_route function, without braking the BGP 
>>> route resolution, but I think that would stress out a performance 
>>> dramatically. This is due the fact that before resolving any BGP 
>>> route it would pass through all vifs to check if they are wireless 
>>> or not (according to Jiangxin
>>> patch)
>>
>>
>> Ok, I haven't looked at this stuff in a while (and perhaps never in 
>> great detail), so a new method: add_direct_route seems good to me.
>>
>> Better than changing behaviour based on an interface flag I think.
>>
>> Thanks,
>> Ben
>>
>>>
>>> BR
>>> Igor
>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc ?http://www.candelatech.com
>>
>



From igorm at etf.rs  Tue Jun 12 07:18:34 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Tue, 12 Jun 2012 16:18:34 +0200
Subject: [Xorp-hackers] XORP enhancement for wireless mesh network
	routing
In-Reply-To: <20120612141230.0AC7F6B2980@mailhub.crc.ca>
References: <CAFdo_mWx4txsKgSyt8=_LJN933pKA8r3QFg4f9Z=Vdu7CbKBtw@mail.gmail.com>
	<20120612141230.0AC7F6B2980@mailhub.crc.ca>
Message-ID: <CAFdo_mW=RWNkVcPYtw9U3vprcPKNFpeGj4-EndJKGB8Pu2WFUA@mail.gmail.com>

Just set it to IPv4::ZERO(), or IPv6::ZERO().

2012/6/12 Jiangxin Hu <jiangxin.hu at crc.gc.ca>:
>
> When the route doesn't have the specified gateway or nexthop it's scope
> should be link(RT_SCOPE_LINK).
> Otherwise it should be global(RT_SCOPE_UNIVERSE).
>
> This is the problem in original XORP. Also how to tell XORP that there is no
> nexthop in the following function call?
>
> bool XrlRibV0p1Client::send_add_interface_route4 ? ? ? ?( ? ? ? const char *
> dst_xrl_target_name,
> ? ? ? ? ? ? ? ?const string & ? ? ? ? ?protocol,
> ? ? ? ? ? ? ? ?const bool & ? ?unicast,
> ? ? ? ? ? ? ? ?const bool & ? ?multicast,
> ? ? ? ? ? ? ? ?const IPv4Net & ? ? ? ? network,
> ? ? ? ? ? ? ? ?const IPv4 & ? ?nexthop,
> ? ? ? ? ? ? ? ?const string & ? ? ? ? ?ifname,
> ? ? ? ? ? ? ? ?const string & ? ? ? ? ?vifname,
> ? ? ? ? ? ? ? ?const uint32_t & ? ? ? ?metric,
> ? ? ? ? ? ? ? ?const XrlAtomList & ? ? policytags,
> ? ? ? ? ? ? ? ?const AddInterfaceRoute4CB & ? ?cb
> ? ? ? ?)
>
> Jiangxin
>
> -----Original Message-----
> From: Igor Maravic [mailto:igorm at etf.rs]
> Sent: Tuesday, June 12, 2012 8:25 AM
> To: Jiangxin Hu
> Cc: Ben Greear; xorp-hackers at icir.org
> Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
> routing
>
> I've just tested. There is NO restriction when adding interface route.
> I even wrote the tests to confirm that.
> Also You can test my claim by adding interface route via static routes!
> Only there is a catch.
>
> If your neighboring router have address 192.168.3.1, and you want to have
> all routes for 192.168.3.0/24 go via that router, you first have to add
> 192.168.3.1/32 interface route, and after that to add 192.168.3.0/24 route.
> This is configuration to do that.
> ---
> protocols {
> ? ? ? ?static {
> ? ? ? ? ? ?interface-route 192.168.3.1/32 {
> ? ? ? ? ? ? ? ?next-hop-interface: "eth2"
> ? ? ? ? ? ? ? ?next-hop-vif: "eth2"
> ? ? ? ? ? ?}
> ? ? ? ? ? ?interface-route 192.168.3.0/32 {
> ? ? ? ? ? ? ? ?next-hop-interface: "eth2"
> ? ? ? ? ? ? ? ?next-hop-vif: "eth2"
> ? ? ? ? ? ? ? ?next-hop-router: 192.168.3.1
> ? ? ? ? ? ?}
> ? ? ? ?}
> ? ?}
> ---
>
> There was a problem with registering those routes in fea, but I fixed that
> problem. I'm sending that patch to the list. Patches for enabling rib test,
> you can find on my github.
> BR
> Igor
>
> 2012/6/8 Jiangxin Hu <jiangxin.hu at crc.gc.ca>:
>> The restriction for subnetwork still there even you use
>> add_interface_route function.
>>
>> The protocol should specify which interface a route go for. The
>> current XORP-OLSR does not do this.
>>
>> By the way, I found to delete a wireless route also has problem.
>>
>> Jiangxin
>>
>> -----Original Message-----
>> From: Igor Maravic [mailto:igorm at etf.rs]
>> Sent: Friday, June 08, 2012 9:51 AM
>> To: Ben Greear
>> Cc: Jiangxin Hu; xorp-hackers at icir.org
>> Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
>> routing
>>
>> Going through the code I found function:
>>
>> add_interface_route in RIB's xrl. With that function, route is
>> directly added to the specified interface, no questions asked.
>>
>> If the OLSR would use that function it could add route as directly
>> connected without any problem. Because I don't know any thing much
>> about OLSR, I have to ask this - Does the route should be added to the
>> interface from which it received advertisement?
>>
>> If that is the case, interface name could be propagated through the
>> code, and instead of calling send_add_route, OLSR could call
>> send_add_interface_route, with appropriate vif name.
>> BR
>> Igor
>>
>> 2012/6/1 Ben Greear <greearb at candelatech.com>:
>>> On 06/01/2012 02:09 PM, Igor Maravic wrote:
>>>>>
>>>>> Igor: ?Why should we ever restrict adding the connected routes?
>>>>>
>>>>> It seems to me that if the routing protocol wants it added, fea
>>>>> should just do so. ?But maybe I'm missing something?
>>>>>
>>>>
>>>> When the route comes to the RIB, if it isn't recognized as direct
>>>> route, RIB assumes that this route is external one.
>>>> This happens with BGP routes, because their nexthop is external.
>>>>
>>>> Because of that it will try to resolve the nexthop for that route
>>>> with existing IGP routes.
>>>>
>>>> The BGP routes can't be resolved, if this behavior is overridden.
>>>>
>>>> Thus I think that the best solution would be if the OLSR would tell
>>>> the RIB to add directly connected route.
>>>> This will resolve the problem of RIB recognizing OLSR routes as
> external.
>>>> My proposition is to add function add_direct_route, that would be
>>>> called via xrl from OLSR, the same way as add_route is called now.
>>>> But that function would be in any doubt if it should resolve route
>>>> as external or not.
>>>>
>>>> Maybe it is possible to check if route is resolved for wireless
>>>> link, or not, from the add_route function, without braking the BGP
>>>> route resolution, but I think that would stress out a performance
>>>> dramatically. This is due the fact that before resolving any BGP
>>>> route it would pass through all vifs to check if they are wireless
>>>> or not (according to Jiangxin
>>>> patch)
>>>
>>>
>>> Ok, I haven't looked at this stuff in a while (and perhaps never in
>>> great detail), so a new method: add_direct_route seems good to me.
>>>
>>> Better than changing behaviour based on an interface flag I think.
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> BR
>>>> Igor
>>>
>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc ?http://www.candelatech.com
>>>
>>
>


From jiangxin.hu at crc.gc.ca  Tue Jun 12 07:23:45 2012
From: jiangxin.hu at crc.gc.ca (Jiangxin Hu)
Date: Tue, 12 Jun 2012 10:23:45 -0400
Subject: [Xorp-hackers] [PATCH] xorp: fea: data_plane: fibconfig: Fix
	usingof rtmsg scope parameter
In-Reply-To: <1339504018-20459-1-git-send-email-igorm@etf.rs>
Message-ID: <20120612142452.DD3C46B2980@mailhub.crc.ca>

You need fix delete_entry() function also.

Jiangxin 

-----Original Message-----
From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org]
On Behalf Of igorm at etf.rs
Sent: Tuesday, June 12, 2012 8:27 AM
To: xorp-hackers at icir.org
Subject: [Xorp-hackers] [PATCH] xorp: fea: data_plane: fibconfig: Fix
usingof rtmsg scope parameter

From: Igor Maravic <igorm at etf.rs>

When the route doesn't have the specified gateway or nexthop it's scope
should be link(RT_SCOPE_LINK).
Otherwise it should be global(RT_SCOPE_UNIVERSE).

Referenced from iproute2.

Signed-off-by: Igor Maravic <igorm at etf.rs>
---
 .../fibconfig_entry_set_netlink_socket.cc          |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git
a/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
b/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
index 5437cf0..b367469 100644
--- a/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
+++ b/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.c
+++ c
@@ -201,7 +201,7 @@ FibConfigEntrySetNetlinkSocket::add_entry(const FteX&
fte)
     rtmsg->rtm_src_len = 0;
     rtmsg->rtm_tos = 0;
     rtmsg->rtm_protocol = RTPROT_XORP;		// Mark this as a XORP route
-    rtmsg->rtm_scope = RT_SCOPE_UNIVERSE;
+    rtmsg->rtm_scope = RT_SCOPE_LINK;
     rtmsg->rtm_type = RTN_UNICAST;
     rtmsg->rtm_flags = RTM_F_NOTIFY;
 
@@ -248,6 +248,7 @@ FibConfigEntrySetNetlinkSocket::add_entry(const FteX&
fte)
 	data = static_cast<uint8_t*>(RTA_DATA(rtattr));
 	fte.nexthop().copy_out(data);
 	nlh->nlmsg_len = NLMSG_ALIGN(nlh->nlmsg_len) + rta_len;
+	rtmsg->rtm_scope = RT_SCOPE_UNIVERSE;
     }
 
     // Get the interface index, if it exists
--
1.7.5.4

_______________________________________________
Xorp-hackers mailing list
Xorp-hackers at icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From igorm at etf.rs  Tue Jun 12 07:44:07 2012
From: igorm at etf.rs (igorm at etf.rs)
Date: Tue, 12 Jun 2012 16:44:07 +0200
Subject: [Xorp-hackers] [PATCH] xorp: fea: data_plane: fibconfig: Fix using
	of rtmsg scope parameter in delete_entry
In-Reply-To: <igorm@etf.rs>
References: <igorm@etf.rs>
Message-ID: <1339512247-22832-1-git-send-email-igorm@etf.rs>

From: Igor Maravic <igorm at etf.rs>

When deleting route we should use RT_SCOPE_NOWHERE instead of RT_SCOPE_UNIVERSE.

Reported-by: Jiangxin Hu <jiangxin.hu at crc.gc.ca>
Signed-off-by: Igor Maravic <igorm at etf.rs>
---
 .../fibconfig_entry_set_netlink_socket.cc          |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc b/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
index b367469..2ce8e14 100644
--- a/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
+++ b/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
@@ -442,7 +442,7 @@ FibConfigEntrySetNetlinkSocket::delete_entry(const FteX& fte)
     rtmsg->rtm_src_len = 0;
     rtmsg->rtm_tos = 0;
     rtmsg->rtm_protocol = RTPROT_XORP;		// Mark this as a XORP route
-    rtmsg->rtm_scope = RT_SCOPE_UNIVERSE;
+    rtmsg->rtm_scope = RT_SCOPE_NOWHERE;
     rtmsg->rtm_type = RTN_UNICAST;
     rtmsg->rtm_flags = RTM_F_NOTIFY;
 
-- 
1.7.5.4


From igorm at etf.rs  Tue Jun 12 07:44:32 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Tue, 12 Jun 2012 16:44:32 +0200
Subject: [Xorp-hackers] [PATCH] xorp: fea: data_plane: fibconfig: Fix
 usingof rtmsg scope parameter
In-Reply-To: <20120612142452.DD3C46B2980@mailhub.crc.ca>
References: <1339504018-20459-1-git-send-email-igorm@etf.rs>
	<20120612142452.DD3C46B2980@mailhub.crc.ca>
Message-ID: <CAFdo_mXDO6jZzMXmGrBp77MR+kk2u30AMkM9mgOy27tnU5_N1g@mail.gmail.com>

Fixed, please test it.
BR
Igor


From greearb at candelatech.com  Tue Jun 12 09:08:31 2012
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 12 Jun 2012 09:08:31 -0700
Subject: [Xorp-hackers] RIB tests
In-Reply-To: <CAFdo_mVhZFLhOfDc0kwEWW9YMo=3QtPprNzaUXeuUTTv=_ehtQ@mail.gmail.com>
References: <CAFdo_mVhZFLhOfDc0kwEWW9YMo=3QtPprNzaUXeuUTTv=_ehtQ@mail.gmail.com>
Message-ID: <4FD7697F.7080204@candelatech.com>

On 06/12/2012 12:28 AM, Igor Maravi? wrote:
> These are the profiling results.
> BR
> Igor

Thanks..I rejected this from the list...was about 4MB and I figure not
so many people care.  I'll read it though.  If you think it should
go to the list, let me know and I'll send it through.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Tue Jun 12 09:10:29 2012
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 12 Jun 2012 09:10:29 -0700
Subject: [Xorp-hackers] XORP crash
In-Reply-To: <CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>
References: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
	<CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>
Message-ID: <4FD769F5.3020400@candelatech.com>

On 06/12/2012 02:04 AM, Igor Maravi? wrote:
> Ben,
> this is the log that I get without your patches:

So this crash was introduced recently when I mucked with
the fea netlink code?

Thanks,
Ben

>
> ---
> XORP 1.8.6-WIP BuildInfo:
> git version: c01d327 built: Tue Jun 12 10:31:33 CEST 2012
> By: igor on machine: Linux igor 3.2.0-mpls-no-dbg+ x86_64 x86_64
> Recent git changes:
> c01d3271 UNDER CONSTRUCTION
> c603fc64 xorp: policy: Fix usage of network{4,6}-lists
> 97d46f39 xorp: rib: Fixed register test
>
> [ 2012/06/12 11:01:22.464462  INFO xorp_rtrmgr:13663 RTRMGR
> rtrmgr/main_rtrmgr.cc:754 main ]
> Host Information:
> Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
> x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l
>
> [ 2012/06/12 11:01:22.539270  WARNING xorp_rtrmgr:13663 RTRMGR
> rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
> [ 2012/06/12 11:01:22.851778  INFO xorp_rtrmgr:13663 RTRMGR
> rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
> firewall, fea
> [ 2012/06/12 11:01:22.852664  INFO xorp_rtrmgr:13663 RTRMGR
> rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
> (xorp_fea)
> [ 2012/06/12 11:01:22.854012  WARNING xorp_rtrmgr:13663
> XrlFinderTarget
> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
> callback_finder_0_2_resolve_xrl ] Handling method for
> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
> "fea" does not exist or is not enabled.
> [ 2012/06/12 11:01:22.854253  WARNING xorp_rtrmgr:13663 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
> Resolve failed  retries: 0  max_retries: 30
> [ 2012/06/12 11:01:23.858789  INFO xorp_fea:13668 MFEA
> fea/mfea_node.cc:295 enable ] MFEA enabled
> [ 2012/06/12 11:01:23.858921  INFO xorp_fea:13668 MFEA
> fea/mfea_node_cli.cc:126 enable ] CLI enabled
> [ 2012/06/12 11:01:23.859318  INFO xorp_fea:13668 MFEA
> fea/mfea_node_cli.cc:92 start ] CLI started
> [ 2012/06/12 11:01:23.859333  INFO xorp_fea:13668 MFEA
> fea/mfea_node.cc:295 enable ] MFEA enabled
> [ 2012/06/12 11:01:23.859345  INFO xorp_fea:13668 MFEA
> fea/mfea_node_cli.cc:126 enable ] CLI enabled
> [ 2012/06/12 11:01:23.859441  INFO xorp_fea:13668 MFEA
> fea/mfea_node_cli.cc:92 start ] CLI started
> [ 2012/06/12 11:01:23.874869  WARNING xorp_fea:13668 FEA
> fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149
> try_read_config_one ] NOTE:  Netlink get single network device works
> on this system.
> [ 2012/06/12 11:01:23.880360  WARNING xorp_fea:13668 FEA
> fea/ifconfig.cc:818 pull_config ] ERROR:  pull_config_one for
> interface: vmnet1 failed: -1
> [ 2012/06/12 11:01:23.880411  WARNING xorp_fea:13668 FEA
> fea/ifconfig.cc:821 pull_config ] ERROR:  Could not find interface:
> vmnet1 after pull_config_one.
> [ 2012/06/12 11:01:23.968857  INFO xorp_rtrmgr:13663 RTRMGR
> rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
> (xorp_fea)
> [ 2012/06/12 11:01:23.970999  INFO xorp_rtrmgr:13663 RTRMGR
> rtrmgr/module_manager.cc:101 execute ] Executing module: fea
> (xorp_fea)
> [ 2012/06/12 11:01:23.973557  INFO xorp_rtrmgr:13663 RTRMGR
> rtrmgr/task.cc:2242 run_task ] No more tasks to run
>
> ---
>
> vmnet1 isn't present, and because of that it couldn't be found on system.
>
> This is my config:
> ---
> interfaces {
>          interface "eth2" {
>                  disable: false
>                  default-system-config
>          }
>          interface "vmnet1" {
>                  disable: false
>                  default-system-config
>          }
> }
> fea {
>          unicast-forwarding4 {
>                  disable: false
>          }
> }
> ---
> BR
> Igor


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From igorm at etf.rs  Wed Jun 13 00:36:21 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Wed, 13 Jun 2012 09:36:21 +0200
Subject: [Xorp-hackers] XORP crash
In-Reply-To: <4FD769F5.3020400@candelatech.com>
References: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
	<CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>
	<4FD769F5.3020400@candelatech.com>
Message-ID: <CAFdo_mVaHvm_m_0q0Em3H+YesFPWFeQtFNnQ1zNsLYhm8TyG6w@mail.gmail.com>

Yes, crash was introduced with one of your recent commits.
BR
Igor

2012/6/12 Ben Greear <greearb at candelatech.com>:
> On 06/12/2012 02:04 AM, Igor Maravi? wrote:
>>
>> Ben,
>> this is the log that I get without your patches:
>
>
> So this crash was introduced recently when I mucked with
> the fea netlink code?
>
> Thanks,
> Ben
>
>
>>
>> ---
>> XORP 1.8.6-WIP BuildInfo:
>> git version: c01d327 built: Tue Jun 12 10:31:33 CEST 2012
>> By: igor on machine: Linux igor 3.2.0-mpls-no-dbg+ x86_64 x86_64
>> Recent git changes:
>> c01d3271 UNDER CONSTRUCTION
>> c603fc64 xorp: policy: Fix usage of network{4,6}-lists
>> 97d46f39 xorp: rib: Fixed register test
>>
>> [ 2012/06/12 11:01:22.464462 ?INFO xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/main_rtrmgr.cc:754 main ]
>> Host Information:
>> Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
>> x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l
>>
>> [ 2012/06/12 11:01:22.539270 ?WARNING xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
>> [ 2012/06/12 11:01:22.851778 ?INFO xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
>> firewall, fea
>> [ 2012/06/12 11:01:22.852664 ?INFO xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
>> (xorp_fea)
>> [ 2012/06/12 11:01:22.854012 ?WARNING xorp_rtrmgr:13663
>> XrlFinderTarget
>> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
>> callback_finder_0_2_resolve_xrl ] Handling method for
>> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
>> "fea" does not exist or is not enabled.
>> [ 2012/06/12 11:01:22.854253 ?WARNING xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
>> Resolve failed ?retries: 0 ?max_retries: 30
>> [ 2012/06/12 11:01:23.858789 ?INFO xorp_fea:13668 MFEA
>> fea/mfea_node.cc:295 enable ] MFEA enabled
>> [ 2012/06/12 11:01:23.858921 ?INFO xorp_fea:13668 MFEA
>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>> [ 2012/06/12 11:01:23.859318 ?INFO xorp_fea:13668 MFEA
>> fea/mfea_node_cli.cc:92 start ] CLI started
>> [ 2012/06/12 11:01:23.859333 ?INFO xorp_fea:13668 MFEA
>> fea/mfea_node.cc:295 enable ] MFEA enabled
>> [ 2012/06/12 11:01:23.859345 ?INFO xorp_fea:13668 MFEA
>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>> [ 2012/06/12 11:01:23.859441 ?INFO xorp_fea:13668 MFEA
>> fea/mfea_node_cli.cc:92 start ] CLI started
>> [ 2012/06/12 11:01:23.874869 ?WARNING xorp_fea:13668 FEA
>> fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149
>> try_read_config_one ] NOTE: ?Netlink get single network device works
>> on this system.
>> [ 2012/06/12 11:01:23.880360 ?WARNING xorp_fea:13668 FEA
>> fea/ifconfig.cc:818 pull_config ] ERROR: ?pull_config_one for
>> interface: vmnet1 failed: -1
>> [ 2012/06/12 11:01:23.880411 ?WARNING xorp_fea:13668 FEA
>> fea/ifconfig.cc:821 pull_config ] ERROR: ?Could not find interface:
>> vmnet1 after pull_config_one.
>> [ 2012/06/12 11:01:23.968857 ?INFO xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
>> (xorp_fea)
>> [ 2012/06/12 11:01:23.970999 ?INFO xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/module_manager.cc:101 execute ] Executing module: fea
>> (xorp_fea)
>> [ 2012/06/12 11:01:23.973557 ?INFO xorp_rtrmgr:13663 RTRMGR
>> rtrmgr/task.cc:2242 run_task ] No more tasks to run
>>
>> ---
>>
>> vmnet1 isn't present, and because of that it couldn't be found on system.
>>
>> This is my config:
>> ---
>> interfaces {
>> ? ? ? ? interface "eth2" {
>> ? ? ? ? ? ? ? ? disable: false
>> ? ? ? ? ? ? ? ? default-system-config
>> ? ? ? ? }
>> ? ? ? ? interface "vmnet1" {
>> ? ? ? ? ? ? ? ? disable: false
>> ? ? ? ? ? ? ? ? default-system-config
>> ? ? ? ? }
>> }
>> fea {
>> ? ? ? ? unicast-forwarding4 {
>> ? ? ? ? ? ? ? ? disable: false
>> ? ? ? ? }
>> }
>> ---
>> BR
>> Igor
>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>


From igorm at etf.rs  Wed Jun 13 01:08:43 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Wed, 13 Jun 2012 10:08:43 +0200
Subject: [Xorp-hackers] RIB tests
In-Reply-To: <4FD7697F.7080204@candelatech.com>
References: <CAFdo_mVhZFLhOfDc0kwEWW9YMo=3QtPprNzaUXeuUTTv=_ehtQ@mail.gmail.com>
	<4FD7697F.7080204@candelatech.com>
Message-ID: <CAFdo_mX3f+fZ_vEVQxfo5X63QEj9PbLL3h3bZxu-Ky4Nth2N=Q@mail.gmail.com>

No problem.

2012/6/12 Ben Greear <greearb at candelatech.com>:
> On 06/12/2012 12:28 AM, Igor Maravi? wrote:
>>
>> These are the profiling results.
>> BR
>> Igor
>
>
> Thanks..I rejected this from the list...was about 4MB and I figure not
> so many people care. ?I'll read it though. ?If you think it should
> go to the list, let me know and I'll send it through.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>


From greearb at candelatech.com  Wed Jun 13 07:47:11 2012
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jun 2012 07:47:11 -0700
Subject: [Xorp-hackers] XORP crash
In-Reply-To: <CAFdo_mVaHvm_m_0q0Em3H+YesFPWFeQtFNnQ1zNsLYhm8TyG6w@mail.gmail.com>
References: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
	<CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>
	<4FD769F5.3020400@candelatech.com>
	<CAFdo_mVaHvm_m_0q0Em3H+YesFPWFeQtFNnQ1zNsLYhm8TyG6w@mail.gmail.com>
Message-ID: <4FD8A7EF.4040600@candelatech.com>

On 06/13/2012 12:36 AM, Igor Maravi? wrote:
> Yes, crash was introduced with one of your recent commits.
> BR
> Igor

I'm mostly away from work today, but will look at it tomorrow
or this evening.

Thanks,
Ben

>
> 2012/6/12 Ben Greear<greearb at candelatech.com>:
>> On 06/12/2012 02:04 AM, Igor Maravi? wrote:
>>>
>>> Ben,
>>> this is the log that I get without your patches:
>>
>>
>> So this crash was introduced recently when I mucked with
>> the fea netlink code?
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> ---
>>> XORP 1.8.6-WIP BuildInfo:
>>> git version: c01d327 built: Tue Jun 12 10:31:33 CEST 2012
>>> By: igor on machine: Linux igor 3.2.0-mpls-no-dbg+ x86_64 x86_64
>>> Recent git changes:
>>> c01d3271 UNDER CONSTRUCTION
>>> c603fc64 xorp: policy: Fix usage of network{4,6}-lists
>>> 97d46f39 xorp: rib: Fixed register test
>>>
>>> [ 2012/06/12 11:01:22.464462  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/main_rtrmgr.cc:754 main ]
>>> Host Information:
>>> Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
>>> x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l
>>>
>>> [ 2012/06/12 11:01:22.539270  WARNING xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
>>> [ 2012/06/12 11:01:22.851778  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
>>> firewall, fea
>>> [ 2012/06/12 11:01:22.852664  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
>>> (xorp_fea)
>>> [ 2012/06/12 11:01:22.854012  WARNING xorp_rtrmgr:13663
>>> XrlFinderTarget
>>> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
>>> callback_finder_0_2_resolve_xrl ] Handling method for
>>> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
>>> "fea" does not exist or is not enabled.
>>> [ 2012/06/12 11:01:22.854253  WARNING xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
>>> Resolve failed  retries: 0  max_retries: 30
>>> [ 2012/06/12 11:01:23.858789  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>> [ 2012/06/12 11:01:23.858921  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>> [ 2012/06/12 11:01:23.859318  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>> [ 2012/06/12 11:01:23.859333  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>> [ 2012/06/12 11:01:23.859345  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>> [ 2012/06/12 11:01:23.859441  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>> [ 2012/06/12 11:01:23.874869  WARNING xorp_fea:13668 FEA
>>> fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149
>>> try_read_config_one ] NOTE:  Netlink get single network device works
>>> on this system.
>>> [ 2012/06/12 11:01:23.880360  WARNING xorp_fea:13668 FEA
>>> fea/ifconfig.cc:818 pull_config ] ERROR:  pull_config_one for
>>> interface: vmnet1 failed: -1
>>> [ 2012/06/12 11:01:23.880411  WARNING xorp_fea:13668 FEA
>>> fea/ifconfig.cc:821 pull_config ] ERROR:  Could not find interface:
>>> vmnet1 after pull_config_one.
>>> [ 2012/06/12 11:01:23.968857  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
>>> (xorp_fea)
>>> [ 2012/06/12 11:01:23.970999  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/module_manager.cc:101 execute ] Executing module: fea
>>> (xorp_fea)
>>> [ 2012/06/12 11:01:23.973557  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/task.cc:2242 run_task ] No more tasks to run
>>>
>>> ---
>>>
>>> vmnet1 isn't present, and because of that it couldn't be found on system.
>>>
>>> This is my config:
>>> ---
>>> interfaces {
>>>          interface "eth2" {
>>>                  disable: false
>>>                  default-system-config
>>>          }
>>>          interface "vmnet1" {
>>>                  disable: false
>>>                  default-system-config
>>>          }
>>> }
>>> fea {
>>>          unicast-forwarding4 {
>>>                  disable: false
>>>          }
>>> }
>>> ---
>>> BR
>>> Igor
>>
>>
>>
>> --
>> Ben Greear<greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From Pat.Shaw at gdcanada.com  Wed Jun 13 08:24:57 2012
From: Pat.Shaw at gdcanada.com (Shaw, Pat)
Date: Wed, 13 Jun 2012 11:24:57 -0400
Subject: [Xorp-hackers] routing issue
Message-ID: <A80739932D1FD74A8E25EBF05B9D508710053F2C@OTTSVW100.gdcan.com>

 

 

 

Patrick J Shaw

Computer Architect. Vetronics

General Dynamics Canada  www.gdcanada.com

613-596-7908

613-796-7803(fax)

 

 

 



The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120613/d4e327e0/attachment.html 

From Pat.Shaw at gdcanada.com  Wed Jun 13 08:28:19 2012
From: Pat.Shaw at gdcanada.com (Shaw, Pat)
Date: Wed, 13 Jun 2012 11:28:19 -0400
Subject: [Xorp-hackers] Rotuing issue
Message-ID: <A80739932D1FD74A8E25EBF05B9D508710053F2D@OTTSVW100.gdcan.com>

I have the following configuration for a 2 routers and 1 switch.  The
eth1 address is never advertised to the RIP so packets received on eth0
are never forwarded to eth1  to my switch!!  ... Am I configuring the
eth1  interface correctly? 

 

 

 

interfaces {

               interface eth0 {

                              vif eth0 {

                                             address 10.0.0.2 {

 
prefix-length: 24

                                             }

                              }

               }

               interface eth1 {

                              vif eth1 {

                                             address 10.0.1.1 {

 
prefix-length: 32

                                             }

                              }

               }

}

fea {

               unicast-forwarding4 {

                              disable: false

               }

}

policy {

               policy-statement connected-to-rip {

                              term 100 {

                                             from {

                                                            protocol:
"connected"

                                             }

                                             then {

                                                            metric: 1

                                             }

                              }

               }

}

protocols {

               rip {

                              export: "connected-to-rip"

                              interface eth0 {

                                             vif eth0 {

                                                            address
10.0.0.2 {

 
disable: false

 
metric: 1

                                                            }

                                             }

                              }

                              interface eth1 {

                                             vif eth1 {

                                                            address
10.0.1.1 {

 
disable: false

 
metric: 1

                                                            }

                                             }

                              }

               }

}

 

Patrick J Shaw

Computer Architect. Vetronics

General Dynamics Canada  www.gdcanada.com

613-596-7908

613-796-7803(fax)

 

 

 



The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120613/ea13aa88/attachment-0001.html 

From igorm at etf.rs  Wed Jun 13 12:42:41 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Wed, 13 Jun 2012 21:42:41 +0200
Subject: [Xorp-hackers] Rotuing issue
In-Reply-To: <A80739932D1FD74A8E25EBF05B9D508710053F2D@OTTSVW100.gdcan.com>
References: <A80739932D1FD74A8E25EBF05B9D508710053F2D@OTTSVW100.gdcan.com>
Message-ID: <CAFdo_mUb_Zo2dDDF6HF7iGh2aSsyjmDQSK9t8-=qDFXR6orfSw@mail.gmail.com>

--->8---
>
> policy {
>
> ?????????????? policy-statement connected-to-rip {
>
> ?????????????? ?????????????? term 100 {
>
> ???????????????????????????????????????????? from {
>
> ??????????????????????????????????????????????????????????? protocol:
> "connected"
>
> ???????????????????????????????????????????? }
>
> ???????????????????????????????????????????? then {
>
> ??????????????????????????????????????????????????????????? metric: 1
I think that You forgot this:
                                                               accept
>
> ???????????????????????????????????????????? }
---8<---
BR
Igor


From noreply at github.com  Wed Jun 13 17:00:46 2012
From: noreply at github.com (GitHub)
Date: Wed, 13 Jun 2012 17:00:46 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] cc6a6a: fea: Fix netlink parsing
 bug recently introduced.
Message-ID: <4fd929ae305c1_20f51828aec161235@sh2.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: cc6a6a7fb001a5a0986b828dd821f420f60f17bd
      https://github.com/greearb/xorp.ct/commit/cc6a6a7fb001a5a0986b828dd821f420f60f17bd
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-06-13 (Wed, 13 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/control_socket/netlink_socket.cc

  Log Message:
  -----------
  fea:  Fix netlink parsing bug recently introduced.

I changed a vector.resize() to vector.reserve(), thinking
it would be more efficient.  Turns out, it breaks things,
though I am not certain if the real bug actually lies elsewhere.

Either way, add a comment and revert the previous change.
This fixes the bug reported by Igor.

Signed-off-by: Ben Greear <greearb at candelatech.com>




From greearb at candelatech.com  Wed Jun 13 17:01:55 2012
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jun 2012 17:01:55 -0700
Subject: [Xorp-hackers] XORP crash
In-Reply-To: <CAFdo_mVaHvm_m_0q0Em3H+YesFPWFeQtFNnQ1zNsLYhm8TyG6w@mail.gmail.com>
References: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
	<CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>
	<4FD769F5.3020400@candelatech.com>
	<CAFdo_mVaHvm_m_0q0Em3H+YesFPWFeQtFNnQ1zNsLYhm8TyG6w@mail.gmail.com>
Message-ID: <4FD929F3.5090106@candelatech.com>

On 06/13/2012 12:36 AM, Igor Maravi? wrote:
> Yes, crash was introduced with one of your recent commits.
> BR
> Igor

I just pushed a fix for this (on my machine).  Please let me know
if top-of-tree works for you now.  I wanted to get this fixed before
applying your patches...

Thanks,
Ben

>
> 2012/6/12 Ben Greear<greearb at candelatech.com>:
>> On 06/12/2012 02:04 AM, Igor Maravi? wrote:
>>>
>>> Ben,
>>> this is the log that I get without your patches:
>>
>>
>> So this crash was introduced recently when I mucked with
>> the fea netlink code?
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> ---
>>> XORP 1.8.6-WIP BuildInfo:
>>> git version: c01d327 built: Tue Jun 12 10:31:33 CEST 2012
>>> By: igor on machine: Linux igor 3.2.0-mpls-no-dbg+ x86_64 x86_64
>>> Recent git changes:
>>> c01d3271 UNDER CONSTRUCTION
>>> c603fc64 xorp: policy: Fix usage of network{4,6}-lists
>>> 97d46f39 xorp: rib: Fixed register test
>>>
>>> [ 2012/06/12 11:01:22.464462  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/main_rtrmgr.cc:754 main ]
>>> Host Information:
>>> Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
>>> x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l
>>>
>>> [ 2012/06/12 11:01:22.539270  WARNING xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
>>> [ 2012/06/12 11:01:22.851778  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
>>> firewall, fea
>>> [ 2012/06/12 11:01:22.852664  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
>>> (xorp_fea)
>>> [ 2012/06/12 11:01:22.854012  WARNING xorp_rtrmgr:13663
>>> XrlFinderTarget
>>> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
>>> callback_finder_0_2_resolve_xrl ] Handling method for
>>> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
>>> "fea" does not exist or is not enabled.
>>> [ 2012/06/12 11:01:22.854253  WARNING xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
>>> Resolve failed  retries: 0  max_retries: 30
>>> [ 2012/06/12 11:01:23.858789  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>> [ 2012/06/12 11:01:23.858921  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>> [ 2012/06/12 11:01:23.859318  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>> [ 2012/06/12 11:01:23.859333  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>> [ 2012/06/12 11:01:23.859345  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>> [ 2012/06/12 11:01:23.859441  INFO xorp_fea:13668 MFEA
>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>> [ 2012/06/12 11:01:23.874869  WARNING xorp_fea:13668 FEA
>>> fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149
>>> try_read_config_one ] NOTE:  Netlink get single network device works
>>> on this system.
>>> [ 2012/06/12 11:01:23.880360  WARNING xorp_fea:13668 FEA
>>> fea/ifconfig.cc:818 pull_config ] ERROR:  pull_config_one for
>>> interface: vmnet1 failed: -1
>>> [ 2012/06/12 11:01:23.880411  WARNING xorp_fea:13668 FEA
>>> fea/ifconfig.cc:821 pull_config ] ERROR:  Could not find interface:
>>> vmnet1 after pull_config_one.
>>> [ 2012/06/12 11:01:23.968857  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
>>> (xorp_fea)
>>> [ 2012/06/12 11:01:23.970999  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/module_manager.cc:101 execute ] Executing module: fea
>>> (xorp_fea)
>>> [ 2012/06/12 11:01:23.973557  INFO xorp_rtrmgr:13663 RTRMGR
>>> rtrmgr/task.cc:2242 run_task ] No more tasks to run
>>>
>>> ---
>>>
>>> vmnet1 isn't present, and because of that it couldn't be found on system.
>>>
>>> This is my config:
>>> ---
>>> interfaces {
>>>          interface "eth2" {
>>>                  disable: false
>>>                  default-system-config
>>>          }
>>>          interface "vmnet1" {
>>>                  disable: false
>>>                  default-system-config
>>>          }
>>> }
>>> fea {
>>>          unicast-forwarding4 {
>>>                  disable: false
>>>          }
>>> }
>>> ---
>>> BR
>>> Igor
>>
>>
>>
>> --
>> Ben Greear<greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From Pat.Shaw at gdcanada.com  Thu Jun 14 04:59:36 2012
From: Pat.Shaw at gdcanada.com (Shaw, Pat)
Date: Thu, 14 Jun 2012 07:59:36 -0400
Subject: [Xorp-hackers] [SPAM] - Re: Rotuing issue - Email found in
	subject
In-Reply-To: <CAFdo_mUb_Zo2dDDF6HF7iGh2aSsyjmDQSK9t8-=qDFXR6orfSw@mail.gmail.com>
References: <A80739932D1FD74A8E25EBF05B9D508710053F2D@OTTSVW100.gdcan.com>
	<CAFdo_mUb_Zo2dDDF6HF7iGh2aSsyjmDQSK9t8-=qDFXR6orfSw@mail.gmail.com>
Message-ID: <A80739932D1FD74A8E25EBF05B9D508710053F37@OTTSVW100.gdcan.com>

Same results!... if I change the 32 to a 24  the routers work properly... it appears to be something to do with the 32... 

-----Original Message-----
From: Igor Maravi? [mailto:igorm at etf.rs] 
Sent: Wednesday, June 13, 2012 3:43 PM
To: Shaw, Pat
Cc: xorp-hackers at icir.org
Subject: [SPAM] - Re: [Xorp-hackers] Rotuing issue - Email found in subject

--->8---
>
> policy {
>
> ?????????????? policy-statement connected-to-rip {
>
> ?????????????? ?????????????? term 100 {
>
> ???????????????????????????????????????????? from {
>
> ??????????????????????????????????????????????????????????? protocol:
> "connected"
>
> ???????????????????????????????????????????? }
>
> ???????????????????????????????????????????? then {
>
> ??????????????????????????????????????????????????????????? metric: 1
I think that You forgot this:
                                                               accept
>
> ???????????????????????????????????????????? }
---8<---
BR
Igor


The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 



From igorm at etf.rs  Thu Jun 14 06:56:40 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Thu, 14 Jun 2012 15:56:40 +0200
Subject: [Xorp-hackers] XORP crash
In-Reply-To: <4FD929F3.5090106@candelatech.com>
References: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
	<CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>
	<4FD769F5.3020400@candelatech.com>
	<CAFdo_mVaHvm_m_0q0Em3H+YesFPWFeQtFNnQ1zNsLYhm8TyG6w@mail.gmail.com>
	<4FD929F3.5090106@candelatech.com>
Message-ID: <CAFdo_mX-WLq7CaDop_a3M1jU5Rhse430O3_EbsYFv1GWxds1pA@mail.gmail.com>

Works for me! :)
But i just got one comment -
resize() and reserve() do allocate memory for vector, but when memory
is allocated with reserve, vector is still empty. If you call size()
on it, it will return 0. Function reserve() should be used when You
intend to use push_back(), to avoid reallocation of vector memory.
Otherwise you should use resize().
Because vector was "empty", when the resize() was called at the end of
the function, all vector memory was set to some default values.
That's why I think You should remove the TODO comment.
BR
Igor

2012/6/14 Ben Greear <greearb at candelatech.com>:
> On 06/13/2012 12:36 AM, Igor Maravi? wrote:
>>
>> Yes, crash was introduced with one of your recent commits.
>> BR
>> Igor
>
>
> I just pushed a fix for this (on my machine). ?Please let me know
> if top-of-tree works for you now. ?I wanted to get this fixed before
> applying your patches...
>
> Thanks,
> Ben
>
>
>>
>> 2012/6/12 Ben Greear<greearb at candelatech.com>:
>>>
>>> On 06/12/2012 02:04 AM, Igor Maravi? wrote:
>>>>
>>>>
>>>> Ben,
>>>> this is the log that I get without your patches:
>>>
>>>
>>>
>>> So this crash was introduced recently when I mucked with
>>> the fea netlink code?
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>>>
>>>> ---
>>>> XORP 1.8.6-WIP BuildInfo:
>>>> git version: c01d327 built: Tue Jun 12 10:31:33 CEST 2012
>>>> By: igor on machine: Linux igor 3.2.0-mpls-no-dbg+ x86_64 x86_64
>>>> Recent git changes:
>>>> c01d3271 UNDER CONSTRUCTION
>>>> c603fc64 xorp: policy: Fix usage of network{4,6}-lists
>>>> 97d46f39 xorp: rib: Fixed register test
>>>>
>>>> [ 2012/06/12 11:01:22.464462 ?INFO xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/main_rtrmgr.cc:754 main ]
>>>> Host Information:
>>>> Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
>>>> x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l
>>>>
>>>> [ 2012/06/12 11:01:22.539270 ?WARNING xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
>>>> [ 2012/06/12 11:01:22.851778 ?INFO xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
>>>> firewall, fea
>>>> [ 2012/06/12 11:01:22.852664 ?INFO xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
>>>> (xorp_fea)
>>>> [ 2012/06/12 11:01:22.854012 ?WARNING xorp_rtrmgr:13663
>>>> XrlFinderTarget
>>>> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
>>>> callback_finder_0_2_resolve_xrl ] Handling method for
>>>> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
>>>> "fea" does not exist or is not enabled.
>>>> [ 2012/06/12 11:01:22.854253 ?WARNING xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
>>>> Resolve failed ?retries: 0 ?max_retries: 30
>>>> [ 2012/06/12 11:01:23.858789 ?INFO xorp_fea:13668 MFEA
>>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>>> [ 2012/06/12 11:01:23.858921 ?INFO xorp_fea:13668 MFEA
>>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>>> [ 2012/06/12 11:01:23.859318 ?INFO xorp_fea:13668 MFEA
>>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>>> [ 2012/06/12 11:01:23.859333 ?INFO xorp_fea:13668 MFEA
>>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>>> [ 2012/06/12 11:01:23.859345 ?INFO xorp_fea:13668 MFEA
>>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>>> [ 2012/06/12 11:01:23.859441 ?INFO xorp_fea:13668 MFEA
>>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>>> [ 2012/06/12 11:01:23.874869 ?WARNING xorp_fea:13668 FEA
>>>> fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149
>>>> try_read_config_one ] NOTE: ?Netlink get single network device works
>>>> on this system.
>>>> [ 2012/06/12 11:01:23.880360 ?WARNING xorp_fea:13668 FEA
>>>> fea/ifconfig.cc:818 pull_config ] ERROR: ?pull_config_one for
>>>> interface: vmnet1 failed: -1
>>>> [ 2012/06/12 11:01:23.880411 ?WARNING xorp_fea:13668 FEA
>>>> fea/ifconfig.cc:821 pull_config ] ERROR: ?Could not find interface:
>>>> vmnet1 after pull_config_one.
>>>> [ 2012/06/12 11:01:23.968857 ?INFO xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
>>>> (xorp_fea)
>>>> [ 2012/06/12 11:01:23.970999 ?INFO xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/module_manager.cc:101 execute ] Executing module: fea
>>>> (xorp_fea)
>>>> [ 2012/06/12 11:01:23.973557 ?INFO xorp_rtrmgr:13663 RTRMGR
>>>> rtrmgr/task.cc:2242 run_task ] No more tasks to run
>>>>
>>>> ---
>>>>
>>>> vmnet1 isn't present, and because of that it couldn't be found on
>>>> system.
>>>>
>>>> This is my config:
>>>> ---
>>>> interfaces {
>>>> ? ? ? ? interface "eth2" {
>>>> ? ? ? ? ? ? ? ? disable: false
>>>> ? ? ? ? ? ? ? ? default-system-config
>>>> ? ? ? ? }
>>>> ? ? ? ? interface "vmnet1" {
>>>> ? ? ? ? ? ? ? ? disable: false
>>>> ? ? ? ? ? ? ? ? default-system-config
>>>> ? ? ? ? }
>>>> }
>>>> fea {
>>>> ? ? ? ? unicast-forwarding4 {
>>>> ? ? ? ? ? ? ? ? disable: false
>>>> ? ? ? ? }
>>>> }
>>>> ---
>>>> BR
>>>> Igor
>>>
>>>
>>>
>>>
>>> --
>>> Ben Greear<greearb at candelatech.com>
>>> Candela Technologies Inc ?http://www.candelatech.com
>>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>


From igorm at etf.rs  Thu Jun 14 07:16:19 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Thu, 14 Jun 2012 16:16:19 +0200
Subject: [Xorp-hackers] [SPAM] - Re: Rotuing issue - Email found in
	subject
In-Reply-To: <A80739932D1FD74A8E25EBF05B9D508710053F37@OTTSVW100.gdcan.com>
References: <A80739932D1FD74A8E25EBF05B9D508710053F2D@OTTSVW100.gdcan.com>
	<CAFdo_mUb_Zo2dDDF6HF7iGh2aSsyjmDQSK9t8-=qDFXR6orfSw@mail.gmail.com>
	<A80739932D1FD74A8E25EBF05B9D508710053F37@OTTSVW100.gdcan.com>
Message-ID: <CAFdo_mU6MZrBjcVRGj35hfe8ki6xu1PvTgVZAkuNZH6Lc8qAfg@mail.gmail.com>

2012/6/14 Shaw, Pat <Pat.Shaw at gdcanada.com>:
> Same results!... if I change the 32 to a 24 ?the routers work properly... it appears to be something to do with the 32...
>

It works me, in both cases.


From greearb at candelatech.com  Thu Jun 14 08:56:04 2012
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 14 Jun 2012 08:56:04 -0700
Subject: [Xorp-hackers] XORP crash
In-Reply-To: <CAFdo_mX-WLq7CaDop_a3M1jU5Rhse430O3_EbsYFv1GWxds1pA@mail.gmail.com>
References: <CAFdo_mXPFvocPUPzDLWd9XO1o4DaS6cXUNWEmSU-7z2zLPKb5g@mail.gmail.com>
	<CAFdo_mVF8LKJwifZ2=nhzwW7=PArXWk4uook+y3bAdcdeBkduw@mail.gmail.com>
	<4FD769F5.3020400@candelatech.com>
	<CAFdo_mVaHvm_m_0q0Em3H+YesFPWFeQtFNnQ1zNsLYhm8TyG6w@mail.gmail.com>
	<4FD929F3.5090106@candelatech.com>
	<CAFdo_mX-WLq7CaDop_a3M1jU5Rhse430O3_EbsYFv1GWxds1pA@mail.gmail.com>
Message-ID: <4FDA0994.6040900@candelatech.com>

On 06/14/2012 06:56 AM, Igor Maravi? wrote:
> Works for me! :)
> But i just got one comment -
> resize() and reserve() do allocate memory for vector, but when memory
> is allocated with reserve, vector is still empty. If you call size()
> on it, it will return 0. Function reserve() should be used when You
> intend to use push_back(), to avoid reallocation of vector memory.
> Otherwise you should use resize().
> Because vector was "empty", when the resize() was called at the end of
> the function, all vector memory was set to some default values.
> That's why I think You should remove the TODO comment.

Ahh, ok..I didn't understand that distinction.  Will clean up that
comment.

Thanks,
Ben

> BR
> Igor
>
> 2012/6/14 Ben Greear<greearb at candelatech.com>:
>> On 06/13/2012 12:36 AM, Igor Maravi? wrote:
>>>
>>> Yes, crash was introduced with one of your recent commits.
>>> BR
>>> Igor
>>
>>
>> I just pushed a fix for this (on my machine).  Please let me know
>> if top-of-tree works for you now.  I wanted to get this fixed before
>> applying your patches...
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> 2012/6/12 Ben Greear<greearb at candelatech.com>:
>>>>
>>>> On 06/12/2012 02:04 AM, Igor Maravi? wrote:
>>>>>
>>>>>
>>>>> Ben,
>>>>> this is the log that I get without your patches:
>>>>
>>>>
>>>>
>>>> So this crash was introduced recently when I mucked with
>>>> the fea netlink code?
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>>
>>>>>
>>>>> ---
>>>>> XORP 1.8.6-WIP BuildInfo:
>>>>> git version: c01d327 built: Tue Jun 12 10:31:33 CEST 2012
>>>>> By: igor on machine: Linux igor 3.2.0-mpls-no-dbg+ x86_64 x86_64
>>>>> Recent git changes:
>>>>> c01d3271 UNDER CONSTRUCTION
>>>>> c603fc64 xorp: policy: Fix usage of network{4,6}-lists
>>>>> 97d46f39 xorp: rib: Fixed register test
>>>>>
>>>>> [ 2012/06/12 11:01:22.464462  INFO xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/main_rtrmgr.cc:754 main ]
>>>>> Host Information:
>>>>> Linux igor 3.2.0-mpls-no-dbg+ #18 SMP Mon Jun 4 17:10:57 CEST 2012
>>>>> x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.10 \n \l
>>>>>
>>>>> [ 2012/06/12 11:01:22.539270  WARNING xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/xrldb.cc:204 XRLdb ] XRLdb validation is enabled.
>>>>> [ 2012/06/12 11:01:22.851778  INFO xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
>>>>> firewall, fea
>>>>> [ 2012/06/12 11:01:22.852664  INFO xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
>>>>> (xorp_fea)
>>>>> [ 2012/06/12 11:01:22.854012  WARNING xorp_rtrmgr:13663
>>>>> XrlFinderTarget
>>>>> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:1066
>>>>> callback_finder_0_2_resolve_xrl ] Handling method for
>>>>> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target
>>>>> "fea" does not exist or is not enabled.
>>>>> [ 2012/06/12 11:01:22.854253  WARNING xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201
>>>>> Resolve failed  retries: 0  max_retries: 30
>>>>> [ 2012/06/12 11:01:23.858789  INFO xorp_fea:13668 MFEA
>>>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>>>> [ 2012/06/12 11:01:23.858921  INFO xorp_fea:13668 MFEA
>>>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>>>> [ 2012/06/12 11:01:23.859318  INFO xorp_fea:13668 MFEA
>>>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>>>> [ 2012/06/12 11:01:23.859333  INFO xorp_fea:13668 MFEA
>>>>> fea/mfea_node.cc:295 enable ] MFEA enabled
>>>>> [ 2012/06/12 11:01:23.859345  INFO xorp_fea:13668 MFEA
>>>>> fea/mfea_node_cli.cc:126 enable ] CLI enabled
>>>>> [ 2012/06/12 11:01:23.859441  INFO xorp_fea:13668 MFEA
>>>>> fea/mfea_node_cli.cc:92 start ] CLI started
>>>>> [ 2012/06/12 11:01:23.874869  WARNING xorp_fea:13668 FEA
>>>>> fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149
>>>>> try_read_config_one ] NOTE:  Netlink get single network device works
>>>>> on this system.
>>>>> [ 2012/06/12 11:01:23.880360  WARNING xorp_fea:13668 FEA
>>>>> fea/ifconfig.cc:818 pull_config ] ERROR:  pull_config_one for
>>>>> interface: vmnet1 failed: -1
>>>>> [ 2012/06/12 11:01:23.880411  WARNING xorp_fea:13668 FEA
>>>>> fea/ifconfig.cc:821 pull_config ] ERROR:  Could not find interface:
>>>>> vmnet1 after pull_config_one.
>>>>> [ 2012/06/12 11:01:23.968857  INFO xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/module_manager.cc:101 execute ] Executing module: firewall
>>>>> (xorp_fea)
>>>>> [ 2012/06/12 11:01:23.970999  INFO xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/module_manager.cc:101 execute ] Executing module: fea
>>>>> (xorp_fea)
>>>>> [ 2012/06/12 11:01:23.973557  INFO xorp_rtrmgr:13663 RTRMGR
>>>>> rtrmgr/task.cc:2242 run_task ] No more tasks to run
>>>>>
>>>>> ---
>>>>>
>>>>> vmnet1 isn't present, and because of that it couldn't be found on
>>>>> system.
>>>>>
>>>>> This is my config:
>>>>> ---
>>>>> interfaces {
>>>>>          interface "eth2" {
>>>>>                  disable: false
>>>>>                  default-system-config
>>>>>          }
>>>>>          interface "vmnet1" {
>>>>>                  disable: false
>>>>>                  default-system-config
>>>>>          }
>>>>> }
>>>>> fea {
>>>>>          unicast-forwarding4 {
>>>>>                  disable: false
>>>>>          }
>>>>> }
>>>>> ---
>>>>> BR
>>>>> Igor
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ben Greear<greearb at candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>
>>
>>
>> --
>> Ben Greear<greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From noreply at github.com  Thu Jun 14 09:50:38 2012
From: noreply at github.com (GitHub)
Date: Thu, 14 Jun 2012 09:50:38 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] 5f57d9: fea: Clean up netlink
 comment from last commit.
Message-ID: <4fda165edf28_302d1443ae4115439@sh3.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: 5f57d9ca2a616db027dbb785dcdb91715b23aae5
      https://github.com/greearb/xorp.ct/commit/5f57d9ca2a616db027dbb785dcdb91715b23aae5
  Author: Ben Greear <greearb at candelatech.com>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/control_socket/netlink_socket.cc

  Log Message:
  -----------
  fea:  Clean up netlink comment from last commit.

Seems I didn't really understand the vector api all that
well.




From noreply at github.com  Thu Jun 14 10:39:42 2012
From: noreply at github.com (GitHub)
Date: Thu, 14 Jun 2012 10:39:42 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] e62f66: trivial: ws fixes
Message-ID: <4fda21de15f4_6d79f3daf4118757@sh2.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: e62f66e1d3efeda0991f653c7f84d10725debfee
      https://github.com/greearb/xorp.ct/commit/e62f66e1d3efeda0991f653c7f84d10725debfee
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/SConstruct
    M xorp/fea/data_plane/control_socket/netlink_socket.cc
    M xorp/fea/data_plane/control_socket/netlink_socket.hh
    M xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc
    M xorp/fea/data_plane/control_socket/netlink_socket_utilities.hh
    M xorp/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.hh
    M xorp/fea/data_plane/ifconfig/ifconfig_parse_getifaddrs.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
    M xorp/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.hh
    M xorp/fea/ifconfig_transaction.hh
    M xorp/fea/iftree.cc
    M xorp/fea/iftree.hh
    M xorp/fea/libfeaclient_bridge.cc
    M xorp/fea/tools/show_interfaces.cc
    M xorp/fea/xrl_fea_target.cc
    M xorp/fea/xrl_fea_target.hh
    M xorp/libfeaclient/ifmgr_atoms.cc
    M xorp/libfeaclient/ifmgr_atoms.hh
    M xorp/libfeaclient/ifmgr_cmd_queue.cc
    M xorp/libfeaclient/ifmgr_cmds.hh
    M xorp/libfeaclient/ifmgr_xrl_mirror.cc
    M xorp/libfeaclient/tests/test_local_copy.cc
    M xorp/libfeaclient/tests/test_remote_copy.cc
    M xorp/libxorp/exceptions.cc
    M xorp/libxorp/exceptions.hh
    M xorp/libxorp/nexthop.cc
    M xorp/libxorp/nexthop.hh
    M xorp/libxorp/tests/test_callback.cc
    M xorp/libxorp/tests/test_vif.cc
    M xorp/libxorp/trie.hh
    M xorp/libxorp/vif.cc
    M xorp/libxorp/vif.hh
    M xorp/policy/common/element.cc
    M xorp/rib/parser.cc
    M xorp/rib/parser_xrl_cmds.hh
    M xorp/rib/protocol.hh
    M xorp/rib/redist_policy.hh
    M xorp/rib/redist_xrl.cc
    M xorp/rib/redist_xrl.hh
    M xorp/rib/rib.cc
    M xorp/rib/rib.hh
    M xorp/rib/route.cc
    M xorp/rib/route.hh
    M xorp/rib/rt_tab_base.cc
    M xorp/rib/rt_tab_base.hh
    M xorp/rib/rt_tab_deletion.cc
    M xorp/rib/rt_tab_deletion.hh
    M xorp/rib/rt_tab_extint.cc
    M xorp/rib/rt_tab_extint.hh
    M xorp/rib/rt_tab_log.cc
    M xorp/rib/rt_tab_log.hh
    M xorp/rib/rt_tab_merged.cc
    M xorp/rib/rt_tab_merged.hh
    M xorp/rib/rt_tab_origin.cc
    M xorp/rib/rt_tab_origin.hh
    M xorp/rib/rt_tab_pol_conn.hh
    M xorp/rib/rt_tab_pol_redist.hh
    M xorp/rib/rt_tab_redist.cc
    M xorp/rib/rt_tab_redist.hh
    M xorp/rib/rt_tab_register.cc
    M xorp/rib/rt_tab_register.hh
    M xorp/rib/tests/dummy_register_server.cc
    M xorp/rib/tests/dummy_register_server.hh
    M xorp/rib/tests/rt_tab_expect.cc
    M xorp/rib/tests/rt_tab_expect.hh
    M xorp/rib/tests/test_deletion.cc
    M xorp/rib/tests/test_redist.cc
    M xorp/rib/tests/test_register.cc
    M xorp/rib/tests/test_register_xrls.cc
    M xorp/rib/tests/test_rib_direct.cc
    M xorp/rib/tests/test_rib_xrls.cc
    M xorp/rib/vifmanager.cc
    M xorp/rip/tools/show_peer_stats.cc

  Log Message:
  -----------
  trivial: ws fixes

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 96b99f18b4be9cb6b6b3605108fa098d66ae3e42
      https://github.com/greearb/xorp.ct/commit/96b99f18b4be9cb6b6b3605108fa098d66ae3e42
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/libxorp/trie.hh

  Log Message:
  -----------
  xorp: libxorp: Add operator* and operator-> to Trie iterators

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 29128b7991e73fd19fa390ef992a39350f6521d0
      https://github.com/greearb/xorp.ct/commit/29128b7991e73fd19fa390ef992a39350f6521d0
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/libxorp/trie.hh

  Log Message:
  -----------
  xorp: libxorp: Add empty() function to Trie

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 84b22b60db3921d72887394624fc95e04a9f21cd
      https://github.com/greearb/xorp.ct/commit/84b22b60db3921d72887394624fc95e04a9f21cd
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_extint.cc
    M xorp/rib/rt_tab_extint.hh

  Log Message:
  -----------
  xorp: rib: Make lookup_next_by_igp_parent() more efficient

We now pass the iterator from where it should look for next route
instead of looping through all the routes to find it.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 0cdf6144124e46fafecf94215e1626e600744a3d
      https://github.com/greearb/xorp.ct/commit/0cdf6144124e46fafecf94215e1626e600744a3d
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_redist.cc

  Log Message:
  -----------
  xorp: rib: NO_LAST_NET needs not to be specialized

Same code is valid for IPv6 and IPv4 class

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 87e71fc8cc369814ee0135982db9ef2785b0322f
      https://github.com/greearb/xorp.ct/commit/87e71fc8cc369814ee0135982db9ef2785b0322f
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_redist.cc
    M xorp/rib/rt_tab_redist.hh

  Log Message:
  -----------
  xorp: rib: Pretify the usage of RedistNetCmp<A> operator()

Defined static member of RedistNetCmp<A> so the usage of operator() would
be more intuitive.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 2325c9229859bbe64bc57e7f5469589cfdd6cb18
      https://github.com/greearb/xorp.ct/commit/2325c9229859bbe64bc57e7f5469589cfdd6cb18
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/SConstruct
    M xorp/rib/tests/SConscript
    M xorp/rib/tests/dummy_register_server.hh
    M xorp/rib/tests/test_register_xrls.cc
    M xorp/rib/tests/test_rib_direct.cc
    M xorp/rib/tests/test_rib_xrls.cc

  Log Message:
  -----------
  xorp: rib: Enable compiling of rib tests

Tests are compiled to the {$builddir}/rib/tests
Files commands, test_rib_xrls.sh and
test_rib_direct.sh are copied to that directory also.

They are going to be compiled only if test building is enabled via
scons command line.

Added new enviroment 'builddir' to the SCons. It represents
string representation of build directory.
I needed it so the files could be copied to apropriate dir.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 554a546a9e6d857ce5ecf96c76e226436ef26436
      https://github.com/greearb/xorp.ct/commit/554a546a9e6d857ce5ecf96c76e226436ef26436
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/tests/test_rib_direct.cc

  Log Message:
  -----------
  xorp: rib: tests: RIB should be initialized before it's used

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: cb035f7ec622df0dfdfb177b3e4cd5d41c4aaece
      https://github.com/greearb/xorp.ct/commit/cb035f7ec622df0dfdfb177b3e4cd5d41c4aaece
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/parser_xrl_cmds.hh

  Log Message:
  -----------
  xorp: rib: Print if command has succeded instead of printing integer

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: d33b346c8ccf9b3a0ba2386ea6ca3c3079faada1
      https://github.com/greearb/xorp.ct/commit/d33b346c8ccf9b3a0ba2386ea6ca3c3079faada1
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/parser.cc

  Log Message:
  -----------
  xorp: rib: Remove unneeded printf in Uint32ArgumentParser::parse

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: c869d77767f5b1acd9c5add736d67f9a4a842b57
      https://github.com/greearb/xorp.ct/commit/c869d77767f5b1acd9c5add736d67f9a4a842b57
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/tests/test_register.cc

  Log Message:
  -----------
  xorp: rib: tests: Minor fixes to function test_route_range

Release RouteRange obtained with route_range_lookup,
and prevent memory leak.

Print that we expected error, when the expected error ocures.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 757d6c82310e57b1586923930065654ec547635d
      https://github.com/greearb/xorp.ct/commit/757d6c82310e57b1586923930065654ec547635d
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/xrl_target.cc

  Log Message:
  -----------
  xorp: rib: Use const map when iterating through admin_distances

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: f01e1b8631fe6e0074550f3b8e145a90c798e0c9
      https://github.com/greearb/xorp.ct/commit/f01e1b8631fe6e0074550f3b8e145a90c798e0c9
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/rib.cc
    M xorp/rib/rib.hh

  Log Message:
  -----------
  xorp: rib: Add function for finding vif by name

Added function find_vif(const string&) to avoid unnecessary
repetition in code

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 47b6afb5eb7f0e7f727b96103c987036cd86e900
      https://github.com/greearb/xorp.ct/commit/47b6afb5eb7f0e7f727b96103c987036cd86e900
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/rib_manager.hh

  Log Message:
  -----------
  xorp: rib: Add const getters for uribs and mribs

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 39241062a4c5e023ebac06471eb2918fc94fd0d8
      https://github.com/greearb/xorp.ct/commit/39241062a4c5e023ebac06471eb2918fc94fd0d8
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/libxorp/range.hh

  Log Message:
  -----------
  xorp: libxorp: Added missing constructors to derived classes of Range

Constructors with two arguments, and one argument were missing
from derived classes.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 5bc27b1c5922bc92df558239a09210647dca29c2
      https://github.com/greearb/xorp.ct/commit/5bc27b1c5922bc92df558239a09210647dca29c2
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/libxorp/nexthop.cc
    M xorp/libxorp/nexthop.hh

  Log Message:
  -----------
  xorp: libxorp: Make printing of Nexthop strings simpler

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 15880f541311f668cdf87fa6867a59bfa8ef67f1
      https://github.com/greearb/xorp.ct/commit/15880f541311f668cdf87fa6867a59bfa8ef67f1
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/route.hh

  Log Message:
  -----------
  xorp: rib: Use explicit inlining instead of explicit

This makes code more readable.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: ca06dac68f92a4221118f1d9bf0a92d5b42df1f4
      https://github.com/greearb/xorp.ct/commit/ca06dac68f92a4221118f1d9bf0a92d5b42df1f4
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-14 (Thu, 14 Jun 2012)

  Changed paths:
    M xorp/rib/route.hh

  Log Message:
  -----------
  xorp: rib: _igp_parent and _egp_parent doesn't need to be mutable members

This members doesn't need to be mutable in ResolvedIPRouteEntry class.

Signed-off-by: Igor Maravic <igorm at etf.rs>


Compare: https://github.com/greearb/xorp.ct/compare/5f57d9ca2a61...ca06dac68f92

From Kira.Farney at ngc.com  Mon Jun 18 07:59:00 2012
From: Kira.Farney at ngc.com (Farney, Kira (IS))
Date: Mon, 18 Jun 2012 14:59:00 +0000
Subject: [Xorp-hackers] problems running xorp_rtrmgr and xorpsh
Message-ID: <A1C8FCD880CA9E47BAC11B56E68DA3B2A73586@XMBVAG73.northgrum.com>

Hi All,

We successfully cross compiled XORP and moved it to target board. We put all the libraries to /usr/lib directory and xorp to /usr/local. Here is what's happening when I am trying to run ./xorp_rtrmgr and ./xorpsh. I noticed that it has issues loading the libraries.

I am not an expert in Linux by any means, so I don't know why these errors being generated. Could anyone assist me please. Your help will be greatly appreciated.


/usr/local/xorp/sbin # ./xorp_rtrmgr -b static.boot
Not doing pidfile...
[ 1970/01/05 19:46:01.458317  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/main_rtrmgr.cc:718 main ]

XORP 1.8.5 BuildInfo:
git version: 00000000 built: Tue Jun 12 11:51:39 EDT 2012
By: root on machine: Linux embedded-dev 2.6.32-5-686 i686 unknown
Recent git changes:
Cannot detect, not a git repository
[ 1970/01/05 19:46:01.462235  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/main_rtrmgr.cc:754 main ]
Host Information:
Linux (none) 2.6.32.27-Cavium-Octeon #4 SMP Fri May 11 13:04:17 EDT 2012 mips64 GNU/Linux

[ 1970/01/05 19:46:01.619398  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces, firewall, fea, rib, policy, static_routes
[ 1970/01/05 19:46:01.622125  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces (xorp_fea)
[ 1970/01/05 19:46:01.623088  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:01.623420  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 0  max_retries: 30
xorp_fea: error while loading shared libraries: libpcap.so.1: cannot open shared object file: No such file or directory
[ 1970/01/05 19:46:01.626264  ERROR xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:781 done_cb ] Command "/usr/local/xorp/lib/xorp/sbin/xorp_fea": exited with exit status 127.
[ 1970/01/05 19:46:01.626319  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:334 module_exited ] Module abnormal exit: interfaces
[ 1970/01/05 19:46:02.624563  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:02.624874  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 1  max_retries: 30
[ 1970/01/05 19:46:03.626023  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:03.626320  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 2  max_retries: 30
[ 1970/01/05 19:46:04.627482  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:04.627778  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 3  max_retries: 30
[ 1970/01/05 19:46:05.628939  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:05.629234  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 4  max_retries: 30
[ 1970/01/05 19:46:06.630289  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:06.630583  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 5  max_retries: 30
[ 1970/01/05 19:46:07.631747  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:07.632041  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 6  max_retries: 30
^C^C^C[ 1970/01/05 19:46:08.470369  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:2242 run_task ] No more tasks to run
^C^C^C^C^CWARNING:  Process: 1057 has message from dflt_sig_handler: SIGINT received
/usr/local/xorp/sbin #


/usr/local/xorp/sbin # ./xorpsh
./xorpsh: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory



Thanks,

Kira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120618/45bbfdd2/attachment.html 

From igorm at etf.rs  Mon Jun 18 08:12:07 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Mon, 18 Jun 2012 17:12:07 +0200
Subject: [Xorp-hackers] problems running xorp_rtrmgr and xorpsh
In-Reply-To: <A1C8FCD880CA9E47BAC11B56E68DA3B2A73586@XMBVAG73.northgrum.com>
References: <A1C8FCD880CA9E47BAC11B56E68DA3B2A73586@XMBVAG73.northgrum.com>
Message-ID: <CAFdo_mXNm6uYUCxqAjHagngjn1wB6Tgf=bBHC07x5DOeUih4ow@mail.gmail.com>

What were your install flags?

2012/6/18 Farney, Kira (IS) <Kira.Farney at ngc.com>:
> Hi All,
>
>
>
> We successfully cross compiled XORP and moved it to target board. We put all
> the libraries to /usr/lib directory and xorp to /usr/local. Here is what?s
> happening when I am trying to run ./xorp_rtrmgr and ./xorpsh. I noticed that
> it has issues loading the libraries.
>
>
>
> I am not an expert in Linux by any means, so I don?t know why these errors
> being generated. Could anyone assist me please. Your help will be greatly
> appreciated.
>
>
>
>
>
> /usr/local/xorp/sbin # ./xorp_rtrmgr -b static.boot
>
> Not doing pidfile...
>
> [ 1970/01/05 19:46:01.458317? INFO xorp_rtrmgr:1057 RTRMGR
> rtrmgr/main_rtrmgr.cc:718 main ]
>
>
>
> XORP 1.8.5 BuildInfo:
>
> git version: 00000000 built: Tue Jun 12 11:51:39 EDT 2012
>
> By: root on machine: Linux embedded-dev 2.6.32-5-686 i686 unknown
>
> Recent git changes:
>
> Cannot detect, not a git repository
>
> [ 1970/01/05 19:46:01.462235? INFO xorp_rtrmgr:1057 RTRMGR
> rtrmgr/main_rtrmgr.cc:754 main ]
>
> Host Information:
>
> Linux (none) 2.6.32.27-Cavium-Octeon #4 SMP Fri May 11 13:04:17 EDT 2012
> mips64 GNU/Linux
>
>
>
> [ 1970/01/05 19:46:01.619398? INFO xorp_rtrmgr:1057 RTRMGR
> rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces,
> firewall, fea, rib, policy, static_routes
>
> [ 1970/01/05 19:46:01.622125? INFO xorp_rtrmgr:1057 RTRMGR
> rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces
> (xorp_fea)
>
> [ 1970/01/05 19:46:01.623088? WARNING xorp_rtrmgr:1057 XrlFinderTarget
> obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135
> handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl
> failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not
> enabled.
>
> [ 1970/01/05 19:46:01.623420? WARNING xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve
> failed? retries: 0? max_retries: 30
>
> xorp_fea: error while loading shared libraries: libpcap.so.1: cannot open
> shared object file: No such file or directory
>
> [ 1970/01/05 19:46:01.626264? ERROR xorp_rtrmgr:1057 RTRMGR
> rtrmgr/module_manager.cc:781 done_cb ] Command
> "/usr/local/xorp/lib/xorp/sbin/xorp_fea": exited with exit status 127.
>
> [ 1970/01/05 19:46:01.626319? INFO xorp_rtrmgr:1057 RTRMGR
> rtrmgr/module_manager.cc:334 module_exited ] Module abnormal exit:
> interfaces
>
> [ 1970/01/05 19:46:02.624563? WARNING xorp_rtrmgr:1057 XrlFinderTarget
> obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135
> handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl
> failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not
> enabled.
>
> [ 1970/01/05 19:46:02.624874? WARNING xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve
> failed? retries: 1? max_retries: 30
>
> [ 1970/01/05 19:46:03.626023? WARNING xorp_rtrmgr:1057 XrlFinderTarget
> obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135
> handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl
> failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not
> enabled.
>
> [ 1970/01/05 19:46:03.626320? WARNING xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve
> failed? retries: 2? max_retries: 30
>
> [ 1970/01/05 19:46:04.627482? WARNING xorp_rtrmgr:1057 XrlFinderTarget
> obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135
> handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl
> failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not
> enabled.
>
> [ 1970/01/05 19:46:04.627778? WARNING xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve
> failed? retries: 3? max_retries: 30
>
> [ 1970/01/05 19:46:05.628939? WARNING xorp_rtrmgr:1057 XrlFinderTarget
> obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135
> handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl
> failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not
> enabled.
>
> [ 1970/01/05 19:46:05.629234? WARNING xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve
> failed? retries: 4? max_retries: 30
>
> [ 1970/01/05 19:46:06.630289? WARNING xorp_rtrmgr:1057 XrlFinderTarget
> obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135
> handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl
> failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not
> enabled.
>
> [ 1970/01/05 19:46:06.630583? WARNING xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve
> failed? retries: 5? max_retries: 30
>
> [ 1970/01/05 19:46:07.631747? WARNING xorp_rtrmgr:1057 XrlFinderTarget
> obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135
> handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl
> failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not
> enabled.
>
> [ 1970/01/05 19:46:07.632041? WARNING xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve
> failed? retries: 6? max_retries: 30
>
> ^C^C^C[ 1970/01/05 19:46:08.470369? INFO xorp_rtrmgr:1057 RTRMGR
> rtrmgr/task.cc:2242 run_task ] No more tasks to run
>
> ^C^C^C^C^CWARNING:? Process: 1057 has message from dflt_sig_handler: SIGINT
> received
>
> /usr/local/xorp/sbin #
>
>
>
>
>
> /usr/local/xorp/sbin # ./xorpsh
>
> ./xorpsh: error while loading shared libraries: libncurses.so.5: cannot open
> shared object file: No such file or directory
>
>
>
>
>
>
>
> Thanks,
>
>
>
> Kira
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From tom.kuhn at ngc.com  Mon Jun 18 10:21:24 2012
From: tom.kuhn at ngc.com (Kuhn, Thomas J (IS))
Date: Mon, 18 Jun 2012 17:21:24 +0000
Subject: [Xorp-hackers] problems running xorp_rtrmgr and xorpsh
In-Reply-To: <A1C8FCD880CA9E47BAC11B56E68DA3B2A73586@XMBVAG73.northgrum.com>
References: <A1C8FCD880CA9E47BAC11B56E68DA3B2A73586@XMBVAG73.northgrum.com>
Message-ID: <79D1420E63043F44B2039BA7A8A7A2441E8379FB@XMBVAG73.northgrum.com>

Here is the install lines we are using...


scons install debug=no strip=no enable_tests=yes build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-strip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
RANLIB=mips64-octeon-linux-gnu-ranlib \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib


Tom Kuhn
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>

From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Farney, Kira (IS)
Sent: Monday, June 18, 2012 10:59 AM
To: xorp-hackers at icir.org
Subject: EXT :[Xorp-hackers] problems running xorp_rtrmgr and xorpsh

Hi All,

We successfully cross compiled XORP and moved it to target board. We put all the libraries to /usr/lib directory and xorp to /usr/local. Here is what's happening when I am trying to run ./xorp_rtrmgr and ./xorpsh. I noticed that it has issues loading the libraries.

I am not an expert in Linux by any means, so I don't know why these errors being generated. Could anyone assist me please. Your help will be greatly appreciated.


/usr/local/xorp/sbin # ./xorp_rtrmgr -b static.boot
Not doing pidfile...
[ 1970/01/05 19:46:01.458317  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/main_rtrmgr.cc:718 main ]

XORP 1.8.5 BuildInfo:
git version: 00000000 built: Tue Jun 12 11:51:39 EDT 2012
By: root on machine: Linux embedded-dev 2.6.32-5-686 i686 unknown
Recent git changes:
Cannot detect, not a git repository
[ 1970/01/05 19:46:01.462235  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/main_rtrmgr.cc:754 main ]
Host Information:
Linux (none) 2.6.32.27-Cavium-Octeon #4 SMP Fri May 11 13:04:17 EDT 2012 mips64 GNU/Linux

[ 1970/01/05 19:46:01.619398  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces, firewall, fea, rib, policy, static_routes
[ 1970/01/05 19:46:01.622125  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces (xorp_fea)
[ 1970/01/05 19:46:01.623088  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:01.623420  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 0  max_retries: 30
xorp_fea: error while loading shared libraries: libpcap.so.1: cannot open shared object file: No such file or directory
[ 1970/01/05 19:46:01.626264  ERROR xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:781 done_cb ] Command "/usr/local/xorp/lib/xorp/sbin/xorp_fea": exited with exit status 127.
[ 1970/01/05 19:46:01.626319  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:334 module_exited ] Module abnormal exit: interfaces
[ 1970/01/05 19:46:02.624563  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:02.624874  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 1  max_retries: 30
[ 1970/01/05 19:46:03.626023  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:03.626320  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 2  max_retries: 30
[ 1970/01/05 19:46:04.627482  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:04.627778  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 3  max_retries: 30
[ 1970/01/05 19:46:05.628939  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:05.629234  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 4  max_retries: 30
[ 1970/01/05 19:46:06.630289  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:06.630583  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 5  max_retries: 30
[ 1970/01/05 19:46:07.631747  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:07.632041  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 6  max_retries: 30
^C^C^C[ 1970/01/05 19:46:08.470369  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:2242 run_task ] No more tasks to run
^C^C^C^C^CWARNING:  Process: 1057 has message from dflt_sig_handler: SIGINT received
/usr/local/xorp/sbin #


/usr/local/xorp/sbin # ./xorpsh
./xorpsh: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory



Thanks,

Kira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120618/783dadac/attachment.html 

From Kira.Farney at ngc.com  Mon Jun 18 10:58:12 2012
From: Kira.Farney at ngc.com (Farney, Kira (IS))
Date: Mon, 18 Jun 2012 17:58:12 +0000
Subject: [Xorp-hackers] problems running xorp_rtrmgr and xorpsh
In-Reply-To: <79D1420E63043F44B2039BA7A8A7A2441E8379FB@XMBVAG73.northgrum.com>
References: <A1C8FCD880CA9E47BAC11B56E68DA3B2A73586@XMBVAG73.northgrum.com>
	<79D1420E63043F44B2039BA7A8A7A2441E8379FB@XMBVAG73.northgrum.com>
Message-ID: <A1C8FCD880CA9E47BAC11B56E68DA3B2A755EF@XMBVAG73.northgrum.com>

We rebuilt ncurses, openssl, and libpcap. As and before, we followed the instructions described in BUILD_NOTES.  Here is the generated list of the directories and their contents.



build at embedded-dev:~/octeon-staging$ ls -la
total 32
drwxr-xr-x  8 root  root  4096 Jun 18 13:33 .
drwxr-xr-x 29 build build 4096 Jun 18 13:38 ..
drwxr-xr-x  2 root  root  4096 Jun 18 13:33 bin
drwxr-xr-x  5 root  root  4096 Jun 18 13:33 include
drwxr-xr-x  4 root  root  4096 Jun 18 13:33 lib
drwxr-xr-x  6 root  root  4096 Jun 18 13:33 man
drwxr-xr-x  6 root  root  4096 Jun 18 13:31 openssl
drwxr-xr-x  5 root  root  4096 Jun 18 13:33 share
build at embedded-dev:~/octeon-staging$

build at embedded-dev:~/octeon-staging/bin$ ls -la
total 3252
drwxr-xr-x 2 root root    4096 Jun 18 13:33 .
drwxr-xr-x 8 root root    4096 Jun 18 13:33 ..
lrwxrwxrwx 1 root root       3 Jun 18 13:33 captoinfo -> tic
-rwxr-xr-x 1 root root   11703 Jun 18 13:33 clear
-rwxr-xr-x 1 root root    4293 Jun 18 13:31 c_rehash
-rwxr-xr-x 1 root root   66086 Jun 18 13:33 infocmp
lrwxrwxrwx 1 root root       3 Jun 18 13:33 infotocap -> tic
-rwxr-xr-x 1 root root    5309 Jun 18 13:33 ncurses5-config
-rwxr-xr-x 1 root root 3035760 Jun 18 13:31 openssl
-rwxr-xr-x 1 root root    1666 Jun 18 13:33 pcap-config
lrwxrwxrwx 1 root root       4 Jun 18 13:33 reset -> tset
-rwxr-xr-x 1 root root   18620 Jun 18 13:33 tabs
-rwxr-xr-x 1 root root   71738 Jun 18 13:33 tic
-rwxr-xr-x 1 root root   19603 Jun 18 13:33 toe
-rwxr-xr-x 1 root root   20005 Jun 18 13:33 tput
-rwxr-xr-x 1 root root   28790 Jun 18 13:33 tset
build at embedded-dev:~/octeon-staging/bin$ ^C
build at embedded-dev:~/octeon-staging/bin$


build at embedded-dev:~/octeon-staging$ cd lib/
build at embedded-dev:~/octeon-staging/lib$ ls -la
total 14480
drwxr-xr-x 4 root root    4096 Jun 18 13:33 .
drwxr-xr-x 8 root root    4096 Jun 18 13:33 ..
drwxr-xr-x 2 root root    4096 Jun 18 13:31 engines
-rw-r--r-- 1 root root 4897958 Jun 18 13:31 libcrypto.a
-rw-r--r-- 1 root root  168860 Jun 18 13:33 libform.a
-rw-r--r-- 1 root root  877392 Jun 18 13:33 libform_g.a
lrwxrwxrwx 1 root root      12 Jun 18 13:33 libform.so -> libform.so.5
lrwxrwxrwx 1 root root      14 Jun 18 13:33 libform.so.5 -> libform.so.5.9
-rwxr-xr-x 1 root root   96054 Jun 18 13:33 libform.so.5.9
-rw-r--r-- 1 root root   83988 Jun 18 13:33 libmenu.a
-rw-r--r-- 1 root root  511056 Jun 18 13:33 libmenu_g.a
lrwxrwxrwx 1 root root      12 Jun 18 13:33 libmenu.so -> libmenu.so.5
lrwxrwxrwx 1 root root      14 Jun 18 13:33 libmenu.so.5 -> libmenu.so.5.9
-rwxr-xr-x 1 root root   41508 Jun 18 13:33 libmenu.so.5.9
-rw-r--r-- 1 root root  774012 Jun 18 13:33 libncurses.a
-rw-r--r-- 1 root root  207804 Jun 18 13:33 libncurses++.a
-rw-r--r-- 1 root root 3784026 Jun 18 13:33 libncurses_g.a
lrwxrwxrwx 1 root root      15 Jun 18 13:33 libncurses.so -> libncurses.so.5
lrwxrwxrwx 1 root root      17 Jun 18 13:33 libncurses.so.5 -> libncurses.so.5.9
-rwxr-xr-x 1 root root  427273 Jun 18 13:33 libncurses.so.5.9
-rw-r--r-- 1 root root   34954 Jun 18 13:33 libpanel.a
-rw-r--r-- 1 root root  199464 Jun 18 13:33 libpanel_g.a
lrwxrwxrwx 1 root root      13 Jun 18 13:33 libpanel.so -> libpanel.so.5
lrwxrwxrwx 1 root root      15 Jun 18 13:33 libpanel.so.5 -> libpanel.so.5.9
-rwxr-xr-x 1 root root   17718 Jun 18 13:33 libpanel.so.5.9
-rw-r--r-- 1 root root 1110644 Jun 18 13:33 libpcap.a
lrwxrwxrwx 1 root root      12 Jun 18 13:33 libpcap.so -> libpcap.so.1
lrwxrwxrwx 1 root root      16 Jun 18 13:33 libpcap.so.1 -> libpcap.so.1.2.1
-rwxr-xr-x 1 root root  658363 Jun 18 13:33 libpcap.so.1.2.1
-rw-r--r-- 1 root root  821140 Jun 18 13:31 libssl.a
drwxr-xr-x 2 root root    4096 Jun 18 13:31 pkgconfig
lrwxrwxrwx 1 root root      17 Jun 18 13:33 terminfo -> ../share/terminfo
build at embedded-dev:~/octeon-staging/lib$


Thanks,
Kira




From: Kuhn, Thomas J (IS)
Sent: Monday, June 18, 2012 1:21 PM
To: Farney, Kira (IS); xorp-hackers at icir.org
Subject: RE: problems running xorp_rtrmgr and xorpsh

Here is the install lines we are using...


scons install debug=no strip=no enable_tests=yes build=mips64-octeon-linux-gnu \
STRIP=mips64-octeon-linux-gnu-strip \
CC=mips64-octeon-linux-gnu-gcc \
CXX=mips64-octeon-linux-gnu-g++ \
RANLIB=mips64-octeon-linux-gnu-ranlib \
CFLAGS=-I/home/build/octeon-staging/include \
CXXFLAGS=-I/home/build/octeon-staging/include \
LINKFLAGS=-L/home/build/octeon-staging/lib


Tom Kuhn
Office: (407) 737-4953
Cell: (407) 721-0628
tom.kuhn at ngc.com<mailto:tom.kuhn at ngc.com>

From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Farney, Kira (IS)
Sent: Monday, June 18, 2012 10:59 AM
To: xorp-hackers at icir.org
Subject: EXT :[Xorp-hackers] problems running xorp_rtrmgr and xorpsh

Hi All,

We successfully cross compiled XORP and moved it to target board. We put all the libraries to /usr/lib directory and xorp to /usr/local. Here is what's happening when I am trying to run ./xorp_rtrmgr and ./xorpsh. I noticed that it has issues loading the libraries.

I am not an expert in Linux by any means, so I don't know why these errors being generated. Could anyone assist me please. Your help will be greatly appreciated.


/usr/local/xorp/sbin # ./xorp_rtrmgr -b static.boot
Not doing pidfile...
[ 1970/01/05 19:46:01.458317  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/main_rtrmgr.cc:718 main ]

XORP 1.8.5 BuildInfo:
git version: 00000000 built: Tue Jun 12 11:51:39 EDT 2012
By: root on machine: Linux embedded-dev 2.6.32-5-686 i686 unknown
Recent git changes:
Cannot detect, not a git repository
[ 1970/01/05 19:46:01.462235  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/main_rtrmgr.cc:754 main ]
Host Information:
Linux (none) 2.6.32.27-Cavium-Octeon #4 SMP Fri May 11 13:04:17 EDT 2012 mips64 GNU/Linux

[ 1970/01/05 19:46:01.619398  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces, firewall, fea, rib, policy, static_routes
[ 1970/01/05 19:46:01.622125  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces (xorp_fea)
[ 1970/01/05 19:46:01.623088  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:01.623420  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 0  max_retries: 30
xorp_fea: error while loading shared libraries: libpcap.so.1: cannot open shared object file: No such file or directory
[ 1970/01/05 19:46:01.626264  ERROR xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:781 done_cb ] Command "/usr/local/xorp/lib/xorp/sbin/xorp_fea": exited with exit status 127.
[ 1970/01/05 19:46:01.626319  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/module_manager.cc:334 module_exited ] Module abnormal exit: interfaces
[ 1970/01/05 19:46:02.624563  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:02.624874  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 1  max_retries: 30
[ 1970/01/05 19:46:03.626023  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:03.626320  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 2  max_retries: 30
[ 1970/01/05 19:46:04.627482  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:04.627778  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 3  max_retries: 30
[ 1970/01/05 19:46:05.628939  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:05.629234  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 4  max_retries: 30
[ 1970/01/05 19:46:06.630289  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:06.630583  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 5  max_retries: 30
[ 1970/01/05 19:46:07.631747  WARNING xorp_rtrmgr:1057 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/05 19:46:07.632041  WARNING xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 6  max_retries: 30
^C^C^C[ 1970/01/05 19:46:08.470369  INFO xorp_rtrmgr:1057 RTRMGR rtrmgr/task.cc:2242 run_task ] No more tasks to run
^C^C^C^C^CWARNING:  Process: 1057 has message from dflt_sig_handler: SIGINT received
/usr/local/xorp/sbin #


/usr/local/xorp/sbin # ./xorpsh
./xorpsh: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory



Thanks,

Kira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120618/66f69868/attachment-0001.html 

From greearb at candelatech.com  Tue Jun 19 09:16:45 2012
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 19 Jun 2012 09:16:45 -0700
Subject: [Xorp-hackers] problems running xorp_rtrmgr and xorpsh
In-Reply-To: <A1C8FCD880CA9E47BAC11B56E68DA3B2A755EF@XMBVAG73.northgrum.com>
References: <A1C8FCD880CA9E47BAC11B56E68DA3B2A73586@XMBVAG73.northgrum.com>
	<79D1420E63043F44B2039BA7A8A7A2441E8379FB@XMBVAG73.northgrum.com>
	<A1C8FCD880CA9E47BAC11B56E68DA3B2A755EF@XMBVAG73.northgrum.com>
Message-ID: <4FE0A5ED.8000003@candelatech.com>

On 06/18/2012 10:58 AM, Farney, Kira (IS) wrote:
> We rebuilt ncurses, openssl, and libpcap. As and before, we followed the instructions described in BUILD_NOTES. Here is the generated list of the directories
> and their contents.

The 'ldd' tool can be useful for figuring out library
issues.  ldconfig might help.

Setting LD_LIBRARY_PATH shell environment variable might help
if libraries are in a strange place.

> /usr/local/xorp/sbin # ./xorpsh
>
> ./xorpsh: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

Check that libncurses.so.5 actually exists on your system?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From noreply at github.com  Wed Jun 20 08:16:15 2012
From: noreply at github.com (GitHub)
Date: Wed, 20 Jun 2012 08:16:15 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] f01c2e: xorp: rib: Make RouteEntry
	more generic
Message-ID: <4fe1e93f262ae_b831245ae44917d9@sh3.rs.github.com.mail>

  Branch: refs/heads/master
  Home:   https://github.com/greearb/xorp.ct
  Commit: f01c2eb428a588a61eeaefc158d68457a17b5dff
      https://github.com/greearb/xorp.ct/commit/f01c2eb428a588a61eeaefc158d68457a17b5dff
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/route.cc
    M xorp/rib/route.hh

  Log Message:
  -----------
  xorp: rib: Make RouteEntry more generic

Make RouteEntry more generic, by making it templetized.
Move _net and _policitags to this class, because all classes that inherit it are using those fields.

IPRouteEntry overides the nexthop function of RouteEntry with different NextHop type.
To be more specific it overides it with IPNextHop type.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 50a0115b5d74b6c1186be502eb526d3c0451c85c
      https://github.com/greearb/xorp.ct/commit/50a0115b5d74b6c1186be502eb526d3c0451c85c
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_deletion.cc
    M xorp/rib/rt_tab_extint.cc
    M xorp/rib/rt_tab_origin.cc
    M xorp/rib/rt_tab_pol_conn.cc
    M xorp/rib/rt_tab_register.cc

  Log Message:
  -----------
  xorp: rib: Use operator* instead of payload() method for Trie class

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 382fe0b7c71b60e92a97c678f773ed3affa34985
      https://github.com/greearb/xorp.ct/commit/382fe0b7c71b60e92a97c678f773ed3affa34985
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rib.cc
    M xorp/rib/rib.hh
    M xorp/rib/route.cc
    M xorp/rib/route.hh
    M xorp/rib/rt_tab_extint.cc
    M xorp/rib/tests/test_deletion.cc
    M xorp/rib/tests/test_redist.cc

  Log Message:
  -----------
  xorp: rib: templatize RibVif class

Make RibVif's class interface cleaner and easier to understand.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 52b91bad501ee25e9fc3aa343f0bd91caf7bdfcc
      https://github.com/greearb/xorp.ct/commit/52b91bad501ee25e9fc3aa343f0bd91caf7bdfcc
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/libxorp/nexthop.cc
    M xorp/libxorp/nexthop.hh
    M xorp/rib/rib.cc
    M xorp/rib/route.cc
    M xorp/rib/route.hh
    M xorp/rib/rt_tab_extint.cc
    M xorp/rib/rt_tab_register.cc
    M xorp/rib/tests/rt_tab_expect.cc
    M xorp/rib/tests/test_register.cc
    M xorp/rib/xrl_target.cc

  Log Message:
  -----------
  xorp: rib: IPRouteEntry directly return NextHop of appropriate type

IPRouteEntry has member of IPNextHop type. It now returns nexthop of
IPNextHop type, without dynamic_casting.
This alows us to avoid unecesary casting!

DiscardNextHop and UnreachableNextHop directly inherit from
IPNextHop.

Passed all rib tests.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 3b95bf9e585aa2e7db15d300bb1a8138e150862e
      https://github.com/greearb/xorp.ct/commit/3b95bf9e585aa2e7db15d300bb1a8138e150862e
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rib_manager.cc
    M xorp/rib/rib_manager.hh

  Log Message:
  -----------
  xorp: rib: Make helper functions be static RibManager members

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 22dcc5f392d8a6904afc95967032f6c6b568cc43
      https://github.com/greearb/xorp.ct/commit/22dcc5f392d8a6904afc95967032f6c6b568cc43
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_pol_redist.cc
    M xorp/rib/rt_tab_pol_redist.hh

  Log Message:
  -----------
  xorp: rib: Templatize PolicyRedistTable by introducing PolicyRedistClient

PolicyRedistClient is template class. It is used as wrapper for XrlPolicyRedist4V0p1Client
and XrlPolicyRedist6V0p1Client, for now, to call send_delete_route{4, 6} and send_add_route{4, 6}
uniformerly by calling functions send_delete_route and send_add_route.

By doing that we don't need to specialize add_redist and delete_redist functions.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: c17cb1d51c7f195039b55497fb7c9acd32d3454b
      https://github.com/greearb/xorp.ct/commit/c17cb1d51c7f195039b55497fb7c9acd32d3454b
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_extint.cc
    M xorp/rib/rt_tab_extint.hh

  Log Message:
  -----------
  xorp: rib: Fix memory leak in ExtIntTable

Add destructor that frees all entries from _ip_unresolved_table
and _ip_route_table.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 688a54af12c9f5a2e7a5c3087d341b02eb15dece
      https://github.com/greearb/xorp.ct/commit/688a54af12c9f5a2e7a5c3087d341b02eb15dece
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_register.cc
    M xorp/rib/rt_tab_register.hh

  Log Message:
  -----------
  xorp: rib: Fix memory leak in RegisterTable

Added destructor that frees all entries from _ipregistry.
Also in function register_route_range, route range obtained with
lookup_route_range is freed.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 861cc3b7821cd95cf31e58ebb57aadf5d262f5ea
      https://github.com/greearb/xorp.ct/commit/861cc3b7821cd95cf31e58ebb57aadf5d262f5ea
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_pol_redist.cc

  Log Message:
  -----------
  xorp: rib: Implemented PolicyRedistTable<A>::str()

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: c097f9bcc8b62300b6a85b15149ddd4b26932b69
      https://github.com/greearb/xorp.ct/commit/c097f9bcc8b62300b6a85b15149ddd4b26932b69
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rt_tab_pol_conn.cc

  Log Message:
  -----------
  xorp: rib: Implemented PolicyConnectedTable<A>::str()

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: b3b40367c6c8ac921f6a7ccf7d51ecb75c9ab520
      https://github.com/greearb/xorp.ct/commit/b3b40367c6c8ac921f6a7ccf7d51ecb75c9ab520
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rib.cc
    M xorp/rib/rib.hh

  Log Message:
  -----------
  xorp: rib: Efficient handling of route tables

All route tables aren't stored any more in one large list. Instead,
each route table, that can have multiple instances in RIB,
has it's own map.
That's why we have MergedTable map, RedistTable map and
OriginTable map.
To provide faster lookup of OriginTables OriginTable map is
splited in two maps - IGP OriginTable map and EGP OriginTable map.

Each route table map has it's own apropriate function for
searching RoutTable entry. OriginTable map has three lookup
functions. One global search function, and one for IGP and EGP maps.
Tables are added in appropriate via overloaded add_route function.

Because we can have only one instance of RegisterTable,
PolicyRedistTable, PolicyConnectedTable and ExtIntTable, they
aren't stored in maps. They are saved as class members.

In code, find_table is replaced with apropriate
find_{origin, igp_origin, egp_origin, merged, redist} calls.
That way a lot of dynamic_cast is avoided!

print_rib() method is pretified, so it would print RoutTables
as they are stored now.

All rib tests passed.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: af6c6a08f15192a72deb5965a51bbc09577c0128
      https://github.com/greearb/xorp.ct/commit/af6c6a08f15192a72deb5965a51bbc09577c0128
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rib.cc
    M xorp/rib/rib.hh

  Log Message:
  -----------
  xorp: rib: Split add_origin_table into smaller units

Added four new functions:
plumb_origin_table - checks existing tables and plumbs origin
table appropriately
plumb_ahead_of_first - plumbs origin table ahead of first
existing table in tree
plumb_ahead_of_merged - creates Merged table and plumbs origin
table ahead of merged table.
plumb_ahead_of_ext_int - creates ExtInt table and plumbs origin
table ahead of ExtInt table

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 4e28909afd43e4a91ec7b1c107953233f319d899
      https://github.com/greearb/xorp.ct/commit/4e28909afd43e4a91ec7b1c107953233f319d899
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rib.cc
    M xorp/rib/rib.hh

  Log Message:
  -----------
  xorp: rib: Make add_route more efficient

When looking if the route is directly connected or not, we only need
to look in connected OriginTable. For that reason, save that table
in a pointer and perform lookup directly in that table.
If the route is not found in connected origin table, we don't need
to loop through all vifs, because vif addresses are dinamically
added/removed from the connected table. Also removed
find_vif(const A& addr) because it isn't used any more.
Connected routes are added directly to vif - no need to loop
through existing vifs!
Passed all tests.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: a889afecca6c87c03018a185d4d976b59660b789
      https://github.com/greearb/xorp.ct/commit/a889afecca6c87c03018a185d4d976b59660b789
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/rib.cc
    M xorp/rib/rt_tab_origin.cc
    M xorp/rib/rt_tab_origin.hh
    M xorp/rib/tests/test_deletion.cc
    M xorp/rib/tests/test_redist.cc

  Log Message:
  -----------
  xorp: rib: Make OriginTable::add_route() more efficient

Instead of passing the reference to route, we pass
route pointer
This way of passing is more efficient because we only have to call
one IPRouteEntryConstructor instead of two.
Pointer shouldn't be changed after it was passed to this function.

Passed all rib tests.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 93642a97a961de113217c7abe8b712587605ca76
      https://github.com/greearb/xorp.ct/commit/93642a97a961de113217c7abe8b712587605ca76
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/tests/test_register.cc

  Log Message:
  -----------
  xorp: rib: Fixed register test

Checking of verifytype in test_route_range was wrong.
If we got route check if we expected it.
If we got the Discard, or Unreachable, route, don't need to
check any more.
If we didn't go the route check if we expected the miss.

Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: 3cf0a20b6c238a6e4c46041eb4c8512a099be56c
      https://github.com/greearb/xorp.ct/commit/3cf0a20b6c238a6e4c46041eb4c8512a099be56c
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/etc/templates/policy.tp
    M xorp/policy/common/element.cc

  Log Message:
  -----------
  xorp: policy: Fix usage of network{4,6}-lists

Add '~' as string distguisher, instead of ' '.
Also add posible completions to policy template.

Reported-by: Jens Dackenberg <jens.devel at gmail.com>
Signed-off-by: Igor Maravic <igorm at etf.rs>


  Commit: a805f4d4e2503cdf5166b5db73822bf764bb1101
      https://github.com/greearb/xorp.ct/commit/a805f4d4e2503cdf5166b5db73822bf764bb1101
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
    M xorp/rib/parser.hh
    M xorp/rib/parser_direct_cmds.hh

  Log Message:
  -----------
  trivial: ws fixes


  Commit: ca6b94e6b0b4ab861aa18a98e541fe1c4e9bc098
      https://github.com/greearb/xorp.ct/commit/ca6b94e6b0b4ab861aa18a98e541fe1c4e9bc098
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/rib/parser.hh
    M xorp/rib/parser_direct_cmds.hh
    M xorp/rib/parser_xrl_cmds.hh
    M xorp/rib/tests/commands
    M xorp/rib/tests/test_rib_direct.cc
    M xorp/rib/tests/test_rib_xrls.cc

  Log Message:
  -----------
  xorp: rib: Add commands for testing adding and deleting of interface routes


  Commit: 6caf1480ec15714f095d30dd1bdccd7000db2668
      https://github.com/greearb/xorp.ct/commit/6caf1480ec15714f095d30dd1bdccd7000db2668
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc

  Log Message:
  -----------
  xorp: fea: data_plane: fibconfig: Fix using of rtmsg scope parameter

When the route doesn't have the specified gateway or nexthop it's scope should be link(RT_SCOPE_LINK).
Otherwise it should be global(RT_SCOPE_UNIVERSE).

Referenced from iproute2.


  Commit: 35d66f2aa672686534b2c881770e200cc4e0d689
      https://github.com/greearb/xorp.ct/commit/35d66f2aa672686534b2c881770e200cc4e0d689
  Author: Igor Maravic <igorm at etf.rs>
  Date:   2012-06-20 (Wed, 20 Jun 2012)

  Changed paths:
    M xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc

  Log Message:
  -----------
  xorp: fea: data_plane: fibconfig: Fix using of rtmsg scope parameter in delete_entry

When deleting route we should use RT_SCOPE_NOWHERE instead of RT_SCOPE_UNIVERSE.

Reported-by: Jiangxin Hu <jiangxin.hu at crc.gc.ca>


Compare: https://github.com/greearb/xorp.ct/compare/ca06dac68f92...35d66f2aa672

From greearb at candelatech.com  Wed Jun 20 10:06:04 2012
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 20 Jun 2012 10:06:04 -0700
Subject: [Xorp-hackers] [xorp.ct] My 35 new commits (#106)
In-Reply-To: <CAFdo_mW1mCWak3mJTSosHREmWp2ST992J5LHMc2Cdw5bGcEY-g@mail.gmail.com>
References: <greearb/xorp.ct/pull/106@github.com>
	<greearb/xorp.ct/pull/106/c6295031@github.com>
	<4FDA21CA.3060400@candelatech.com>
	<4FDF8ACA.2070203@candelatech.com>
	<CAFdo_mUfeQO_8=fk_CFuzDPr25mgqk_p6vU45qiw84FE2S2m2A@mail.gmail.com>
	<4FE0C048.7080503@candelatech.com>
	<CAFdo_mW1mCWak3mJTSosHREmWp2ST992J5LHMc2Cdw5bGcEY-g@mail.gmail.com>
Message-ID: <4FE202FC.7030101@candelatech.com>

On 06/20/2012 08:04 AM, Igor Maravi? wrote:
> Hi Ben,
>
> git pull --rebase ...
> git push -f
>
> did the trick. :)
> Now in the pull requests all commits, that are after the changed
> commit are shown.

I notice that there are some new failures in build-bot after pushing
your changes.  Do you have a chance to take a look at them?

http://dmz2.candelatech.com:8010/waterfall


old failures:
./test_peering1.sh: Tests Failed (BGP: test26)
./test_peering1.sh: Tests Failed (BGP: test26)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
Total test failures: 6

new failures:
./test_peering1.sh: Tests Failed (BGP: test26)
./test_peering1.sh: Tests Failed (BGP: test26)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
./test_rib1.sh: Tests Failed (BGP/RIB: test7)
./test_rib1.sh: Tests Failed (BGP/RIB: test7)
./test_rib1.sh: Tests Failed (BGP/RIB: test1 test1_ipv6 test2 test3 test4 test5 test6 test7 test8 test9 test10)
./test_rib_fea1.sh: Tests Failed (BGP/FEA: test2)
./test_rib_fea1.sh: Tests Failed (BGP/FEA: test2)
./test_rib_fea1.sh: Tests Failed (BGP/FEA: test1 test1_ipv6 test2 test2_ipv6 test3 test4 test5 test6)
Total test failures: 12

Thanks,
Ben

>
> Is that ok?
>
> BR
> Igor


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From igorm at etf.rs  Thu Jun 21 08:03:39 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Thu, 21 Jun 2012 15:03:39 +0000
Subject: [Xorp-hackers] [xorp.ct] My 35 new commits (#106)
In-Reply-To: <4FE202FC.7030101@candelatech.com>
References: <greearb/xorp.ct/pull/106@github.com>
	<greearb/xorp.ct/pull/106/c6295031@github.com>
	<4FDA21CA.3060400@candelatech.com>
	<4FDF8ACA.2070203@candelatech.com>
	<CAFdo_mUfeQO_8=fk_CFuzDPr25mgqk_p6vU45qiw84FE2S2m2A@mail.gmail.com>
	<4FE0C048.7080503@candelatech.com>
	<CAFdo_mW1mCWak3mJTSosHREmWp2ST992J5LHMc2Cdw5bGcEY-g@mail.gmail.com>
	<4FE202FC.7030101@candelatech.com>
Message-ID: <CAFdo_mVtb-fsgf0+pYzyQmPoHuRfZgDaneoHaahpwUnHy1x9fw@mail.gmail.com>

I will certainly take a look at them.
Unfortunately I don't have much time, so I can't promise any fixes
before Thursday.
BR
Igor

2012/6/20 Ben Greear <greearb at candelatech.com>:
> On 06/20/2012 08:04 AM, Igor Maravi? wrote:
>>
>> Hi Ben,
>>
>> git pull --rebase ...
>> git push -f
>>
>> did the trick. :)
>> Now in the pull requests all commits, that are after the changed
>> commit are shown.
>
>
> I notice that there are some new failures in build-bot after pushing
> your changes. ?Do you have a chance to take a look at them?
>
> http://dmz2.candelatech.com:8010/waterfall
>
>
> old failures:
> ./test_peering1.sh: Tests Failed (BGP: test26)
> ./test_peering1.sh: Tests Failed (BGP: test26)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
> Total test failures: 6
>
> new failures:
> ./test_peering1.sh: Tests Failed (BGP: test26)
> ./test_peering1.sh: Tests Failed (BGP: test26)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
> ./test_peering1.sh: Tests Failed (BGP: test28_ipv6_ok)
> ./test_rib1.sh: Tests Failed (BGP/RIB: test7)
> ./test_rib1.sh: Tests Failed (BGP/RIB: test7)
> ./test_rib1.sh: Tests Failed (BGP/RIB: test1 test1_ipv6 test2 test3 test4
> test5 test6 test7 test8 test9 test10)
> ./test_rib_fea1.sh: Tests Failed (BGP/FEA: test2)
> ./test_rib_fea1.sh: Tests Failed (BGP/FEA: test2)
> ./test_rib_fea1.sh: Tests Failed (BGP/FEA: test1 test1_ipv6 test2 test2_ipv6
> test3 test4 test5 test6)
> Total test failures: 12
>
> Thanks,
> Ben
>
>>
>> Is that ok?
>>
>> BR
>> Igor
>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>


From greearb at candelatech.com  Thu Jun 21 08:10:49 2012
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 21 Jun 2012 08:10:49 -0700
Subject: [Xorp-hackers] [xorp.ct] My 35 new commits (#106)
In-Reply-To: <CAFdo_mVtb-fsgf0+pYzyQmPoHuRfZgDaneoHaahpwUnHy1x9fw@mail.gmail.com>
References: <greearb/xorp.ct/pull/106@github.com>
	<greearb/xorp.ct/pull/106/c6295031@github.com>
	<4FDA21CA.3060400@candelatech.com>
	<4FDF8ACA.2070203@candelatech.com>
	<CAFdo_mUfeQO_8=fk_CFuzDPr25mgqk_p6vU45qiw84FE2S2m2A@mail.gmail.com>
	<4FE0C048.7080503@candelatech.com>
	<CAFdo_mW1mCWak3mJTSosHREmWp2ST992J5LHMc2Cdw5bGcEY-g@mail.gmail.com>
	<4FE202FC.7030101@candelatech.com>
	<CAFdo_mVtb-fsgf0+pYzyQmPoHuRfZgDaneoHaahpwUnHy1x9fw@mail.gmail.com>
Message-ID: <4FE33979.5030208@candelatech.com>

On 06/21/2012 08:03 AM, Igor Maravi? wrote:
> I will certainly take a look at them.
> Unfortunately I don't have much time, so I can't promise any fixes
> before Thursday.
> BR
> Igor

Ok.  It would take a while, but could probably 'git bisect' the problem
without too much trouble since there were only 20 or so commits in that
last push.

I didn't look at exactly what the tests were complaining about though,
maybe the problem is obvious with some study of that output...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From igorm at etf.rs  Thu Jun 21 08:17:18 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Thu, 21 Jun 2012 15:17:18 +0000
Subject: [Xorp-hackers] [xorp.ct] My 35 new commits (#106)
In-Reply-To: <4FE33979.5030208@candelatech.com>
References: <greearb/xorp.ct/pull/106@github.com>
	<greearb/xorp.ct/pull/106/c6295031@github.com>
	<4FDA21CA.3060400@candelatech.com>
	<4FDF8ACA.2070203@candelatech.com>
	<CAFdo_mUfeQO_8=fk_CFuzDPr25mgqk_p6vU45qiw84FE2S2m2A@mail.gmail.com>
	<4FE0C048.7080503@candelatech.com>
	<CAFdo_mW1mCWak3mJTSosHREmWp2ST992J5LHMc2Cdw5bGcEY-g@mail.gmail.com>
	<4FE202FC.7030101@candelatech.com>
	<CAFdo_mVtb-fsgf0+pYzyQmPoHuRfZgDaneoHaahpwUnHy1x9fw@mail.gmail.com>
	<4FE33979.5030208@candelatech.com>
Message-ID: <CAFdo_mXoaKJxxKrom0Hdu7iMAMOFAcLwnESE1ZnFNGTTRYc-kg@mail.gmail.com>

That would be helpful.

I couldn't start up the test today. I had the problem with library
dependencies of test_peer and coord binaries.
I examined their SConstruct and I saw that there is RPATH missing.

How do you start BGP harness tests?

Are all dependencies that are written in .sh file necessary (Like
starting of BGP, FEA...)?
BR
Igor

2012/6/21 Ben Greear <greearb at candelatech.com>:
> On 06/21/2012 08:03 AM, Igor Maravi? wrote:
>>
>> I will certainly take a look at them.
>> Unfortunately I don't have much time, so I can't promise any fixes
>> before Thursday.
>> BR
>> Igor
>
>
> Ok. ?It would take a while, but could probably 'git bisect' the problem
> without too much trouble since there were only 20 or so commits in that
> last push.
>
> I didn't look at exactly what the tests were complaining about though,
> maybe the problem is obvious with some study of that output...
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>


From greearb at candelatech.com  Thu Jun 21 08:21:05 2012
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 21 Jun 2012 08:21:05 -0700
Subject: [Xorp-hackers] [xorp.ct] My 35 new commits (#106)
In-Reply-To: <CAFdo_mXoaKJxxKrom0Hdu7iMAMOFAcLwnESE1ZnFNGTTRYc-kg@mail.gmail.com>
References: <greearb/xorp.ct/pull/106@github.com>
	<greearb/xorp.ct/pull/106/c6295031@github.com>
	<4FDA21CA.3060400@candelatech.com>
	<4FDF8ACA.2070203@candelatech.com>
	<CAFdo_mUfeQO_8=fk_CFuzDPr25mgqk_p6vU45qiw84FE2S2m2A@mail.gmail.com>
	<4FE0C048.7080503@candelatech.com>
	<CAFdo_mW1mCWak3mJTSosHREmWp2ST992J5LHMc2Cdw5bGcEY-g@mail.gmail.com>
	<4FE202FC.7030101@candelatech.com>
	<CAFdo_mVtb-fsgf0+pYzyQmPoHuRfZgDaneoHaahpwUnHy1x9fw@mail.gmail.com>
	<4FE33979.5030208@candelatech.com>
	<CAFdo_mXoaKJxxKrom0Hdu7iMAMOFAcLwnESE1ZnFNGTTRYc-kg@mail.gmail.com>
Message-ID: <4FE33BE1.5080300@candelatech.com>

On 06/21/2012 08:17 AM, Igor Maravi? wrote:
> That would be helpful.
>
> I couldn't start up the test today. I had the problem with library
> dependencies of test_peer and coord binaries.
> I examined their SConstruct and I saw that there is RPATH missing.
>
> How do you start BGP harness tests?
>
> Are all dependencies that are written in .sh file necessary (Like
> starting of BGP, FEA...)?

I think it's just something like:

scons check

at the top level.  It's been a long time since I poked at it,
and I'm not sure how to run tests for just a certain module.

You do have to start the fea module and such to run the tests,
but the scripts should take care of that.

Thanks,
Ben

> BR
> Igor
>
> 2012/6/21 Ben Greear<greearb at candelatech.com>:
>> On 06/21/2012 08:03 AM, Igor Maravi? wrote:
>>>
>>> I will certainly take a look at them.
>>> Unfortunately I don't have much time, so I can't promise any fixes
>>> before Thursday.
>>> BR
>>> Igor
>>
>>
>> Ok.  It would take a while, but could probably 'git bisect' the problem
>> without too much trouble since there were only 20 or so commits in that
>> last push.
>>
>> I didn't look at exactly what the tests were complaining about though,
>> maybe the problem is obvious with some study of that output...
>>
>> Thanks,
>> Ben
>>
>>
>> --
>> Ben Greear<greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From Kira.Farney at ngc.com  Mon Jun 25 10:26:00 2012
From: Kira.Farney at ngc.com (Farney, Kira (IS))
Date: Mon, 25 Jun 2012 17:26:00 +0000
Subject: [Xorp-hackers] Is xorp running?
Message-ID: <A1C8FCD880CA9E47BAC11B56E68DA3B2A769F3@XMBVAG73.northgrum.com>

Hi All,

I am not sure if xorp is up and running. Here is the log when I try running it. My config file is also included below. I can ping a host from the development board, but when I ping two hosts being on different networks it says "Destination host unreachable". I am not sure why.
Can anyone help me out here please?



./xorp_rtrmgr -b static.boot
Not doing pidfile...
[ 1970/01/06 02:30:35.218501  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/main_rtrmgr.cc:718 main ]

XORP 1.8.5 BuildInfo:
git version: 00000000 built: Tue Jun 19 10:32:36 EDT 2012
By: root on machine: Linux embedded-dev 2.6.32-5-686 i686 unknown
Recent git changes:
Cannot detect, not a git repository
[ 1970/01/06 02:30:35.222455  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/main_rtrmgr.cc:754 main ]
Host Information:
Linux (none) 2.6.32.27-Cavium-Octeon #4 SMP Fri May 11 13:04:17 EDT 2012 mips64 GNU/Linux

[ 1970/01/06 02:30:35.379938  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces, firewall, fea, rib, policy, static_routes
[ 1970/01/06 02:30:35.382678  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces (xorp_fea)
[ 1970/01/06 02:30:35.383658  WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
[ 1970/01/06 02:30:35.383989  WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 0  max_retries: 30
[ 1970/01/06 02:30:36.389045  INFO xorp_fea:1945 MFEA fea/mfea_node.cc:295 enable ] MFEA enabled
[ 1970/01/06 02:30:36.389442  INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 1970/01/06 02:30:36.390207  INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:92 start ] CLI started
[ 1970/01/06 02:30:36.390308  INFO xorp_fea:1945 MFEA fea/mfea_node.cc:295 enable ] MFEA enabled
[ 1970/01/06 02:30:36.390404  INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 1970/01/06 02:30:36.390666  INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:92 start ] CLI started
[ 1970/01/06 02:30:36.415970  WARNING xorp_fea:1945 FEA fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149 try_read_config_one ] NOTE:  Netlink get single network device works on this system.
[ 1970/01/06 02:30:36.424249  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: firewall (xorp_fea)
[ 1970/01/06 02:30:36.425733  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: fea (xorp_fea)
[ 1970/01/06 02:30:36.427727  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: rib (xorp_rib)
[ 1970/01/06 02:30:36.428345  WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does not exist or is not enabled.
[ 1970/01/06 02:30:36.428627  WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 0  max_retries: 30
[ 1970/01/06 02:30:37.431879  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: policy (xorp_policy)
[ 1970/01/06 02:30:37.432586  WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "policy" does not exist or is not enabled.
[ 1970/01/06 02:30:37.432876  WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 0  max_retries: 30
[ 1970/01/06 02:30:38.436423  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: static_routes (xorp_static_routes)
[ 1970/01/06 02:30:38.437135  WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "static_routes" does not exist or is not enabled.
[ 1970/01/06 02:30:38.437427  WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed  retries: 0  max_retries: 30
[ 1970/01/06 02:30:39.444492  INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:2242 run_task ] No more tasks to run





/usr/local/xorp/sbin # ./xorpsh
Invalid window width (0); window width unchanged (80)

Invalid window height (0); window height unchanged (25)

Welcome to XORP v1.8.5 on (none)

Version tag: 00000000  Build Date: 2012-06-19 10:32 64-bit

root@(none)>




static.boot configuration file:


/* $XORP$ */

interfaces {
    interface eth0 {
      vif eth0 {
          address 192.168.0.10 {
            prefix-length: 24
          }
      }
    }
    interface eth1 {
      vif eth1 {
          address 192.168.10.10 {
            prefix-length: 24
          }
      }
    }
}

fea {
    unicast-forwarding4 {
      disable: false
    }
}

protocols {
    static {
      route 192.168.0.50/24 {
          next-hop: 192.168.10.10
      }
    }
}



Thanks,

Kira



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20120625/f92a8d9b/attachment-0001.html 

From greearb at candelatech.com  Mon Jun 25 10:31:20 2012
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 25 Jun 2012 10:31:20 -0700
Subject: [Xorp-hackers] Is xorp running?
In-Reply-To: <A1C8FCD880CA9E47BAC11B56E68DA3B2A769F3@XMBVAG73.northgrum.com>
References: <A1C8FCD880CA9E47BAC11B56E68DA3B2A769F3@XMBVAG73.northgrum.com>
Message-ID: <4FE8A068.6080808@candelatech.com>

On 06/25/2012 10:26 AM, Farney, Kira (IS) wrote:
> Hi All,
>
> I am not sure if xorp is up and running. Here is the log when I try running it. My config file is also included below. I can ping a host from the development
> board, but when I ping two hosts being on different networks it says ?Destination host unreachable?. I am not sure why.
>
> Can anyone help me out here please?

Looks like it is running.  You can use 'ps' to see the xorp processes.

And, xorpsh will complain if it cannot connect to the rtr-mgr.

You can inspect routes through xorp, and you can also look at
the linux routing table from the linux command line with something
like 'ip route show'.

Thanks,
Ben

>
> ./xorp_rtrmgr -b static.boot
>
> Not doing pidfile...
>
> [ 1970/01/06 02:30:35.218501 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/main_rtrmgr.cc:718 main ]
>
> XORP 1.8.5 BuildInfo:
>
> git version: 00000000 built: Tue Jun 19 10:32:36 EDT 2012
>
> By: root on machine: Linux embedded-dev 2.6.32-5-686 i686 unknown
>
> Recent git changes:
>
> Cannot detect, not a git repository
>
> [ 1970/01/06 02:30:35.222455 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/main_rtrmgr.cc:754 main ]
>
> Host Information:
>
> Linux (none) 2.6.32.27-Cavium-Octeon #4 SMP Fri May 11 13:04:17 EDT 2012 mips64 GNU/Linux
>
> [ 1970/01/06 02:30:35.379938 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces, firewall, fea, rib, policy,
> static_routes
>
> [ 1970/01/06 02:30:35.382678 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces (xorp_fea)
>
> [ 1970/01/06 02:30:35.383658 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:35.383989 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:36.389045 INFO xorp_fea:1945 MFEA fea/mfea_node.cc:295 enable ] MFEA enabled
>
> [ 1970/01/06 02:30:36.389442 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:126 enable ] CLI enabled
>
> [ 1970/01/06 02:30:36.390207 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:92 start ] CLI started
>
> [ 1970/01/06 02:30:36.390308 INFO xorp_fea:1945 MFEA fea/mfea_node.cc:295 enable ] MFEA enabled
>
> [ 1970/01/06 02:30:36.390404 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:126 enable ] CLI enabled
>
> [ 1970/01/06 02:30:36.390666 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:92 start ] CLI started
>
> [ 1970/01/06 02:30:36.415970 WARNING xorp_fea:1945 FEA fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149 try_read_config_one ] NOTE: Netlink get single
> network device works on this system.
>
> [ 1970/01/06 02:30:36.424249 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: firewall (xorp_fea)
>
> [ 1970/01/06 02:30:36.425733 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: fea (xorp_fea)
>
> [ 1970/01/06 02:30:36.427727 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: rib (xorp_rib)
>
> [ 1970/01/06 02:30:36.428345 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:36.428627 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:37.431879 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: policy (xorp_policy)
>
> [ 1970/01/06 02:30:37.432586 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "policy" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:37.432876 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:38.436423 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: static_routes (xorp_static_routes)
>
> [ 1970/01/06 02:30:38.437135 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "static_routes" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:38.437427 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:39.444492 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:2242 run_task ] No more tasks to run
>
> /usr/local/xorp/sbin # ./xorpsh
>
> Invalid window width (0); window width unchanged (80)
>
> Invalid window height (0); window height unchanged (25)
>
> Welcome to XORP v1.8.5 on (none)
>
> Version tag: 00000000 Build Date: 2012-06-19 10:32 64-bit
>
> root@(none)>
>
> static.boot configuration file:
>
> /* $XORP$ */
>
> interfaces {
>
> interface eth0 {
>
> vif eth0 {
>
> address 192.168.0.10 {
>
> prefix-length: 24
>
> }
>
> }
>
> }
>
> interface eth1 {
>
> vif eth1 {
>
> address 192.168.10.10 {
>
> prefix-length: 24
>
> }
>
> }
>
> }
>
> }
>
> fea {
>
> unicast-forwarding4 {
>
> disable: false
>
> }
>
> }
>
> protocols {
>
> static {
>
> route 192.168.0.50/24 {
>
> next-hop: 192.168.10.10
>
> }
>
> }
>
> }
>
> Thanks,
>
> Kira
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From Kira.Farney at ngc.com  Mon Jun 25 10:42:32 2012
From: Kira.Farney at ngc.com (Farney, Kira (IS))
Date: Mon, 25 Jun 2012 17:42:32 +0000
Subject: [Xorp-hackers] EXT :Re:  Is xorp running?
In-Reply-To: <4FE8A068.6080808@candelatech.com>
References: <A1C8FCD880CA9E47BAC11B56E68DA3B2A769F3@XMBVAG73.northgrum.com>
	<4FE8A068.6080808@candelatech.com>
Message-ID: <A1C8FCD880CA9E47BAC11B56E68DA3B2A76A19@XMBVAG73.northgrum.com>

I will try that. Thanks a lot, Ben.





-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Monday, June 25, 2012 1:31 PM
To: Farney, Kira (IS)
Cc: xorp-hackers at icir.org
Subject: EXT :Re: [Xorp-hackers] Is xorp running?

On 06/25/2012 10:26 AM, Farney, Kira (IS) wrote:
> Hi All,
>
> I am not sure if xorp is up and running. Here is the log when I try running it. My config file is also included below. I can ping a host from the development
> board, but when I ping two hosts being on different networks it says "Destination host unreachable". I am not sure why.
>
> Can anyone help me out here please?

Looks like it is running.  You can use 'ps' to see the xorp processes.

And, xorpsh will complain if it cannot connect to the rtr-mgr.

You can inspect routes through xorp, and you can also look at
the linux routing table from the linux command line with something
like 'ip route show'.

Thanks,
Ben

>
> ./xorp_rtrmgr -b static.boot
>
> Not doing pidfile...
>
> [ 1970/01/06 02:30:35.218501 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/main_rtrmgr.cc:718 main ]
>
> XORP 1.8.5 BuildInfo:
>
> git version: 00000000 built: Tue Jun 19 10:32:36 EDT 2012
>
> By: root on machine: Linux embedded-dev 2.6.32-5-686 i686 unknown
>
> Recent git changes:
>
> Cannot detect, not a git repository
>
> [ 1970/01/06 02:30:35.222455 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/main_rtrmgr.cc:754 main ]
>
> Host Information:
>
> Linux (none) 2.6.32.27-Cavium-Octeon #4 SMP Fri May 11 13:04:17 EDT 2012 mips64 GNU/Linux
>
> [ 1970/01/06 02:30:35.379938 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces, firewall, fea, rib, policy,
> static_routes
>
> [ 1970/01/06 02:30:35.382678 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: interfaces (xorp_fea)
>
> [ 1970/01/06 02:30:35.383658 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:35.383989 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:36.389045 INFO xorp_fea:1945 MFEA fea/mfea_node.cc:295 enable ] MFEA enabled
>
> [ 1970/01/06 02:30:36.389442 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:126 enable ] CLI enabled
>
> [ 1970/01/06 02:30:36.390207 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:92 start ] CLI started
>
> [ 1970/01/06 02:30:36.390308 INFO xorp_fea:1945 MFEA fea/mfea_node.cc:295 enable ] MFEA enabled
>
> [ 1970/01/06 02:30:36.390404 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:126 enable ] CLI enabled
>
> [ 1970/01/06 02:30:36.390666 INFO xorp_fea:1945 MFEA fea/mfea_node_cli.cc:92 start ] CLI started
>
> [ 1970/01/06 02:30:36.415970 WARNING xorp_fea:1945 FEA fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:149 try_read_config_one ] NOTE: Netlink get single
> network device works on this system.
>
> [ 1970/01/06 02:30:36.424249 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: firewall (xorp_fea)
>
> [ 1970/01/06 02:30:36.425733 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: fea (xorp_fea)
>
> [ 1970/01/06 02:30:36.427727 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: rib (xorp_rib)
>
> [ 1970/01/06 02:30:36.428345 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:36.428627 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:37.431879 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: policy (xorp_policy)
>
> [ 1970/01/06 02:30:37.432586 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "policy" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:37.432876 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:38.436423 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/module_manager.cc:101 execute ] Executing module: static_routes (xorp_static_routes)
>
> [ 1970/01/06 02:30:38.437135 WARNING xorp_rtrmgr:1942 XrlFinderTarget obj/mips64-octeon-linux-gnu/xrl/targets/finder_base.cc:1135 handle_finder_0_2_resolve_xrl
> ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "static_routes" does not exist or is not enabled.
>
> [ 1970/01/06 02:30:38.437427 WARNING xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve failed retries: 0
> max_retries: 30
>
> [ 1970/01/06 02:30:39.444492 INFO xorp_rtrmgr:1942 RTRMGR rtrmgr/task.cc:2242 run_task ] No more tasks to run
>
> /usr/local/xorp/sbin # ./xorpsh
>
> Invalid window width (0); window width unchanged (80)
>
> Invalid window height (0); window height unchanged (25)
>
> Welcome to XORP v1.8.5 on (none)
>
> Version tag: 00000000 Build Date: 2012-06-19 10:32 64-bit
>
> root@(none)>
>
> static.boot configuration file:
>
> /* $XORP$ */
>
> interfaces {
>
> interface eth0 {
>
> vif eth0 {
>
> address 192.168.0.10 {
>
> prefix-length: 24
>
> }
>
> }
>
> }
>
> interface eth1 {
>
> vif eth1 {
>
> address 192.168.10.10 {
>
> prefix-length: 24
>
> }
>
> }
>
> }
>
> }
>
> fea {
>
> unicast-forwarding4 {
>
> disable: false
>
> }
>
> }
>
> protocols {
>
> static {
>
> route 192.168.0.50/24 {
>
> next-hop: 192.168.10.10
>
> }
>
> }
>
> }
>
> Thanks,
>
> Kira
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From igorm at etf.rs  Fri Jun 29 11:38:03 2012
From: igorm at etf.rs (igorm at etf.rs)
Date: Fri, 29 Jun 2012 20:38:03 +0200
Subject: [Xorp-hackers] [PATCH] xorp: rib: Key for saving resolved route
	entries isn't pointer to IPRouteEntry any more, it's IPNet
In-Reply-To: <igorm@etf.rs>
References: <igorm@etf.rs>
Message-ID: <1340995083-16033-1-git-send-email-igorm@etf.rs>

From: Igor Maravic <igorm at etf.rs>

When the connected route is deleted, it's first deleted in PolicyConnectedTable and then after that
it's propagated (as different pointer) to other tables.
If the external route is resolved to connected nexthop, and the connected nexthop is deleted,
problem occures because we can't delete the resolved nexthop, because we're searching with different pointer.

Passed all BGP and RIB tests.

Signed-off-by: Igor Maravic <igorm at etf.rs>
---
 xorp/rib/route.hh         |    2 +-
 xorp/rib/rt_tab_extint.cc |   40 ++++++++++++++++++++--------------------
 xorp/rib/rt_tab_extint.hh |    6 +++---
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/xorp/rib/route.hh b/xorp/rib/route.hh
index 4f82b86..09b4621 100644
--- a/xorp/rib/route.hh
+++ b/xorp/rib/route.hh
@@ -256,7 +256,7 @@ typedef IPRouteEntry<IPv6> IPv6RouteEntry;
 template <class A>
 class ResolvedIPRouteEntry : public IPRouteEntry<A> {
 public:
-    typedef multimap<const IPRouteEntry<A>* , ResolvedIPRouteEntry<A>* > RouteBackLink;
+    typedef multimap<const IPNet<A> , ResolvedIPRouteEntry<A>* > RouteBackLink;
 
 public:
     /**
diff --git a/xorp/rib/rt_tab_extint.cc b/xorp/rib/rt_tab_extint.cc
index 59ec9e3..a8afef8 100644
--- a/xorp/rib/rt_tab_extint.cc
+++ b/xorp/rib/rt_tab_extint.cc
@@ -234,7 +234,7 @@ ExtIntTable<A>::resolve_and_store_route(const IPRouteEntry<A>& route,
     }
 
     typename ResolvedRouteBackLink::iterator backlink;
-    backlink = _ip_igp_parents.insert(make_pair(nexthop_route,
+    backlink = _ip_igp_parents.insert(make_pair(nexthop_route->net(),
 						resolved_route));
     resolved_route->set_backlink(backlink);
 
@@ -267,7 +267,7 @@ ExtIntTable<A>::delete_route(const IPRouteEntry<A>* route,
 	}
 
 	const ResolvedIPRouteEntry<A>* found;
-	found = lookup_by_igp_parent(route);
+	found = lookup_by_igp_parent(route->net());
 
 	if (found != NULL) {
 	    _resolving_routes.erase(route->net());
@@ -288,7 +288,7 @@ ExtIntTable<A>::delete_route(const IPRouteEntry<A>* route,
 	    egp_parent = found->egp_parent();
 	    delete found;
 	    add_route(*egp_parent, _ext_table);
-	    found = lookup_by_igp_parent(route);
+	    found = lookup_by_igp_parent(route->net());
 	}
 
 	// Propagate the original delete
@@ -344,7 +344,7 @@ ExtIntTable<A>::delete_ext_route(const IPRouteEntry<A>* route,
 
 	// Delete the route's IGP parent from _resolving_routes if
 	// no-one is using it anymore
-	if (lookup_by_igp_parent(found->igp_parent()) == NULL) {
+	if (lookup_by_igp_parent(found->igp_parent()->net()) == NULL) {
 	    _resolving_routes.erase(found->igp_parent()->net());
 	}
 
@@ -455,33 +455,33 @@ ExtIntTable<A>::delete_unresolved_nexthop(const IPRouteEntry<A>* route)
 
 template<class A>
 const ResolvedIPRouteEntry<A>*
-ExtIntTable<A>::lookup_by_igp_parent(const IPRouteEntry<A>* route)
+ExtIntTable<A>::lookup_by_igp_parent(const IPNet<A>& route_net)
 {
-    debug_msg("lookup_by_igp_parent %p -> %s\n",
-	      route, route->net().str().c_str());
+    debug_msg("lookup_by_igp_parent %s\n",
+	      route_net.str().c_str());
 
     typename ResolvedRouteBackLink::iterator iter;
-    iter = _ip_igp_parents.find(route);
+    iter = _ip_igp_parents.find(route_net);
     if (iter == _ip_igp_parents.end()) {
 	debug_msg("Found no routes with this IGP parent\n");
 	return NULL;
     } else {
-	debug_msg("Found route with IGP parent %p:\n    %s\n",
-		  route, (iter->second)->str().c_str());
+	debug_msg("Found route with IGP parent %s:\n    %s\n",
+		  route_net.str().c_str(), (iter->second)->str().c_str());
 	return iter->second;
     }
 }
 
 template<class A>
 const ResolvedIPRouteEntry<A>*
-ExtIntTable<A>::lookup_next_by_igp_parent(const IPRouteEntry<A>* route,
+ExtIntTable<A>::lookup_next_by_igp_parent(const IPNet<A>& route_net,
 			const typename IGPParentMultiMap::iterator& previous)
 {
-    debug_msg("lookup_next_by_igp_parent %p -> %s, starting from %p -> %s\n",
-	      route, route->net().str().c_str(),
+    debug_msg("lookup_next_by_igp_parent %s, starting from %p -> %s\n",
+	      route_net.str().c_str(),
 	      previous->second, previous->second->net().str().c_str());
 
-    pair<typename IGPParentMultiMap::iterator, typename IGPParentMultiMap::iterator> route_range = _ip_igp_parents.equal_range(route);
+    pair<typename IGPParentMultiMap::iterator, typename IGPParentMultiMap::iterator> route_range = _ip_igp_parents.equal_range(route_net);
     typename IGPParentMultiMap::iterator iter = previous;
     if (iter++ == route_range.second ||
         iter == route_range.second) {
@@ -489,8 +489,8 @@ ExtIntTable<A>::lookup_next_by_igp_parent(const IPRouteEntry<A>* route,
 	return NULL;
     }
 
-    debug_msg("Found next route with IGP parent %p:\n    %s\n",
-	      route, (iter->second)->str().c_str());
+    debug_msg("Found next route with IGP parent %s:\n    %s\n",
+	      route_net.str().c_str(), (iter->second)->str().c_str());
     return iter->second;
 }
 
@@ -514,7 +514,7 @@ ExtIntTable<A>::recalculate_nexthops(const IPRouteEntry<A>& new_route)
     const ResolvedIPRouteEntry<A>* found;
     typename IGPParentMultiMap::iterator last_not_deleted = _ip_igp_parents.end();
     const IPRouteEntry<A>* egp_parent;
-    found = lookup_by_igp_parent(old_route);
+    found = lookup_by_igp_parent(old_route->net());
     while (found != NULL) {
 	egp_parent = found->egp_parent();
 	XLOG_ASSERT(egp_parent->nexthop()->type() != DISCARD_NEXTHOP);
@@ -530,7 +530,7 @@ ExtIntTable<A>::recalculate_nexthops(const IPRouteEntry<A>& new_route)
 
 	    // Delete the route's IGP parent from _resolving_routes if
 	    // no-one's using it anymore
-	    if (lookup_by_igp_parent(found->igp_parent()) == NULL) {
+	    if (lookup_by_igp_parent(found->igp_parent()->net()) == NULL) {
 		_resolving_routes.erase(found->igp_parent()->net());
 	    }
 
@@ -549,9 +549,9 @@ ExtIntTable<A>::recalculate_nexthops(const IPRouteEntry<A>& new_route)
 	}
 
 	if (last_not_deleted == _ip_igp_parents.end()) {
-	    found = lookup_by_igp_parent(old_route);
+	    found = lookup_by_igp_parent(old_route->net());
 	} else {
-	    found = lookup_next_by_igp_parent(old_route, last_not_deleted);
+	    found = lookup_next_by_igp_parent(old_route->net(), last_not_deleted);
 	}
     }
     debug_msg("done recalculating nexthops\n------------------------------------------------\n");
diff --git a/xorp/rib/rt_tab_extint.hh b/xorp/rib/rt_tab_extint.hh
index f42d2a3..401b568 100644
--- a/xorp/rib/rt_tab_extint.hh
+++ b/xorp/rib/rt_tab_extint.hh
@@ -167,7 +167,7 @@ public:
 private:
     typedef typename ResolvedIPRouteEntry<A>::RouteBackLink ResolvedRouteBackLink;
     typedef typename UnresolvedIPRouteEntry<A>::RouteBackLink UnresolvedRouteBackLink;
-    typedef multimap<const IPRouteEntry<A>*, ResolvedIPRouteEntry<A>* > IGPParentMultiMap;
+    typedef multimap<const IPNet<A>, ResolvedIPRouteEntry<A>* > IGPParentMultiMap;
     typedef map<IPNet<A>, UnresolvedIPRouteEntry<A>* > IpUnresolvedTableMap;
 
     int delete_ext_route(const IPRouteEntry<A>* route,
@@ -187,10 +187,10 @@ private:
     void recalculate_nexthops(const IPRouteEntry<A>& route);
 
     const ResolvedIPRouteEntry<A>* lookup_by_igp_parent(
-	const IPRouteEntry<A>* route);
+	const IPNet<A>& route_net);
 
     const ResolvedIPRouteEntry<A>* lookup_next_by_igp_parent(
-	const IPRouteEntry<A>* route,
+	const IPNet<A>& route_net,
 	const typename IGPParentMultiMap::iterator& previous);
 
     const IPRouteEntry<A>* lookup_route_in_igp_parent(
-- 
1.7.9.5


From igorm at etf.rs  Fri Jun 29 11:40:10 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 29 Jun 2012 20:40:10 +0200
Subject: [Xorp-hackers] Fix BGP test fail
Message-ID: <CAFdo_mUvmy3q2pqm3WiikFjOC2_fCu8_SK7BV_+d43_noJoKGw@mail.gmail.com>

Hi Ben,
I've send the patch. Problem wasn't with my patches, but my patches
just uncovered existing problem. :)
BR
Igor