I'm running 2 OpenWrt devices. One in dump AP mode and the other strictly at gateway router.
The dumb AP and Gateway router have the exact same configuration with multiple VLANs. I'm able to obtain DHCP addresses on all VLANs from the router via the WiFI on Dumb AP fine except on VLAN4 for some reason.
I have the LAN port assigned a maintenance address of 192.168.169.2 if that matters. When joining any associated WiFI to br-VLAN other than br-VLAN4 its works great! I can see on the Dumb AP DHCP ACKs but WiFI devices never get assigned an IP. However, computers seem to obtain an IP on VLAN4 fine. Might I add, the Ethernet Switch is a Mikrotik running SWOS and the port the Dumb AP is plugged into is set to accept all tagged traffic, however any untagged traffic it forces a VLAN4 assignment. This has got to be something really dumb on my part.
root@ap01-sbl:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.169.1 0.0.0.0 UG 0 0 0 br-lan
10.3.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-VLAN3_VOX
10.5.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-VLAN5_UNT
10.6.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-VLAN6_UNT
10.7.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-VLAN7_PRT
10.69.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-VLAN9_UNT
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-VLAN4_UNT
192.168.8.0 0.0.0.0 255.255.255.0 U 0 0 0 br-VLAN8_UNT
192.168.169.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
WAN port is disabled. Any help greatly appreciated. P.S. I did try creating another VLAN and placing that WiFI on it with a different IP schema and it works fine, however, I need that WiFI to be on the same subnet as the Ethernet LAN its sitting on 192.168.2.0/24.
Before diving in on the VLAN 4 question, why does the AP need anything more than a single IP address on a single, management VLAN?
Clients of a bridging AP typically don't need to access anything on the AP itself. Adding an IP on each VLAN complicates firewall rules if your intent is to block access to the AP itself from various clients on anything but the "management VLAN".
If you do decide that for some reason you need an address on every VLAN, I'd look into if your "master" DHCP is supplying DHCP on that VLAN. tcpdump or Wireshark would be the tools I'd use to confirm that the packets are reaching the AP and your DHCP server as expected.
No SSID / LAN Management IP 192.168.169.2
SSID 4 <-> VLAN4 192.168.2.2 Ether ----- Ether 192.168.2.1 VLAN4 DHCP Server
SSID 5 <-> VLAN5 10.5.10.2 Ether ---------Ether 10.5.10.1 VLAN5 DHCP Server
etc.. etc..
Ironically, the working SSIDs that are able to obtain an IP from the Router are also able to access the Dumb AP as well as the Routers Luci. However, computers on the LAN Ethernet on the same VLAN have to use the 192.168.169.2 address to access Luci on the Dumb AP and the gateway address on the Router gives them Luci. I'm not trying to block access to the Router or Dumb AP, just enable WiFI through it and have each client be on the proper VLAN. Hope that answers your question.
The logreads:
Router:
Mon Mar 11 09:37:57 2019 daemon.info dnsmasq-dhcp[16498]: DHCPDISCOVER(br-VLAN4_UNT) 38:f7:3d:05:9f:09
Mon Mar 11 09:37:57 2019 daemon.info dnsmasq-dhcp[16498]: DHCPOFFER(br-VLAN4_UNT) 192.168.2.207 38:f7:3d:05:9f:09
Mon Mar 11 09:37:57 2019 daemon.info dnsmasq-dhcp[16498]: DHCPDISCOVER(br-VLAN4_UNT) 38:f7:3d:05:9f:09
Mon Mar 11 09:37:57 2019 daemon.info dnsmasq-dhcp[16498]: DHCPOFFER(br-VLAN4_UNT) 192.168.2.207 38:f7:3d:05:9f:09
Mon Mar 11 09:38:05 2019 daemon.info dnsmasq-dhcp[16498]: DHCPDISCOVER(br-VLAN4_UNT) 38:f7:3d:05:9f:09
Mon Mar 11 09:38:05 2019 daemon.info dnsmasq-dhcp[16498]: DHCPOFFER(br-VLAN4_UNT) 192.168.2.207 38:f7:3d:05:9f:09
Dumb AP:
Mon Mar 11 09:13:20 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 38:f7:3d:05:9f:09
Mon Mar 11 09:13:50 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 38:f7:3d:05:9f:09
Mon Mar 11 09:13:50 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: disassociated
Mon Mar 11 09:13:51 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Mar 11 09:13:52 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: authenticated
Mon Mar 11 09:13:52 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: associated (aid 1)
Mon Mar 11 09:13:52 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 38:f7:3d:05:9f:09
Mon Mar 11 09:14:23 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 38:f7:3d:05:9f:09
Mon Mar 11 09:14:23 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: disassociated
Mon Mar 11 09:14:24 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Mar 11 09:14:25 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: authenticated
Mon Mar 11 09:14:25 2019 daemon.info hostapd: wlan1: STA 38:f7:3d:05:9f:09 IEEE 802.11: associated (aid 1)
Mon Mar 11 09:14:25 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 38:f7:3d:05:9f:09
Mon Mar 11 09:14:56 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 38:f7:3d:05:9f:09
Hi @mpa yes, sort of. All the WiFI VLANs are working through each corresponding Ethernet VLAN through the Dumb AP, just not WiFI DHCP through VLAN4. I think it has something to do with the SWOS switch -- the port the Dumb AP is plugged into forces VLAN4 on DHCP request on untagged traffic. The IP being sent doesn't seem to make it back through the Dumb AP for WiFI client assignment.
As stated, all other work fine. It has something to do with the 192.168.2 range and untagged traffic on the switches port being forced to a VLAN4 assignment. But in fact, does not.
Still no reason to need for an IP address on the "slave" AP for anything but a single, management VLAN.
Just bridge the wlan device for each SSID to the proper sub-interface on the wired for the VLAN in question.
config interface 'vlanNNNN'
option type 'bridge'
option stp '1'
option ifname 'eth0.NNNN'
option proto 'none'
option auto '1'
option delegate '0'
(or whatever the Ethernet device you use is). /etc/config/wireless then references vlanNNNN as the UCI interface to associate with. option delegate'0', as I recall, turns off IPv6 delegation to the interface and is "optional", depending on your personal preferences and objectives.
Most people want VLAN isolation. In that case, the slave AP should have firewall rules that block VLAN-to-VLAN traffic.
Attempting your bridge approach now, the Dumb AP documentation specifically state to give the interface a static one up from the gateway e.g. 192.168.2.1, 192.168.2.2
Looks like there is no proto 'auto" in the drop down for Luci. I was able to get close to your config though by blanking at the static fields, probably won't work - but trying anyway.
config interface 'VLAN4_UNT'
option proto 'static'
option type 'bridge'
option delegate '0'
option ifname 'eth0.4'
option stp '1'
There's no need for the packets from the clients of the slave AP to be routed by the slave AP when they are bridged.
Client X comes on line and connects to SSID X
Client X sends a broadcast DHCP discover
Slave AP bridges this packet onto VLAN X (and it goes out over the wire)
DHCP server sees this packet on VLAN X and offers 10.11.12.13/24, default router 10.11.12.1
The packet goes out over the wire and the bridge on Slave AP recognizes the MAC, and sends to to Client X
Client X completes the DHCP exchange, and wants to send an off-link packet
Client X ARPs for 10.11.12.1, which is bridged over the wire and Master Router responds
Client X sends 10.11.12.13 => 1.2.3.4 via the MAC address the ARP reply specified for 10.11.12.1
...
By properly bridging them over a VLAN, they are all on the same network segment. Slave AP doesn't do anything more than transparently bridge the packets destined for delivery through the default route via Master Router.
Thanks for the bullets, I understand what a bridge is. However there is no "auto" protocol via Luci unless I'm missing a package. I've tried the exact flat file config you've provided by using uci to set proto to auto, DHCP addresses are still not getting to the Client X connecting to SSID X.
Here is the Mikrotik Ethernet Switch and Port VLAN info the Dumb AP is plugged into:
All untagged traffic is directed Router DHCP server to assign an address on VLAN4. Whats weird is when tagged traffic e.g. VLAN5 is passed to it, it directs DHCP server on Router to assign a VLAN5 address... which is successful. Its only when a VLAN4 address is requested via WiFI X client assignment fails.
That's because auto is not a protocol.
After creating the interface, go to its "Advanced Settings" tab and check "Bring up on boot", which will set the auto option. This is necessary because an interface with option proto 'none' is not started automatically by default, and you want it to be started since you are using it as a bridge.
There is still the untagged VLAN 1 on OpenWrt - maybe this is mapped to VLAN 4 by the switch and causes confusion? Can you make a direct connection between router and AP without the switch?
PS @jeff I've applied your recommendation to the other VLANs 3, 5, and 6 and they all continue to work properly with no statics thanks. VLAN4 is a head scratcher.
At least for the way I work, I always set a VLAN tag on all my trunks. That way there's never any question as to what will happen with an untagged packet. No untagged packets, "period". I set the PVID to a value that is not assigned to any port. I prefer 4095 as it is the standard "internal only" VLAN (at least for Cisco SG300 switches), though, as I recall, not supported by the switches on the OpenWrt devices I use.
@mpa thats exactly whats happening I bet. The switch is configured to direct all untagged traffic to be tagged VLAN4. I had to setup the switch like this in order to accommodate your question in the link thread regarding DHCP Option: 132,VID=3. I have VoIP phones that are daisy chained to computers using the phone's PC port. The computers get assigned VLAN4, The phones send out Option 132 telling the Router they belong to VLAN3, the Router changes their VLAN4 address to a VLAN3 address and tag. Works great! However, stumps a dumb ap.
I'm trying the following now. I'm trying a few things with LAN interface and bridging to see if there is a work around.
Maybe succumb to their pre-configuration (as I understand it) and just stick with VLAN 3 for those devices. You've got another 4000 to pick from (though some require explicit configuration of VID and PVID if they are above the total number permitted by your OpenWrt switch).
I have to succumb to it unfortunately... the is the only way you can daisy chain as I understand it.
Computers <----> untagged traffic to port (switch says OK you're VLAN4 (192.168.2.0/24))
Computers <----> phones <-----> Phones are initially assigned to VLAN4 however DHCP server responds
twice due to receiving option 132,VID=3, then reassigns the phone to VLAN3 (10.3.10.0/24)
Well, it was the Switch as I've tested with a non-managed one. I think I have a work around, two actually. One: get IPs to WAP users via another VLAN, then place static routes from the VLAN to the VLAN4 so they can access VLAN4 or Two which would be really nice... does OpenWrt have the ability to pass DHCP options during request?
thanks. VLAN4 is a head scratcher.