Rule error related to DHCP VLAN prio
-
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.
-
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.
-
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.
-
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.
