Clarification about not compliant packet

[Lorenzo Salvatore]

Hi
I was trying to create a couple of parser for Hello and TC messages to add in a plugin. I've taken the default parsers to learn how to manage the packages. In the TC parser there were lots of strange thing but after checking I've understood that those were a set of operation to work with LQ. I'm neither interested nor annoyed by LQ, but if that modify packet I should know how.
For example, about Hello packet, I've seen that there is a check in the parser to know if the packet is a LQ Hello or not. In the first case it start the deserialization procedure for LQ (you can see those things in deserialize_hello). About TC packet the deserialization procedure is done every time, without checking if the packet is LQ or not. Why? Inside the deserialization process there is a check?
And then, if I let active the LQ plugin, every TC and Hello packets sent are LQ?
Anyway, how TC and Hello LQ packets are different from the standard?
Thanks in advance
--
Olsr-users mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

[Henning Rogge]

Hi,

both LQ_TC and LQ_Hello depend (in theory) on the metric
implementation, but all of OLSRd metrics use the same format and a
very similar semantic.

We add a four byte sequence at the end of each neighbor entry in Hello
and TC messages (right in front of the next address). One byte encodes
the LQ (link quality), one encodes the NLQ (neighbor link quality) and
two bytes are unused.

Wireshark can read the format, so this might be a good way for you to
learn more about the format.

I think we also use a "reserved" 2 byte field in the TCs to encode the
range of IPs for fragmented TCs, but you can just ignore the field if
you want.

Henning Rogge

On Wed, Feb 12, 2014 at 2:36 AM, Lorenzo Salvatore
<***@hotmail.it> wrote:
> Hi
> I was trying to create a couple of parser for Hello and TC messages to add in a plugin. I've taken the default parsers to learn how to manage the packages. In the TC parser there were lots of strange thing but after checking I've understood that those were a set of operation to work with LQ. I'm neither interested nor annoyed by LQ, but if that modify packet I should know how.
> For example, about Hello packet, I've seen that there is a check in the parser to know if the packet is a LQ Hello or not. In the first case it start the deserialization procedure for LQ (you can see those things in deserialize_hello). About TC packet the deserialization procedure is done every time, without checking if the packet is LQ or not. Why? Inside the deserialization process there is a check?
> And then, if I let active the LQ plugin, every TC and Hello packets sent are LQ?
> Anyway, how TC and Hello LQ packets are different from the standard?
> Thanks in advance
> --
> Olsr-users mailing list
> Olsr-***@lists.olsr.org
> https://lists.olsr.org/mailman/listinfo/olsr-users

--
Olsr-users mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

[Lorenzo Salvatore]

Thanks for the answer. I've used wireshark to better understand the differences between usual packets and lq packets and how bits are distributed. Anyway, to better understand also the implementation, why in the tc parser the lq deserialization is always done? In the hello parser there is a control if the packet is a LQ.
----------------------------------------
> From: ***@gmail.com
> Date: Wed, 12 Feb 2014 08:29:41 +0100
> Subject: Re: [Olsr-users] Clarification about not compliant packet
> To: ***@hotmail.it
> CC: olsr-***@lists.olsr.org
>
> Hi,
>
> both LQ_TC and LQ_Hello depend (in theory) on the metric
> implementation, but all of OLSRd metrics use the same format and a
> very similar semantic.
>
> We add a four byte sequence at the end of each neighbor entry in Hello
> and TC messages (right in front of the next address). One byte encodes
> the LQ (link quality), one encodes the NLQ (neighbor link quality) and
> two bytes are unused.
>
> Wireshark can read the format, so this might be a good way for you to
> learn more about the format.
>
> I think we also use a "reserved" 2 byte field in the TCs to encode the
> range of IPs for fragmented TCs, but you can just ignore the field if
> you want.
>
> Henning Rogge
>
> On Wed, Feb 12, 2014 at 2:36 AM, Lorenzo Salvatore
> <***@hotmail.it> wrote:
>> Hi
>> I was trying to create a couple of parser for Hello and TC messages to add in a plugin. I've taken the default parsers to learn how to manage the packages. In the TC parser there were lots of strange thing but after checking I've understood that those were a set of operation to work with LQ. I'm neither interested nor annoyed by LQ, but if that modify packet I should know how.
>> For example, about Hello packet, I've seen that there is a check in the parser to know if the packet is a LQ Hello or not. In the first case it start the deserialization procedure for LQ (you can see those things in deserialize_hello). About TC packet the deserialization procedure is done every time, without checking if the packet is LQ or not. Why? Inside the deserialization process there is a check?
>> And then, if I let active the LQ plugin, every TC and Hello packets sent are LQ?
>> Anyway, how TC and Hello LQ packets are different from the standard?
>> Thanks in advance
>> --
>> Olsr-users mailing list
>> Olsr-***@lists.olsr.org
>> https://lists.olsr.org/mailman/listinfo/olsr-users
--
Olsr-users mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

[Henning Rogge]

On 02/13/2014 02:54 AM, Lorenzo Salvatore wrote:
> Thanks for the answer. I've used wireshark to better understand the
> differences between usual packets and lq packets and how bits are
> distributed. Anyway, to better understand also the implementation,
> why in the tc parser the lq deserialization is always done? In the
> hello parser there is a control if the packet is a LQ.

It is not... at least it doesn't looks like this if you read tc_set.c
line 648 to 650.

Yes, the code of OLSRv1 is a huge mess of spaghetti... and nobody wants
to touch it anymore.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon [phone], Fax [phone]
mailto:***@fkie.fraunhofer.de http://www.fkie.fraunhofer.de