Re: PAT not able to digipeat properly using direwolf
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
|
Re: PAT not able to digipeat properly using direwolf
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
|
Re: PAT not able to digipeat properly using direwolf
OK thanks for the reply, I am running Raspbian GNU/Linux 10 \n \l?with Linux 5.10.11-v7+ armv7l
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. 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. 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. 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 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. Example of how I was able to attached ax25 port to use:
#!/bin/bash
?
sleep 50
sudo /usr/sbin/kissattach /tmp/kisstnc radiovhf &
sudo /usr/sbin/kissattach /dev/pts/1 radiovhf &
sudo /usr/sbin/kissattach /dev/pts/2 radiovhf & afterwhich I do this:
#!/bin/bash
?
# script called from crontab and start direwolf both require this delay
sleep 60
?
sudo /usr/sbin/kissparms -c 1 -p radiovhf -s 100 -r 63 -t 600 -l 100 &
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. Thanks for finding out this is a bug and helping me find a work a round for now....73
|
Re: PAT not able to digipeat properly using direwolf
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
On 03/27/2021 10:27 AM, David Ranch
wrote:
toggle quoted message
Show quoted text
Curious, what Linux distribution and kernel version are you using?
--David
KI6ZHD
On 03/26/2021 06:14 PM, W8DSB wrote:
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....
|
Re: PAT not able to digipeat properly using direwolf
Curious, what Linux distribution and kernel version are you using?
--David
KI6ZHD
On 03/26/2021 06:14 PM, W8DSB wrote:
toggle quoted message
Show quoted text
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....
|
Re: PAT not able to digipeat properly using direwolf
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....
|
Re: PAT not able to digipeat properly using direwolf
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:
Active AX.25 sockets
Dest? ? ? ?Source? ? ?Device? State? ? ? ? Vr/Vs? ? Send-Q?
Recv-Q
* ? ?? ??? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
This could be another symptom of the buggy LInux AX.25 stack
issue.
--David
KI6ZHD
On 03/26/2021 04:03 PM, W8DSB wrote:
toggle quoted message
Show quoted text
Active AX.25 sockets
Dest? ? ? ?Source? ? ?Device? State? ? ? ? Vr/Vs? ? Send-Q?
Recv-Q
W8MSP-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
KE8QQQ-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
W8JMB-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
KE8JKF-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
K8CA-0? ? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
K8CA-2? ? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
KE8JKF-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
WB8SFY-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
KE8GXK-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
KI8A-0? ? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
N8RDF-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ? ?
W8DSB-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ?
?0? ??
|
Re: PAT not able to digipeat properly using direwolf
Active AX.25 sockets
Dest? ? ? ?Source? ? ?Device? State? ? ? ? Vr/Vs? ? Send-Q? Recv-Q
W8MSP-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
KE8QQQ-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
W8JMB-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
KE8JKF-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
K8CA-0? ? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
K8CA-2? ? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
KE8JKF-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
WB8SFY-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
KE8GXK-0? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
KI8A-0? ? ?W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
N8RDF-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ? ?
W8DSB-0? ? W8LRK-10? ?ax0? ? ?LISTENING? ? 000/000? 0? ? ? ?0? ??
|
New CM108 sound card coming soon
All, my club is lucky enough to have Steve N8AR as a member. He is the designer for the SHARI and the DINAH. We recently asked him to produce a more convenient sound card for our club packet project. It is named the PAUL. It¡¯s not yet listed on the kitsforhams.com website as we helped design and bought all 30 of the first builds. I am attaching a picture. So far we have deployed 25 of these without a hitch. I just wanted to say publicly, thank you to Steve and also tell everyone another sound card is coming. Our main goal was to have the connectors on one end. So we could put it in a go box, such as a pelican. Have it compatible with all the TNC cables already on the market. Have an hardware adjustable RX and TX pot (no amp). I feel we have succeeded in making this hobby just a little bit better. 
|
Re: PAT not able to digipeat properly using direwolf
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.
|
Re: Pat Winlink 2M Packet 1200 baud Setup
Thanks for the update here Michael and we really
need to pin your post on Groups.IO.? Why?? There are many users
trying to setup packet stations with Baofeng and other too-cheap
radios due to new / popular Youtube videos, the solution cost is
so low not to try it, etc. yet few will have real *complete*
success.
--David
KI6ZHD
On 03/26/2021 12:26 PM, Michael LaBlanc
wrote:
toggle quoted message
Show quoted text
Today I successfully connected to my local 1200 baud,
packet Remote Message Server about 10 times and was able to
both send and receive email messages.
What allowed me to do this was to swap out the Baofeng
UV-5R for a 21 year old Kenwood TNC.? I used the exact same
antenna, in the exact same spot and left the software
configuration for the Pi, Pat Winlink, and Direwolf the same.
I know some folks have been successful with the UV-5R's on
packet, but the 2 Baofeng's that I own (purchased from Amazon
about 2 years ago) did not seem to be up to the task.
I want to send out a HUGE THANKS to everyone that responded
with all your helpful suggestions.? As I am just returning to
the Ham Radio hobby after a long absence, it is totally
inspiring to find a vibrant community willing to help out a
newbie.
Thanks again,
Mike
KC3EHR
On Thu, Mar 25, 2021 at 5:05
PM Ray Wells < aprs@...>
wrote:
I
know you won't want to hear this .....
The problem may be as simple as using the Baofeng radio, those
radios
having a very solid reputation for poor performance for packet
radio. Rx
recovery time after dropping PTT is unacceptably long and
somewhat
unpredictable in this regard regardless of running squelched
or
unsquelched. The rx recovery time is a long way from good
enough for
data. That problem can only be solved by getting other
stations to
increase their TXD to unacceptable times, to the detriment of
the entire
network.
If you search the archives you'll find poor Baofeng
performance
mentioned over and over again. I have the skills and test
equipment but
gave up on trying to use the Baofeng for packet radio, and I'm
not the
only one.
The frequently recommended fix is to source a used "brand
name" radio
and use that instead.
Ray vk2tv
On 25/3/21 11:52 pm, Michael LaBlanc wrote:
> I have made some progress and now have good audio levels
and am
> getting stable call/response between my home radio setup
and the RMS.
>
> However, it seems like my station calls for SAMB, then
the RMS returns
> with the expected RR (ready to receive), but my station
ignores this
> and sends another SAMB anyway.? Then the RMS sends a DM
(Disconnect)
> command.
>
> Any ideas why my station is not continuing on with the
connection
> steps after the RR command from the RMS?
>
> Thanks in advance for your help.
>
> Mike
> KC2EHR
>
> Direwolf Log 3/25/2021
> ---------------------------------
>
> pi@RaspPi4:~ $ sudo direwolf -p
> Dire Wolf version 1.6
> Includes optional support for: ?hamlib cm108-ptt
>
> Reading config file direwolf.conf
> Audio device for both receive and transmit: plughw:2,0
?(channel 0)
> Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100
sample rate / 3.
> Note: PTT not configured for channel 0. (Ignore this if
using VOX.)
> Ready to accept AGW client application 0 on port 8000 ...
> Ready to accept KISS TCP client application 0 on port
8001 ...
> Virtual KISS TNC is available on /dev/pts/2
> Created symlink /tmp/kisstnc -> /dev/pts/2
> [0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> KC2EHR audio level = 0(0/0) ? [NONE] ? _|||_____
> [0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> K2DLL-10 audio level = 55(22/23) ? [NONE] ? |||||____
> [0.2] K2DLL-10>KC2EHR:(RR cmd, n(r)=0, p=1)
> [0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> KC2EHR audio level = 2(6/7) ? [NONE] ? |||||____
> [0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> K2DLL-10 audio level = 55(22/23) ? [NONE] ? |||||____
> [0.2] K2DLL-10>KC2EHR:(DM res, f=0)
> [0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> KC2EHR audio level = 0(0/0) ? [NONE] ? |||||____
> [0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> K2DLL-10 audio level = 54(21/23) ? [NONE] ? ||||||___
> [0.2] K2DLL-10>KC2EHR:(DM res, f=0)
> [0L] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>
> KC2EHR audio level = 0(1/1) ? [NONE] ? |||||____
> [0.2] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>
> On Wed, Mar 24, 2021 at 5:06 PM Michael LaBlanc via
> <>
<mlablan1=[email protected]
> <mailto:[email protected]>>
wrote:
>
>? ? ?I agree about the audio levels - I have figured out
how to
>? ? ?stabilize the audio level response from the Remote
Message Server,
>? ? ?but I am still unable to connect.? The RMS seems to
be immediately
>? ? ?issuing a DM, which I believe is a connection refused
message.?
>? ? ?Also, I noticed a message from Direwolf about needing
to issue a
>? ? ?"kissparms -c 1 -p radio" command, so I did that.?
This got rid of
>? ? ?the Direwolf message on the next restart, but I am
still getting
>? ? ?the DM messages from the RMS.? I am working through
the 3
>? ? ?documents referenced to better understand how it is
supposed to
>? ? ?work.? I continue to try different antennas, located
in different
>? ? ?locations.? Progress, but no success yet...
>? ? ?Pat Winlink Log 3/24/2021
>? ? ?-------------------------
>? ? ?pi@RaspPi4:~ $ sudo kissattach /dev/pts/8 wl2k
>? ? ?AX.25 port wl2k bound to device ax0
>? ? ?pi@RaspPi4:~ $ kissparms -c 1 -p wl2k
>? ? ?kissparms: socket: Operation not permitted
>? ? ?pi@RaspPi4:~ $ sudo kissparms -c 1 -p wl2k
>? ? ?pi@RaspPi4:~ $ pat http
>? ? ?2021/03/24 16:28:41 Starting HTTP service
(0.0.0.0:5000)...
>? ? ?2021/03/24 16:29:14 Connecting to K2DLL-10 (ax25)...
>? ? ?2021/03/24 16:29:59 Unable to establish connection to
remote: Dial
>? ? ?timeout
>? ? ?Direwolf Log 3/24/2021
>? ? ?----------------------
>? ? ?pi@RaspPi4:~ $ sudo direwolf -p
>? ? ?Dire Wolf version 1.6
>? ? ?Includes optional support for:? hamlib cm108-ptt
>? ? ?Reading config file direwolf.conf
>? ? ?Audio device for both receive and transmit:
plughw:2,0? (channel 0)
>? ? ?Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+,
44100 sample rate / 3.
>? ? ?Ready to accept AGW client application 0 on port 8000
...
>? ? ?Ready to accept KISS TCP client application 0 on port
8001 ...
>? ? ?Virtual KISS TNC is available on /dev/pts/7
>? ? ?Created symlink /tmp/kisstnc -> /dev/pts/7
>? ? ?Invalid transmit channel 8 from KISS client app.
>? ? ?Are you using AX.25 for Linux?? It might be trying to
use a modified
>? ? ?version of KISS which uses the port (channel) field
differently
>? ? ?than the
>? ? ?original KISS protocol specification.? The solution
might be to use
>? ? ?a command like "kissparms -c 1 -p radio" to set CRC
none mode.
>? ? ?Another way of doing this is pre-loading the "kiss"
kernel module
>? ? ?with CRC disabled:
>? ? ?sudo /sbin/modprobe -q mkiss crc_force=1
>? ? ?<<< Data frame from KISS client application,
port 8, total length = 18
>? ? ?? 000:? 80 96 64 88 98 98 40 f4 96 86 64 8a 90 a4 61
3f?
>? ? [email protected]?
>? ? ?? 010:? c9 d9 ? ? ..
>? ? ?Invalid transmit channel 2 from KISS client app.
>? ? ?Are you using AX.25 for Linux?? It might be trying to
use a modified
>? ? ?version of KISS which uses the port (channel) field
differently
>? ? ?than the
>? ? ?original KISS protocol specification.? The solution
might be to use
>? ? ?a command like "kissparms -c 1 -p radio" to set CRC
none mode.
>? ? ?Another way of doing this is pre-loading the "kiss"
kernel module
>? ? ?with CRC disabled:
>? ? ?sudo /sbin/modprobe -q mkiss crc_force=1
>? ? ?<<< Data frame from KISS client application,
port 2, total length = 18
>? ? ?? 000:? 20 96 64 88 98 98 40 f4 96 86 64 8a 90 a4 61
3f?
>? ? [email protected]?
>? ? ?? 010:? 24 20 ? ? $
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 50(20/21)? ?[NONE]? ?|||||____
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 50(20/21)? ?[NONE]? ?||||||___
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 10(10/10)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 50(21/21)? ?[NONE]? ?|||||____
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?|||||____
>? ? ?[0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 49(20/21)? ?[NONE]? ?|||||____
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>? ? ?KC2EHR audio level = 0(3/3)? ?[NONE]? ?|||||____
>? ? ?[0.2] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>
>
|
Re: Pat Winlink 2M Packet 1200 baud Setup
CORRECTION -
??
I swaped out the Baofeng UV-5R for a 21 year old Kenwood HT ?? NOT a TNC
On Thu, Mar 25, 2021 at 10:13 AM WB2OSZ < wb2osz@...> wrote: On Thu, Mar 25, 2021 at 08:53 AM, Michael LaBlanc wrote:
However, it seems like my station calls for SAMB, then the RMS returns with the expected RR (ready to receive), but my station ignores this
and sends another SAMB anyway.? Then the RMS sends a DM (Disconnect) command.
RR is not expected at this point.
The station requesting a connection sends SABM until one of the following happens:
- Receive UA frame which means the connection has been accepted.
- Receive DM frame which means the connection has been refused.
- Retry count has been exceeded.
The relevant state diagrams can be found on pages? 86 - 88? here:??
The other station is refusing the connection:
[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
|
Re: Pat Winlink 2M Packet 1200 baud Setup
Today I successfully connected to my local 1200 baud, packet Remote
Message Server about 10 times and was able to both send and receive
email messages.
What allowed me to do this was
to swap out the Baofeng UV-5R for a 21 year old Kenwood TNC.? I used the
exact same antenna, in the exact same spot and left the software
configuration for the Pi, Pat Winlink, and Direwolf the same.
I
know some folks have been successful with the UV-5R's on packet, but
the 2 Baofeng's that I own (purchased from Amazon about 2 years ago) did
not seem to be up to the task.
I want to send
out a HUGE THANKS to everyone that responded with all your helpful
suggestions.? As I am just returning to the Ham Radio hobby after a long
absence, it is totally inspiring to find a vibrant community willing to
help out a newbie.
Thanks again,
Mike KC3EHR
On Thu, Mar 25, 2021 at 5:05 PM Ray Wells < aprs@...> wrote: I know you won't want to hear this .....
The problem may be as simple as using the Baofeng radio, those radios
having a very solid reputation for poor performance for packet radio. Rx
recovery time after dropping PTT is unacceptably long and somewhat
unpredictable in this regard regardless of running squelched or
unsquelched. The rx recovery time is a long way from good enough for
data. That problem can only be solved by getting other stations to
increase their TXD to unacceptable times, to the detriment of the entire
network.
If you search the archives you'll find poor Baofeng performance
mentioned over and over again. I have the skills and test equipment but
gave up on trying to use the Baofeng for packet radio, and I'm not the
only one.
The frequently recommended fix is to source a used "brand name" radio
and use that instead.
Ray vk2tv
On 25/3/21 11:52 pm, Michael LaBlanc wrote:
> I have made some progress and now have good audio levels and am
> getting stable call/response between my home radio setup and the RMS.
>
> However, it seems like my station calls for SAMB, then the RMS returns
> with the expected RR (ready to receive), but my station ignores this
> and sends another SAMB anyway.? Then the RMS sends a DM (Disconnect)
> command.
>
> Any ideas why my station is not continuing on with the connection
> steps after the RR command from the RMS?
>
> Thanks in advance for your help.
>
> Mike
> KC2EHR
>
> Direwolf Log 3/25/2021
> ---------------------------------
>
> pi@RaspPi4:~ $ sudo direwolf -p
> Dire Wolf version 1.6
> Includes optional support for: ?hamlib cm108-ptt
>
> Reading config file direwolf.conf
> Audio device for both receive and transmit: plughw:2,0 ?(channel 0)
> Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
> Note: PTT not configured for channel 0. (Ignore this if using VOX.)
> Ready to accept AGW client application 0 on port 8000 ...
> Ready to accept KISS TCP client application 0 on port 8001 ...
> Virtual KISS TNC is available on /dev/pts/2
> Created symlink /tmp/kisstnc -> /dev/pts/2
> [0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> KC2EHR audio level = 0(0/0) ? [NONE] ? _|||_____
> [0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> K2DLL-10 audio level = 55(22/23) ? [NONE] ? |||||____
> [0.2] K2DLL-10>KC2EHR:(RR cmd, n(r)=0, p=1)
> [0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> KC2EHR audio level = 2(6/7) ? [NONE] ? |||||____
> [0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> K2DLL-10 audio level = 55(22/23) ? [NONE] ? |||||____
> [0.2] K2DLL-10>KC2EHR:(DM res, f=0)
> [0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> KC2EHR audio level = 0(0/0) ? [NONE] ? |||||____
> [0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>
> K2DLL-10 audio level = 54(21/23) ? [NONE] ? ||||||___
> [0.2] K2DLL-10>KC2EHR:(DM res, f=0)
> [0L] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>
> KC2EHR audio level = 0(1/1) ? [NONE] ? |||||____
> [0.2] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>
> On Wed, Mar 24, 2021 at 5:06 PM Michael LaBlanc via
> <> <mlablan1=[email protected]
> <mailto:[email protected]>> wrote:
>
>? ? ?I agree about the audio levels - I have figured out how to
>? ? ?stabilize the audio level response from the Remote Message Server,
>? ? ?but I am still unable to connect.? The RMS seems to be immediately
>? ? ?issuing a DM, which I believe is a connection refused message.?
>? ? ?Also, I noticed a message from Direwolf about needing to issue a
>? ? ?"kissparms -c 1 -p radio" command, so I did that.? This got rid of
>? ? ?the Direwolf message on the next restart, but I am still getting
>? ? ?the DM messages from the RMS.? I am working through the 3
>? ? ?documents referenced to better understand how it is supposed to
>? ? ?work.? I continue to try different antennas, located in different
>? ? ?locations.? Progress, but no success yet...
>? ? ?Pat Winlink Log 3/24/2021
>? ? ?-------------------------
>? ? ?pi@RaspPi4:~ $ sudo kissattach /dev/pts/8 wl2k
>? ? ?AX.25 port wl2k bound to device ax0
>? ? ?pi@RaspPi4:~ $ kissparms -c 1 -p wl2k
>? ? ?kissparms: socket: Operation not permitted
>? ? ?pi@RaspPi4:~ $ sudo kissparms -c 1 -p wl2k
>? ? ?pi@RaspPi4:~ $ pat http
>? ? ?2021/03/24 16:28:41 Starting HTTP service (0.0.0.0:5000)...
>? ? ?2021/03/24 16:29:14 Connecting to K2DLL-10 (ax25)...
>? ? ?2021/03/24 16:29:59 Unable to establish connection to remote: Dial
>? ? ?timeout
>? ? ?Direwolf Log 3/24/2021
>? ? ?----------------------
>? ? ?pi@RaspPi4:~ $ sudo direwolf -p
>? ? ?Dire Wolf version 1.6
>? ? ?Includes optional support for:? hamlib cm108-ptt
>? ? ?Reading config file direwolf.conf
>? ? ?Audio device for both receive and transmit: plughw:2,0? (channel 0)
>? ? ?Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
>? ? ?Ready to accept AGW client application 0 on port 8000 ...
>? ? ?Ready to accept KISS TCP client application 0 on port 8001 ...
>? ? ?Virtual KISS TNC is available on /dev/pts/7
>? ? ?Created symlink /tmp/kisstnc -> /dev/pts/7
>? ? ?Invalid transmit channel 8 from KISS client app.
>? ? ?Are you using AX.25 for Linux?? It might be trying to use a modified
>? ? ?version of KISS which uses the port (channel) field differently
>? ? ?than the
>? ? ?original KISS protocol specification.? The solution might be to use
>? ? ?a command like "kissparms -c 1 -p radio" to set CRC none mode.
>? ? ?Another way of doing this is pre-loading the "kiss" kernel module
>? ? ?with CRC disabled:
>? ? ?sudo /sbin/modprobe -q mkiss crc_force=1
>? ? ?<<< Data frame from KISS client application, port 8, total length = 18
>? ? ?? 000:? 80 96 64 88 98 98 40 f4 96 86 64 8a 90 a4 61 3f?
>? ? [email protected]?
>? ? ?? 010:? c9 d9 ? ? ..
>? ? ?Invalid transmit channel 2 from KISS client app.
>? ? ?Are you using AX.25 for Linux?? It might be trying to use a modified
>? ? ?version of KISS which uses the port (channel) field differently
>? ? ?than the
>? ? ?original KISS protocol specification.? The solution might be to use
>? ? ?a command like "kissparms -c 1 -p radio" to set CRC none mode.
>? ? ?Another way of doing this is pre-loading the "kiss" kernel module
>? ? ?with CRC disabled:
>? ? ?sudo /sbin/modprobe -q mkiss crc_force=1
>? ? ?<<< Data frame from KISS client application, port 2, total length = 18
>? ? ?? 000:? 20 96 64 88 98 98 40 f4 96 86 64 8a 90 a4 61 3f?
>? ? [email protected]?
>? ? ?? 010:? 24 20 ? ? $
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 50(20/21)? ?[NONE]? ?|||||____
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 50(20/21)? ?[NONE]? ?||||||___
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 10(10/10)? ?[NONE]? ?||||_____
>? ? ?[0.1] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 50(21/21)? ?[NONE]? ?|||||____
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?KC2EHR audio level = 0(0/0)? ?[NONE]? ?|||||____
>? ? ?[0.2] KC2EHR>K2DLL-10:(SABM cmd, p=1)
>? ? ?K2DLL-10 audio level = 49(20/21)? ?[NONE]? ?|||||____
>? ? ?[0.2] K2DLL-10>KC2EHR:(DM res, f=0)
>? ? ?[0L] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>? ? ?KC2EHR audio level = 0(3/3)? ?[NONE]? ?|||||____
>? ? ?[0.2] KC2EHR>K2DLL-10:(DISC cmd, p=1)
>
>
|
Re: PAT not able to digipeat properly using direwolf
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
On 03/26/2021 08:48 AM, WB2OSZ wrote:
toggle quoted message
Show quoted text
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.
|
Re: PAT not able to digipeat properly using direwolf
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.?
|
Re: PAT not able to digipeat properly using direwolf
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.
|
Re: PAT not able to digipeat properly using direwolf
Why not just use Direwolf's built up n digipeating?
|
Re: PAT not able to digipeat properly using direwolf
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
|
Re: PAT not able to digipeat properly using direwolf
Just curious, does it (P2P) work if you don't use the alias but the actual call-ssid? ? W8LRK-5?
On Friday, March 26, 2021, 7:04:43 AM EDT, W8DSB <w8dsb@...> wrote:
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:
0L 20:27] W8DSB>N8RDF,LRK:(SABM cmd, p=1)
?
Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__|||||__
[0.4 20:27] W8DSB>N8RDF,W8LRK-5*:(SABM cmd, p=1)
I call n8rdf via LRK
direwolf changes LRK to w8lrk-5 but then it never connects
|
Re: PAT not able to digipeat properly using direwolf
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:
0L 20:27] W8DSB>N8RDF,LRK:(SABM cmd, p=1)
?
Digipeater W8LRK-5 audio level = 49(15/9)? ?[NONE]? ?__|||||__
[0.4 20:27] W8DSB>N8RDF,W8LRK-5*:(SABM cmd, p=1)
I call n8rdf via LRK
direwolf changes LRK to w8lrk-5 but then it never connects
|
Basil Gunn
W8DSB
John Hays - K7VE / WRJT-215