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.] [RFC PATCH] batman-adv: Increase DHCP snooped DAT entry purge timeout in DHT
Date: Tue, 10 Jul 2018 22:23:44 +0200 [thread overview]
Message-ID: <20180710202344.GB1525@otheros> (raw)
In-Reply-To: <20180625172919.GA2433@otheros>
On Mon, Jun 25, 2018 at 07:29:19PM +0200, Linus Lüssing wrote:
> Currently, we only update the DHT on outgoing (= into the mesh)
> ARP Replies. I'm worried that an ARP Request would never reach
> this node (B) during the whole extended timeout, therefore not
> triggering the necessary ARP Reply, therefore leaving this
> node unreachable over this whole time frame. Which would probably
> result in a lot of confusion, I guess.
Another option I was wondering about is whether we could go for
the original, simpler idea and add snooping of outgoing hw-src/IP-src
pairs from ARP Requests. And whether that could be frequent and
reliable enough to avoid confusion for the previously mentioned
scenario.
I'm also wondering why we do not snoop outgoing ARP Requests yet,
why we only snoop ARP Replies. Currently, in
batadv_dat_snoop_outgoing_arp_request() there is only a:
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
to fill the local DAT cache. But something like a
"batadv_dat_send_data(bat_priv, skb, ip_src, vid, BATADV_P_DAT_DHT_PUT);"
to update the DHT seems absent.
Am I missing something?
next prev parent reply other threads:[~2018-07-10 20:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 23:48 [B.A.T.M.A.N.] [RFC PATCH] batman-adv: Increase DHCP snooped DAT entry purge timeout in DHT Linus Lüssing
2018-06-03 11:53 ` Marek Lindner
2018-06-25 17:29 ` Linus Lüssing
2018-07-10 20:23 ` Linus Lüssing [this message]
2018-07-20 4:47 ` Antonio Quartulli
2019-01-05 21:02 ` Linus Lüssing
2018-07-20 4:06 ` Marek Lindner
2019-01-05 20:41 ` Linus Lüssing
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=20180710202344.GB1525@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox