I will try this scenario on my Pi with bookworm, and replace the /usr/local/bin/rmsgw with a shell script that writes to a log file.
? I had an interesting result, basically trying this same test. ?I modified ax25d.conf and replaced rmsgw with /usr/games/fortune on my test Pi pair. ?The idea was to use a non-ax.25 app to produce some output and see if we can isolate the problem.
? After making the change on RMS Pi, the PAT Pi connected as it normally does, receiving a fortune cookie instead of a WL2K banner. ?Obviously the connection from PAT failed, but I let it run for about 2 days before I noticed the "netstat issue" again. ?I killed ax25d and immediately received a kernel Oops, but, interesting, not an immediate crash. ?The crash happened when I restarted ax25d:
root@hammyRMS:~# grep -v "^#" /etc/ax25/ax25d.conf
[MYCALL-4 via dw12]
NOCALL * * * * * * L
default ?* * * * * * ?0 ? ?root ?/usr/games/fortune fortune
root@hammyRMS:~# netstat -an
....
Active AX.25 sockets
Dest ? ? ? Source ? ? Device ?State ? ? ? ?Vr/Vs ? ?Send-Q ?Recv-Q
* ? ? ? ? ?MYCALL-4 ? ? ? ? ? LISTENING ? ?000/000 ?0 ? ? ? 0
root@hammyRMS:~#
root@hammyRMS:~# ps -ef | grep ax25
root ? ? ? ? 968 ? ? ? 1 ?0 Feb25 ? ? ? ? ?00:00:00 /usr/sbin/ax25d -l
root ? ? ?479232 ? ? 792 ?0 09:08 pts/3 ? ?00:00:00 grep ax25
root@hammyRMS:~# kill 968
root@hammyRMS:~#
Message from syslogd@hammyRMS at Feb 28 09:09:05 ...
?kernel:[227603.958206] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
?
Message from syslogd@hammyRMS at Feb 28 09:09:05 ...
?kernel:[227603.958206] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
?
Message from syslogd@hammyRMS at Feb 28 09:09:05 ...
?kernel:[227604.256120] Code: f9426400 d538d082 12800003 8b020000 (885f7c05)
?
root@hammyRMS:~#
root@hammyRMS:~# uptime
?09:09:18 up 2 days, 15:13, ?9 users, ?load average: 0.09, 0.17, 0.20
root@hammyRMS:~#
root@hammyRMS:~# ax25d -l
root@hammyRMS:~# client_loop: send disconnect: Broken pipe
?
What this tells me is that I don't need to waste any time troubleshooting rmsgw. ?The problem lies between the kernel and ax25d's use of the kernel API. ?I think I've taken this about as far as I can without digging into the code. ?I think next steps would be to see if I can add some verbose logging to ax25d and try to understand what has changed in the kernel's AX.25 stack between my version and a working version.
? Cheers
? Mike
