Bug 224961 - VLAN ID 0 Not Supported
Summary: VLAN ID 0 Not Supported
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-07 02:19 UTC by johnllyon
Modified: 2018-01-18 18:05 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description johnllyon 2018-01-07 02:19:03 UTC
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.
Comment 1 Reshad Patuck 2018-01-07 05:25:41 UTC
(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.
Comment 2 johnllyon 2018-01-08 17:00:43 UTC
(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.
Comment 3 Eugene Grosbein freebsd_committer 2018-01-08 18:47:43 UTC
(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.
Comment 4 Rodney W. Grimes freebsd_committer 2018-01-08 19:07:45 UTC
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.
Comment 5 johnllyon 2018-01-18 18:05:08 UTC
(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.