Linux AX25: `address already in use` error after first connection

[Tyler-2]

I've got Direwolf running as a software TNC with the -p command, and I run kissattach to connect the Linux AX.25 stack to that port.

This works, and when I connect in Pat, my emails are sent and received, and Pat disconnects.

Afterwards, any attempts to connect again are met with:

Remote accepted 4BR6SH6JZATY
Transmitting [Re: Test] [offset 0]
FF
>FQ
2022/05/16 02:25:09 Disconnected.
2022/05/16 02:25:24 Connecting to N4POW-10 (ax25)...
2022/05/16 02:25:24 Unable to establish connection to remote: address already in use

Active AX.25 sockets
Dest       Source     Device  State        Vr/Vs    Send-Q  Recv-Q
N4POW-10   K1MLN-0    ax0     LISTENING    006/001  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    002/004  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    006/000  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    005/002  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    005/002  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    005/002  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    006/003  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    006/000  0       0     
N4POW-10   K1MLN-0    ???     LISTENING    005/002  0       0     

$ sudo ifconfig ax0
ax0: flags=67<UP,BROADCAST,RUNNING>  mtu 255
        ax25 K1MLN-9  txqueuelen 10  (AMPR AX.25)
        RX packets 81  bytes 6678 (6.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 1397 (1.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I have no similar problems when using simply axcall. I can connect and reconnect all day, even after Pat gets into this bad state. But Pat will not work.

Restarting Pat doesn't resolve it - I have to restart everything all the way up to Direwolf.

Pat Version 0.12.1-2+b1
Direwolf Version 1.6
$ uname -rv
5.17.5-surface #3 SMP PREEMPT Sat May 7 16:37:05 UTC 2022
(A custom kernel for Surface Laptops running Debian)

[martinhpedersen]

I've been trying to reproduce this today running two Pat instances (P2P) (develop builds) with older kernel versions:

• Linux node-a 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux
• Linux node-b 4.9.0-18-686-pae #1 SMP Debian 4.9.303-1 (2022-03-07) i686 GNU/Linux

The connection teardown works as intended, with no dangling connections. This leads me to believe that this is either a bug in recent Linux kernels or has already been resolved in recent commits.

Can you please try building the develop branch and see if you're able to reproduce the issue?

Thanks!

[dranch]

This specific kernel bug (others) has finally been getting some review. Please see https://www.spinics.net/lists/linux-hams/ for some of the archives. Specifically, here is the thread on the stale AX.25 session issue: https://www.spinics.net/lists/linux-hams/msg04952.html . Once a viable fix is made available aligning to all the other fixes that are in flight, it will take some time (months / quarters) until a standard Linux distribution might publish them for enduser consumption

[programmin1]

Same here with latest Pat and Linux 5.15.0-37-generic #39-Ubuntu.
I have to unplug and plug it in again and use my window picker to call up AX25 on the device again:
https://github.com/programmin1/Pat-Window/

[dranch]

Not sure what you mean by "unplug/plug" but an ugly work around is to do:
ifconfig ax0 down
killall kissattach
and then bring the stack back up again. This issue doesn't always happen and it's not clear why it does/doesn't occur but I can say that it does NOT happen to me on u20.04 running 5.13.0-40-generic. Anyway.. several fixes have made it into the kernel but I don't when they will make it to specific distro kernel packages just yet.

[n7nix]

The symptom described by Tyler-2 is the symptom fixed for kernel 4.2.0 in June of 2016. See submission here: AX.25: Close socket connection on session completion. @Tyler-2 which Linux kernel are you using?

[Tyler-2]

Linux 5.17.9-surface #1 SMP PREEMPT Sat May 21 02:11:54 UTC 2022
from
https://github.com/linux-surface/linux-surface

I don't know how to check the status of that patch in this custom kernel but naturally I assume it's in there.

[nx2i]

I am seeing the same behavior. I am running pat v0.13 with Linux 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux. This is the current version of Linux Mint. The direwolf version is 1.7.

[martinhpedersen]

As this is most likely a kernel bug, I'm tagging this issue as wontfix. Keeping it open for now, so we can track progress and discuss this further.

It would be great if someone could dig into this and investigate why the bug still exists in Linux >= 5.4 if the patch was merged in 4.2.0. Maybe a new bug was introduced? 🤔 I guess a good place to start would be to verify that the patch did in fact fix the issue.

I saw similar issues back when I was running Debian Jessie (kernel 3.6). When I upgraded to Debian Stretch (kernel 4.9) the issue was resolved IIRC. Maybe a similar bug was introduced in a later kernel release? 🤷

Anyway, the local RMS packet node in my area has been QRT for a couple of years now, so it's difficult for me to investigate further right now 😞.

[jlrgraham]

For what it's worth, I did a custom build of Linux 5.19.9 on Debian Bullseye and this issue no longer seems to be present. It was present for me on 5.10.0-18-amd64 (the 5.10.140 dpkg in Bullseye).

[xssfox]

stumbled upon this issue while researching. I suspect this kernel patch might resolve the issue entirely https://github.com/torvalds/linux/blob/v5.19/net/ax25/af_ax25.c - so 5.19 kernels might be ok now - yet to test

[xssfox]

Just upgraded to 5.19 kernel on Ubuntu and this appears to be resolved :)