[Olsr-dev] Re: why adding mac address in hello-msg

Henning Rogge (spam-protected)
Mon Oct 12 19:24:03 CEST 2015


Hi,

I have added a function called nhdp_writer_set_mac_TLV_state() to the
NHDP subsystem that allows you to switch off the MAC_TLV, either if
you don't need it or if you can get the information from a different
source.

This should make experiments easier to find a better solution for this "hack".

Henning

On Mon, Oct 12, 2015 at 3:55 PM, xl <(spam-protected)> wrote:
> Basicly,I agree with you.I understand even the olsrv2 would cost much more than 6 Bytes.
> But for the most part of my Heterogeneous network, radio resources are quit sufficient.And for some other important reasons, I have to try the mesh protocol.At least I have to try and prove thart it is imposible.
> Thank you for your suggestion.
>
>
>  "Ferry Huberts";<(spam-protected)>;
>  Re: [Olsr-dev] why adding mac address in hello-msg
>
> On 12/10/15 07:47, work_xl wrote:
>> I know the mac Bytes cost only a little for wifi.But I am working on a
>> network in which some channels are so bad ,every Byte is important.I
>> will try to set a constant metric for these channels and test the
>> performance.
>>
>
> If you can't spare 6 bytes in such a message then maybe you shouldn't
> run a mesh protocol over it. You should at least think very hard about
> it :-)
>
>>
>>
>> On 2015-10-11 21:03 , Henning Rogge <mailto:(spam-protected)> Wrote:
>>
>>     What metric do you plan to use?
>>
>>     the MAC tlv is not that much overhead because its only in the Hello
>>     messages, which are not flooded through the network.
>>
>>     Henning
>>
>>     P.S.: please reply to the mailing list if possible so that other
>>     people can learn from your experience and handling of the software.
>>
>>     On Sun, Oct 11, 2015 at 2:45 PM, work_xl <(spam-protected)> wrote:
>>      > Thank you for your instruction.Now I can understand your
>>     "beautiful"mac
>>      > hack. I would not use DATmetric.So I will just cut this mac bytes
>>     for lower
>>      > radio channel cost and see what's going to happen.
>>      >
>>      >
>>      > On 2015-10-10 18:08 , Henning Rogge Wrote:
>>      >
>>      > Hi,
>>      >
>>      > very nice to see someone noticed this "slightly ugly hack".
>>      >
>>      > The DAT metric I use for NHDP/OLSRv2 uses linklayer information
>>     to get
>>      > the incoming datarate for each neighbor... unfortunately the nl80211
>>      > subsystem (of course) does only know the MAC address of the
>>     neighbors,
>>      > so I need a way to know which MAC address corresponds to which NHDP
>>      > neighbor (which I know via IP address).
>>      >
>>      > The joke is that while every incoming (linklocal) multicast from the
>>      > neighbors contains the MAC address in the ethernet header, there
>>     is no
>>      > way in Linux to get the MAC address of an incoming UDP packet except
>>      > for using a raw socket... which are a headache to use with multicast
>>      > (e.g. creating the necessary IGMP/ICMPv6 multicast join/leave
>>      > messages).
>>      >
>>      > I still hope there is a better way to do this, but until someone
>>      > suggest one I just added the MAC address to each NHDP HELLO
>>     message as
>>      > an easy way to get the MAC address of the other sides interface.
>>      >
>>      > Henning
>>      >
>>      > On Sat, Oct 10, 2015 at 5:26 AM, work_xl <(spam-protected)> wrote:
>>      >> Hi,
>>      >> In nhdp plugin code,there is a msg tlv named
>>     NHDP_MSGTLV_MAC.Writer write
>>      >> it
>>      >> and reader read it.But I could not find it in both rfc6130 and
>>     rfc7181.On
>>      >> the other hand,I did not realize its function in the codes
>>     .So,why do we
>>      >> add
>>      >> this tlv?What could happen if I just remove it?
>>      >> Best regards.
>>      >>
>>      >> xl
>>      >>
>>      >> --
>>      >> Olsr-dev mailing list
>>      >> (spam-protected)
>>      >> https://lists.olsr.org/mailman/listinfo/olsr-dev
>>     Q
>>
>>
>>
>
> --
> Ferry Huberts
> --
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev



More information about the Olsr-dev mailing list