Re: [LEDE-DEV] DHCP via bridge in case of IPv4
Hello, On Mon, 2016-07-11 at 06:15 +, Alexey Brodkin wrote: > Hi Russel, > > On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote: > > > > > > > > > "Alexey" == Alexey Brodkinwrites: > > Alexey> Hi Aaron, > > Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > > > > > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > > > > wrote: > > > > > > > > > > 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. > > > > > > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > > > > https://wiki.openwrt.org/doc/howto/clientmode > > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't > > be an issue. It's only client-mode interfaces that have trouble with > > bridging. > > > > I'd suggest running tcpdump on the Dumb AP's wireless interface and the > > client's wireless interface and see which of them sees the various parts > > of the DHCP handshake. > > So I did but for DHCP server and wireless client (had no tcpdump on Dump AP > at the moment). > > That's what I see on the server: > ->8--- > No. TimeSource Destination Protocol Length Info > 3 0.151181000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 11 2.760796000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 14 5.220985000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 15 5.22115 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 23 15.649835000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 24 15.650017000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 32 25.648589000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 33 25.648758000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 43 35.864567000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 48 38.832837000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > ->8--- > > That's on the wireless client: > ->8--- > No. Time Source Destination Protocol Length Info > 1171 94.192971000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1182 99.263686000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1185 109.692642000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1186 119.691474000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1190 129.907507000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > ->8--- > > I'll try to capture data from Dumb AP sometime soon and will reply to the > thread. So finally after quite some time I figured out what
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
Hello, On Mon, 2016-07-11 at 06:15 +, Alexey Brodkin wrote: > Hi Russel, > > On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote: > > > > > > > > > "Alexey" == Alexey Brodkin writes: > > Alexey> Hi Aaron, > > Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > > > > > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > > > > wrote: > > > > > > > > > > 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. > > > > > > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > > > > https://wiki.openwrt.org/doc/howto/clientmode > > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't > > be an issue. It's only client-mode interfaces that have trouble with > > bridging. > > > > I'd suggest running tcpdump on the Dumb AP's wireless interface and the > > client's wireless interface and see which of them sees the various parts > > of the DHCP handshake. > > So I did but for DHCP server and wireless client (had no tcpdump on Dump AP > at the moment). > > That's what I see on the server: > ->8--- > No. TimeSource Destination Protocol Length Info > 3 0.151181000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 11 2.760796000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 14 5.220985000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 15 5.22115 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 23 15.649835000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 24 15.650017000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 32 25.648589000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 33 25.648758000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > 43 35.864567000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 48 38.832837000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- > Transaction ID 0x31dc321f > ->8--- > > That's on the wireless client: > ->8--- > No. Time Source Destination Protocol Length Info > 1171 94.192971000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1182 99.263686000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1185 109.692642000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1186 119.691474000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > 1190 129.907507000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - > Transaction ID 0x31dc321f > ->8--- > > I'll try to capture data from Dumb AP sometime soon and will reply to the > thread. So finally after quite some time I figured out what happens in my setup. Basically it all boils down to the
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
Hi Russel, On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > "Alexey" == Alexey Brodkinwrites: > Alexey> Hi Aaron, > Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > > > > > > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > > > wrote: > > > > > > > > > > > > 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. > > > > > > > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > > > https://wiki.openwrt.org/doc/howto/clientmode > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't > be an issue. It's only client-mode interfaces that have trouble with > bridging. > > I'd suggest running tcpdump on the Dumb AP's wireless interface and the > client's wireless interface and see which of them sees the various parts > of the DHCP handshake. So I did but for DHCP server and wireless client (had no tcpdump on Dump AP at the moment). That's what I see on the server: ->8--- No. TimeSource Destination Protocol Length Info 3 0.151181000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 11 2.760796000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 14 5.220985000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 15 5.22115 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 23 15.649835000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 24 15.650017000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 32 25.648589000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 33 25.648758000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 43 35.864567000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 48 38.832837000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f ->8--- That's on the wireless client: ->8--- No. Time Source Destination Protocol Length Info 1171 94.192971000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1182 99.263686000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1185 109.692642000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1186 119.691474000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1190 129.907507000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f ->8--- I'll try to capture data from Dumb AP sometime soon and will reply to the thread. -Alexey
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
Hi Russel, On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > "Alexey" == Alexey Brodkin writes: > Alexey> Hi Aaron, > Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > > > > > > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > > > wrote: > > > > > > > > > > > > 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. > > > > > > > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > > > https://wiki.openwrt.org/doc/howto/clientmode > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't > be an issue. It's only client-mode interfaces that have trouble with > bridging. > > I'd suggest running tcpdump on the Dumb AP's wireless interface and the > client's wireless interface and see which of them sees the various parts > of the DHCP handshake. So I did but for DHCP server and wireless client (had no tcpdump on Dump AP at the moment). That's what I see on the server: ->8--- No. TimeSource Destination Protocol Length Info 3 0.151181000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 11 2.760796000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 14 5.220985000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 15 5.22115 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 23 15.649835000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 24 15.650017000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 32 25.648589000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 33 25.648758000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 43 35.864567000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 48 38.832837000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f ->8--- That's on the wireless client: ->8--- No. Time Source Destination Protocol Length Info 1171 94.192971000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1182 99.263686000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1185 109.692642000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1186 119.691474000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1190 129.907507000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f ->8--- I'll try to capture data from Dumb AP sometime soon and will reply to the thread. -Alexey
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
> "Alexey" == Alexey Brodkinwrites: Alexey> Hi Aaron, Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: >> On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin >> wrote: >> > >> > 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. >> >> >> Do you have WDS enabled? If not, DHCP has issues in that scenario: >> https://wiki.openwrt.org/doc/howto/clientmode If the Dumb AP's wireless interface is in ap-mode, then this shouldn't be an issue. It's only client-mode interfaces that have trouble with bridging. I'd suggest running tcpdump on the Dumb AP's wireless interface and the client's wireless interface and see which of them sees the various parts of the DHCP handshake. -- Russell Senior, President russ...@personaltelco.net
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
> "Alexey" == Alexey Brodkin writes: Alexey> Hi Aaron, Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: >> On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin >> wrote: >> > >> > 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. >> >> >> Do you have WDS enabled? If not, DHCP has issues in that scenario: >> https://wiki.openwrt.org/doc/howto/clientmode If the Dumb AP's wireless interface is in ap-mode, then this shouldn't be an issue. It's only client-mode interfaces that have trouble with bridging. I'd suggest running tcpdump on the Dumb AP's wireless interface and the client's wireless interface and see which of them sees the various parts of the DHCP handshake. -- Russell Senior, President russ...@personaltelco.net
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
Hi Aaron, On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin >wrote: > > > > 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. > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > https://wiki.openwrt.org/doc/howto/clientmode I don't have WDS enabled. I tried to have as simple setup as possible. Still from what I see in the Wiki article above problem happens when there're 4 devices in the chain, right? Because as it says: >8 The 802.11 standard only uses three MAC addresses for frames transmitted between the Access Point and the Station. Frames transmitted from the Station to the AP don't include the ethernet source MAC of the requesting host and response frames are missing the destination ethernet MAC to address the target host behind the client bridge. >8 But in my case I only have 3 devices in the chain so I would think it's something else but issue described in the article. Anyways thanks for the hint. -Alexey
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
Hi Aaron, On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > wrote: > > > > 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. > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > https://wiki.openwrt.org/doc/howto/clientmode I don't have WDS enabled. I tried to have as simple setup as possible. Still from what I see in the Wiki article above problem happens when there're 4 devices in the chain, right? Because as it says: >8 The 802.11 standard only uses three MAC addresses for frames transmitted between the Access Point and the Station. Frames transmitted from the Station to the AP don't include the ethernet source MAC of the requesting host and response frames are missing the destination ethernet MAC to address the target host behind the client bridge. >8 But in my case I only have 3 devices in the chain so I would think it's something else but issue described in the article. Anyways thanks for the hint. -Alexey
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkinwrote: > 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. Do you have WDS enabled? If not, DHCP has issues in that scenario: https://wiki.openwrt.org/doc/howto/clientmode Aaron Z
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin wrote: > 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. Do you have WDS enabled? If not, DHCP has issues in that scenario: https://wiki.openwrt.org/doc/howto/clientmode Aaron Z