From Uri.Yanai at ngsoft.com  Wed May  4 07:37:45 2011
From: Uri.Yanai at ngsoft.com (Uri Yanai)
Date: Wed, 4 May 2011 17:37:45 +0300
Subject: [Xorp-hackers] Configure router NOT through the CLI xorpsh
Message-ID: <AEED46D459A9D8468E484CBBE5854447A899DA@exchange.Giant-Steps.local>

Hi
I need to configure the XORP router not through the CLI xorpsh.
When I directly call the component XRLs I notice that router manager isn't effected.
In other words, I don't see my configuration changes in xorpsh configuration mode 'show'.
>From reading the xorp_rtrmgr documentation, I found that I can change configuration using the rtrmgr XRLs, more specific calling send_apply_config_change() passing 'deltas' with the configuration changes but I didn't figure out how do I generate the 'deltas'.
I would be glad to know how can I in code configure the XORP router and then also see my changes 
in xorpsh configuration mode 'show' .

Thanks for your help.
Uri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110504/b0d78b27/attachment.html 

From greearb at candelatech.com  Wed May  4 11:36:11 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 04 May 2011 11:36:11 -0700
Subject: [Xorp-hackers] Configure router NOT through the CLI xorpsh
In-Reply-To: <AEED46D459A9D8468E484CBBE5854447A899DA@exchange.Giant-Steps.local>
References: <AEED46D459A9D8468E484CBBE5854447A899DA@exchange.Giant-Steps.local>
Message-ID: <4DC19C9B.3090802@candelatech.com>

On 05/04/2011 07:37 AM, Uri Yanai wrote:
> Hi
> I need to configure the XORP router not through the CLI xorpsh.
> When I directly call the component XRLs I notice that router manager
> isn't effected.
> In other words, I don't see my configuration changes in xorpsh
> configuration mode 'show'.
>  >From reading the xorp_rtrmgr documentation, I found that I can change
> configuration using the rtrmgr XRLs, more specific calling
> send_apply_config_change() passing 'deltas' with the configuration
> changes but I didn't figure out how do I generate the 'deltas'.
> I would be glad to know how can I in code configure the XORP router and
> then also see my changes
> in xorpsh configuration mode 'show' .

This is liable to be difficult.  Maybe start by copying and then modifying
the xorpsh code to do what you want?

You can also script xorpsh with -c "command1" -c "command2" arguments if you
wish.

Thanks,
Ben

>
> Thanks for your help.
> Uri
>
>
>
> _______________________________________________
> 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 B22341 at freescale.com  Thu May  5 22:10:45 2011
From: B22341 at freescale.com (Naidu Sai-B22341)
Date: Fri, 6 May 2011 05:10:45 +0000
Subject: [Xorp-hackers] Cand-rp hold time and priority in bootstrap message
 is being sent as 0 on ppc
Message-ID: <4512B01EC84A9448A77B126336319EC80A0CFF@039-SN1MPN1-004.039d.mgd.msft.net>

Hi,
I have compiled and brought up xorp-1.6 on a power pc platform.
I have used a small setup to test xorp with one RP and one DR.

Host1 (sender)-----------RUT1 (RP)---------RUT2(DR)------------------Host2 (receiver)

I made the required configuration to get RUT1 to be the RP and RUT2 be the DR for a group.
The multicast traffic got routed correctly when I used STATIC RPs. But when I tried to get the RP elected through bootstrapping, the routing failed.
After going through the bootstrap packets capture, I found that the cand-rp hold time and priority value were always being sent as zero. This happens irrespective of the values given in the config.boot file.
Even when no values are given for the cand-rp hold time and priority, the default value being sent in the bootstrap message is 0.

But when I replaced the powerpc boards with X86 PCs(with the same configuration files), traffic was getting routed correctly. The bootstrap messages had the correct (default) values for  cand-rp hold time and priority.

Has anybody faced similar issue? Could this be an endian issue?

Could anybody suggest a fix or point me to the location in the xorp code where this copy happens.

Thank you.

Regards,
Sai Naidu

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

From B22341 at freescale.com  Fri May  6 02:41:30 2011
From: B22341 at freescale.com (Naidu Sai-B22341)
Date: Fri, 6 May 2011 09:41:30 +0000
Subject: [Xorp-hackers] Cand-rp hold time and priority in bootstrap message
 is being sent as 0 on ppc
Message-ID: <4512B01EC84A9448A77B126336319EC80A0D9E@039-SN1MPN1-004.039d.mgd.msft.net>

Hi,
I have compiled and brought up xorp-1.6 on a power pc platform.
I have used a small setup to test xorp with one RP and one DR.

Host1 (sender)-----------RUT1 (RP)---------RUT2(DR)------------------Host2 (receiver)

I made the required configuration to get RUT1 to be the RP and RUT2 be the DR for a group.
The multicast traffic got routed correctly when I used STATIC RPs. But when I tried to get the RP elected through bootstrapping, the routing failed.
After going through the bootstrap packets capture, I found that the cand-rp hold time and priority value were always being sent as zero. This happens irrespective of the values given in the config.boot file.
Even when no values are given for the cand-rp hold time and priority, the default value being sent in the bootstrap message is 0.

But when I replaced the powerpc boards with X86 PCs(with the same configuration files), traffic was getting routed correctly. The bootstrap messages had the correct (default) values for  cand-rp hold time and priority.

Has anybody faced similar issue? Could this be an endian issue?

Could anybody suggest a fix or point me to the location in the xorp code where this copy happens.

Thank you.

Regards,
Sai Naidu

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

From greearb at candelatech.com  Fri May  6 06:36:08 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 06 May 2011 06:36:08 -0700
Subject: [Xorp-hackers] Cand-rp hold time and priority in bootstrap
 message is being sent as 0 on ppc
In-Reply-To: <4512B01EC84A9448A77B126336319EC80A0D9E@039-SN1MPN1-004.039d.mgd.msft.net>
References: <4512B01EC84A9448A77B126336319EC80A0D9E@039-SN1MPN1-004.039d.mgd.msft.net>
Message-ID: <4DC3F948.3000305@candelatech.com>

On 05/06/2011 02:41 AM, Naidu Sai-B22341 wrote:
> Hi,
>
> I have compiled and brought up xorp-1.6 on a power pc platform.
>
> I have used a small setup to test xorp with one RP and one DR.
>
> Host1 (sender)-----------RUT1 (RP)---------RUT2(DR)------------------Host2 (receiver)
>
> I made the required configuration to get RUT1 to be the RP and RUT2 be the DR for a group.
>
> The multicast traffic got routed correctly when I used STATIC RPs. But when I tried to get the RP elected through bootstrapping, the routing failed.
>
> After going through the bootstrap packets capture, I found that the cand-rp hold time and priority value were always being sent as zero. This happens
> irrespective of the values given in the config.boot file.
>
> Even when no values are given for the cand-rp hold time and priority, the default value being sent in the bootstrap message is 0.
>
> But when I replaced the powerpc boards with X86 PCs(with the same configuration files), traffic was getting routed correctly. The bootstrap messages had the
> correct (default) values for cand-rp hold time and priority.
>
> Has anybody faced similar issue? Could this be an endian issue?
>
> Could anybody suggest a fix or point me to the location in the xorp code where this copy happens.

Please try the top-of-tree xorp and see if the problem still exists.  I don't think anyone
is actively working on xorp 1.6 code anymore.

https://github.com/greearb/xorp.ct

Thanks,
Ben

>
> Thank you.
>
> Regards,
>
> Sai Naidu
>
>
>
> _______________________________________________
> 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 phugg at crc.ca  Thu May 19 08:24:09 2011
From: phugg at crc.ca (Philip Hugg)
Date: Thu, 19 May 2011 11:24:09 -0400
Subject: [Xorp-hackers] XRL is busy and does not send
Message-ID: <4DD53619.1010406@crc.ca>

Hello everyone,

I'm currently working on Xorp-OLSR.

The problem with OLSR is the route flapping.
I've managed to find a few obvious bugs up to now however this one
involves the interface to the XRL. I'm not sure how to fix.

The problem I found is in file 'xrl_port.cc' where OLSR is sending the 
packets

Here's the portion of the code:
(extracted from the xorp/socket_programming document)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

//
// Sending operations.
//
template  <>
bool  PortBase<IPv4>
::send_to(const  IPv4&  dst_address,
         const  uint16_t  dst_port,
         const  vector<uint8_t>&  payload)
{
     if  (_pending)  {
         debug_msg("PortOutput %p: send skipped (pending XRL)\n",this);
         return  false;
     }
  
     XrlSocket4V0p1Client cl(&_xrl_router);

     bool  success=  cl.send_send_to(_socket_server_name.c_str(),
                                    _socket_id,
                                    dst_address,
                                    dst_port,
                                    payload,
                                    callback(this,&PortBase::send_cb));
  
     debug_msg("Sent %u bytes to %s:%u from %s:%u\n",
               XORP_UINT_CAST(payload.size()),
               cstring(_dst_addr), XORP_UINT_CAST(_dst_port),
               cstring(_src_addr), XORP_UINT_CAST(_src_port));

     if  (success)
         _pending=  true;

     return  success;
}

template  <typename  A>
void
PortBase::send_cb(const  XrlError&  e)
{
     debug_msg("SendCB %s\n", e.str().c_str());

     if  (e!=  XrlError::OKAY())  {
         XLOG_WARNING("Failed to send datagram.");
     }
  
     _pending=  false;
}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now what I'm seeing is the debug message "PortOutput ...: send skipped 
(pending XRL)".
It doesn't happen all the time but it's just enough to cause route flapping.

My question is how could I fix the pending issue without causing a race 
condition in the code?


I haven't looked into XRL yet but I don't understand why the packet is 
not sent.
Should it be OLSR's responsibility to re-shedule the resending of the 
packet?
Does this problem occur on the other routing protocols (BGP, OSPF ...)?

Thanks,
Phil.



From greearb at candelatech.com  Thu May 19 08:46:42 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 19 May 2011 08:46:42 -0700
Subject: [Xorp-hackers] XRL is busy and does not send
In-Reply-To: <4DD53619.1010406@crc.ca>
References: <4DD53619.1010406@crc.ca>
Message-ID: <4DD53B62.20605@candelatech.com>

On 05/19/2011 08:24 AM, Philip Hugg wrote:
> Hello everyone,
>
> I'm currently working on Xorp-OLSR.
>
> The problem with OLSR is the route flapping.
> I've managed to find a few obvious bugs up to now however this one
> involves the interface to the XRL. I'm not sure how to fix.
>
> The problem I found is in file 'xrl_port.cc' where OLSR is sending the
> packets


> Now what I'm seeing is the debug message "PortOutput ...: send skipped
> (pending XRL)".
> It doesn't happen all the time but it's just enough to cause route flapping.
>
> My question is how could I fix the pending issue without causing a race
> condition in the code?
>
>
> I haven't looked into XRL yet but I don't understand why the packet is
> not sent.
> Should it be OLSR's responsibility to re-shedule the resending of the
> packet?
> Does this problem occur on the other routing protocols (BGP, OSPF ...)?

You might try a 'git blame' on that xrl_port.cc file and see if there
are any recent changes there.  There has been some work to support
async-xrls recently, and it's possible it is causing bugs.

Thanks,
Ben


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


From greearb at candelatech.com  Thu May 19 09:32:46 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 19 May 2011 09:32:46 -0700
Subject: [Xorp-hackers] XRL is busy and does not send
In-Reply-To: <4DD53619.1010406@crc.ca>
References: <4DD53619.1010406@crc.ca>
Message-ID: <4DD5462E.50301@candelatech.com>

On 05/19/2011 08:24 AM, Philip Hugg wrote:
> Hello everyone,
>
> I'm currently working on Xorp-OLSR.
>
> The problem with OLSR is the route flapping.
> I've managed to find a few obvious bugs up to now however this one
> involves the interface to the XRL. I'm not sure how to fix.
>
> The problem I found is in file 'xrl_port.cc' where OLSR is sending the
> packets

>
> Now what I'm seeing is the debug message "PortOutput ...: send skipped
> (pending XRL)".
> It doesn't happen all the time but it's just enough to cause route flapping.
>
> My question is how could I fix the pending issue without causing a race
> condition in the code?

I took a look at that code, and it looks quite fragile.
As the code exists currently, I suppose you'd
need to check the results of send_to and queue up pkts for retransmit
if sending failed.

Maybe it was to make sure some initial config logic completed before
send_to started functioning?

Maybe use a different flag like _setup_complete that is set in
socket_setup_complete() and have send_to fail to send until
setup is complete?

It doesn't look like an general XRL problem to me, by the way.

Thanks,
Ben

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


From phugg at crc.ca  Thu May 19 11:29:51 2011
From: phugg at crc.ca (Philip Hugg)
Date: Thu, 19 May 2011 14:29:51 -0400
Subject: [Xorp-hackers] XRL is busy and does not send
In-Reply-To: <4DD5462E.50301@candelatech.com>
References: <4DD53619.1010406@crc.ca> <4DD5462E.50301@candelatech.com>
Message-ID: <4DD5619F.6010901@crc.ca>

On 19/05/2011 12:32 PM, Ben Greear wrote:
> On 05/19/2011 08:24 AM, Philip Hugg wrote:
>> Hello everyone,
>>
>> I'm currently working on Xorp-OLSR.
>>
>> The problem with OLSR is the route flapping.
>> I've managed to find a few obvious bugs up to now however this one
>> involves the interface to the XRL. I'm not sure how to fix.
>>
>> The problem I found is in file 'xrl_port.cc' where OLSR is sending the
>> packets
>
>>
>> Now what I'm seeing is the debug message "PortOutput ...: send skipped
>> (pending XRL)".
>> It doesn't happen all the time but it's just enough to cause route 
>> flapping.
>>
>> My question is how could I fix the pending issue without causing a race
>> condition in the code?
>
> I took a look at that code, and it looks quite fragile.
> As the code exists currently, I suppose you'd
> need to check the results of send_to and queue up pkts for retransmit
> if sending failed.
>
> Maybe it was to make sure some initial config logic completed before
> send_to started functioning?
>
> Maybe use a different flag like _setup_complete that is set in
> socket_setup_complete() and have send_to fail to send until
> setup is complete?
>
> It doesn't look like an general XRL problem to me, by the way.
>
> Thanks,
> Ben
>
Hi Ben,

Thank you for answering so quickly.

I presume the socket setup is done when xorp is started and is done only 
once.
In my case, the socket has been setup and is currently sending and 
receiving packets.

The problem I'm seeing is that when a send-to call is made it becomes 
busy (pending=true)
for a short while. It is freed (pending=false) when the callback 
'send_cb' is returned from cl.send_send_to(...).

It just sometimes happens that OLSR is sending packets in that short 
busy state.

To me, this is a problem!

A queuing mechanism on the OLSR side would probably mean implementing a 
new thread
of code just spinning and waiting for the XRL to become free.
This will take a while but I'll take a look at the other protocols (BGP, 
OSPF) to see how
  they are handling the XRL pending.

again thanks,
Phil.



From greearb at candelatech.com  Thu May 19 11:40:25 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 19 May 2011 11:40:25 -0700
Subject: [Xorp-hackers] XRL is busy and does not send
In-Reply-To: <4DD5619F.6010901@crc.ca>
References: <4DD53619.1010406@crc.ca> <4DD5462E.50301@candelatech.com>
	<4DD5619F.6010901@crc.ca>
Message-ID: <4DD56419.9020104@candelatech.com>

On 05/19/2011 11:29 AM, Philip Hugg wrote:
> On 19/05/2011 12:32 PM, Ben Greear wrote:
>> On 05/19/2011 08:24 AM, Philip Hugg wrote:
>>> Hello everyone,
>>>
>>> I'm currently working on Xorp-OLSR.
>>>
>>> The problem with OLSR is the route flapping.
>>> I've managed to find a few obvious bugs up to now however this one
>>> involves the interface to the XRL. I'm not sure how to fix.
>>>
>>> The problem I found is in file 'xrl_port.cc' where OLSR is sending the
>>> packets
>>
>>>
>>> Now what I'm seeing is the debug message "PortOutput ...: send skipped
>>> (pending XRL)".
>>> It doesn't happen all the time but it's just enough to cause route flapping.
>>>
>>> My question is how could I fix the pending issue without causing a race
>>> condition in the code?
>>
>> I took a look at that code, and it looks quite fragile.
>> As the code exists currently, I suppose you'd
>> need to check the results of send_to and queue up pkts for retransmit
>> if sending failed.
>>
>> Maybe it was to make sure some initial config logic completed before
>> send_to started functioning?
>>
>> Maybe use a different flag like _setup_complete that is set in
>> socket_setup_complete() and have send_to fail to send until
>> setup is complete?
>>
>> It doesn't look like an general XRL problem to me, by the way.
>>
>> Thanks,
>> Ben
>>
> Hi Ben,
>
> Thank you for answering so quickly.
>
> I presume the socket setup is done when xorp is started and is done only once.
> In my case, the socket has been setup and is currently sending and receiving packets.
>
> The problem I'm seeing is that when a send-to call is made it becomes busy (pending=true)
> for a short while. It is freed (pending=false) when the callback 'send_cb' is returned from cl.send_send_to(...).
>
> It just sometimes happens that OLSR is sending packets in that short busy state.
>
> To me, this is a problem!
>
> A queuing mechanism on the OLSR side would probably mean implementing a new thread
> of code just spinning and waiting for the XRL to become free.
> This will take a while but I'll take a look at the other protocols (BGP, OSPF) to see how
> they are handling the XRL pending.

I don't think there is any real reason sending while 'busy'.

Please post your existing patches, and for your testing, try just
commenting out this code:

     if (success)
	_pending = true;

in send_to()

Thanks,
Ben

>
> again thanks,
> Phil.
>


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


From phugg at crc.ca  Thu May 19 13:00:05 2011
From: phugg at crc.ca (Philip Hugg)
Date: Thu, 19 May 2011 16:00:05 -0400
Subject: [Xorp-hackers] XRL is busy and does not send
In-Reply-To: <4DD56419.9020104@candelatech.com>
References: <4DD53619.1010406@crc.ca> <4DD5462E.50301@candelatech.com>
	<4DD5619F.6010901@crc.ca> <4DD56419.9020104@candelatech.com>
Message-ID: <4DD576C5.9040303@crc.ca>

On 19/05/2011 2:40 PM, Ben Greear wrote:
> On 05/19/2011 11:29 AM, Philip Hugg wrote:
>> On 19/05/2011 12:32 PM, Ben Greear wrote:
>>> On 05/19/2011 08:24 AM, Philip Hugg wrote:
>>>> Hello everyone,
>>>>
>>>> I'm currently working on Xorp-OLSR.
>>>>
>>>> The problem with OLSR is the route flapping.
>>>> I've managed to find a few obvious bugs up to now however this one
>>>> involves the interface to the XRL. I'm not sure how to fix.
>>>>
>>>> The problem I found is in file 'xrl_port.cc' where OLSR is sending the
>>>> packets
>>>
>>>>
>>>> Now what I'm seeing is the debug message "PortOutput ...: send skipped
>>>> (pending XRL)".
>>>> It doesn't happen all the time but it's just enough to cause route 
>>>> flapping.
>>>>
>>>> My question is how could I fix the pending issue without causing a 
>>>> race
>>>> condition in the code?
>>>
>>> I took a look at that code, and it looks quite fragile.
>>> As the code exists currently, I suppose you'd
>>> need to check the results of send_to and queue up pkts for retransmit
>>> if sending failed.
>>>
>>> Maybe it was to make sure some initial config logic completed before
>>> send_to started functioning?
>>>
>>> Maybe use a different flag like _setup_complete that is set in
>>> socket_setup_complete() and have send_to fail to send until
>>> setup is complete?
>>>
>>> It doesn't look like an general XRL problem to me, by the way.
>>>
>>> Thanks,
>>> Ben
>>>
>> Hi Ben,
>>
>> Thank you for answering so quickly.
>>
>> I presume the socket setup is done when xorp is started and is done 
>> only once.
>> In my case, the socket has been setup and is currently sending and 
>> receiving packets.
>>
>> The problem I'm seeing is that when a send-to call is made it becomes 
>> busy (pending=true)
>> for a short while. It is freed (pending=false) when the callback 
>> 'send_cb' is returned from cl.send_send_to(...).
>>
>> It just sometimes happens that OLSR is sending packets in that short 
>> busy state.
>>
>> To me, this is a problem!
>>
>> A queuing mechanism on the OLSR side would probably mean implementing 
>> a new thread
>> of code just spinning and waiting for the XRL to become free.
>> This will take a while but I'll take a look at the other protocols 
>> (BGP, OSPF) to see how
>> they are handling the XRL pending.
>
> I don't think there is any real reason sending while 'busy'.
>
> Please post your existing patches, and for your testing, try just
> commenting out this code:
>
>     if (success)
>     _pending = true;
>
> in send_to()
>
> Thanks,
> Ben
>
>>
>> again thanks,
>> Phil.
>>
>
>
Ben, the testing is working great! The OLSR topology table is very 
stable now!
However, I will continue testing. I have other OLSR topologies I would 
like to try.

I guess this means the sendto() doesn't need the pending flag after all.


About the patches-

I've only made changes to the OLSR and in XORP-1.5.
Did you want the patches for that?

Thanks,
Phil.




From greearb at candelatech.com  Thu May 19 13:30:55 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 19 May 2011 13:30:55 -0700
Subject: [Xorp-hackers] XRL is busy and does not send
In-Reply-To: <4DD576C5.9040303@crc.ca>
References: <4DD53619.1010406@crc.ca> <4DD5462E.50301@candelatech.com>
	<4DD5619F.6010901@crc.ca> <4DD56419.9020104@candelatech.com>
	<4DD576C5.9040303@crc.ca>
Message-ID: <4DD57DFF.3090907@candelatech.com>

On 05/19/2011 01:00 PM, Philip Hugg wrote:

> Ben, the testing is working great! The OLSR topology table is very
> stable now!
> However, I will continue testing. I have other OLSR topologies I would
> like to try.
>
> I guess this means the sendto() doesn't need the pending flag after all.
>
>
> About the patches-
>
> I've only made changes to the OLSR and in XORP-1.5.
> Did you want the patches for that?

Sure, it's possible they still apply.  I did fix quite a few OLSR
bugs in the xorp 1.7 timeframe though...I'd suggest upgrading to the
latest xorp from github if you can.

Thanks,
Ben

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


From noreply at github.com  Thu May 19 13:44:46 2011
From: noreply at github.com (noreply at github.com)
Date: Thu, 19 May 2011 13:44:46 -0700
Subject: [Xorp-hackers] [greearb/xorp.ct] f3e6ee: olsr: Fix xrl_port pending
	logic.
Message-ID: <20110519204446.89D38425E9@smtp1.rs.github.com>

Branch: refs/heads/master
Home:   https://github.com/greearb/xorp.ct

Commit: f3e6eead7cc22181dd072eca623d0f6c2a3c4ff6
    https://github.com/greearb/xorp.ct/commit/f3e6eead7cc22181dd072eca623d0f6c2a3c4ff6
Author: Ben Greear <greearb at candelatech.com>
Date:   2011-05-19 (Thu, 19 May 2011)

Changed paths:
  M xorp/contrib/olsr/xrl_port.cc
  M xorp/contrib/olsr/xrl_port.hh

Log Message:
-----------
olsr:  Fix xrl_port pending logic.

The _pending logic guards initialization and teardown logic,
but it doesn't need to restrict normal send_to messages.
This causes un-necessary packet loss, which causes link flapping.

Reported-by: Philip Hugg <phugg at crc.ca>
Signed-off-by: Ben Greear <greearb at candelatech.com>