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 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 The 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: I 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.

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

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. The 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?

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.

Code: Select all

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 none

The 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?

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.

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?

@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.

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:
viewtopic.php?f=2&t=138232

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.

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?

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?

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

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.

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