1

Using a Raspberry Pi 3B, Signalink, HT, direwolf and ax25-tools and ax15-apps. All up to date. Clean start.

Commands:

sudo direwolf -p  
sudo kissattach /tmp/kisstnc wl2k

obtain assignment to ax0, then

beacon -s wl2k "testing"
  • first attempt - direwolf reports: Invalid transmit channel 8 from KISS client app.
  • second attempt - direwolf report: Invalid transmit channel 2 from KISS client app.
  • third attempt - works just fine and the RPi transmits the "testing" perfectly.

I want to address the channel issue and can find nothing in documentation. What is going wrong, what can I do to fix this?

Kevin Reid AG6YO
  • 24,195
  • 7
  • 48
  • 101
ASzy
  • 77
  • 4

3 Answers3

3

This is issue #42 on Direwolf's GitHub page.

https://github.com/wb2osz/direwolf/issues/42

To work around it, put the interface into CRC mode "none" with a command like this:

# kissparms -c 1 -p radio
Mike Playle
  • 327
  • 2
  • 4
  • Thank you Mike. Actually figured this out by examining dmesg dumps. Came up with the exact same command line. Glad I was on the correct track. – ASzy Jan 30 '19 at 00:02
  • @ASzy You can indicate that an answer solved your problem or is satisfactory by clicking the checkmark next to it. Welcome to Amateur Radio Stack Exchange! – Kevin Reid AG6YO Jan 30 '19 at 00:52
1

this is not a direwolf issue. this is an issue with the ax0 N_KISS line dicipline for tty/pty's of the linux kernel. indeed. first packet -after you bring an ax0 interface up- has KISS control byte 80 (data packet channel 8), second has KISS control byte 20 (data packet, channel 2). any packet following that is fine. bug should therefore be fixed in the ax25 protocol stack of the linux kernel (mainly the part that handles kiss and ax0 type interfaces) and not in direwolf. it happens wether you use it for direwolf or not. comes out of the interface itself (either that or something very weird is going on with the pty most people would use to create a fake serial line.

just spent an hour tracing down where these wrong bytes came from as well.

probably does the same thing on a real ttyS0 serial port as it does on the pty. didn't test that. people with a real tnc on a real serial port would never notice 2 packets going missing anyway. at most it'd blink a led. none of em would have 8 or even 3 channels ;P

note that the time at which this problem occurs is the first 2 packets after -creating- and -bringing up- the ax0 device. (and only then). you can close the tcp socket to direwolf (or anything kiss-tcp), restart direwolf as a whole and let it reconnect, etc. as long as that ax0 interface stays there, the problem will not re-occur.

HRH Sven Olaf of CyberBunker
  • 11
  • 2
  • 2
    Hello and welcome to ham.stackexchange.com! Your post would be a little easier to read with conventional capitalization. – rclocher3 Dec 06 '21 at 23:10
0

actually... TFPCX + GP1.63 on dosbox with serial to tcp emulation does exactly the same thing as the linux mkiss (ax0) driver. this may be copied behaviour from that. i'd say it's undesirable to 'test things' with user packets either way. more so blatantly sending them to the wrong channel (suppose someone would actually have a tnc with 3 or 9 physical channels ;)

HRH Sven Olaf of CyberBunker
  • 11
  • 2