Bug 257079

Summary: natd keeps crashing
Product: Base System Reporter: Jack <xxjack12xx>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Some People CC: ohartmann, xxjack12xx
Priority: ---    
Version: 13.0-STABLE   
Hardware: amd64   
OS: Any   

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

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 to not me out via bge0
00200 deny ip from any to
00300 deny ip from 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_flags="-f /etc/natd.conf"
in /etc/rc.conf

cat /etc/natd.conf
use_sockets yes
same_ports yes

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 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 to not me out via bge0
ipfw add 200 deny ip from any to
ipfw add 300 deny ip from 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.