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

[Jernej Kos]

Hello!

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.


Jernej

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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20141226/2f59efa0/attachment.sig>