[Olsr-users] Received message to big to be forwarded

[Henning Rogge]

Can you give us the output of the txtinfo for both sides of a
connection that "fails" ?

"/link" and "/neigh" would be interesting to see.

Henning

On Sun, May 3, 2015 at 9:09 PM, Jernej Kos <(spam-protected)> wrote:
> Hello!
>
> I think it is only the link towards the central node that fails. At
> least on one node that I checked, the other links were fine.
>
>
> Jernej
>
> On 03. 05. 2015 20:03, Henning Rogge wrote:
>> Just another question...
>>
>> is it only the link towards the central node that gets killed? Or do
>> you see some malfunction at other links of these neighbors?
>>
>> Henning
>>
>> On Sun, May 3, 2015 at 6:50 PM, Jernej Kos <(spam-protected)> wrote:
>>> Hello!
>>>
>>> Yes, I think that all the failing links were towards the central nodes
>>> that were patched (the other nodes were not patched). But I can't be sure.
>>>
>>> So on the failing nodes, all the routing table entries towards the
>>> patched nodes were removed, while entries towards other neighbours were
>>> still there.
>>>
>>>
>>> Jernej
>>>
>>> On 01. 05. 2015 10:15, Henning Rogge wrote:
>>>> Hi,
>>>>
>>>> just to be sure, we are talking about links between nodes that did not
>>>> had the patch? Or links of other nodes to the "big central node" ?
>>>>
>>>> Henning
>>>>
>>>> On Thu, Apr 30, 2015 at 2:39 PM, Jernej Kos <(spam-protected)> wrote:
>>>>> Hello!
>>>>>
>>>>> It seems I spoke too soon. After deploying the patch on two of the
>>>>> largest nodes, several other nodes started gradually loosing
>>>>> connectivity and after 4 hours around a hundred nodes were already
>>>>> unreachable.
>>>>>
>>>>> Therefore I reverted the patch on those two nodes, which caused the
>>>>> other nodes to become routable again. Really strange.
>>>>>
>>>>>
>>>>> Jernej
>>>>>
>>>>> On 30. 04. 2015 11:33, Ferry Huberts wrote:
>>>>>> I'll push it into deployment stream.
>>>>>>
>>>>>>
>>>>>> On 30/04/15 11:23, Henning Rogge wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I will push it, it should not prevent the aggregation of larger
>>>>>>> packets, just the generation of large messages.
>>>>>>>
>>>>>>> We can give it a test until the next release... if we notice something
>>>>>>> is very wrong with the message aggregation, I have to look over it
>>>>>>> again.
>>>>>>>
>>>>>>> If it works, we can also backport it to the other release branches.
>>>>>>>
>>>>>>> Henning
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 30, 2015 at 11:03 AM, Ferry Huberts <(spam-protected)>
>>>>>>> wrote:
>>>>>>>> Henning,
>>>>>>>>
>>>>>>>> Shall we integrate your patch?
>>>>>>>> Can you push it?
>>>>>>>>
>>>>>>>> At least on master, unsure about other branches.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 30/04/15 10:44, Jernej Kos wrote:
>>>>>>>>>
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Sorry for taking so long, there were some other issues which prevented
>>>>>>>>> the tests. I've tested this again today on the nodes with most links
>>>>>>>>> and
>>>>>>>>> it seems that the patch does fix the issue.
>>>>>>>>>
>>>>>>>>> I will push the patch to our OpenWrt feeds so that we can test it more.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jernej
>>>>>>>>>
>>>>>>>>> On 28. 04. 2015 09:26, Henning Rogge wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> any news about the test?
>>>>>>>>>>
>>>>>>>>>> Henning
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 17, 2015 at 7:33 PM, Jernej Kos <(spam-protected)> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello!
>>>>>>>>>>>
>>>>>>>>>>> Ok, great, I will test it out. Thanks!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jernej
>>>>>>>>>>>
>>>>>>>>>>> On 17. 04. 2015 19:32, Henning Rogge wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Yes,
>>>>>>>>>>>>
>>>>>>>>>>>> start with the "lots of neighbors" nodes... this should already
>>>>>>>>>>>> resolve the problem. if it works (and if we cannot find a problem
>>>>>>>>>>>> with
>>>>>>>>>>>> it) we will commit it and it will be part of the next olsrd bugfix
>>>>>>>>>>>> release.
>>>>>>>>>>>>
>>>>>>>>>>>> Henning
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Apr 17, 2015 at 7:29 PM, Jernej Kos <(spam-protected)> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello!
>>>>>>>>>>>>>
>>>>>>>>>>>>> So it will not help at all if we deploy it only at nodes
>>>>>>>>>>>>> producing big
>>>>>>>>>>>>> announces? Then this will not help much as we can't just upgrade
>>>>>>>>>>>>> all
>>>>>>>>>>>>> the
>>>>>>>>>>>>> ~400 nodes at the moment.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jernej
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 17. 04. 2015 19:26, Henning Rogge wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you should deploy this patch on ALL nodes... it should work
>>>>>>>>>>>>>> against
>>>>>>>>>>>>>> the current "master branch"... but also against your source.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Henning
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Apr 17, 2015 at 7:25 PM, Jernej Kos <(spam-protected)> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So if I understand this code correctly, this will limit the
>>>>>>>>>>>>>>> maximum
>>>>>>>>>>>>>>> message size that an originator node will produce? So I should
>>>>>>>>>>>>>>> apply
>>>>>>>>>>>>>>> this patch at the nodes with high neighbour count?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Against which revision is this? I will test the patch over the
>>>>>>>>>>>>>>> weekend
>>>>>>>>>>>>>>> and report back.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jernej
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 17. 04. 2015 16:41, Henning Rogge wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jernej,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> can you test the following patch?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/src/net_olsr.c b/src/net_olsr.c
>>>>>>>>>>>>>>>> index afd24ec..4db54b1 100644
>>>>>>>>>>>>>>>> --- a/src/net_olsr.c
>>>>>>>>>>>>>>>> +++ b/src/net_olsr.c
>>>>>>>>>>>>>>>> @@ -258,7 +258,14 @@ net_outbuffer_push_reserved(struct
>>>>>>>>>>>>>>>> interface_olsr
>>>>>>>>>>>>>>>> *ifp, const void *data, const
>>>>>>>>>>>>>>>>    int
>>>>>>>>>>>>>>>>    net_outbuffer_bytes_left(const struct interface_olsr *ifp)
>>>>>>>>>>>>>>>>    {
>>>>>>>>>>>>>>>> -  return ifp->netbuf.maxsize - ifp->netbuf.pending;
>>>>>>>>>>>>>>>> +  /* IPv6 minimum MTU - IPv6 header - UDP header - VLAN-Tag */
>>>>>>>>>>>>>>>> +  static int MAX_REMAINING = 1280 - 40 - 8 - 4;
>>>>>>>>>>>>>>>> +  int remaining = ifp->netbuf.maxsize - ifp->netbuf.pending;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +  if (remaining > MAX_REMAINING) {
>>>>>>>>>>>>>>>> +    return MAX_REMAINING;
>>>>>>>>>>>>>>>> +  }
>>>>>>>>>>>>>>>> +  return remaining;
>>>>>>>>>>>>>>>>    }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Henning
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ferry Huberts
>>>>>>
>>>>>
>>>
>