Hello Thomas,
I think you're hitting a known AX.25 kernel bug. What kernel version
are you running? Below is an email thread with another HAMs that was
seeing
something similar. He came back with:
Ubuntu 14.04 LTS with the older kernel. Works great.
A few of us have been trying to find some help to get a few known kernel
bugs squashed but haven't had any luck. As such, many people are having
to stay on <= 3.18.x kernels.
--David
KI6ZHD
-------- Forwarded Message --------
Hi David. More info!
Before I connect:
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
* WA7FPV-10 ax0 LISTENING 000/000 0 0
While the connection is active:
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
WA7FPV-0 WA7FPV-10 ax0 ESTABLISHED 000/002 2112 0
* WA7FPV-10 ax0 LISTENING 000/000 0 0
Now I've issued the disconnect from WA7FPV-0
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
WA7FPV-0 WA7FPV-10 ax0 DISC SENT 001/003 0 0
* WA7FPV-10 ax0 LISTENING 000/000 0 0
Now WA7FPV-0 has reported a clean disconnect, and sent the -UA frame
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
WA7FPV-0 WA7FPV-10 ax0 LISTENING 001/003 0 0
* WA7FPV-10 ax0 LISTENING 000/000 0 0
And we are stuck here.
Next I tried connecting to WA7FPV-10 again from WA7FPV-0. I observed
that DireWolf is decoding the packets ok. I hit disconnect (which
generates another -UA frame), and that is also decoded by DireWolf, but
does not close that listening socket. It seems like we have lost our
ability to communicate with that rogue socket and tell it to close. And
that rogue socket is blocking further connections. I tried 'axctl 0
WA7FPV-0 WA7FPV-10 kill' - no dice. The socket still shows up when I run
netstat.
I can still connect to/from WA7FPV-15 <--> WA7FPV using 'call 0 WA7FPV'.
This works fine - I can keyboard to my self :) When I disconnect the
socket closes like it should.
Connected:
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
WA7FPV-0 WA7FPV-15 ax0 ESTABLISHED 000/000 0 0
WA7FPV-0 WA7FPV-10 ax0 LISTENING 001/003 0 0
* WA7FPV-10 ax0 LISTENING 000/000 0 0
Couldn't capture the 'disconnect' state as it happened too fast, but
here is after the disconnect:
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
WA7FPV-0 WA7FPV-10 ax0 LISTENING 001/003 0 0
* WA7FPV-10 ax0 LISTENING 000/000 0 0
So clearly the audio levels are good, AX.25 is working, DireWolf is
working. I guess that leaves rmsgw. Or perhaps something about ax25d?
This is my ax25d.conf
# /etc/ax25/ax25d.conf
[WA7FPV-10 via 0]
NOCALL * * * * * * L
default * * * * * * - rmsgw /usr/local/bin/rmsgw rmsgw -l debug -P %d %U
# End /etc/ax25/ax25d.conf
Here is possibly useful info from /var/log/syslog
Mar 25 12:34:23 LinuxRMSGatewayBox kernel: [ 402.289950] IPv6:
ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
Mar 25 12:34:35 LinuxRMSGatewayBox dhclient: DHCPREQUEST of
128.208.93.190 on eth0 to 140.142.5.93 port 67 (xid=0x2c5d9cce)
Mar 25 12:34:35 LinuxRMSGatewayBox dhclient: DHCPACK of 128.208.93.190
from 140.142.5.93
Mar 25 12:34:35 LinuxRMSGatewayBox dhclient: bound to 128.208.93.190 --
renewal in 368550 seconds.
Mar 25 12:34:46 LinuxRMSGatewayBox kernel: [ 425.323910] perf interrupt
took too long (2532 > 2500), lowering kernel.perf_event_max_sample_rate
to 50000
Mar 25 12:35:48 LinuxRMSGatewayBox kernel: [ 487.195348] mkiss: ax0:
Trying crc-smack
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: getopt saw '-l'
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: optarg = debug
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: getopt saw '-P'
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: optarg = 0
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: configfilearg = (null)
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: configfile =
/etc/rmsgw/gateway.conf
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: using config file
/etc/rmsgw/gateway.conf
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: using version file
/etc/rmsgw/.version_info
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: #012WA7FPV-10 - Linux
RMS Gateway 2.4.0 Mar 24 2016 (CN87us)#012
Mar 25 12:35:48 LinuxRMSGatewayBox kernel: [ 487.346736] mkiss: ax0:
Trying crc-flexnet
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: WARNING: setcmsstat()
failed (errno = 13)
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: Channel: WA7FPV-10 on 0
(145050000 Hz, mode 0)
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: Login WA7FPV on 0
connected to sandiego.winlink.org <http://sandiego.winlink.org>
Mar 25 12:35:48 LinuxRMSGatewayBox rmsgw[1490]: *** Secure Gateway Logon
Mar 25 12:36:19 LinuxRMSGatewayBox rmsgw[1490]: ; INFO: Connection
closed by CMS (sense = 0x0000)#015
Mar 25 12:36:20 LinuxRMSGatewayBox rmsgw[1490]: Logout WA7FPV tx:81
rx:2 32.0s 2.6 Bytes/s (0)
Mar 25 12:41:59 LinuxRMSGatewayBox kernel: [ 857.739997] perf interrupt
took too long (5003 > 5000), lowering kernel.perf_event_max_sample_rate
to 25000
Not sure where to go from here. I'm going to recreate this setup on
another box using Ubuntu 12.04.5. I'm currently on Ubuntu 14.04.4 LTS
(GNU/Linux 4.2.0-34-generic i686).
Thanks,
-Josh
On Thu, Mar 24, 2016 at 9:35 PM, Josh Gibbs <gibb...@gmail.com
<mailto:gibb...@gmail.com>> wrote:
Thanks for this David... I'm going to run netstat a few times during
disconnect like you did and see what I see. Will report back in the
morning... time to put kids to bed.
Really appreciate your help!
-Josh WA7FPV
On Thu, Mar 24, 2016 at 8:22 PM, David Ranch <dra...@trinnet.net
<mailto:dra...@trinnet.net>> wrote:
Hey Josh,
Btw, I tried to reproduce your issue from home using a local
command like the following where I'm not actively using -4 but
-1 is a service that should answer:
sudo call -s KI6ZHD-4 d710 ki6zhd-1 via k6fb-7 (you cannot
make local connections so I'm using a remote digitpeater)
You can see below, I have the established connection, from
within the session I request to disconnect, and it does
disconnect. For a moment, I see the same condition as your
station but then KI6ZHD-4 receives the final "-UA" frame to
acknowledge the session should go away and then the funky
session goes away. Unless something is really wrong, I'm
thinking you're Direwolf audio levels might not be very good to
copy the end connections OR the timing of your TXDELAY and
TXTAIL might be too short.
Anyway.. reply to my first email and then this one.
--David
KI6ZHD
hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
ax25 -an
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
KI6ZHD-4 KI6ZHD-1 ax0 ESTABLISHED 000/001 0 0
<---------------------- Good connectionbut I request to disconnect
KI6ZHD-1 KI6ZHD-4 ax0 ESTABLISHED 001/000 0 0
* KI6ZHD-2 ax0 LISTENING 000/000 0 0
* KI6ZHD-1 ax0 LISTENING 000/000 0 0
* KI6ZHD-0 ax0 LISTENING 000/000 0 0
* KI6ZHD-5 ax0 LISTENING 000/000 0 0
hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
ax25 -an
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
KI6ZHD-4 KI6ZHD-1 ax0 DISC SENT 001/002 0 0
<--------------- Connection is going down
KI6ZHD-1 KI6ZHD-4 ax0 ESTABLISHED 001/001 768 0
* KI6ZHD-2 ax0 LISTENING 000/000 0 0
* KI6ZHD-1 ax0 LISTENING 000/000 0 0
* KI6ZHD-0 ax0 LISTENING 000/000 0 0
* KI6ZHD-5 ax0 LISTENING 000/000 0 0
hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
ax25 -an
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
KI6ZHD-4 KI6ZHD-1 ax0 DISC SENT 001/002 0 0
<------------ One side is gone, the other side needs to be ACKed
* KI6ZHD-2 ax0 LISTENING 000/000 0 0
* KI6ZHD-1 ax0 LISTENING 000/000 0 0
* KI6ZHD-0 ax0 LISTENING 000/000 0 0
* KI6ZHD-5 ax0 LISTENING 000/000 0 0
hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
ax25 -an
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
KI6ZHD-4 KI6ZHD-1 ax0 LISTENING 001/002 0
0<-------------- This is the screwy state you are seeing; I
think this is a display bug but it's minor
* KI6ZHD-2 ax0 LISTENING 000/000 0 0
* KI6ZHD-1 ax0 LISTENING 000/000 0 0
* KI6ZHD-0 ax0 LISTENING 000/000 0 0
* KI6ZHD-5 ax0 LISTENING 000/000 0 0
hampacket2:~/.wine/drive_c/Program Files/SCCo Packet$ netstat -A
ax25 -an <------------ I receive the -UA frame and now the
session goes away
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
* KI6ZHD-2 ax0 LISTENING 000/000 0 0
* KI6ZHD-1 ax0 LISTENING 000/000 0 0
* KI6ZHD-0 ax0 LISTENING 000/000 0 0
* KI6ZHD-5 ax0 LISTENING 000/000 0 0
--David
On 12/15/2018 04:47 PM, Thomas Karpiniec wrote:
Hi list,
I have a KISS-attached TNC that I use primarily for outgoing AX.25 layer
connections, and for TCP/IP services listening on ax0. I am not running ax25d
or any software listening on an AX.25-family socket. I've noticed on several
occasions that if somebody sends an SABM to my station the connection will be
accepted. The data doesn't go anywhere. Eventually they DISC and my station
replies UA. I am left with a lingering socket which means I can't communicate
with that station any more.
1: fm VK7BEN-1 to VK7NTK-1 ctl SABM+ 10:29:59
1: fm VK7NTK-1 to VK7BEN-1 ctl UA- 10:29:59
... (snip "I" and "RR" frames as remote user sends data) ...
1: fm VK7BEN-1 to VK7NTK-1 ctl DISC+ 10:30:36
1: fm VK7NTK-1 to VK7BEN-1 ctl UA- 10:30:36
When I come along later:
$ netstat -a -A ax25
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
VK7BEN-1 VK7NTK-1 ax0 LISTENING 005/000 0 0
$ sudo axcall 1 vk7ben-1
GW4PTS AX.25 Connect v1.11
Trying...
connect: Address already in use
I can attempt to kill it - the remote station responds that it's in disconnected mode,
but I am still left with this odd "LISTENING" socket.
$ sudo axctl 1 VK7BEN-1 VK7NTK-1 kill
1: fm VK7NTK-1 to VK7BEN-1 ctl DISC+ 11:18:56
1: fm VK7BEN-1 to VK7NTK-1 ctl DM- 11:18:57
$ netstat -a -A ax25
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
VK7BEN-1 VK7NTK-1 ax0 LISTENING 005/000 0 0
I was wondering if anyone could help me understand why the connection gets
accepted in the first place, and if there is a way to clean up the lingering
connection?
Regards,
Tom
VK7NTK
