I have a vlan over wifi interface from configuration point of view everything working as expected however, for unknown reason for me, the vlan interface don't start on device boot (need interface restart manually after boot).
Some details
wifi interface is actually a wifi client!
So I guess for some reason vlan interface not go in running state until wifi (client) interface connect to the remote wifi AP but also do not go in running state after the wifi (client) is connected !.
Actual setup is
wan -- ap1 (none owrt) --- wifi(+vlan) --- ap2( owrt ) -- lan
I do not have any other issue, ap2(owrt) connect via wifi to ap1 however (sorry if I repate my self) vlan interface not go in running state after boot/reoot
note: I have the same issue with or without "force_link - vlan interface" not sure if this is related
If I manually restart the vlan interface (luci) everything start to work as expected
Here is my network config (ap2) do I miss something ?
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd36:3246:700c::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.2.1'
config device
option name 'wan'
option macaddr '5c:02:14:30:3a:f3'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
option type 'bridge'
config interface 'wwan'
option proto 'dhcp'
config interface 'wwan_ac'
option proto 'static'
option netmask '255.255.255.0'
option gateway '192.168.1.1'
option ipaddr '192.168.1.2'
config device
option type '8021q'
option ifname 'wlan1'
option vid '13'
option name 'wlan1.13'
option ipv6 '0'
config interface 'WWAN_VLAN13'
option proto 'static'
option device 'wlan1.13'
option ipaddr '192.168.254.6'
option gateway '192.168.254.5'
option netmask '255.255.255.252'
option force_link '0'
the wlan hardware (radios) should never be specified in the network file. These should only be in the wireless file, where you will then connect the radio to a network. Additionally, the wlan definitions don't work with 802.1q tags/VLANs like this.
Where does VLAN 13 come from? And what physical device holds the address 192.168.254.5 (the apparent gateway for this network)? Also, with a net mask of 252, nothing else can join this network since its a /30 with a max number of hosts = 2.
EDIT: Is this some GRE type network link where the VLANs are encapsulated over the wifi link? Standard wifi doesn't have the concept of VLANs, but VLANs can be encapsulated and then sent over the medium. I'm not an expert on this method, but you do have to unwrap the encapsulation first... not sure where that is happening based on your config.
As general I don't want to go in details why use vlan over wifi because we will go out of the topic and I have reasons which are not important here
Btw I do not see any reason to not use vlan over wifi (L2) .. also this is another story as well
All configurations are done via LuCI not manually created
Since it sounds like you have a use case that I am unable to help with (I lack this specific knowledge) I'll step aside at this point... I've never seen VLAN over wifi except if it is encapsulated. I'll keep reading so I can learn, but I won't be able to help for obvious reasons.
But one question... does it actually work when the interface is up? And if you connect without the VLAN does it not work (i.e. using wlan1 instead of wlan1.13)?
Yes this is what I wrote in the first post .. everything work as my expectations ,
My problem again is .. vlan interface is not in running state after owrt boot/reboot .. when I manually reset the vlan interface everything start to work
also again (sorry for this repeating ) I'm almost sure is related somehow to the delay between owrt boot and wifi client connection (if I not mistake wifi int. will not be in running state if is not connected -> vlan cannot be in running state as well .. this is normal but why vlan int. not go automatically in up/running state after the wifi int. is connected ?) ... probably I miss something
Ok, yes I did see that. My question was related to the VLAN itself -- if you don't specify the VLAN (so just wlan1), does it fail to work at all. I'm asking because I've never seen a VLAN over wifi in this way, and I'm wondering if it is actually doing anything useful there (for example, is the kernel just seeing wlan1.13 and simply treating it as wlan1 anyway). Right now, I'm asking for my own learning.
The screenshots mirror the text configs, which makes sense. The thing I want to know (to learn) is what the VLAN actually does on a wifi interface. Unlike ethernet where 802.1q operates, wifi packets don't have a mechanism for VLAN tags (at least as far as I've understood). With ethernet, if frames are tagged with 802.1q VLANs, both sides of the link have to be capable of, and configured to work with those tags (and specifically the VLAN IDs being used), otherwise the connection does not work.
If the logic from 802.1q over ethernet applies here, both sides of your wifi link need to be tagged. But I'm trying to understand if the kernel on both sides of the link are actually just ignoring this VLAN tag and just running 'untagged' (since, AFAIUI, there isn't a place for 802.1q tags in wifi packets). Another way of looking at this would be to say that if you remove the tag from one side, but leave it tagged on the other side, would your connection still work? If so, that means that the VLAN tag really isn't doing anything. If it broke, though, it would suggest that the tags are getting applied (although I'm still not understanding how this is possible).
I really am interested in learning here, so can you provide more info about how this is actually configured and what happens if you remove the tag from one side of the link?
My be the quick way to show you ..
The remote side is mikrotik device .
In packet sniffer I enable only wlan2 (phisical wifi interface) and vlan13 (vlan 13 on wlan2)
ping 192.168.254.5(mikrotik vlan13 int) to 192.168.254.6(owrt vlan3 int)
You can notice something interesting
packet on wlan2 (vlan id 13 ) - packet is seen with vlan tag
packet on vlan13 (no vlan id) - this is inside the vlan
Probably is not the best ... probably I miss something but look like normal to me
..
I’m trying to figure out if the tag is actually traveling over the air (in the actual WiFi data packets) or if the tags are simply applied on the ‘copper’ side of the radio. Consider this question like the way a managed switch with an access port needs to remove/add the tags as the data egresses/ingresses that port*.
*the tags themselves don’t necessarily transit the internal switch fabric, as the switch may or may not have other mechanisms by which it accounts for the port-vlan memberships internally that are not purely 802.1q, but it must apply/remove tags at the ports.
I fully understand your question from the first time
Usual way it to assign vlan per SSID on lan side ..
The problem is I'm not sure as well and probably is some none sense configuration from my side !
I never thinking about it, I do not have any important reason to use vlan, "work as expected", actually I have OSPF (PtP) (this is way the network is /30 ).. no issues between neighbors etc ..
Again do I have any specific reason to put OSPF in vlan .. no I just play around with owrt .. ospf is used for networks behind AP2 ..but this is a long story
.. also I cannot answer for sure if is ok or not since this is in remote site
This days I will be there (my parent's house) and will check ..
Probably I will connect 3th client to this network without any vlan .. If this client see vlan traffic .. no good , if not see it well .. will check and rfc ..
This is absolutely good question .. where is the tag in wifi frame header ?! not sure
but this not explain a lot how wifi transport the tag
pcap is taken from owrt (tcpdump -i wlan1 -w test.pcap -c 200 net 192.168.254.4/30)
src mac (AP1) - dst mac (AP2)
Yes 802.11 does not include 802.1q but some vendors support it anyway, at least some sources state so.
(I use batman-adv for Vlan transport. I have never tried to do it natively. But as long as your frame includes the tag who cares )
Don't forget to increase the subnet size. Currently you can only accommodate 2 hosts.
Yeah, from my perspective, I want to know if the VLAN tags actually make it over the air or if they are stripped off by the kernel or the radio.
But importantly, this may possibly work in your scenario but will probably not work in the vast majority of other configurations since VLAN tags are not specifically supported by 802.11. This means that that it will be very hardware specific and may not be reliable as a general method. For that reason, typically VLANs are handled either 1-per-SSID, or they are encapsulated for transit from one AP to another (as is often done for multi-SSID mesh networks or wireless bridge devices). If VLANs are encapsulated for transit, the physical wifi link is used to send this encapsulated trunk and that means it is not possible for it to be used by standard wifi sta mode devices for normal wifi functionality.
A very common task is to forward only a certain set of VLANs over a Wireless Point-to-Point (PtP) link
This is what I've been talking about insofar as it is not a normal wifi connection (i.e. it would not be suitable for general clients to join) because it is a PtP link. It is not clear from the 'Tik documentation what happens if a regular sta device joins (say a phone), but I'm not sure if it would be able to get a network connection because of the PtP nature of the link.
I'm still really curious what is going over the air... I don't know what is happening, but I still think that the VLAN tags are not going to be on the air. (I could be wrong, of course).
I will check it for sure, I have a lot of personal tasks this days, however I promise when I have a little free time to investigate / do research and will reply .
)