[Olsr-dev] [PATCH v1 1/1] lq_packet: only report a neighbour once in a hello message

Henning Rogge (spam-protected)
Thu Jan 19 15:00:04 CET 2017


On Thu, Jan 19, 2017 at 2:57 PM, Ferry Huberts <(spam-protected)> wrote:

>
>
> On 19/01/17 13:33, Henning Rogge wrote:
>
>> Hi,
>>
>> back from (two) business trips...
>>
>> On Mon, Jan 16, 2017 at 6:14 PM, Ferry Huberts <(spam-protected)
>> <mailto:(spam-protected)>> wrote:
>>
>>     I think I may have stumbled onto a MUCH easier fix to this problem.
>>
>>
>>     The actual problem is quite involved (with fragmented hello messages
>>     etc) but it all boils down to a later UNSPEC link overwriting a
>>     previous SYM/ASYM/other link on the receiving end.
>>
>>     Since the neighbours in a hello message are already ordered when the
>>     hello message is sent out, the following patch also solves it.
>>
>>     Opinions?
>>
>>
>> I like the idea of solve the problem by sorting, but I worry that doing
>> so on the TX side is a bit "brittle"... its easy to break because there
>> is nothing on the TX side that needs this order. And there will always
>> be older Olsrd installations on many community networks.
>>
>> How difficult would it be to do the sorting on the RX side
>> in deserialize_hello() (process_package.c: 318..)?
>>
>> Instead of building them into a single linked list, have an array with
>> MAX_LINK lists, one for each link type... and then concatenate this
>> lists before parsing in the right order.
>>
>> This way we also fix the problem appearing again because of an outdated
>> Olsrd sending bad data, right?
>>
>>
>
> If we do that as a follow-up patch? Would that be ok?
>

Sounds good... quick fix now to solve the problem for the current code,
cleanup later to make it future proof.

Henning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20170119/912a1266/attachment.html>


More information about the Olsr-dev mailing list