Bug#606338: ax25ipd transmission bug
On Wed, Dec 08, 2010 at 08:59:08AM -0600, John Goerzen wrote:
> First of all, thank you very much for your work on the AX.25
> userland tools. It is much appreciated. I am new both to amateur
> radio and to AX.25 in general and am thus being exposed to them for
> the first time.
>
> I have discovered a bug in ax25ipd. I was setting up ax25ipd last
> night, and it would receive data fine, but wouldn't transmit
> anything out the IP side. After looking in my log files, I observed
> this message every time I tried to send a packet out via ax25ipd:
>
> Dec 7 17:49:56 hephaestus ax25ipd: assemble_kiss: dumped - control
> byte non-zero
Hm.. Thomas, we may want to log the actual value of the control byte here.
John, what is the actual value of the control byte in your case?
> I investigated, and found a check on the control byte in kiss.c. I
> studied the control bytes, and believe that they are used primarily
> to select a port on multi-port TNCs. I don't know why kissnetd or
> kissattach cares about them, but there it is.
>
> Now then, this is trivial to fix with the attached patch. This is a
> minimally-invasive one; a more proper upstream patch would remove
> the
> whole test. I have tested this patch and it works beautifully.
This is broken. From the original K3MC / KA9Q KISS spec:
[...]
To distinguish between command and data frames on the host/TNC link, the first byte of each asynchronous frame between host and TNC is a "type" indicator. This type indicator byte is broken into two 4-bit nibbles so that the low-order nibble indicates the command number (given in the table below) and the high-order nibble indicates the port number for that particular command. In systems with only one HDLC port, it is by definition Port 0. In multi-port TNCs, the upper 4 bits of the type indicator byte can specify one of up to sixteen ports. The following commands are defined in frames to the TNC (the "Command" field is in hexadecimal):
Command Function Comments
0 Data frame The rest of the frame is data to
be sent on the HDLC channel.
1 TXDELAY The next byte is the transmitter
keyup delay in 10 ms units.
The default start-up value is 50
(i.e., 500 ms).
2 P The next byte is the persistence
parameter, p, scaled to the range
0 - 255 with the following
formula:
P = p * 256 - 1
The default value is P = 63
(i.e., p = 0.25).
3 SlotTime The next byte is the slot interval
in 10 ms units.
The default is 10 (i.e., 100ms).
4 TXtail The next byte is the time to hold
up the TX after the FCS has been
sent, in 10 ms units. This command
is obsolete, and is included here
only for compatibility with some
existing implementations.
5 FullDuplex The next byte is 0 for half duplex,
nonzero for full duplex.
The default is 0
(i.e., half duplex).
6 SetHardware Specific for each TNC. In the
TNC-1, this command sets the
modem speed. Other implementations
may use this function for other
hardware-specific functions.
FF Return Exit KISS and return control to a
higher-level program. This is useful
only when KISS is incorporated
into the TNC along with other
applications.
[...]
With your patch every packet, including control packets will be treated as
a data packet.
> The procedure I'm using to set up ax25ipd is documented here:
>
> http://wiki.complete.org/LinuxPacketRadio#ax25ipd
>
> I have other kissnetd / kissattach instances running on my system,
> which may possibly explain why the control byte is nonzero.
>
> Thank you,
>
> -- John Goerzen
> KR0L
> diff -durN ax25-apps-0.0.6/ax25ipd/kiss.c fixed/ax25-apps-0.0.6/ax25ipd/kiss.c
> --- ax25-apps-0.0.6/ax25ipd/kiss.c 2001-10-08 20:03:12.000000000 -0500
> +++ fixed/ax25-apps-0.0.6/ax25ipd/kiss.c 2010-12-07 18:35:19.444623640 -0600
> @@ -72,7 +72,7 @@
> if (c == FEND) {
> if (ifcount > 0) {
> /* Make sure that the control byte is zero */
> - if (*iframe == '\0' || *iframe == 0x10) {
> + if (1) {
I'm just wondering why the test isn't (*iframe & 0xf) == 0 which would
handle the full number of possible 16 possible TNCs.
Thanks,
Ralf
Reply to: