[Olsr-users] OLSR routing issue with highly connected node

[Mitar]

Hi!

On Fri, Dec 26, 2014 at 2:41 PM, Jernej Kos <(spam-protected)> wrote:
> I agree that it is better to prevent fragmentation as otherwise issues
> such as this one, where a wrong MTU was configured, would go overlooked
> since things would appear to work.
>
> But perhaps some reporting in case of fragmentation errors might be a
> good idea.

I agree. It is better to optimize behavior and ETX calculation, but it
should also be detected when things are going badly and reported.

Or, in fact, I do not think if it really matters if packets are
fragmented or not if we report that they are, when they are. (I do not
see much difference between saying "they are fragmented and they
should not be" and "they would be fragmented and they should not be".)

So, how we could detect this and report?


Mitar

> On 26. 12. 2014 14:38, Henning Rogge wrote:
>> On Fri, Dec 26, 2014 at 1:20 PM, Ferry Huberts <(spam-protected)> wrote:
>>> Maybe we should add some 'send' checks in the relevant send paths.
>>> In the pud plugin I had to add
>>>>
>>>>                                         /* force the pending buffer out if
>>>> there's not enough space for our message */
>>>>                                         if ((int)olsrMessageLength >
>>>> net_outbuffer_bytes_left(ifn)) {
>>>>                                           net_output(ifn);
>>>>                                         }
>>>
>>>
>>> because sometimes the buffer was already too full and I got error reports in
>>> the log. With these lines added those errors disappeared.
>>
>> We have the same for Hello/TC messages...
>>
>> see tc_set.c line 564 as an example.
>>
>> Yes, the code is really ugly because its done once per message
>> (instead of doing it in a generic way), but it should work (I think).
>>
>>> I also don't see anything explictly related to DF, I do see fiddling with
>>> interface MTUs. Code that - to me - looks entirely superfluous since we
>>> should let the network stack handle that kind of stuff.
>>
>> Fragmenting the OLSR UDP messages on IP level would interfere with the
>> ETX calculation... I think the "read the MTU and make them small
>> enough so they should not fragment" is a good approach.
>>
>>> I think there is not a particular good reason to not allow fragmenting.
>>> Once the mesh grows larger than 159 (for a normal 1500 MTU interface) we do
>>> need fragmentation.
>>
>> We already do fragment OLSR messages when necessary... the problem
>> just happens because the interface reports the wrong MTU and the
>> default settings of the IP stack prevent the IP stack from fragmenting
>> our UDP packets.
>>
>> Henning Rogge
>>
>
>
> --
> Olsr-users mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-users



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m