Category: Pi1lap

Kantronics KPC3+ KISS considered harmful

Posted onAuthorPD9Q1 Comment

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

Posted onAuthorPD9QLeave a comment

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 and Jnos (review)

Posted onAuthorPD9Q2 Comments

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.

# Create pty pair
socat -d -d -ly PTY,link=/dev/ttyq1 PTY,link=/dev/ptyq1 &
sleep 2
# Start Direwolf
direwolf -d kn -c /direwolf/direwolf.conf &> /var/log/direwolf.log >/dev/tty3 &
sleep 2

Direwolf.conf
SERIALKISS  /dev/ttyq1 19200

# Jnos autoexec.nos
attach asy ptyq1 - ax25 ax0 4096 256 19200

Fireup Jnos
./jnos -C -g2 -u3 -f nos.cfg -i

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

>>> Data frame to KISS client application, port 0, total length = 82
  000:  c0 00 92 88 40 40 40 40 e0 9c 98 70 b4 b4 8a 60  ....@@@@...p...`
  010:  ae 92 88 8a 62 40 63 03 f0 43 6f 6e 6e 65 63 74  ....b@c..Connect
  020:  20 4e 4c 36 5a 5a 45 20 66 6f 72 20 74 68 65 20   PD2LT-6 for the
  030:  4a 4e 4f 53 20 43 6f 6e 76 65 72 73 20 28 6c 69  JNOS Convers (li
  040:  6e 6b 65 64 20 77 69 74 68 20 6f 74 68 65 72 73  nked with others
  050:  29 c0

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.

/etc/default/grub:
Change line from:
GRUB_CMDLINE_LINUX=""
to:
GRUB_CMDLINE_LINUX="pty.legacy_count=10"
(Where 10 is the number of pty legacy devices you require.)
This created 10 ptypX/ttypX terminal pairs.

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.

The Direwolf SERIALKISS 
SERIALKISS /dev/ptyp0 19200

The associated JNOS2 attach line:
attach asy ttyp0 - ax25 hfgw 4096 256 19200

New DoS

Posted onAuthorPD9QLeave a comment

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.

# new port 11211 DoS
/sbin/iptables -t filter -I INPUT -s 0.0.0.0/0 -p tcp --dport 11211 -j DROP
/sbin/iptables -t filter -I OUTPUT -s 0.0.0.0/0 -p tcp --dport 11211 -j DROP
/sbin/iptables -t filter -I FORWARD -s 0.0.0.0/0 -p tcp --dport 11211 -j DROP
/sbin/iptables -t filter -I INPUT -s 0.0.0.0/0 -p udp --dport 11211 -j DROP
/sbin/iptables -t filter -I OUTPUT -s 0.0.0.0/0 -p udp --dport 11211 -j DROP
/sbin/iptables -t filter -I FORWARD -s 0.0.0.0/0 -p udp --dport 11211 -j DROP

 

9600 BAUD Parameters

Posted onAuthorPD9QLeave a comment

TXDelay…….between 8 and 15 – set for best throughput BUT that depending upon your RIG. Several commercial rigs they don’t accepts TXD less than 25-30 because they needs enough time to “LOCK-on” the PLL unit, otherwise the TX signal is unusable. Of course, if you want that values (8-15), we talking for modern Transmitters using PIN-diodes and very fast PLL-units for RX-TX swithces and NOT for RIGs with Relays in the output and slllooowwww PLLs… Relays and slow-PLLs have extremely large values between RX-TX, which that means Hi-Value TXD settings!

RESPtime …..100 mS seems to have better results than 0

Frack……….. 8 seconds on a busy channel; but never less than 5 sec

PERSIST…….128/users; if it’s a pretty clean channel, 64 is nice; if it’s busy, guesstimate the average number of users and divide 128 by this number, i.e. 4 users = 128/4 = 32

SLOTTIME… 20

MAXFrame… If the channel is great, 7; average, 3; rough, 1

RETry……….15

Check………. 300 seconds