Creating a virtual interface with the VLAN ID set to 0 (e.g., em0.0, em1.0, etc.) is not supported by FreeBSD's vlan implementation. The issue is that IEEE 802.1Q specifies that VLAN 0 is "reserved." FreeBSD honors this reservation because the implementation is standards compliant. However, in some instances it would be able to create interfaces on VLAN 0 (e.g., when wanting to use FreeBSD for a "reserved" purpose). I understand that standards compliance is the good default design here. However, it would be great if there were a sysctl flag that could be set to allow interfaces on VLAN0. The default value could be for standards compliant behavior, thereby allowing users to enable VLAN 0 if desired and they know what they are doing.
(In reply to johnllyon from comment #0) I believe netgraph with ng_vlan can do this. I have not tested with vlan id 0 but I do remember it giving me finer control of VLANs than the if_vlan implementation. I used it when I had to separate vlan traffic in such a way that tagged traffic could no longer be seen on the physical interface. You can use the example on the ng_vlan man page and set up with vlan id 0. This creates a virtual interface named ngeth which should have the traffic you want.
(In reply to Reshad Patuck from comment #1) Netgraph -- I love it's power, but the documentation is frustratingly sparse regarding certain fundamental concepts. I will give ng_vlan a brief try later this week when I have some free time to experiment. Do you know if I can attach services and assign an IP to the virtual interface created by ng_vlan? For some context, my server is receiving traffic tagged with VLAN 0. Services on that interface (e.g., dhcp client) don't appear to recognize the traffic because it is tagged as vlan 0 (versus being not tagged at all). So I'm trying to create an interface assigned to vlan 0 so that I my services on that interface will work. Think ng_vlan can help me do that? For some context these links describe my problem and a Linux solution to it: http://blog.0xpebbles.org/Bypassing-At-t-U-verse-hardware-NAT-table-limits https://strscrm.io/bypassing-gigapowers-provided-modem.html https://www.reddit.com/r/Ubiquiti/comments/60rfdr/transparent_proxy_for_8021xeap/dfcba6o/ I'm trying to create a FreeBSD equivalent solution. I've already successfully duplicated the functionality of ebtables using Netgraph. I'm just stuck at the last part because I can't assign vlan 0 to an interface (or create a virtual interface on vlan 0) to which I can move my services (e.g., DHCP client). Thanks.
(In reply to johnllyon from comment #2) Incoming ethernet frames tagged with zero vlan tag are not correct, so first operation should be conversion of such frames to standard untagged frames. ng_vlan should perform this flawlessly if configured with command like "ngctl msg vlan: addfilter '{ vlan=0 hook="untagged" }' and hook "untagged" connected to ng_eiface node that creates ngeth0 interface. Also, ng_vlan's "downstream" hook should be connected to ng_ether node corresponding "real" interface like em0 and its hook "lower". Then real interface passes incoming packets to ng_vlan instead of normal delivery. ng_vlan strips incorrect vlan tag and result is delivered normally as received from ngeth0. Ethernet frames received without vlan tag will be dropped by this comple schema but it is possible to process them too by inserting ng_tee node into the graph. ng_tee is capable of combining two streams of data into single one and passing it to arbitrary next node.
Be aware that vlan tag of 0 is special, it is reserved, and it is reserved for: The reserved value 0x000 indicates that the frame does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a priority (in PCP and DEI fields) and is referred to as a priority tag. We should be able to match and process these frames, they are standard.
(In reply to Eugene Grosbein from comment #3) I think therein lies the problem. We are not recognizing frames tagged as vlan 0 as being untagged. On the flip side, it seems that if we detect that we are receiving frames tagged with vlan 0, we should be transmitting frames tagged with vlan 0 as well (but we don't seem to be). I like the idea of Netgraph as a work around as it would allow me to both send and receive frames tagged as vlan 0.
More and more ISP's are using a tagged vlan0 on their interfaces now. I agree that it's time to incorporate this. It's starting to effect too many people and adding a managed switch between handoff and WAN is not a real solution.
Look for "pcp" in "man ifconfig" --HPS
Hans, Are you saying that I can do "ifconfig igb0 vlanpcp 0" and all my traffic on that interface will be tagged as vlan 0 and that incoming traffic tagged as vlan 0 will be received? I had a netgraph setup that was doing this and working wonderfully for me under 12.1. I upgraded to 13.1 and now my setup won't successfully do EAPoL using the same same configuration and binary as the 12.1 setup. I'm not sure that it's due to the vlan 0 requirement of my upstream device and I'm not sure I have the expertise to diagnose this further but it would be delightful if I could ditch the netgraph stuff and just use the command above. Regards, Christopher
You maybe need a 13-stable kernel. Yes, setting the pcp, cause network traffic to use VLAN ID=0. You can check using tcpdump ? --HPS
Hans, I greatly appreciate your previous feedback here! Thank you This does indeed seem to work to issue vlan 0 packets, at least as far as I can understand looking at tcpdump output on a stock 13.1 system. However, I think it's tagging all traffic as vlan 0. I think it shouldn't be tagging BPDU (Bridge Protocol Data Unit) traffic that way. My wpa_supplicant packets (EAPoL) look like they're also being taged as vlan 0 and I think that's why authentication isn't happening for me. Should EAPoL packets be tagged with a vlan? Christopher
kib@ : Can you comment on the question above, for WLAN EAPOL packets being prio-tagged. Maybe a WIFI router problem? --HPS
This isn't actually happening on a wlan. My fiber network connection requires EAP authentication to pass traffic and I'm trying to get that to work. Christopher
I just wanted to offer my assistance in this problem as I am experiencing the same issue.
I am also experiencing this issue. I think another way of describing what we may be seeing is that WPA_Supplicant may be unable to process requests tagged with VID 0. This may be similar to how dhclient was unable to do so until Franco worked on having dhclient decapsulate VID 0. I am using a netgraph configuration on 13.1 that filters out 802.1Q information if it contains VID 0 and from looking at the CAP for that netgraph interface, it appears to respond to EAP Identity requests normally. And like the others, if I simply use WPA_Supplicant with the physical interface and let it receive the VID 0 EAP identity request traffic, it doesn't respond to the identity requests. What we may need is for WPA_Supplicant to decapsulate 802.1Q information from the frame if there's a VID of 0.
(In reply to topsecretsauce from comment #14) I forgot to mention. I'm referring to this change to dhclient https://reviews.freebsd.org/D31515