How to get pfSense WAN to accept VLAN 0
-
@stephenw10 said in How to get pfSense WAN to accept VLAN 0:
I expect CE snapshots to be re-based before that happens given the current development work
Steve,
What does this mean "I expect CE snapshots to be re-based before that happens given the current development work"
Are we expected to see this fix on the next release or not?
-
If the fix you mean is in the e1000 driver that is part of FreeBSD 13 then, yes, I expect that to be in CE snapshots before a 2.7 release is branched.
Steve
-
@stephenw10 Thank you Steve for the confirmation, as you know this is driving some of us insane. :-)
-
@stephenw10 said in How to get pfSense WAN to accept VLAN 0:
If the fix you mean is in the e1000 driver that is part of FreeBSD 13 then, yes, I expect that to be in CE snapshots before a 2.7 release is branched.
Steve
Just to clarify, you said the e1000 driver is already in the 2.7 snapshots, yet the vlan0 issue is not fixed by that. Just tried the latest to verify again. Vlan0 is still not working in it.
Are you saying the vlan0 fix is to be added to 2.7 at a later date?
-
He is hinting pfsense v2.7 will probably be based on BSD v13 by the time it is released.
But he isn’t going to guarantee it because he does not know what problems will be encountered until after it is done and can’t be certain it will fix your problem until your problem has been tested with the v2.7 release.
-
@patch said in How to get pfSense WAN to accept VLAN 0:
He is hinting pfsense v2.7 will probably be based on BSD v13 by the time it is released.
But he isn’t going to guarantee it because he does not know what problems will be encountered until after it is done and can’t be certain it will fix your problem until your problem has been tested with the v2.7 release.
Oh, I didn't get that at all. From what I understood from his "hint", they ported the e1000 driver thinking that would fix the vlan0 issue. But I don't think that's the fix we all want. Meaning it doesn't fix vlan0 compatibility.
Edit;
On another note, does anyone know if that script works on the chelsio (cxlx) driver? -
Since I don't have anything using this setup I can't test it directly so my understanding here is based on when others have reported here, in the pfatt thread and the bug reports.
As I understand it:The script itself works fine.
It cannot work with the e1000 driver in FreeBSD 12.2/3 because the driver itself fails to pass VLAN0 tagged packets.
The driver in FreeBSD 13 does not have this issue. Proven by people testing in OPN. Unless they patched the driver for this specifically.
2.7 when it is branched for release will not be based on FreeBSD 12 so should also include that fix.Anyone seeing something disagrees with that?
Steve
-
https://docs.netgate.com/pfsense/en/latest/releases/versions.html
-
It shows 12.3 there because that's what current snapshots were built on.
-
@stephenw10 Steve,
Do we have some sort of timeline when the newer snapshots (based on BSD v13) will be compile and release to the community to test? -
Nothing fixed but I would guess 'weeks'. We have some initial snapshots internally and are working through the show-stopping issues as quickly as possible so we can restart public snapshot builds.
-
Hey All, you guys see that pfsense is skipping over freebsd 13 and going straight to 14. I'm gonna find some spare hardware and load 14 on it and check it as I haven't yet.
-
@michaellacroix Wonder if this means vlan0 will be handled natively by pfsense
-
@schwiing
It was in freebsd 13 so I assume??? it will be in 14. -
@michaellacroix guess y'all will have to let me know. The fiber feeder got delayed at my residence anyhow
-
It should certainly contain any fixes that are in 13, yes. Though I don't think that includes a fix for the e1000 driver not passing it.
-
@stephenw10 i have ix anyway. But perhaps this means netgraph wont be needed anymore
-
@stephenw10
Its suppose to have a ton of driver updates so we will keep our fingers crossed for you.... -
Yeah, the situation is unclear because we have reports here and in other threads that conflict with test results. What I can say is that testing is much easier in main because you can just set a priority tag on any interface using ifconfig directly:
[2.7.0-DEVELOPMENT][admin@m470-2.stevew.lan]/root: ifconfig igb12 pcp 4 [2.7.0-DEVELOPMENT][admin@m470-2.stevew.lan]/root: ifconfig igb12 igb12: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: PCP0 options=4e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 00:90:7f:db:ca:b2 pcp 4 inet6 fe80::290:7fff:fedb:cab2%igb12 prefixlen 64 scopeid 0xd inet 10.13.0.1 netmask 0xffffff00 broadcast 10.13.0.255 media: Ethernet autoselect status: no carrier nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>And then you will see:
23:16:10.138805 00:90:7f:db:ca:b2 > 00:90:7f:87:dc:7a, ethertype 802.1Q (0x8100), length 102: vlan 0, p 4, ethertype IPv4, (tos 0x0, ttl 64, id 53358, offset 0, flags [none], proto ICMP (1), length 84) 10.13.0.1 > 10.13.0.2: ICMP echo request, id 59732, seq 0, length 64However the em NIC I'm sending that to, also under 2.7-dev (main) does not see that packet at all.
Testing against a different NIC type though, fxp here, the traffic is seen and we see responses:23:20:18.274026 00:90:7f:db:ca:b2 > 00:90:7f:87:dc:74, ethertype 802.1Q (0x8100), length 102: vlan 0, p 4, ethertype IPv4, (tos 0x0, ttl 64, id 26894, offset 0, flags [none], proto ICMP (1), length 84) 10.13.0.1 > 10.13.0.2: ICMP echo request, id 60464, seq 0, length 64 23:20:18.274140 00:90:7f:87:dc:74 > 00:90:7f:db:ca:b2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 36849, offset 0, flags [none], proto ICMP (1), length 84) 10.13.0.2 > 10.13.0.1: ICMP echo reply, id 60464, seq 0, length 64The confusing thing though is that that also works when testing against an igc NIC in 22.05 and my understanding was that it should not....
-
Thanks Stephen, thats good to know.
