From: Sven Eckelmann <sven@narfation.org>
To: Jonathan Haws <jhaws@sdl.usu.edu>
Cc: "guohuizou2000@sina.com" <guohuizou2000@sina.com>,
"b.a.t.m.a.n@lists.open-mesh.org"
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] alfred and batadv-vis issue
Date: Tue, 23 Oct 2018 08:29:05 +0200 [thread overview]
Message-ID: <2008119.62L72lsrl6@bentobox> (raw)
In-Reply-To: <e287b33a075cd802539d75d95319805eee0010ea.camel@sdl.usu.edu>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Dienstag, 23. Oktober 2018 04:04:42 CEST Jonathan Haws wrote:
[...]
> > I have a doubt for the issue.
> > Alfred should send the info by multicast packets. So the packet's dst
> > mac address should be multicast mac address.
> > The packet with multicast mac address should be received by all group
> > member, isn't it?
> > Why does the mesh point need peer's mac address for sending the info?
>
> The rest of the devs may be able to answer better, but I believe it is
> how alfred does its data storage and mapping of the source.
Correct, alfred is storing the data from each server using its mac address. It
is also looking up the TQ of master servers via the mac address. And the mac
address is expected to be extractable from the EUI64 based link-local IPv6
address.
And of course, Jonathan's IPv4 implementation must get the mac address using
different methods. It is using the function ipv4_arp_request to get the
information from IPv4 neighbor table. And it looks like his implementation is
missing a reliable way to fill this neighbor table.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-10-23 6:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-18 5:53 [B.A.T.M.A.N.] alfred and batadv-vis issue gary
2018-10-18 6:22 ` Sven Eckelmann
2018-10-22 17:36 ` Jonathan Haws
2018-10-23 3:02 ` gary
2018-10-23 4:04 ` Jonathan Haws
2018-10-23 6:29 ` Sven Eckelmann [this message]
2018-10-23 9:52 ` gary
2018-10-23 10:25 ` Sven Eckelmann
2018-10-23 13:50 ` Jonathan Haws
2018-10-23 14:06 ` Sven Eckelmann
2018-10-23 14:11 ` Jonathan Haws
2018-10-23 14:16 ` Sven Eckelmann
2018-10-24 18:39 ` Jonathan Haws
2018-10-25 6:15 ` Sven Eckelmann
2018-10-25 9:06 ` gary
2018-10-29 16:07 ` Jonathan Haws
2018-10-29 16:48 ` Sven Eckelmann
2018-10-29 17:25 ` Jonathan Haws
2018-10-29 17:34 ` Sven Eckelmann
2018-10-30 5:24 ` gary
2018-10-30 14:20 ` Jonathan Haws
2018-10-30 14:27 ` Sven Eckelmann
-- strict thread matches above, loose matches on Subject: below --
2018-10-25 13:40 Jonathan Haws
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2008119.62L72lsrl6@bentobox \
--to=sven@narfation.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=guohuizou2000@sina.com \
--cc=jhaws@sdl.usu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox