VLAN priority for DHCP not working

[doktornotor]

Also, post the output of this:

Code Select Expand

sysctl net.link.vlan.mtag_pcp

both with that DHCP priority enabled and disabled.

[Ilford]

@meyergru : Same result with a floating rule :(

@doktornotor I'm not playing with dhclient conf files directly, vlan-pcp is set via GUI on WAN interface config.

sysctl net.link.vlan.mtag_pcp : made some tries by enabling and disabling priority at VLAN level and at WAN's DHCP level, it is always "1"

 

[doktornotor]

@doktornotor I'm not playing with dhclient conf files directly, vlan-pcp is set via GUI on WAN interface config.

Well yes, but why???

Otherwise, you can change the rule priority in the code I linked and try again.

IMNSHO, all this automagic behind the scenes stuff is just annoying.

[Patrick M. Hausen]

IMNSHO, all this automagic behind the scenes stuff is just annoying.

Amen, brother  :)

[Ilford]

Thanks for the tip, I'll try messing with the code next week maybe  ;D

[doktornotor]

Can you post output for this?

Code Select Expand

grep "set prio" /tmp/rules.debug

For manual messing, these two lines:

https://github.com/opnsense/core/blob/d3a12a6d62e765f0a9f520f67933f0d584eae505/src/etc/inc/filter.lib.inc#L396
https://github.com/opnsense/core/blob/d3a12a6d62e765f0a9f520f67933f0d584eae505/src/etc/inc/filter.lib.inc#L350

Make a backup, change that 1 to 300000 and try again with your manually created rule and see if it matches anything. (Disable and re-enable so that it's reloaded.)

[dseven]

Well yes, but why???

because the ISP requires it, apparently. I'm sure all this messing is a fun exercise (??), but, if I'm understanding the discussion that I linked earlier, what the OP was trying to do should work (without any faffing around with rules) - either there's a regression, or the OP is doing something else that's making it not work....

[doktornotor]

because the ISP requires it, apparently.

The question was - that VLAN priority header is already being set by the pf rules. Why is the same thing being done by dhclient at the same time (with the final result that none of that works).

[dseven]

The question was - that VLAN priority header is already being set by the pf rules. Why is the same thing being done by dhclient at the same time (with the final result that none of that works).

Oh, I see. "Belt and suspenders", maybe? Having the same priority set in two different places doesn't seem like an obvious reason for it to not work.

I'm half-tempted to create a VM and try to reproduce this.

[doktornotor]

Oh, I see. "Belt and suspenders", maybe?

🤷‍♂️🤔 https://github.com/opnsense/core/commit/d195cd2e8a315ccd2069c01507cbf258793630f7

This links to this topic - surprise - about Orange not working. https://forum.opnsense.org/index.php?topic=33376.0

Hmmm, getting kinda circular.

[dseven]

That's the thread I linked to this morning. Supposedly the issue was resolved in 23.1.6

[doktornotor]

Uhm, lets try something different - is the OP here using Suricata or some other of those things that use netmap on the VLAN interface?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236219

[dseven]

FWIW, I created a VM which uses VLAN 832 on a PCI-passed-through NIC for the WAN interface, and set the priorities for DHCP (4 and 6) on that to 6, and it appears to do what I expect - i.e. tcpdump shows p6 on the DHCP requests (there's nothing there to answer, of course)....

Code Select Expand


root@OPNsense:~ # tcpdump -nnvei igc0
tcpdump: listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:46:47.517488 00:d0:b4:01:a5:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 832, p 6, ethertype IPv4 (0x0800), (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:d0:b4:01:a5:a1, length 300, xid 0xea8b2ca, secs 32, Flags [none]
          Client-Ethernet-Address 00:d0:b4:01:a5:a1
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            Client-ID (61), length 7: ether 00:d0:b4:01:a5:a1
            Hostname (12), length 8: "OPNsense"
            Parameter-Request (55), length 10:
              Subnet-Mask (1), BR (28), Time-Zone (2), Classless-Static-Route (121)
              Default-Gateway (3), Domain-Name (15), Domain-Name-Server (6), Hostname (12)
              Unknown (119), MTU (26)


This is OPNsense 24.7, without any updates (as I don't have a WAN connection to update over)....

[franco]

I just want to chime in to say we have several trusty users who use the priority setting and it should work as expected, at least in the scope that those users are using it. Pretty sure about that. They would be here now otherwise (the good Orange FR people).


Cheers,
Franco

[doktornotor]

Yep, I'd bet on netmap breaking this ATM.