dhclient does not decode 802.1q-encapsulated replies

[ipartola]

My ISP's DHCP server sends DHCPOFFER datagrams inside 802.1q-encapsulated frames with VLAN 0. It seems that OPNSense's dhclient ignores these. I found a similar issue in pfsense (https://redmine.pfsense.org/issues/8526) and a corresponding pull request (pfsense/FreeBSD-src#9). The actual code diff is here: pfsense/FreeBSD-src@15051bf

I don't see 802.1q handling in https://github.com/opnsense/src/blob/master/sbin/dhclient/bpf.c or https://github.com/opnsense/src/blob/master/sbin/dhclient/packet.c. It seems like this code should be added to OPNSense's dhclient code.

[fichtner]

Hi @ipartola,

VLAN 0 is a Cisco addition which there is no support in FreeBSD. While there is a patch it heavily complicates our BPF filter which already knows how to skip VLAN.

Does your ISP require you to run Cisco gear or can they disable the priority feature?

https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/ios-xml/ios/atm/configuration/15-mt/atm-15-mt-book/atm-15-mt-book_chapter_011000.html.xml

TBH, this also breaks QinQ so the question is why is this forced on customers in the first place.

Cheers,
Franco

[fichtner]

PS: The VLAN priority reference is here and not to be confused with VLAN 0 hijacking 5e4e4f842b7

[ipartola]

@fichtner I have no Cisco gear, though I suspect they use it on their end. My whole setup consists of a XGS-PON ONT (model FOX222) and an amd64 box with an Intel dual NIC running OPNSense.

The behavior I see is that dhclient sends out a DHCPDISCOVER and the ISP's DCHP server responds with a DHCPOFFER which dhclient ignores entirely:

01:09:47.918351 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from a0:ce:c8:01:05:8b (oui Unknown), length 300

01:09:47.935354 IP 32.217.174.1.bootps > 32.219.252.142.bootpc: BOOTP/DHCP, Reply, length 300

Looking at tcpdump further I get

11:56:43.560290 a4:7b:2c:29:53:74 > 80:61:5f:08:2d:7a, ethertype 802.1Q (0x8100), length 346: vlan 0, p 7, ethertype IPv4, 32.219.248.1.67 > 32.219.250.238.68: BOOTP/DHCP, Reply, length 300
Which is consistent with the pfsense bug. The only work-around I've found searching the web is to put a managed switch between my ONT and the OPNSense WAN port that would strip the 802.1q tag, but that seems like a hardware solution to a software problem. My old OpenWRT router has no problem with the ISP's setup and gets an IPv4 address immediately.

[fichtner]

IMO just talk to your ISP as they shouldn't force a maybe-VLAN0 on you. You obviously don't need it to communicate with them so they can avoid it too.

VLAN 0 needs support in the kernel in general, not just dhclient. The ISP could encapsulate any traffic it deems priority and you will never see it.

There may be a way with a bridge and VLAN 0 (if 0 is a supported setting), but I would not recommend either way.

Cheers,
Franco

[fichtner]

And for further reference a FreeBSD ticket from 2018: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224961

[fichtner]

Ok so this pertains to the read filter, not write filter. I suppose we could patch it in but I don't trust a BPF filter that I haven't written...

[ipartola]

@fichtner thank you I appreciate the consideration! I am happy to help test if that would be useful. I will reach out to my ISP but I don't have high hopes for their ability to sort it out based on my experiences with their level 1 & 2 support thus far.

[ipartola]

@fichtner Two things I have learned:

1. Unofficial reply regarding what my ISP is doing was: "VLAN0 is so 802.1p can be passed". I haven't gotten any other info from them regarding this behavior and honestly don't really understand what they are doing with 802.1p here.

2. I tried the following patch on 21.1.5 and it worked like a charm: 2d00172. If this looks good to you, I'm happy to make a pull request.

[fichtner]

@ipartola alright, I tried to remove some fluff from the original patch... can you try this one instead? bf0e9ca

I could provide a build too. It looks like it doesn't break the non-VLAN case, but I cannot easily test the VLAN-0 case.

Cheers,
Franco