[Olsr-dev] Smartgateway

[Teco Boot]

Op 9 dec. 2011, om 11:45 heeft Henning Rogge het volgende geschreven:

> On 12/09/2011 11:39 AM, Teco Boot wrote:
>> I tested a bit more.
>> I took GW function on 173 down.
>> Then, 173 started use tunnel to 179, which is no GW anymore (wrong).
>> 179 lost tunnel to 173 and default routes, because 173 stopped announcing
>> as SGW. 179 sends ICMP net unreachable to 173, as reply on packets to
>> Internet.
>> 
>> An olsrd restart on 179 did remove the SGW tunnel on 173 (because no link to
>> 179: cleanup HNA&  SGW).
>> 
>> During a reproduction, I had some trouble when verifying self advertised HNA.
>> Same for self advertised SGW info. It would be nice to include this in the
>> txtinfo output.
>> 
>> With tcpdump, the SGW is shown as 0.0.0.0/4294967295 (0/32), HNA info in packet
>> was 0000 0000 0007 5903. I think /32 is shown if first mask bit(s) is(are) 0.
>> Could be improved.
> You mean /0 instead of /32, right?
No, the mask is displayed as /4294967295, which is 255.255.255.255. Sounds like /32.
It would be nice tcpdump shows the SGW info encoded in the mask.

> The SmartGw use a "shortcut" in the OLSR.org code to place additional information into the 0.0.0.0/0 HNA. OLSR.org ignores bytes 2-4 if the first byte is zero, so this three bytes are used for propagating data about the internet gateway.
> 
> Not a nice solution, but the 'best/easiest' I came up with for OLSRv1.
It *is* a nice solution. Maybe not the cleanest, but very useful for experiments.
Now we can learn and do it right in OLSRv2.
First steps is make it work and play with it.

FYI, the pud plugin uses the SGW table to find the "cluster leader", for downlink
multicast traffic (position info flooded with olsr msgs in our case).
It is important that we can rely on the SGW (stripped HNA) table.

>> More debugging:
>> When default route on 179 goes down, it takes some seconds before a HNA without
>> the SGW info is advertised. But then, the HNA&  SGW entries on the 173 must be
>> cleaned up. Or after time-out. It didn't. Maybe it is caused by lack of info
>> similar to txtinfo not showing HNA's that overlap an own HNA with same info?
> 
> There is some kind of filter in the OLSR.org code for not accepting HNAs which collide with local ones, but I have to look it up again to say how it works.
OK, maybe tunnel is set up during reception of such HNA, but tunnel is not cleaned up afterwards.

Teco

> 
> Henning Rogge
> 
> -- 
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Neuenahrer Straße 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:(spam-protected) http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev