All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCHv2 2/2] batman-adv: Snoop DHCPACKs for DAT
Date: Thu, 7 Jul 2016 12:14:42 +0200	[thread overview]
Message-ID: <20160707101442.GC7076@otheros> (raw)
In-Reply-To: <20160707092436.GH5978@prodigo.lan>

Hi Antonio,

> have you tried applying this patch on one of your servers and measure the local
> effect? (i.e. if the number of BRD ARP req is reduced or not?)

I had queried Martin Weinelt just yesterday, they will test it on
a 500 nodes compat-v15 setup soon :).

> 
> I think that a DHCP ACK packet should already refresh the local ARP cache (or
> not?), thus the need for an ARP request should not be triggered by the newly
> joined client. (I might be wrong, but that's why I ask measuring the effect)

Hm, I don't think that the operating system will snoop DHCPACKs
itself to fill its ARP cache. I didn't see that in the VMs either.

But now that you are asking, re-read my thoughts regarding ARP+DAT
on the Gluon issue tracker. Which made me wonder again, why
the issue occures in the first place (e.g. client issues an ARP
Request first - why does that one not fill the DAT appropriately,
why does it need to fallback from the unicast DAT query to an ARP
Request flood?).

Looking at the code again now, I have a hunch. Question: Why 
does batadv_dat_snoop_outgoing_arp_request() add the MAC/IP source
pair of the client to the local DAT cache only, why isn't it
propagated to the DHT?

Regards, Linus

  parent reply	other threads:[~2016-07-07 10:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05 18:01 [B.A.T.M.A.N.] [PATCHv2 1/2] batman-adv: Add wrapper for ARP reply creation Linus Lüssing
2016-07-05 18:01 ` [B.A.T.M.A.N.] [PATCHv2 2/2] batman-adv: Snoop DHCPACKs for DAT Linus Lüssing
2016-07-07  9:24   ` Antonio Quartulli
2016-07-07  9:43     ` Sven Eckelmann
2016-07-07 10:14     ` Linus Lüssing [this message]
2016-07-07 13:40       ` Linus Lüssing
2016-07-08  0:33         ` Antonio Quartulli
2016-07-10 11:42   ` Sven Eckelmann
2016-08-23  1:31     ` Linus Lüssing
2016-07-10 11:18 ` [B.A.T.M.A.N.] [PATCHv2 1/2] batman-adv: Add wrapper for ARP reply creation Sven Eckelmann
2016-10-18 13:01 ` [B.A.T.M.A.N.] [v2, " Sven Eckelmann

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=20160707101442.GC7076@otheros \
    --to=linus.luessing@c0d3.blue \
    --cc=b.a.t.m.a.n@lists.open-mesh.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.