Rule error related to DHCP VLAN prio
-
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.
-
@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
-
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.
-
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.
-
@marcosm
I installed the system patches package, which does provide an extra menu item.
Then I did update to the latest today 2.7 buildI 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.
-
@louis2 Use the commit ID
c0d7519df5dc1632ba9f2791ab377bdc19f45105. See here https://docs.netgate.com/pfsense/en/latest/development/system-patches.html#adding-a-patch -
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:3Crash 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-devCrash 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 3348No FreeBSD crash data found.
-
@louis2 Apologies - we saw that and a fix is coming soon.
-
Latest snapshot should have a good fix in it (for that error and others), so if you can, give that a try.
-
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
-
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 --- -
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.
