[Olsr-users] Clarification about not compliant packet

[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
<(spam-protected)> 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
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-users