netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"lede-dev@lists.infradead.org" <lede-dev@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>
Subject: DHCP via bridge in case of IPv4
Date: Sat, 9 Jul 2016 08:37:55 +0000	[thread overview]
Message-ID: <1468053400.5007.5.camel@synopsys.com> (raw)

Hello,

I was playing with quite simple bridged setup on different boards with
very recent kernels (4.6.3 as of this writing) and found one interesting
behavior that I cannot yet understand and googling din't help here as well.

My setup is pretty simple:
-------------       ------------------       -------------------------
| HOST      |       | "Dumb AP"      |       | Wireless client       |
| with DHCP |<----->(eth0)     (wlan0)<----->| attempting to         |
| server    |       |    \ br0 /     |       | get settings via DHCP |
-------------       ------------------       -------------------------

* HOST is my laptop with DHCP server that works for sure.
* "Dumb AP" is a separate board (I tried ARM-based Wandboard and ARC-based
  AXS10x boards but results are exactly the same) with wired (eth0) and wireless
  (wlan0) network controllers bridged together (br0). That "br0" bridge flawlessly
  gets its settings from DHCP server on host.
* Wireless client could be either a smatrphone or another laptop etc but
  what's important it should be configured to get network settings by DHCP as well.

So what happens "br0" always gets network settings from DHCP server on HOST.
That's fine. But wireless client only reliably gets settings from DHCP server
if IPv6 is enabled on "Dumb AP" board. If IPv6 is disabled I may see that
wireless client sends "DHCP Discover" then server replies with "DHCP Offer" but
that offer never reaches wireless client.

Well actually sometimes very-very rarely that offer may reach wireless client but
I cannot understand how to reproduce it reliably.

Still looks like enabling of IPv6 fixes that issue.

So my question here is: why I see that difference with IPv4 vs IPv6?

One sidenote:
  Somehow I figured out that in case of IPv4 so-called routing
  cache is absent (it was removed in Linux kernel 3.6) while with IPv6 it
  still exist. And assuming my hardware is sane and no data gets lost I may
  think that it's really a routing problem and missing routing cache might
  be an answer. Still being a noob in networking stuff I'd like to get a bit
  better explanation of things I see.

All thoughts and comments are more than welcome.

Regards,
Alexey

             reply	other threads:[~2016-07-09  8:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-09  8:37 Alexey Brodkin [this message]
2016-07-09 11:47 ` [LEDE-DEV] DHCP via bridge in case of IPv4 Aaron Z
2016-07-09 12:05   ` Alexey Brodkin
2016-07-10  7:19     ` Russell Senior
2016-07-11  6:15       ` Alexey Brodkin
2016-08-16  5:57         ` Alexey Brodkin

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=1468053400.5007.5.camel@synopsys.com \
    --to=alexey.brodkin@synopsys.com \
    --cc=davem@davemloft.net \
    --cc=lede-dev@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).