[Ns-bugs] [Bug 407] OLSR may select wrong interface in MID context

[code@nsnam.ece.gatech.edu]

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





--- Comment #2 from Tom Henderson <tomh at tomh.org>  2008-12-06 21:12:07 EDT ---
(In reply to comment #1)
> Sorry, I'm retarded, corrections to my bug report...
> 
> TOPOLOGY:
> 
>      WIRED CSMA             WIRELESS CHANNEL
>    ______________
>    O            O  ))          (( O ))           (( O
>    N3           N0                N1                N2  
> 
> 
> Running the UdpEcho application, the packets make it to the
> destination N3 (172.16.0.1), but for some reason, N3 cannot echo the packet
> back to N2. Looking at the pcap file, it seems that N3 is asking (ARP) for the
> MAC
> address of 192.168.0.1 (the gateway N0 on Wifi interface) and it should be
> asking for 172.16.0.2 (the gateway N0 on CSMA interface).
> 

I've been looking at this off and on for the past week or so.  Here is what
I've found.

1) here are the routes that N3 OLSR builds:

dest: 192.168.0.1 next: 192.168.0.1 iface: 172.16.0.1 dist: 1
dest: 172.16.0.2 next: 172.16.0.2 iface: 172.16.0.1 dist: 1
dest: 192.168.0.2 next: 192.168.0.1 iface: 172.16.0.1 dist: 2
dest: 192.168.0.3 next: 192.168.0.1 iface: 172.16.0.1 dist: 3

What I think is missing is the following entry 
dest: 192.168.0.1 next: 172.16.0.2 iface 172.16.0.1 dist: 1

my read of step 4 of section 10 of RFC 3626 suggests that the above entry
should be added, because N3 does have a mid message from N0.  It looks like
step 4 of RFC 3626 is implemented in the ns-3 code, but I haven't debugged yet
why it adds no routes at this step.

2) however, even if the above entry is added, I don't think it will route
correctly.  OLSR will still return 192.168.0.1 to the caller for destination
192.168.0.3.  There needs to be some intelligence somewhere (either in the
caller or in OLSR) to know that 192.168.0.1 is not on-link, and that 172.16.0.2
is the next hop for 192.168.0.1.  So, either OLSR would need to add those
routes (which seem to be outside of what the RFC specifies) or Ipv4L3Protocol
would need to know to recurse, ask again for next hop to 192.168.0.1, and OLSR
would then have to return 172.16.0.2 instead of 192.168.0.1.

So, I'm doubtful there is an easy, purely OLSR fix for this.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.