Rule error related to DHCP VLAN prio

louis2

Hello,

I defined a WAN-interface related to IPTV which I am not currently using, never the less here an error I see after installing (16/12) yesterdays build.

For the particular vlan-interface I did define DHCP client advanced configuration.

DHCP VLAN Priority Video (VI,4)

As said I am not effectively using this vlan. I just configured it based on what I saw on the internet.

There were error(s) loading the rules: /tmp/rules.debug:530: syntax error - The line in question reads [530]: pass out quick on $WAN_IPTV proto udp from any port = 68 to any port = 67 ridentifier 1000017262 label "allow dhcp client out WAN_IPTV" set prio
@ 2022-12-17 12:31:01

jimp

So you have the interface assigned but disabled?

And yet DHCP is configured and enabled on that same interface?

louis2

@jimp

I checked to be sure, but no the interface / vlan is enabled. See picture. I disabled the DHCP VLAN Priority setting, after the error occurred. To get rid of the issue.

jimp

Interesting, and it let you enable the DHCP server on that?

DHCP Server requires a static address on an interface. The GUI won't let me change away from static IP address with the DHCP server enabled on an interface.

I'm not sure how you landed in that invalid configuration then. You shouldn't be able to have the DHCP server on there.

louis2

@jimp

If I select Services / DHCP Server, the WAN_IPTV interface is not there. Also not when selecting DHCPv6 server.

For information, my provider does offer IP-TV as an option, however I have cable TV. So I do not use it.

When setting up the VLAN's I did however define the config in favor of IPTV in line with configs found on the internet.

As said, I am not using it at all, so it does not harm me. I was just surprised to see alarms with this build, I never saw before.

jimp

Oh, I was misreading the rule, it's for the client out, not server in.

Though even in that case I don't see how it would end up with a syntax error there.

louis2

@jimp
Eating is the proof of the pudding .... something there ...

I copied what I defined below below. But I do not recognize the (automatic) rule the error is referring to

normal rules

outbound nat

jimp

The rule it's complaining about is internal and automatic -- it's to allow the DHCP client traffic to egress the interface so it can request an address. It should work even when the interface doesn't have an address yet.

marcosm

This issue should be resolved with https://redmine.pfsense.org/issues/13754#note-9 - you can apply that patch with the System Patches package. Feel free to confirm / leave feedback there if it fixes the issue for you.

louis2

@marcosm
I installed the system patches package, which does provide an extra menu item.
Then I did update to the latest today 2.7 build

I did not apply a patch, since there are no available patches in the patch menu.
So no idea how to apply the patch

When accessing the IPTV_WAN interface, changing nothing and saving it again, the error is there.

marcosm

@louis2 Use the commit ID c0d7519df5dc1632ba9f2791ab377bdc19f45105. See here https://docs.netgate.com/pfsense/en/latest/development/system-patches.html#adding-a-patch

louis2

@marcosm

I think the patch is causing problems

PHP ERROR: Type: 1, File: /etc/inc/util.inc, Line: 3348, Message: Uncaught TypeError: array_get_path(): Argument #2 ($path) must be of type string, null given, called in /etc/inc/filter.inc on line 3725 and defined in /etc/inc/util.inc:3348
Stack trace:
#0 /etc/inc/filter.inc(3725): array_get_path(Array, NULL, '')
#1 /etc/inc/filter.inc(361): filter_rules_generate()
#2 /etc/rc.filter_configure_sync(32): filter_configure_sync()
#3 {main}
thrown @ 2022-12-20 09:39:33
PHP ERROR: Type: 1, File: /etc/inc/util.inc, Line: 3348, Message: Uncaught TypeError: array_get_path(): Argument #2 ($path) must be of type string, null given, called in /etc/inc/filter.inc on line 3725 and defined in /etc/inc/util.inc:3348
Stack trace:
#0 /etc/inc/filter.inc(3725): array_get_path(Array, NULL, '')
#1 /etc/inc/filter.inc(361): filter_rules_generate()
#2 /etc/rc.filter_configure_sync(32): filter_configure_sync()
#3 {main}
thrown @ 2022-12-20 09:39:3

Crash report begins. Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #0 devel-main-n255823-0ee8d072543: Mon Dec 19 06:30:58 UTC 2022 root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-master-main/obj/amd64/3fXURXSN/var/jenkins/workspace/pfSense-CE-snapshots-master-main/sources/FreeBSD-src-dev

Crash report details:

PHP Errors:
[20-Dec-2022 09:39:33 Europe/Amsterdam] PHP Fatal error: Uncaught TypeError: array_get_path(): Argument #2 ($path) must be of type string, null given, called in /etc/inc/filter.inc on line 3725 and defined in /etc/inc/util.inc:3348
Stack trace:
#0 /etc/inc/filter.inc(3725): array_get_path(Array, NULL, '')
#1 /etc/inc/filter.inc(361): filter_rules_generate()
#2 /etc/rc.filter_configure_sync(32): filter_configure_sync()
#3 {main}
thrown in /etc/inc/util.inc on line 3348
[20-Dec-2022 09:39:33 Europe/Amsterdam] PHP Fatal error: Uncaught TypeError: array_get_path(): Argument #2 ($path) must be of type string, null given, called in /etc/inc/filter.inc on line 3725 and defined in /etc/inc/util.inc:3348
Stack trace:
#0 /etc/inc/filter.inc(3725): array_get_path(Array, NULL, '')
#1 /etc/inc/filter.inc(361): filter_rules_generate()
#2 /etc/rc.filter_configure_sync(32): filter_configure_sync()
#3 {main}
thrown in /etc/inc/util.inc on line 3348

No FreeBSD crash data found.

marcosm

@louis2 Apologies - we saw that and a fix is coming soon.

jimp

Latest snapshot should have a good fix in it (for that error and others), so if you can, give that a try.

louis2

@jimp

The good news is, that I did not see that specific failure in the past hours.

The bad news is that switching on and of the interface now does crash the system.

See attached crash dumps

textdump.tar.0 info.0

jimp

That wouldn't be related to the rules, but it's some other issue entirely. I don't recall ever seeing a backtrace similar to that one.

db:0:kdb.enter.default>  bt
Tracing pid 0 tid 100012 td 0xfffffe00219de720
kdb_enter() at kdb_enter+0x32/frame 0xfffffe00c7917730
vpanic() at vpanic+0x182/frame 0xfffffe00c7917780
panic() at panic+0x43/frame 0xfffffe00c79177e0
propagate_priority() at propagate_priority+0x2ba/frame 0xfffffe00c7917820
turnstile_wait() at turnstile_wait+0x380/frame 0xfffffe00c7917870
__rw_rlock_hard() at __rw_rlock_hard+0x2a8/frame 0xfffffe00c79178f0
__rw_rlock_int() at __rw_rlock_int+0xc0/frame 0xfffffe00c7917920
X_ip_mforward() at X_ip_mforward+0x56/frame 0xfffffe00c7917990
ip_input() at ip_input+0x5a0/frame 0xfffffe00c79179f0
netisr_dispatch_src() at netisr_dispatch_src+0x220/frame 0xfffffe00c7917a50
ether_demux() at ether_demux+0x17c/frame 0xfffffe00c7917a80
ether_nh_input() at ether_nh_input+0x3f6/frame 0xfffffe00c7917ae0
netisr_dispatch_src() at netisr_dispatch_src+0xaf/frame 0xfffffe00c7917b40
ether_input() at ether_input+0x99/frame 0xfffffe00c7917ba0
ether_demux() at ether_demux+0xcd/frame 0xfffffe00c7917bd0
ether_nh_input() at ether_nh_input+0x3f6/frame 0xfffffe00c7917c30
netisr_dispatch_src() at netisr_dispatch_src+0xaf/frame 0xfffffe00c7917c90
ether_input() at ether_input+0x99/frame 0xfffffe00c7917cf0
iflib_rxeof() at iflib_rxeof+0xdf4/frame 0xfffffe00c7917e00
_task_fn_rx() at _task_fn_rx+0x7a/frame 0xfffffe00c7917e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa7/frame 0xfffffe00c7917ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame 0xfffffe00c7917ef0
fork_exit() at fork_exit+0x80/frame 0xfffffe00c7917f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c7917f30
--- trap 0x6eb93c2d, rip = 0x1df1b8d8f28a662f, rsp = 0xdf1a8d8e28a762f, rbp = 0xd3fc47596e133c87 ---

jimp

Actually that backtrace does appear to be the same as the one we see occasionally for IGMP Proxy: https://redmine.pfsense.org/issues/12079

I added your textdump there, but that won't be one we get to for the 23.01 release.