Trouble with DHCP on Wireless

RouterOS Wireless Networking
1

Dear Community,

I have some trouble with DHCP on a wireless network.
The DHCP Server sits on the Interface VLAN200, which is attached to a bridge.
Wireless is configured via Capsman
/caps-man datapath
add arp=enabled bridge=bridge-VNET client-to-client-forwarding=yes name=VLAN200 vlan-id=200 vlan-mode=use-tag
add arp=enabled channel.band=5ghz-a/n/ac channel.control-channel-width=20mhz channel.extension-channel=disabled channel.frequency=5200 configuration.mode=ap configuration.ssid=test-5g
datapath=VLAN200 disabled=no l2mtu=1600 mac-address=CE:2D:E0:5D:89:17 master-interface=cap2-5G name=test radio-mac=CC:2D:E0:5D:89:17 rates=basic_default security.authentication-types=
wpa2-psk security.encryption=aes-ccm security.group-encryption=aes-ccm security.group-key-update=1h security.passphrase=supersecret
DHCP actually works for another (wired) client connected to ether1 and tagged with vlan200.
Also the DHCP seems to register and answer to the DHCP Request but the answer never reaches the client.
The Output from logging seems fine for me (Prefix DHCP-Fail):
21:43:33 system,info log rule changed by admin
21:43:47 caps,info E4:RE:DA:CT:ED:XX@test connected, signal strength -55
21:43:52 dhcp,debug,packet DHCP-FAIL: Guest-DHCP-Server received discover with id 1470733553 from 0.0.0.0
21:43:52 dhcp,debug,packet DHCP-FAIL: secs = 5
21:43:52 dhcp,debug,packet DHCP-FAIL: ciaddr = 0.0.0.0
21:43:52 dhcp,debug,packet DHCP-FAIL: chaddr = E4:RE:DA:CT:ED:XX
21:43:52 dhcp,debug,packet DHCP-FAIL: Msg-Type = discover
21:43:52 dhcp,debug,packet DHCP-FAIL: Host-Name = “Client-Hostname”
21:43:52 dhcp,debug,packet DHCP-FAIL: Parameter-List = Subnet-Mask,Broadcast-Address,Unknown(2),Classless-Route,Domain-Name,Domain-Server,Host-Name,Unknown(40),Unknown(41),NTP-Server,Interface-MTU,Domain-Search,Router,Classless-Route,MS-Classless-Route,Static-Route,Auto-Proxy-Config,NTP-Se
21:43:52 dhcp,debug,packet DHCP-FAIL: rver
21:43:52 dhcp,debug,packet DHCP-FAIL: Client-Id = SO-ME-RA-ND-OM-WI-RE-LE-SS-CL-IE-NT-ID-US-ED-BY-TH-ED-HC-PS-ER-VE-R3
21:43:52 firewall,info DHCP input: in:vlan200 out:(unknown 0), src-mac E4:RE:DA:CT:ED:XX, proto UDP, 0.0.0.0:68->255.255.255.255:67, len 333
21:43:53 dhcp,debug,packet DHCP-FAIL: Guest-DHCP-Server sending offer with id 1470733553 to 172.22.15.183
21:43:53 dhcp,debug,packet DHCP-FAIL: ciaddr = 0.0.0.0
21:43:53 dhcp,debug,packet DHCP-FAIL: yiaddr = 172.22.15.183
21:43:53 dhcp,debug,packet DHCP-FAIL: siaddr = 172.22.15.1
21:43:53 dhcp,debug,packet DHCP-FAIL: chaddr = E4:RE:DA:CT:ED:XX
21:43:53 dhcp,debug,packet DHCP-FAIL: Msg-Type = offer
21:43:53 dhcp,debug,packet DHCP-FAIL: Server-Id = 172.22.15.1
21:43:53 dhcp,debug,packet DHCP-FAIL: Address-Time = 3600
21:43:53 dhcp,debug,packet DHCP-FAIL: Subnet-Mask = 255.255.255.0
21:43:53 dhcp,debug,packet DHCP-FAIL: Domain-Server = 172.22.15.253
21:43:53 dhcp,debug,packet DHCP-FAIL: NTP-Server = 0.0.0.0
21:43:53 dhcp,debug,packet DHCP-FAIL: Router = 172.22.15.253
21:44:05 dhcp,debug,packet DHCP-FAIL: Guest-DHCP-Server received discover with id 1470733553 from 0.0.0.0
21:44:05 dhcp,debug,packet DHCP-FAIL: secs = 18
21:44:05 dhcp,debug,packet DHCP-FAIL: ciaddr = 0.0.0.0
21:44:05 dhcp,debug,packet DHCP-FAIL: chaddr = E4:RE:DA:CT:ED:XX
21:44:05 dhcp,debug,packet DHCP-FAIL: Msg-Type = discover
21:44:05 dhcp,debug,packet DHCP-FAIL: Host-Name = “Client-Hostname”
21:44:05 dhcp,debug,packet DHCP-FAIL: Parameter-List = Subnet-Mask,Broadcast-Address,Unknown(2),Classless-Route,Domain-Name,Domain-Server,Host-Name,Unknown(40),Unknown(41),NTP-Server,Interface-MTU,Domain-Search,Router,Classless-Route,MS-Classless-Route,Static-Route,Auto-Proxy-Config,NTP-Se
21:44:05 dhcp,debug,packet DHCP-FAIL: rver
21:44:05 dhcp,debug,packet DHCP-FAIL: Client-Id = SO-ME-RA-ND-OM-WI-RE-LE-SS-CL-IE-NT-ID-US-ED-BY-TH-ED-HC-PS-ER-VE-R3
21:44:05 dhcp,debug,packet DHCP-FAIL: Guest-DHCP-Server sending offer with id 1470733553 to 172.22.15.183
21:44:05 dhcp,debug,packet DHCP-FAIL: ciaddr = 0.0.0.0
21:44:05 dhcp,debug,packet DHCP-FAIL: yiaddr = 172.22.15.183
21:44:05 dhcp,debug,packet DHCP-FAIL: siaddr = 172.22.15.1
21:44:05 dhcp,debug,packet DHCP-FAIL: chaddr = E4:RE:DA:CT:ED:XX
21:44:05 dhcp,debug,packet DHCP-FAIL: Msg-Type = offer
21:44:05 dhcp,debug,packet DHCP-FAIL: Server-Id = 172.22.15.1
21:44:05 dhcp,debug,packet DHCP-FAIL: Address-Time = 3600
21:44:05 dhcp,debug,packet DHCP-FAIL: Subnet-Mask = 255.255.255.0
21:44:05 dhcp,debug,packet DHCP-FAIL: Domain-Server = 172.22.15.253
21:44:05 dhcp,debug,packet DHCP-FAIL: NTP-Server = 0.0.0.0
21:44:05 dhcp,debug,packet DHCP-FAIL: Router = 172.22.15.253
21:44:05 firewall,info DHCP input: in:vlan200 out:(unknown 0), src-mac E4:RE:DA:CT:ED:XX, proto UDP, 0.0.0.0:68->255.255.255.255:67, len 333The last line is from the firewall log. There is a firewall rule allowing DHCP for that VLAN. I already disabled the DROP rule in the firewall:
/ip firewall filter
add action=accept chain=input comment=“allow est. related” connection-state=established,related
add action=accept chain=input log-prefix=allow-vnet src-address-list=allowed_to_router
add action=accept chain=input protocol=icmp
add action=accept chain=input comment=“Allow DHCP on VLAN200” dst-port=67 in-interface=vlan200 log=yes log-prefix=DHCP protocol=udp src-port=68
add action=drop chain=input comment=“DROP everything else” disabled=yes log=yes log-prefix=DROPI have already ensured that there is a Admin MAC Address configured in the bridge. RSTP is off and authoritative is set to after-2sec-delay

Any ideas on this?
Second question, maybe not related:
If I set “client-to-client-forwarding” to “no” the client is not able to reach the gateway (DHCP-Option: Router = 172.22.15.253). Seems like it can not resolve the MAC via ARP and therefore can not connect to the Gateway. So I had to set “client-to-client-forwarding=yes”. Which is not so good for an guest network. Can this behaviour been changed or do I need some firewall rules here to prevent clients from seeing each other?

Kind Regards and thanks a lot.

2

Check that capsman interface is set to be a tagged port for vlan200 on the bridge.

3

The Capsman Interface for the appropriate Wireless under "/interface bridge port" is actually shown as dynamic and can not been changed.
I have changed the Interface "CAP" to PVID200 but I dont see a change - the client still dont get an IP from the DHCP-Server.
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload

INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON

0 CAP bridge-VNET yes 200 0x80 10 10 noneThe message is still:
22:34:10 dhcp,warning Guest-DHCP-Server offering lease 172.22.15.183 for E4:RE:DA:CT:ED:XX without success
Also tagging is done at "/caps-man datapath" isnt it?

4

You need to change “create dynamic enabled” to “create enabled” in provision - this way you will have static interface.
Then you need to add this interface as tagged for vlan-ids=200 in /interface bridge vlan

Yes, tagging on ingress is done on the cap, and passed to the bridge already tagged.
As you don’t filter it in /interface bridge port for this cap, it is accepted on the bridge, and goes further as it should.
But the traffic in the opposite direction - from the bridge to cap - also needs to be tagged, so the cap itself could untag it.
If you pass it untagged - the cap won’t accept it.

5

Okay, I have changed the provision to “create enabled”.
My Test Interface is still “D” - dynamic and thus can not been changed it is set to PVID 1.
BUT I have now tagged the appropriate Interface in “/interface bridge vlan” with the correct VLAN and everything is working now.

@xvo: Thanks a lot.
Do you have any resources like documentation or tutorials on this? I would like to learn more about this.
I thought tagging here is not needed, since it is already done at capsman datapath.

Also, any thoughts on this?:
If I set “client-to-client-forwarding” to “no” the client is not able to reach the gateway (DHCP-Option: Router = 172.22.15.253). Seems like it can not resolve the MAC via ARP and therefore can not connect to the Gateway. So I had to set “client-to-client-forwarding=yes”. Which is not so good for an guest network. Can this behaviour been changed or do I need some firewall rules here to prevent clients from seeing each other?

6

You are welcome.

The thing is, that the whole approach on vlan filtering on the bridge is quite recent, and not very much is written on the topic yet.
Even the info on official wiki is a little mixed.
There was a rather informative thread here on the forum, but it didn’t involve wireless and capsman, just the general concept:
http://forum.mikrotik.com/t/sofware-vlan-bridge-on-ruteros-explained/122534/1

You are right about tagging - it was done on the cap interface, so the traffic got to the bridge already tagged and the PVID setting in /interface bridge port for cap interface was ignored and as the filtering was disabled for that port the frames were just admitted as is. That is why the request got to DHCP server in the first place.

The reason why the answer didn’t get back is not tagging, but untagging.
The frames were untagged too early - when leaving the bridge and entering the cap interface.
But the cap interface was to admit only tagged frames, so the untagged frames were discarded.

As a matter of fact there is a big difference between ethernet port and wlan (or cap) interface in this aspect:
you can think of ethernet interface like a hole in the bridge - the frame leaves unchanged the same time it enters.
All modifications or filters are done before.
On contrary wlan interface have both in and out sides, and it can modify and filter what passes through it.

That is strange.
“client-to-client-forwarding” should affect only traffic between two clients connected to the same radio.
Even the traffic between two different radios on the same AP should not be affected.
Are you sure that the problem is still persistent after you’ve solved the problem with vlan tagging?

7

xvo, I’ve spent days trying to troubleshoot VLANs + CAPsMAN, working on Saturday + Sunday because I’ve to deliver this tomorrow Monday at 8:00.
Not the easiest scenario to try CAPsMAN for the first time…
Now it works thanks to you.
Thanks a LOT.

8

Could you please post the code from your configuration? (export compact for this part) What did you actually change at the end?

  • example: Would this be correct?

/caps-man datapath
add bridge=bridge-for-cap bridge-horizon=7
client-to-client-forwarding=no local-forwarding=no name=datapath1
vlan-id=1000 vlan-mode=use-tag

/interface bridge
add admin-mac=B8:69:F4:4F:C9:7F auto-mac=no frame-types=
admit-only-vlan-tagged igmp-snooping=yes igmp-version=3
ingress-filtering=yes mld-version=2 name=bridge-for-cap
protocol-mode=none pvid=1000 vlan-filtering=yes

/interface bridge vlan
add bridge=bridge-for-cap tagged=
bridge-for-cap vlan-ids=1000