[Olsr-dev] Re： why adding mac address in hello-msg
Mon Oct 12 19:24:03 CEST 2015
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
This should make experiments easier to find a better solution for this "hack".
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
> 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.
>> 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
>> > 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
>> > 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
>> >> 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
> Ferry Huberts
> Olsr-dev mailing list
More information about the Olsr-dev