Freebsd 13.1 supports vlan 0 tagging but ....
christopher-bowman opened this issue · comments
using the vlanpcp option to ifconfig, FreeBSD is supposed to now support tagging with vlan zero.
I have a working setup using a variant of the this script with netgraph and extracted certs (so I know the certs and wpa_supplicant config is working). I can't tcdpdump my ATT RG doing negotiation and passing traffic since I'm not setup for that so I can't tell what "golden" traffic should look like but I have noticed some interesting things:
-
The MAC address that my traffic comes from doesn't actually have to match that of the ATT RG. While wpa_supplicant does have to be configured with the ATT RG MAC address when I look at tcpdump from my working FreeBSD configuration the packets on the ethernet port connected to the ONT don't show the same MAC as my ATT RG and yet traffic flows.
-
The initial packet of my EAPoL don't seem to be vlan tagged with the netgraph approach. I don't have traces available right now to confirm but that's what I recall.
-
In the new approach using ifconfig vlanpcp 0 without netgraph it does look like the packets are vlan0 tagged INCLUDING all the EAPoL traffic and I don't see any responses from the ONT in this setup even when the packet do properly have the ATT RG MAC address.
What I'm thinking is that the EAPoL traffic tagged as vlan0 shouldn't be as it's BPDU traffic that shouldn't have a vlan tag and so the ONT doesn't respond but I don't know enough about networking to be sure.
Can you confirm any of this? It would are really nice if you could simply use ifconfig to clone the MAC address (if that's even really necessary) and tag packets to vlan0 and then configure wpa_supplicant eliminating the netgraph need. This would all be much easier. I find netgraph confusing. Plus presumably it would also work on recent PFsense (and all other FreeBSD derived firewall OSes)
In some of these scripts I'm seeing, I dont see a filter for eap traffic to not be tagged (unless I'm missing something). Seems to be several reports of it working correctly with all traffic tagged as vlan 0.
I don't either but I was surprised to see at least one packet from the EAPoL protocol was not tagged. I think it was the initial broadcast on the MAC address used to start the interaction. At least that's my recollection from the working setup.
@christopher-bowman Netgate (the company that makes pfsense) has recently completed a lot of work incorporating Layer 2 functionality in pf. As part of this, we enabled two new pieces of functionality 'dup-to' and 'bridge-to' that are designed with the idea of replacing the netgraph-based functionality of pfatt.
I'm wondering if you (and @tman785 is welcome of course, but IDK when OPNsense might adopt this work, and IDK if @MonkWho is even watching this repo at this point) are open to testing this (very new) functionality
@christopher-bowman Finally got around to getting non-tethered to work on 22.7.4. As for whether setting vlanpcp 0 works, I couldn't get past authorization. At some point maybe next week, I'll do a packet trace between the two methods.
@christopher-bowman I gave it a shot to look at the traffic. Vlan is set to 0 when we run ifconfig $ONT_IF vlanpcp 0.
But for some reason, after wpa_supplicant sends out the START command, we receive the "Request, Identity" from the ONT, but nothing occurs after. It's like wpa_supplicant isnt responding to the traffic.
As for the script, I used my actual working script and modified it to comment out anything referring to netgraph. One thing I also did was comment these out:
# /sbin/ifconfig $ONT_IF up
# /sbin/ifconfig $ONT_IF promisc -vlanhwtag -vlanhwfilter -vlanhwtso
I dont think we need the $ONT_IF in promiscuous mode.
Any ideas? I dont get how wpa_supplicant will start the process but not respond. Unless there's an issue w/ the script itself.
I am having similar issues with newer versions of Opnsense. I have seen it work on older versions though. I wonder what has changed and how to fix it. I am trying to setup a packet trace, I think a promiscuous listener 3rd party on a dumb switch should work, right?
I am having similar issues with newer versions of Opnsense. I have seen it work on older versions though. I wonder what has changed and how to fix it. I am trying to setup a packet trace, I think a promiscuous listener 3rd party on a dumb switch should work, right?
Never heard of it working outside of netgraph - I didnt think FreeBSD officially supports vlan 0 and we're just using some workaround where setting the pcp value to 0 also sets the vlan to 0.
I did see one post do it on ESXi, but they had the adapter within the host tag everything as vlan 0.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224961
Just to add some of my own notes here. I am current user of the Intel 350 NIC and because of this have had troubles getting this to work on native PfSense. I have since moved to ESXi and using the VLAN 0 option of the vswitch at the ESXi layer have been able to bypass the need for NetGraph and it's incompatibility with my native 12.x intel driver.
During this however I purchased a UDMP SE from ubiquity and was able to get it to authenticate natively by using VLAN 0 but I had to set a QoS value of 1, I thought this was just a GUI limitation but looking at the FreeBSD bug link above I wonder if setting the PCP to 1 would actually still set the VLAN to 0 and provide the desired result with respect to this traffic. Just judging from some of the responses in the thread linked above it looks like PCP actually designates a priority and not a VLAN but a side effect is that it sets the VLAN to 0 as a result.
Anyways it's something to try, hope it helps.
Some more information I found from here https://www.freebsd.org/cgi/man.cgi?ifconfig(8)
vlanpcp priority_code_point
Priority code point (PCP) is an 3-bit field which refers to the
IEEE 802.1p class of service and maps to the frame priority
level.
Values in order of priority are: 1 (Background (lowest)), 0 (Best
effort (default)), 2 (Excellent effort), 3 (Critical
applications), 4 (Video, < 100ms latency and jitter), 5 (Voice, <
10ms latency and jitter), 6 (Internetwork control), 7 (Network
control (highest)).
Maybe try using a value higher than 1?
wpa supplicant was patched to allow this to work, not sure if anyone saw that announcement in the other threads