I set up a hAP ac2 to supply my laptops with Wifi. The hAP receives a trunk with various VLANs, one for the WiFi (3), which links the hAP to a hEX, which runs the DHCP and performs routing. This internal WiFi works like a charm.
Alas, I added a virtual interface to wlan1 for Guest access, hooked it to another VLAN (2), and it does not exchange any data. The clients can register with the guest net, they are rejected, if I enter the wrong passphrase, but they don’t receive DHCP. In fact, I cannot even MAC ping them from the very hAP.
I currently have no idea how to analyze the situation any further. As I see it, the two interfaces are set-up in exactly the same way. I’d appreciate any hints to further analyse the situation.
This is the a sanitized excerpt of the configuration of the hAP:
Of course this does not work by itself; you need to have another router connected to ether1-Trunk which has VLAN 2 configured with a network, DHCP server, firewall rules, etc.
There could be an error there.
When it is a MikroTik router as well, run a Torch or Packet Sniffer on the VLAN 2 there and see what happens when you connect a client.
As I said there is a hEX for providing DHCP connected to the trunk. Thanks for the hint with the packet sniffer, and now I’m completely confused. In the hEX I see a complete DHCP protocol. On the hAP I do not see the answers from the DHCP on the hEX. This is particularly strange, since I see the DHCP Request in both devices i.e., the client should have seen the DHCP Offer, which I did not see on the hAP. These are the wireshark analyses of the packet sniffer files.
# The hEX with the DHCP server sniffed on VLAN 2
0.0.0.0 255.255.255.255 DHCP Discover - Transaction ID 0x7da0dcf3
192.168.188.1 198.168.188.253 DHCP Offer - Transaction ID 0x7da0dcf3
0.0.0.0 255.255.255.255 DHCP Request - Transaction ID 0x7da0dcf3
192.168.188.1 198.168.188.253 DHCP ACK - Transaction ID 0x7da0dcf3
# The hAP with the wireless interface sniffed on VLAN 2
0.0.0.0 255.255.255.255 DHCP Discover - Transaction ID 0x7da0dcf3
0.0.0.0 255.255.255.255 DHCP Request - Transaction ID 0x7da0dcf3
Interestingly, if I sniff on the wireless interface itself i.e., Guest-Wifi not on VLAN 2, I see the responses of the DHCP server, which were on VLAN 2 in the hEX. It seems like downstream packets somehow by-pass VLAN 2 inside the hEX, which is strange. Sniffer settings were identical except for the interface.
Still wierder: sniffing VLAN3 looks the same, but on VLAN3 attached to wlan2 I have perfect DHCP and Internet connection.
I am confused as well. I use a similar setup with a RB4011 and a hAP ac2. It works.
The only difference I see is that I use protocol-mode=none on my bridge configurations.
Also, are you sure you have no /interface ethernet switch configuration on either device? (maybe leftover from old days)
Concerning the relevant VLANs it’s a straight line:
WAN – Fritz!Box --(192.168.178.0/24)-- hEX (ether3 Trunk with VLAN 2,3,4) – hAP ( wlan1,wlan2 on VLAN 3, Guest(wlan1) on VLAN2).
Nothing else on the hAP so far. The hEX has other trunks to other switches, none of them receive VLAN2 or VLAN3. VLAN4 is administration. All VLANs are associated with /24 networks of the 172.18.0.0 range. Except, VLAN3 is 192.168.188.0/24 and therefore addresses different NAT rules. However, since I’m beginning to set up the system, the firewall is empty except for NAT, yet.
I meanwhile sniffed on the trunk in between hEX and hAP. There I see the complete DHCP negotiation and all packets are in the correct VLAN. The DHCP server lists a proper lease for the client’s MAC. But I cannot ping the device.
I used a Linux system as client. Wireshark shows the complete DHCP protocol on the client, but not a single ICMP from the simultaneous /ping on the hAP. And, for whatever reason, the Linux system determines that the link is broken, retries and later deactivates the WLAN interface.
No, so far I didn’t. As I understood this is required to allow for hardware offloading, which at least in the hEX acting as router and firewall is not intended, is it? However, I tried:
/interface bridge set protocol-mode=none
on either box, and these prompt me for numbers:. I have no idea what to answer here.
You can set it in the GUI by going to STP tab in the bridge config and click “none” and OK.
Do it on both devices and see if there is a difference. When not, you can just leave it. If anything, it will prevent offloading, not allow it.
(but on your devices bridges with vlan filtering will never be offloaded)
There is no STP tab in the bridge config. I run 6.49.2. The tabs in the bridge config are: Bridge, Ports, Port Extensions, VLANs, MSTIs, Port MST Overrides, Filters, NAT, Hosts, MDB.
There is an STP tab in “Bridge Port”, but this does not exist for the wireless ports.
Ah, found. Setting to none didn’t change the situation.
I tried something else. I attached ether2 to the same VLAN, plugged in a laptop and see that it is configured to 192.168.188.252/32!
Well, I added 192.168.188.16/24 to the interface, tried to ping 192.168.188.1, but it fails. I neither see anything using torch on ether2 during the ping.
If I map ether2 to VLAN3 instead, everything works as expected; I get 172.18.34.252/24 and can ping 172.18.34.1. And, since the hEX does no firewalling so far, I can even ping 192.168.188.1. This situation does not change whether or not I chose RSTP on the bridges.
It seems I found the issue, and it’s a really dumb error. Having mistyped during a ping I re-checked for other typos and it turned out that the DHCP pool was in 198.168.188.0/24! After correcting the pool it seems to work. I set protocol-mode to the rstp default, and it still works.
Thanks for your help and patience, and sorry for my bad recognition of numbers.
At any time, no more than one wireless hosted network can be enabled on a local computer, and only one wireless adapter will be used by the wireless hosted network. If there is more than one wireless hosted network adapter, Windows will select one adapter to use with the wireless hosted network. When hosted network APIs are used, the hosted network capable wireless adapter is virtualized to a maximum of 3 logical adapters