All, I have a image for our club that runs direwolf, PAT and QtTerm. What works and what does not:

works
If I compose a message and send to a BPQ / CMS server it works
If I send a message to someone in range via P2P it works
If I send to the person via a wide area digipeater using its full callsign W8LRK-5 (ax25://w8lrk-5/callsign) it works

does not work
If I send to the same person via the short digipeater alias name the P2P does not connect...

The above wide area system is running direwolf with LINBPQ but all the digipeating in done at the direwolf level.

Setting below:
mycall w8lrk-5

here is a copy of the non-working connection if someone can help:

开云体育

Hello Darryl,

does not work
If I send to the same person via the short digipeater alias name the P2P does not connect...

I see your issue..

CDIGIPEAT 0 0 LRK

You're configuring your Direwolf station to act as a digipeater named "LRK".? Don't name your digipeater with a name that's in use by a different digipeater.? You do NOT need to configure the CDIGIPEAT feature for any of your local AX.25 clients.? This option is only for *other* stations trying to use your station as a digipeater.


--David
KI6ZHD

Thanks David for the reply. This setup is the digipeater at the repeater site not my station.

My call w8dsb

Tower call w8lrk

If I digi from w8dsb via w8lrk-5 to another station then P2P works

If I digi from w8dsb via LRK to another station it does not work for P2P but it works for CHAT, beacons and other things. LRK is the alias for w8lrk-5 not my station.?

Maybe I am misunderstanding something, but I can't figure out why it does not work when using P2P it worked when we had a KPC3 up there but I replaced it with a PI and direwolf so we would have better packet correction.

See this part of the log:

开云体育

Hello Darryl,

I had written the following reply but then I replied to your second email as I thought it might be a misconfiguration.? Anyway.. I held on to this email instead of deleting it and I'm glad I did.? So onward..

here is a copy of the non-working connection if someone can help:

Ok.. let's go through this packet by packet:

[0L 20:27] W8DSB>N8RDF,LRK:(SABM cmd, p=1)

GOOD:? your initiating "SABM" via a digipeater (LRK)

?Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__|||||__

[0.4 20:27] W8DSB>N8RDF,W8LRK-5*:(SABM cmd, p=1)

GOOD: You hear your packet from the digipeater (noticed it identifying itself not as LRK but as W8LRK-5.? That's legal

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__||||||_

[0.4 20:27] N8RDF>W8DSB,W8LRK-5*:(RR cmd, n(r)=0, p=1)

BAD:? You didn't hear the "UA" packet via the digipeater yet.? You're system will have to retry the connection

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?___|||||_

[0.5 20:27] N8RDF>W8DSB,W8LRK-5*:(UA res, f=1)

BAD: Here is the missing "UA" frame coming expected from the digipeater but it's coming out of order!? Are you consistently seeing this behavior?? Do you know who runs this digipeater?? If it continues doing this, it might need a reboot

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?___||||__

[0.4 20:27] N8RDF>W8DSB,W8LRK-5*:(I cmd, n(s)=0, n(r)=0, p=0, pid=0xf0)Open source Winlink client - getpat.io<0x0d>

GOOD: Assuming the Linux AX.25 stack thinks the connection is open, you're sending a payload packet.? To confirm the status of the stack, you can run the netstat command (found in the in the net-tools package) in terminal window:

netstat -A ax25 -an
--
Active AX.25 sockets
Dest?????? Source???? Device? State??????? Vr/Vs??? Send-Q? Recv-Q
*????????? KI6ZHD-3?? ax0???? LISTENING??? 000/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
--

Here is an example with an established connection
--
Dest?????? Source???? Device? State??????? Vr/Vs??? Send-Q? Recv-Q
AA6WK-0??? KI6ZHD-1?? ax0???? ESTABLISHED? 000/000? 0?????? 0????
*????????? KI6ZHD-3?? ax0???? LISTENING??? 000/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
--

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__|||||__

[0.4 20:27] N8RDF>W8DSB,W8LRK-5*:(I cmd, n(s)=1, n(r)=0, p=1, pid=0xf0);FW: N8RDF<0x0d>[Pat-0.10.0-B2FHMG$]<0x0d>; W8DSB DE N8RDF (EN82cn)><0x0d>

GOOD, you've received a good payload packet from the remote station

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__||||||_

[0.4 20:27] N8RDF>W8DSB,W8LRK-5*:(RR cmd, n(r)=0, p=1)

[0L 20:27] W8DSB>N8RDF,LRK:(SABM cmd, p=1)

Is this a copy/paste issue?? Why is your station sending another SABM connection request?!? Is this a new connection?? We didn't see the previous connection get terminated first.? It's critical that you send the complete output *accurately* for us to have any chance to help you here.

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__|||||__

[0.4 20:27] W8DSB>N8RDF,W8LRK-5*:(SABM cmd, p=1)

Assuming this is a new connection attempt, this looks GOOD

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__|||||__

[0.4 20:28] N8RDF>W8DSB,W8LRK-5*:(UA res, f=1)

GOOD:? initial connection complete

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?___|||||_

[0.5 20:28] N8RDF>W8DSB,W8LRK-5*:(I cmd, n(s)=0, n(r)=0, p=0, pid=0xf0)Open source Winlink client - getpat.io<0x0d>

GOOD: you've received a payload packet from the remote station

Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__|||||__

[0.4 20:28] N8RDF>W8DSB,W8LRK-5*:(I cmd, n(s)=1, n(r)=0, p=1, pid=0xf0);FW: N8RDF<0x0d>[Pat-0.10.0-B2FHMG$]<0x0d>; W8DSB DE N8RDF (EN82cn)><0x0d>

GOOD: you've received a second payload packet from the remote station

So what happens after this?? Does the remote station keep retrying some specific packet?? Maybe your station keeps retrying something?? Please include those packets as well.


--David
KI6ZHD

The fundamental problem here is that the originating station does not seem to be processing the UA frame as expected.
This starts out good.?

[0L 20:27] W8DSB>N8RDF,LRK:(SABM cmd,

[0.4 20:27] W8DSB>N8RDF,W8LRK-5*:(SABM cmd, p=1)

The originating station specifies the "LRK" alias for the digipeater.
The digipeater substitutes its actual callsign.
This is all good.

The expected UA frame comes back.

?

[0.5 20:27] N8RDF>W8DSB,W8LRK-5*:(UA res, f=1)

This is all good.

However the originating station keeps sending SABM as if it never heard the UA.

I think the most likely explanation is that the connection link layer software has a bug.
It started the connection via digipeater LRK and is expecting the reply to come back via LRK.
The UA is ignored because it did not come via the expected path.?

I would consider this to be a defect.? It should not care about the contents of the via path, only that all of the digipeater fields are marked as being used.

Robert had an excellent suggestion:? Try using the actual callsign for the digipeater, W8LRK-5, rather than the alias LRK.

I think you already answered this question at the beginning:

If I digi from w8dsb via w8lrk-5 to another station then P2P works.
If I digi from w8dsb via LRK to another station it does not work for P2P ...


Is PAT connecting directly to direwolf with the AGW network interface or are you using the AX.25 for Linux in the middle?

If the latter, this seems to be a bug in AX.25 for Linux.

I would recommend using the direct connection to direwolf using the AGW network interface.? It is a lot simpler to set up and there is less to go wrong.?

开云体育

The challenge here is that PAT uses the Linux AX.25 stack.? I don't see how this would be a PAT bug.

--David
KI6ZHD

WOW, I go to work and come back to a bunch of help. Thank you everyone for answering.

Yes if I use the callsign it works fine, just not with the alias

Yes PAT is using the AX25 stack

Yes, If I replace the pi running direwolf with a TNC the callsign and the alias both work with the same PAT setup.

I am the control op for the digipeater, its about 2 miles away and up about 200' on our repeater tower.

I am also the president of our local club and we bought radios, had a sound card designed and built a image for 70 members but I am guessing only about 20 will try it.

This looks like its a bug somewhere that I do not have control of; late tonight after everyone goes to bed I will reboot the digi PI and see if it fixes itself. If not I will tell everyone just to use the callsign if they want to do P2P.

开云体育

That doesn't look right.? Why are all these remote callsigns listed if they aren't connected.? Do you know if these were stations that previously connected to your station?? Techically speaking, you should see something like:




This could be another symptom of the buggy LInux AX.25 stack issue.

--David
KI6ZHD

Yes, these are all stations that have popped mail using PAT as this PI also has linbpq running on it. It is using w8lrk-10 and LARK not w8lrk-5 or LRK....

开云体育

Curious, what Linux distribution and kernel version are you using?

--David
KI6ZHD

开云体育

Hello Darryl,

I've been doing some noodling around your "netstat -A ax25 -an" output issue and I was reminded by DL9DAU that this is a known kernel bug (I remember the issue slightly differently).? The root of the issue is that once someone makes a connection to your station and then disconnects, they will NEVER be able to re-connect to your station until you either restart the Linux AX.25 stack (run your shutdown script and then bring it back up) or reboot..? I encourage you do some confirmation testing by contacting some of these other stations and see if they can connect multiple times to your station or if they get failures after the initial connection.

It was mentioned that this specific issue might occur LESS on single core systems.? This would be easy for you to test by making this one configuration change then doing a simple:

??

Obviously, this will quarter your Raspberry Pi's performance but just for a Winlink station, I don't think would be much of an issue at least for testing.


As for long term fixes, I think this kernel issue was already fixed upstream but it might not have made it into current production kernel versions:

??


Then there is this possibly DIFFERENT fix that is said to be effective yet might not be upstreamed:

??


If this second fix is the real solution, it will require the recompilation of the AX.25 kernel module but I don't think it will be too bad.? I'm researching the *easiest* way to recompile AX.25 kernel module and once I find something, I'll let you know.

--David
KI6ZHD

OK thanks for the reply, I am running Raspbian GNU/Linux 10 \n \l?with Linux 5.10.11-v7+ armv7l

Darrell,

So I did have to cheat some in the beginning, the tmp/kisstnc port
that is created when direwolf starts up for some reason was always
busy or locked so I had to play some scripting games.

Since you are using the 5.10.11 kernel, stop pulseaudio to see if that
frees up direwolf from being busy.

sudo systemctl --system stop pulseaudio
sudo systemctl --system disable pulseaudio
sudo systemctl --user stop pulseaudio
sudo systemctl --user disable pulseaudio

/Basil n7nix

开云体育

Hello Darryl,

OK thanks for the reply, I am running Raspbian GNU/Linux 10 \n \l?with Linux 5.10.11-v7+ armv7l

Got it.

What I know so far, I started with HAMPI because it had other software that my club wanted. I installed direwolf, PAT and QtTermTCP and wrote a boatload of scripts.

Ok.

We can CHAT with each other on and off all day and it never fails, I recently installed a CHAT server at our repeater site to stop all the P2P chatting. Now QtTerm uses AGW and that never seems to fail. We are using both the LINUX version on the PI and also the PC version and connecting to the PI over WiFi to use as a modem.

When you say "chat", what program is this?? Is this something AX25 enabled that comes in HamPi?

Now PAT can connect and get mail over and over without issue to the RMS / CMS server. The only issue we have had is what I reported here and that is trying to send PAT mail using a alias. Today I released a updated version to our group removing the the via DIGIPEATER and the problem will just be a known bug.

Hmmm.. I'll need to test this to see if I can replicate.

I changed all the dial alias as follows:
? ? "P2P w8dsb via LRK": "ax25:///LRK/w8dsb?freq=145050",? ? ?<=== old does not work stack bug
? ? "P2P w8dsb via w8lrk-5": "ax25:///w8lrk-5/w8dsb?freq=145050",? ?<=== new way that does work
I did this for all the club members on packet so the list is kinda long

Curious, instead of PAT, can you make a connection to the remote Winlink server manually using the "call" or "axcall" program using the "LRK" digipeater?? Technically speaking, you can connect, authenticate, send, and receive Winlink messages all manually using the call program without using GUI tools like PAT.? This would help narrow things down to know if it's PAT's bug or something else.

So I did have to cheat some in the beginning, the tmp/kisstnc port that is created when direwolf starts up for some reason was always busy or locked so I had to play some scripting games.

Ok.. that's bad and shouldn't happen either.

sleep 50

Why are you waiting almost a full minute?? No Need.

sudo /usr/sbin/kissattach /tmp/kisstnc radiovhf &

sudo /usr/sbin/kissattach /dev/pts/1 radiovhf &

sudo /usr/sbin/kissattach /dev/pts/2 radiovhf &

Unless you have two different direwolf sessions working, this is very broken as the first line will most likely conflict with one of the two following ones.? I recommend you follow the simple approach that's recommended from the Direwolf UserGuide or if you want something more flexible, try my start up and shutdown scripts:

??
??
??

Their specific setup and all that is documented here:

?

# script called from crontab and start direwolf both require this delay

sleep 60

Waiting another full minute is unnecessary

sudo /usr/sbin/kissparms -c 1 -p radiovhf -s 100 -r 63 -t 600 -l 100 &

Setting a TXDELAY of 600ms is *very* slow.? What radio do you have?? I would expect a value of 200ms to be more than slow enough for 80% of the radios on the market.? Many good radios can do 150 and a few radios can do say 120.

I don't think any of this is causing the digi issue. but as long as a user does not stop and restart direwolf more then twice all is good. I told them to always reboot if they shut it down by accident.

I know I could run as a service but everyone wants to watch it like a lava lamp.

Ha.. yes.. I can appreciate that as well.? The above approach will log everything to a LOG file so they can watch things fly by if they wish.

Thanks for finding out this is a bug and helping me find a work a round for now....73

Well.. I would appreciate if you could do the above test and help narrow things down a little more before we call this a Direwolf bug vs a PAT bug vs. a Linux AX.25 stack bug.

--David

Just to follow up before this topic gets locked. I changed all the alias lists in PAT to use the full callsign as a work around. I also wrote Martin as asked if AGW and Forms are coming for PAT. He replied saying that Forms are first and soon but AGW is on the list of wants.