Hello misc@ I have a home router where it seems that DHCP over vr(4) on bridge(4) through vether(4) does not work.
Sorry about the lack of hard details, it was late last night, I was tired and need to figure out what details to look into now... The home router is an ALIX 2d13 which has 3 vr(4) interfaces on board and one athn(4) on mini-PCI. WAN is vr2, LAN is vr1 and WLAN is athn0. I had a setup working with dhcpd serving constant addresses based on MAC address to the LAN on vr0 and athn0 with one address range for vr0 and one for athn0. Now I need to start using the 5 GHz Wifi band so I asked the athn0 with "ifconfig athn0 chan" which channels it supported, tried to configure a 5 GHz one and got an IOCTL error so I guiss it was not acually supported. Then I bought an ASUS EA-N66 access point that can do 5 GHz and connected it to vr1. I did a bridge configuration according to the FAQ with bridge0 containing athn0, vr1 and vether0. vether0 got the IP address configuration that athn0 had before, dhcpd was reconfigured to serve vr0 and vether0 and that worked just fine. DHCP over athn0 passes through bridge0 and vether0 to dhcpd as well as directly from vr0 to dhcpd. But DHCP over vr1 through bridge0 and vether0 does not work. I had to configure a static address on the access point to get any further. I know that DHCP over vr0 that dhcpd serves directly works, and I know that it works when dhcpd serves athn0 directly, plus it works when dhcpd serves athn0 throught bridge0 and vether0. I tcpdumped vr1 (but now I was getting really tired) and saw 0.0.0.0.bootp -> 255.255.255.255.bootc packets that I think are DHCP broadcasts from a client. But when tcpdumping on vether0 I think I did not see them (lots of chatter), but possibly other strange packets. When letting a client connect over athn0, on the other hand, I think I saw these broadcast packets on vether0, and got log entries in /var/log/daemon about dhcpd giving out a license. Not so when letting a client connect over the access point and vr0. So my theory is that either have I missed some stupid little flag, or there is a bug in vr(4) when it passes packets over a bridge(4) to a vether(4) so encapsulation is misinterpreted and the IP broadcasts does not arrive in recognizable shape... Any hints on how to procede? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
