TCP connection in OLSR wireless mesh sometimes leads to assertion in ARP

[Björn Lichtblau]

Hi,

i have setup a simulation of a 20 node wireless mesh network with OLSR
and created a TCP connection from one node to another
through the network. It works partially, but sometimes (depending on the
transmit power, i played with that) i get an assertion within the arp
protocol:

assert failed. file=../src/internet-stack/arp-l3-protocol.cc, line=326,
cond="route != 0"

which is this:

Ptr<Ipv4Route> route = ipv4->GetRoutingProtocol ()->RouteOutput (packet,
header, interface, errno_);
NS_ASSERT (route != 0);

Does anyone have an idea why this happens, how it could be avoided or
for what this assertion exactly is for?

I can have my scenario cleanly finish or suddenly break during the
simulation, depending on the transmit power i set (nothing else changed).
I assume that somehow due to bad links (that is what i want) OLSR drops
discovered routes again, so a node can become responsible
for routing a packet although it has no route for it, and then this
assertion in the ARP protocol stops the simulation.
I think this is the behaviour i want, but this problem should result in
a stalling TCP connection or a connection reset, and not in an assertion
stopping the simulation?!

Unfortunatley my source is at the moment to cluttered for posting, i
will try to get a cleaner example for this next week, but maybe someone
already can have a look at this assertion and verify if it is really
needed or if this case should not be handled in some other way... or
point me at something i may have done wrong...

Regards and have a nice weekend, Bj�rn

[Kevin Peters]

2009/11/27 Björn Lichtblau <lich...@informatik.hu-berlin.de>

 

I am having a similiar problem with a routing protocol I am building.  This seems to happen for ARP requests for nodes that are not within one hop, but that may have been in the past.  The routing protocol gives a 0 route entry for the ARP route request.  As a hack, for now, I think I am just going to return a bad route that will result in the ARP request failing.  Another solution might be to make the ARP cache timeouts really high (http://www.nsnam.org/doxygen-release/classns3_1_1_arp_cache.html).

 

Regards,
Kevin

[mariem thaalbi]

Hello Björn, 

Me too, i work on the wireless mesh networks (the 802.11s norme) i want to simulate this network with OLSR but i didn't know  how to process, because when i install the 802.11s stack on a node automatically  the HWMP will be installed as a routing protocol and i didn't know to install the OLSR instead of it.

Can you share with me the part of your code which disccuss this side, please.

Best regards,

Mariem 

2009/11/27 Kevin Peters <kev...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

--
--------------------------------------

Mariem Thaalbi

Ingénieur télécommunications

[Tom Henderson]

Kevin Peters wrote:
> 2009/11/27 Bj�rn Lichtblau <lich...@informatik.hu-berlin.de
> <mailto:lich...@informatik.hu-berlin.de>>

thanks for the report; I filed a bug.

http://www.nsnam.org/bugzilla/show_bug.cgi?id=755

- Tom

[Gustavo Carneiro]

2009/11/27 mariem thaalbi <thaalbi...@gmail.com>

Hello Björn, 

Me too, i work on the wireless mesh networks (the 802.11s norme) i want to simulate this network with OLSR but i didn't know  how to process, because when i install the 802.11s stack on a node automatically  the HWMP will be installed as a routing protocol and i didn't know to install the OLSR instead of it.

What do you mean OLSR _instead of_ HWMP?  They work at different layers, so both can be used simultaneously, at least in theory...
 

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[mariem thaalbi]

In fact i want to work only with OLSR and not the twice OLSR and HWMP.

If i install the dot11S stack it will work with HWMP as layer 2 routing protocol, but for me i want to evaluate the performance of a WMN using only OLSR as IP routing protocol 

2009/11/28 Gustavo Carneiro <gjcar...@gmail.com>

[Gustavo Carneiro]

2009/11/28 mariem thaalbi <thaalbi...@gmail.com>

In fact i want to work only with OLSR and not the twice OLSR and HWMP.

If i install the dot11S stack it will work with HWMP as layer 2 routing protocol, but for me i want to evaluate the performance of a WMN using only OLSR as IP routing protocol 

In that case you should use 802.11 adhoc mode and OLSR on top.  Don't use 802.11s, nobody forces you to.
 

[Björn Lichtblau]

Hi again,

first thanks for filing this.

I could fix it for me by just cancelling the ARP request if no route for
a node exists (i also played with the ArpCache
settings like Kevin proposed and could avoid the problem, but i think
this was only compensating for semi-working links,
not really fixing the cause):
--- a/src/internet-stack/arp-l3-protocol.cc Wed Nov 11 00:27:47 2009
+0300
+++ b/src/internet-stack/arp-l3-protocol.cc Wed Dec 02 16:04:07 2009
+0100
@@ -323,7 +323,7 @@
Socket::SocketErrno errno_;
Ptr<Packet> packet = Create<Packet> ();

Ptr<Ipv4Route> route = ipv4->GetRoutingProtocol ()->RouteOutput
(packet, header, interface, errno_);

- NS_ASSERT (route != 0);
+ if(route == 0) return;
NS_LOG_LOGIC ("ARP: sending request from node "<<m_node->GetId ()<<
" || src: " << cache->GetDevice ()->GetAddress () <<
" / " << route->GetSource () <<


But i doubt that this is a clean solution and don't know about the
consequences for other existing code, but i am also not sure how it
could be handled better.

What i'm wondering about is how the arp request comes off at all. If
there is no route to a destination anymore, TCP should not try to send
packets to it (which it still seems to do because of the ARP request),
shouldn't it fail with no route or reset the connection ?
I thought about a concurrency issue, but i think it is very unlikely
that the route is there when a packet over TCP needs to get
sent/forwarded and is just removed by OLSR before the SendArpRequest is
issued, the time window should be very small or even be zero in the
simulation..

The second thing that made me thinking is the comment in SendArpRequest:
// need to pick a source address; use routing implementation to select
The route determination in the SendArpRequest function is only needed to
set the source address for the arp request... but couldn't/shouldn't the
arp
protocol work indepently of routing knowledge, and isn't the source
address already fixed by the device the arp request is sent over (and
could be retrieved from there)?

Source to produce the situation is attached, sorry if not everything
makes sense in there, but i quickly stripped it down as far as i could ;)

Regards, Bj�rn