开云体育

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