Kantronics KPC3+ KISS considered harmful

I was reading on the aprs.fi blog and came across some interesting things.

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html

If you happen to have a Kantronics KPC-3+ TNC, please do not use it for your APRS igate. It appears to have a software bug which causes delays of over 10 minutes when receiving packets from the radio and then forwarding them to the computer, which then forwards them to the Internet (or possibly retransmits the old packets back to the radio channel, if digipeating).

This is a very bad thing to do, as the greatly delayed packets cause network overload and make moving vehicles jump back and forth between their current positions and the past positions. Looks very funny when aprs.fi tries to draw a track line between the received positions.

For years there have been anecdotal stories and suggestions about a possible problem. Yesterday Alan (radionerd1) has uploaded three videos to Youtube demonstrating the problem. This serves as a nice technical proof that the problem is real, and demonstrably a problem of the KPC-3+. There have been hints that the bug could be in UI-View32 (when using it with the KPC-3+), but Alan demonstrated the problem without involving UI-View.

Alan ran APRSIS32 on a computer, and connected it to two APRS receivers. One used a KPC-3+ and one used AGW packet engine (sound card packet decoder). At first, the two ports received the same packets at the same time. After about a week the KPC-3+ started to misbehave – the received packets were given to the computer only after they had been held as hostage for over 10 minutes. Some people have reported that it can go in this delaying mode within hours or days – it might be due to bad luck, or due to the amount of traffic received. The KPC-3+ did put out a KISS packet to the computer every time a packet was heard from the radio, but it was an old one. When the TNC was reset, it started performing well again.

My guess, as a programmer, would be that the KPC-3+ looses count of the packet it should be transmitting on the serial port. It receives a packet on the radio port, puts it in the received packets buffer, and then prints the wrong packet on the serial port. It might be the oldest packet in the buffer, or thereabouts. The amount of perceived delay would depend on the amount of traffic received in your area.

So, I repeat: If you have a KPC-3+ on your igate in KISS mode, please switch it to something else as soon as possible (KPC-3, OpenTracker, TinyTrak, TNC2 clones, whatever). If you wish to continue using it later, please contact Kantronics at service@kantronics.com and ask them to fix the software bug.

It has been said that the problem only exists in KISS mode. So if you’re using the KPC-3+ as a stand-alone digipeater, it should be fine (in this respect). If you’re using it as a digipeater in KISS mode, with the digipeating happening on the computer (digipeating enabled in UI-View32 or APRSIS32), the effects are seriously bad, as you’re transmitting old packets on the radio channel.

Solution

I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.

New Soundmodem version is available UZ7HO

New Soundmodem version is available: http://uz7.ho.ua/packetradio.htm

SoundModem v1.00b changes:
– Added “DW QPSK 2400bd” and “DW 8PSK 4800bd” Direwolf compatible modes.
The carrier frequency must be “1800Hz” (for a full compatibility with Direwolf).

http://uz7.ho.ua/modem_beta/CHANGELOG.txt

http://uz7.ho.ua/modem_beta/user_guide_v045b_EN.pdf

Get the version V1.00b http://uz7.ho.ua/modem_beta/soundmodem100.zip

Direwolf to LinBPQ configuration and parms

John WQ6N has found a solution for direwolf and Linbpq that works very well for HF.

Direwolf.conf

bpq32.cfg

 

Direwolf and Jnos (review)

In the previous post about Direwolf and jnos i use Direwolf-1.3 and does not know about the SERIALKISS port.
John WQ6N point it out to me… Tnx John WQ6N. Nice one.
Read the previous post.
So maybe I wrote that script for nothing. This is working pretty simple 🙂

In Direwolf 1.5-beta is it possible to use SERIALKISS to connect com to com.
I have try to use a PTY pair created with socat.

I use conspy to look at the output of Direwolf. apt-get install conspy
Use it just like this “conspy 3” The number 3 stands for the tty were Direwolf is running on /dev/tty3.
Hit the escape button a couple of times to exit.

Here is the output of Direwolf

Ok that is working quit well.
I start Direwolf with the option “-d kn” So you can look at the kiss communication between Direwolf and Jnos.

Some text out of the User-Guide.pdf.
“Up to 3 concurrent TCP KISS client applications are allowed at the same time.
You can raise this limit by increasing the value of MAX_NET_CLIENTS, in source file kissnet.c and recompiling.”

Whoooo thats nice up to 3 (and more) applications can connect to Direwolf on the KISSPORT.
And there is also the AGW and the SERIALKISS port. Men where do I start.

John WQ6N

John WQ6N has found something that is useful. He use a Legacy BSD pseudo pair.
There are no Legacy BSD pseudo pairs in Linux any more. But it is possible to create some.

After editing the grub file run the command “update-grub” and reboot.

So now it`s time to set Direwolf and Jnos to use the pty Legacy devices.

Direwolf and Jnos

The scipt…. Small but work quit well

This is what i found in the change.log of Jnos

This is some monitor output of Direwolf.

Dire Wolf version 1.3

Reading config file /direwolf/direwolf.conf
Audio device for both receive and transmit: plughw:0,0 (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate.
Ready to accept AGW client application 0 on port 8000 …
Use -p command line option to enable KISS pseudo terminal.
Ready to accept KISS client application on port 8001 …

Connected to KISS client application …

[0L] PD2LT-2>NODES:<0xfe>
[0L] PD2LT-9>NODES:<0xff>LAPNOS
[0L] PD2LT-9>NODES:<0xfe>LAPNOS

PD2LT-2 audio level = 14(3/3) [NONE] |||||||__
[0.3] PD2LT-2>NODES:<0xfe>

PD2LT-9 audio level = 14(3/3) [NONE] ||||||||_
[0.3] PD2LT-9>NODES:<0xff>LAPNOS

New DoS

If you have not already seen it, experiences it, or read about it, working to head off another reflection DOS vector. This time it is memcached on port 11211 UDP & TCP. There are active exploits using these ports. Reflection attacks and the memcached is not new. We know how reflection attacks work (send a spoofed packet to a device and have it reflected back (yes please deploy source address validation and BCP 38).

Operators are asked to review their networks and consider updating their Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP port 11211 for all ingress and egress traffic. If you do not know about iACLs or Explorable port filters, you can use this white paper details and examples from peers on Exploitable Port Filters:

http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/

Enterprises are also asked to update their iACLs, Exploitable Port Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress and egress traffic.

Deploying these filters will help protect your network, your organization, your customers, and the Internet.

This should help protect you if you add this to your firewall.