I have a problem with cap interface if I enable VLAN.
VLAN mode = use tag
VLAN ID = 111
Than I create VLAN interface with VLAN ID = 111 on cap interface. After that dhcp cannot assign address on VLAN interface. It keeps saying “offering lease without success” in log.
If I set VLAN mode = none and add dhcp server directly on cap than everything works fine.
Any idea?
please upgrade the CAPsMAN system to RouterOS v6.13 and then check if you have some problems.
About the Vlan problem, please contact support@mikrotik.com and include the network diagram and support output files.
Sorry, I forgot to mention it was with v6.13.
After that I tried with setting interface to local forwarding mode. CAP device was set to add any intrface to local bridge.
When I add IP and DHCP server on that local bridge everything works fine. But, when I add VLAN interface to that bridge and move IP and DHCP to that VLAN then again there is a same problem with offering lease (on CAPsMAN I made changes to add aproppriate vlan tag to that interface).
If you add a vlan interface to the bridge ports you must leave the dhcp server on the bridge interface and not on one of the bridge ports.
Please contact support@mikrotik.com and include the network diagram and support output files from CAP and CAPsMAN.
No, I did not add VLAN as bridge port. I created VLAN interface which has bridge as it’s interface. That’s why I put dhcp on VLAN.
Point is:
Please contact > support@mikrotik.com > and include the network diagram and support output files from CAP and CAPsMAN.
Sure. Will do that.
Ok, now I am 100% sure this problem depends on VLAN implementation.
If I do not use VLAN tag in CAP interface configuration and leave it to connect CAP interface on bridge locally than everything works fine.
After I enable vlan tagging on CAP interface and put VLAN interface on top of local bridge interface CAP interface is connected to… then client keeps reconnecting every few seconds and log on CAPsMAN says “extensive data loss”. Client can be connected long enough to get address from dhcp but after few seconds it starts reconnecting.
As I said, without having VLAN on top of local bridge there is no problem at all.
Tested with several iOS, Android and OS X devices and every time it is the same situation.
Ok, still doing some testing when VLAN is on top of bridge…
As I said in my previous message, client keeps reconnecting with message in ROS log “extensive data loss”.
Before “extensive data loss” occurs log is saying this regarding communication with DHCP:
…dhcp received discover…
…dhcp sending offer…
…dhcp received request… (following by the same data it was offered)
…dhcp sending ack…
…dhcp received request…
…dhcp sending ack…
…dhcp received request…
…extensive data loss…
So, client receives offer from dhcp and send it back as request but it seems that ack never gets to client so it keeps resending it…?
looks like we were able to reproduce your problem - we hope we will be able to fix it soon.
Ok, thank you!
Wow, that was fast 
v6.14rc3 does not have this bug.
I’m pretty sure this is happening to me in 6.19.
I have three RB2011UiAS-2HnD-IN boxes linked together, spanning three floors of a building. They all all linked through HP switches on each floor of the building. Each HP switch carries VLAN-99 and the Mikrotik boxes are plugged in to untagged ports that are members of VLAN-99.
The Mikrotik boxes all communicate perfectly.
The box at the bottom floor is the CAPSMAN, and we are pushing out 3 SSIDs ‘patrol’, ‘staff’, and ‘public’. Each one has a datapath that maps:
patrol - VLAN-20
staff - VLAN-30
public - VLAN-60
The pfSense firewall has a port with those VLANs tagged and is running DHCP.
I can connect to any of the networks, and I see the same result:
DHCP packets arrive at the pfSense router on the correct VLAN for the SSID I am connecting to, the pfSense router returns an address, and then the wireless client never seems to receive the response.
Setting all the datapaths to not use VLAN tagging works correctly (after untagging the pfSense router as well), I am able to receive the DHCP packet and my phone connects.
Anything I should check/test next?
-A
^ I can confirm this.
When not doing local forwarding and using vlan tagging lease is being offered but client is not responding to that (at least that is what log shows, maybe client is responding but dhcp do not get that response).
This is only happening when vlan tag is used. Without it it works fine.
Another problem I have when doing vlan tagging + local forward is that wifi clients cannot communicate to each other. Option “client to client forwarding” is enabled but they can only communicate to devices not on the same ssid or to devices on ethernet. I tried adding another ssid (on same radio) with same vlan tag and then two clients can communicate only if they are on different ssid. Very important to say is that this problem is only present when doing vlan tagging. Without vlan tagging it all works fine.
Note: Wifi clients on same ssid but different CAP and same VLAN can communicate between each other. The problem is only when on same radio and ssid.
Could someone from MT try to reproduce this problem?
Anyone?
In the meantime I tried with other devices also on 6.20 and problem is there also so I am pretty sure it is not me
Could someone from MT please fix this issue?
So, to remind you:
CAPsMAN datapath config:
Bridge, bridge cost and bridge horizon: empty;
Local forwarding: yes
Client to client forwarding: yes
Vlan mode: use tag
VLAN id: 998
CAP is configured to fw all traffic to bridge. On that bridge there is VLAN interface with vlan id 998. On vlan interface there is address and dhcp server.
Clients can, without any problem, connect to wifi, get config from dhcp and communicate with gateway (address which is added to vlan interface). Problem is communication between devices connected to that wifi. I could not isolate pattern but at first ping is going from one device to others but after a few minutes there is “timeout” but other devices still can communicate with gateway. Interesting thing is when communication is broken between devices they still can communicate to gateway as well as with devices which are connected to same bridge via ethernet.
So… one more time, problem is communication between devices on same ssid with vlan tagging. Please fix this.