MRECW Students E- Learning Point Computer Security Student (CSS)

Dear all,

in my previous post
(https://groups.google.com/forum/?fromgroups#!topic/ns-3-users/v9K5v6y...)
I was trying to identify the reason why a node that correctly received a
packet did not forward it.
I thought that the problem was at the MAC level, but I've just noted that
the real problem is at the IP level.

By analyzing the routing tables, I observed that the 'selfish' node does
not forward the packet because it's missing some routing paths info.

SCENARIO:
one source node transmits TCP packets via bulk-send-application to a
destination node that is 5 hops away (CHAIN topology).
(source)0 ---> 1 ---> 2 ---> 3 ---> 4 ---> 5(destination)

NETWORK CONFIG:
- Wifi 802.11a
- TCP NewReno
- Fixed positions (100 meters inter-node distance)
- OLSR

The 'selfish' node is Node 3; it correctly received ACK=X, but it did not
enqueued the packet in its transmission queue, approximately at time 46.  

In the following, please find the routing tables of each node at time 45.6.
As you can note, Node 3 does not 'see' Node 0.

NODE 0
Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.2        1        1    
10.1.1.3        10.1.1.2        1        2    
10.1.1.4        10.1.1.2        1        3    
10.1.1.5        10.1.1.2        1        4    
10.1.1.6        10.1.1.2        1        5    

NODE 1
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.1        1        1    
10.1.1.3        10.1.1.3        1        1    
10.1.1.4        10.1.1.3        1        2    
10.1.1.5        10.1.1.3        1        3    
10.1.1.6        10.1.1.3        1        4    

NODE 2
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.2        1        2    
10.1.1.2        10.1.1.2        1        1    
10.1.1.4        10.1.1.4        1        1    
10.1.1.5        10.1.1.4        1        2    
10.1.1.6        10.1.1.4        1        3    

NODE 3
Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.3        1        2    
10.1.1.3        10.1.1.3        1        1    
10.1.1.5        10.1.1.5        1        1    
10.1.1.6        10.1.1.5        1        2    

NODE 4
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.4        1        4    
10.1.1.2        10.1.1.4        1        3    
10.1.1.3        10.1.1.4        1        2    
10.1.1.4        10.1.1.4        1        1    
10.1.1.6        10.1.1.6        1        1    

NODE 5
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.5        1        5    
10.1.1.2        10.1.1.5        1        4    
10.1.1.3        10.1.1.5        1        3    
10.1.1.4        10.1.1.5        1        2    
10.1.1.5        10.1.1.5        1        1

Later routing tables (time 46.4) show that also Node 4 and Node 5 stops
having routing information about Node 0.

NODE 0
Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.2        1        1    
10.1.1.3        10.1.1.2        1        2    
10.1.1.4        10.1.1.2        1        3    
10.1.1.5        10.1.1.2        1        4    
10.1.1.6        10.1.1.2        1        5    

NODE 1
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.1        1        1    
10.1.1.3        10.1.1.3        1        1    
10.1.1.4        10.1.1.3        1        2    
10.1.1.5        10.1.1.3        1        3    
10.1.1.6        10.1.1.3        1        4    

NODE 2
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.2        1        2    
10.1.1.2        10.1.1.2        1        1    
10.1.1.4        10.1.1.4        1        1    
10.1.1.5        10.1.1.4        1        2    
10.1.1.6        10.1.1.4        1        3    

NODE 3
Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.3        1        2    
10.1.1.3        10.1.1.3        1        1    
10.1.1.5        10.1.1.5        1        1    
10.1.1.6        10.1.1.5        1        2    

NODE 4
Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.4        1        3    
10.1.1.3        10.1.1.4        1        2    
10.1.1.4        10.1.1.4        1        1    
10.1.1.6        10.1.1.6        1        1    

NODE 5
Destination    NextHop        Interface    Distance
10.1.1.2        10.1.1.5        1        4    
10.1.1.3        10.1.1.5        1        3    
10.1.1.4        10.1.1.5        1        2    
10.1.1.5        10.1.1.5        1        1

At around 50 seconds, the routing tables are again complete.

Please note that I am using OLSR routing with its default configuration,
and the nodes are static...
Does anybody have an idea?

Further, as I said, by evaluating 100s-long simulations with different
seeds, this is occurring 2/3 times.

Thanks in advance for your support. 

I am no OLSR expert at all, but I guess that OLSR is mistakenly detecting
that a link goes down, and I guess this might happen because e.g. of missed
hello packets or something similar. Now the question is why this happens...
for example I wonder if OLSR control packets end up in the same wifi queue
of data packet, and hence might be discarded by a buffer overflow. I seem
to recall that ns-2 had an explicit priority queue mechanism for this
purpose. No idea how ns-3 handle this... maybe some routing expert could
shed some light.  

The OLSR control packets are enqueued in the same wifi queue of data
packet, but the buffer is never overflowing.

1) If any of you, routing experts, have a suggestion, please contact me.

otherwise

2) Does any of you know if there is a simple way to freeze the routing
tables initially generated with OLSR until the end of the simulation?

Regards,

Marco Mezzavilla
Ph.D. Student - SIGNET Group
Department of Information Engineering (DEI)
University of Padova - Italy 



thanks for the support.
I tried to focus on the analysis of HELLO+TC messages, and it looks like it
is all working properly, no losses nor collisions.
I would kindly ask some routing (OLSR) experts to give a look to this
discussion.

In few words, I can't understand why at a certain time a node loses some
routing info for few seconds.
I tried to log OLSR procedures, but I do not see any strange behavior (find
attached, starting from approximately 40seconds, referring to the previous
example).

Thanks

On Tue, May 22, 2012 at 12:09 PM, Konstantinos <dinos.katsa...@gmail.com>wrote:

- Show quoted text -

--
Marco Mezzavilla
Ph.D. Student - SIGNET Group
Department of Information Engineering (DEI)
University of Padova - Italy

logging_olsr.txt.zip 379K View Download