|Summary:||natd keeps crashing|
|Product:||Base System||Reporter:||Jack <xxjack12xx>|
|Component:||bin||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Severity:||Affects Some People||CC:||ohartmann, xxjack12xx|
Description Jack 2021-07-09 12:34:28 UTC
natd keeps crashing after latest update 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n246214-4a58aca40df9: Fri Jul 9 03:21:11 PDT 2021 pid 3637 (natd), jid 0, uid 0: exited on signal 8 (core dumped) /sbin/natd -f /etc/natd.conf -dynamic -n bge0 cat /etc/natd.conf use_sockets yes same_ports yes dynamic ipfw list 00100 allow ip from any to any via bge1 00101 allow ip from any to any via lo0 00102 divert 8668 ip from any to me in via bge0 00103 divert 8668 ip4 from 10.0.0.0/24 to not me out via bge0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65535 allow ip from any to any
Comment 1 Jack 2021-07-09 14:58:49 UTC
To clarify, natd starts up, works for a little while, then crashes
Comment 2 Jack 2021-07-11 08:43:42 UTC
It appears to have stopped crashing after recompiling the system with the latest git.
Comment 3 Jack 2021-07-11 11:17:12 UTC
Actually, it's still randomly crashing with the src built from 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n246228-47c5e288eee9: Sun Jul 11 01:16:08 PDT 2021 Jul 11 04:02:39 jack kernel: pid 2455 (natd), jid 0, uid 0: exited on signal 8 (core dumped)
Comment 4 Jack 2021-07-15 08:40:55 UTC
I see the commit 791035c8da5e8a693b3b954db67ff50b4f8695cb fixed the issue.
Comment 5 O. Hartmann 2021-07-18 07:34:59 UTC
I use FreeBSD 13-STABLE on an APU2C4 as routing/firewalling appliance in conjunction with a ISP provided DSL line. The router does NAT in kernel, using IPFW as its native filtering facility - and we see those spontaneously crashes also - without using natd! The time when it crashes (and reboots) is not to be determined. The last know good build was: FreeBSD 13.0-STABLE #17 stable/13-n246147-16d43e56022: Sat Jul 3 08:45:39 CEST 2021 amd64 Successors are crashing. I do not know whether this is really natd related or the the bug is just simply triggered by natd in the reported case and is settled much deeper. Please, can you reopen?
Comment 6 Jack 2021-07-18 07:51:11 UTC
My original setup was natd would crash within minutes after starting up and doing nat in kernel without natd would cause a kernel panic/reboot. With the latest update to FreeBSD 13.0-STABLE #0 stable/13-n246270-cd2e5ae71bb1: Wed Jul 14 23:39:18 PDT 2021, it has stopped crashing. My natd setup that kept having natd crash was natd_enable="YES" natd_flags="-f /etc/natd.conf" natd_interface="bge0" in /etc/rc.conf cat /etc/natd.conf use_sockets yes same_ports yes dynamic The setup that was causing a kernel panic/reboot was ipfw list 00100 nat 1 ip4 from any to me in via bge0 00101 nat 1 ip4 from 10.0.0.0/24 to any out via bge0 65535 allow ip from any to any
Comment 7 Jack 2021-07-18 07:52:46 UTC
I forgot to mention, my ipfw rules with natd running were ipfw add 100 allow ip from any to any via bge1 ipfw add 101 allow ip from any to any via lo0 ipfw add 102 divert natd ip from any to me in via bge0 ipfw add 103 divert 8668 ip4 from 10.0.0.0/24 to not me out via bge0 ipfw add 200 deny ip from any to 127.0.0.0/8 ipfw add 300 deny ip from 127.0.0.0/8 to any
Comment 8 O. Hartmann 2021-07-18 09:42:20 UTC
The last time I did check whether my NanoBSD APU works or works not, was on July, 14th! Maybe I just missed to mysterious fix, I'll try immediately. My point is, since it is very hard to reconfigure the image we build to be a fully debuggable, I only see a short time the crash info on the serial console. Since I still do not have a clue how to catch via "tip" the output of the terminal of the crashing firewall, I'm a bit blind here. Since the system completely operates in memory, there is no trace of the crash left. So, having said this, it is great to have someone with similar or the same experiences met here and you've discovered another trace of the problem with the natd daemon. I fear that there is a underlying problem/bug, being able to bubble up anytime in the future again, so it should be targeted and at least reported and well described.
Comment 9 O. Hartmann 2021-07-18 12:48:18 UTC
The latest 13-STABLE (FreeBSD 13.0-STABLE #8 stable/13-n246370-74ff46ac172: Sun Jul 18 11:18:45 CEST 2021 amd64) is now up for almost three hours without any crash. So it might be correct, that with July, 14th 2021 a set of solving patches arrived in 13-STABLE.