KISS implementation bug: not ignoring invalid commands?

[worsthorse]

I setup Direwolf as the TNC for Winlink (RMSExpress), replacing Soundmodem. I used the default configuration of Direwolf, other than changing MYCALL and properly setting the ports for transmit and receive audio. When Winlink tries to connect, it sends a series of KISS commands to Direwolf and all is well until...

Connected to KISS client application ...

KISS protocol set Persistence = 160, port 0
KISS protocol set SlotTime = 30 (*10mS units = 300 mS), port 0
KISS protocol set TXDELAY = 40 (*10mS units = 400 mS), port 0
KISS protocol set FullDuplex = 0, port 0
KISS Invalid command 12

<<< Invalid 12 from KISS client application, port 0, total length = 18
000: 0c 04 dd 96 8c 6e 98 94 90 f4 96 6e ae b0 ae 40 .....n.....n...@
010: 61 3f a?

Winlink is sending a command related to ACK mode operation, which Direwolf does not support. In fact, if Winlink's "Packet TNC Model" setting is set to NORMAL, this error doesn't occur.

But I think this reveals a bug in Direwolf's KISS implementation. The only valid KISS commands are 0 through 6 and FF. Properly implemented KISS TNCs should ignore other command numbers completely, not mark them as invalid, or drop the connection to the client.

[dranch]

I understand that this ACKMODE is Winlink's naming for XKISS. Direwolf doesn't support XKISS today

[worsthorse]

That appears to be the case. Still, if the commands are an extension, shouldn't Direwolf just ignore them rather throwing an exception and dropping the client connection?

[dranch]

It could be an enhancement to see if Direwolf could dynamically determine the actual KISS protocol being used and give, at minimum, better error messages. On the longer term, there might be some benefit to add XKISS support though running XKISS over a a reliable TCP-KISS network socket is somewhat redundant and only adds to the overall network transport's overhead.

[erikarn]

Hi! replying to an old bug here.
ACKMODE is interesting because you get told when a frame gets transmitted out, rather than it just being accepted by the TNC. That allows for timers on the client side to only start once the TNC has sent the frame out rather than triggering many retransmissions because the air was super busy for an extended period of time.

Would you be interested in adding at least ACKMODE support? I can go dig into what the actual framing format is.

Thanks!

-adrian
(KK6VQK)

[erikarn]

after digging into linbpq, it looks like John used 0xc as the command byte for ACKMODE.

• tx[0] = 0x0c (for TNC 0): send following frame with ACK mode
• tx[1], tx[2] = 16 bit ACK value
• tx[3] = start of normal payload

RX is the same: rx[0] = 0x0c (plus the TNC 0), rx[1] and rx[2] are the tx'ed frame ACK value. it looks like the TNC just sends that as a status notice.

[wb2osz]

You understand one of the reasons why trying to layer connected mode AX.25 on top of KISS is a bad idea. Yes, it can be made to work, but with work-arounds, compromises, and reduced performance.

The Link Layer state machine needs to know more about the radio channel to make good choices about when to transmit. It can’t make good choices if it does not know if the transmitter is currently on, how many frames are in the transmit queue, waiting to go out, or if the channel is busy because someone else is transmitting. Why keep piling inadequate 1980’s hacks on top of other inadequate 1980’s hacks, when there is a much better way? Rather than using Dire Wolf as a KISS TNC, use the AGW network interface instead. Dire Wolf can handle the (“connected mode”) Link Layer and do a much better job than something layered on top of KISS. You can find a more in-depth discussion here:

https://github.com/wb2osz/direwolf/raw/dev/doc/Why-is-9600-only-twice-as-fast-as-1200.pdf

Simply switching to a higher data rate will probably result in great disappointment. You might expect it to be 8 times faster but it can turn out to be only twice as fast.
In this document, we look at why a large increase in data bit rate can produce a much smaller increase in throughput. We will explore techniques that can be used to make large improvements and drastically speed up large data transfer.

[erikarn]

Oh yeah, this is exactly what I just found out jnos2/ka9q/n0ary-bbs are all doing with KISS over the last week or so, and it's varying takes on forms of T2 or a lack of T2. Yeah, it's not nice.

I've done this stuff with wifi mac/phy implementations so I know what's involved in making a MAC layer make better decisions. It's just a lot faster these days :-P

As a side note, one of the interesting side effects of having T2 implemented is you give others a chance to sneak in and send frames. When doing BBS transfer bursts I've noticed that the transfer/ACK turnaround can be so quick that no-one else gets a chance to queue any traffic with the default TXTIME settings. So there's some airtime fairness stuff among multiple users to sort out.

I'll go do some more experiments and see if I can shoehorn ACKTIME in without too much trouble. I'm also going to see about adding some carrier state reporting too (like what we do in wifi silicon) so the MAC knows about the state of RF sensing and PHY state. Then at least I can experiment with mixing AX25 session data, digipeating and some AX25 IP / U frame traffic all together to see if I can elicit crappy behaviour.

(And yes, I'll look at the AGW interface too, if only to have some method of A/B testing ideas!)

[chrisdebian]

Looking at the age of this, just wondering whether it's still an issue?

[dranch]

Another strange unexpected undusting of an idle Github issue since 2019. Regardless, direwolf still does not support ACKMODE / XKISS. As a workaround, configure Winlink to use the AGW interface instead as recommended by WB2OSZ (the Direwolf author) back in 2019.