From: Jonathan Haws <Jonathan.Haws@sdl.usu.edu>
To: "sven@narfation.org" <sven@narfation.org>,
"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.] [PATCH] IPv4 multicast distribution support.
Date: Wed, 18 Jan 2017 05:12:12 +0000 [thread overview]
Message-ID: <1484716332.8609.3.camel@sdl.usu.edu> (raw)
In-Reply-To: <1560076.ER48KEDWps@bentobox>
> > > > +int ipv4_to_mac(const alfred_addr *addr, struct ether_addr
> > > > *mac)
> > > > +{
> [...]
> >
> > >
> > > This will not return the mac address of the device. It will
> > > therefore
> > > break
> > > the synchronization code. see SOURCE_FIRST_HAND in sync_data and
> > > the
> > > code
> > > which sets data_source in finish_alfred_push_data.
> > You are correct - this does not return the MAC address of the
> > device.
> > Rather it uses the source IP address. Since we're dealing with
> > IPv4
> > in this case I believe it is safe to assume that the network has
> > been
> > properly configured and the remote node will have a valid IPv4
> > address,
> > which is used here. In my testing the synchronization and data
> > sharing
> > worked properly and all data was shared as expected.
> It should not be synced between masters when the data was received
> from a
> slave (because the master will not detect it as FIRST_HAND). If it
> does still
> work then you have a bug somewhere else.
>
> [...]
> >
> > What would you like to see here? Would you prefer an ARP request
> > to go
> > and get the MAC address of the remote node?
> Doesn't sound that nice. @Simon, do you have an opinion about this
> patch
> before Jonathan rewrites it? (It may take a while until he answers
> because he
> should be offline this week)
I got thinking about the testing I did and realized that I tested in a
setup where every node was set to master - there were no slaves. My
testing consisted of the following:
Node A:
$ cat hostname | alfred -s 100
Node B:
$ alfred -r 100
I was able to see the entry from the remote node (with the correct MAC
address) in the query result.
Is there a typical test routine that is used to ensure proper operation
of alfred? Should I simply add a third node to my setup and configure
it as a slave and make sure things operate properly or is there a more
automated test or better approach?
next prev parent reply other threads:[~2017-01-18 5:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 19:49 [B.A.T.M.A.N.] [PATCH] IPv4 multicast distribution support Jonathan Haws
2017-01-16 19:52 ` Jonathan Haws
2017-01-17 7:44 ` Sven Eckelmann
2017-01-17 15:39 ` Jonathan Haws
2017-01-17 16:54 ` Sven Eckelmann
2017-01-17 19:11 ` Linus Lüssing
2017-01-18 5:12 ` Jonathan Haws [this message]
2017-01-18 8:11 ` Sven Eckelmann
2017-01-17 19:30 ` Linus Lüssing
2017-01-18 5:06 ` 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=1484716332.8609.3.camel@sdl.usu.edu \
--to=jonathan.haws@sdl.usu.edu \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=sven@narfation.org \
/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