Linux HAM/Amateur Radio development
 help / color / mirror / Atom feed
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
To: Bill V WA7NWP <wa7nwp@gmail.com>
Cc: linux-hams <linux-hams@vger.kernel.org>
Subject: Re: Linux AX25 KISS driver for Kenwood D700
Date: Tue, 29 Dec 2009 14:49:41 +0100	[thread overview]
Message-ID: <20091229134941.GA23742@linux-mips.org> (raw)
In-Reply-To: <5abd436b0912171434g6bfa1c46r52cca684de4f7999@mail.gmail.com>

On Thu, Dec 17, 2009 at 02:34:47PM -0800, Bill V WA7NWP wrote:

> Is this where the maintainers of the Linux KISS code would be found?

Generic way of finding a maintainer for a piece of kernel code:

 o look in the MAINTAINERS file in the root directory of the kernel source
   tree
 o Look for email addresses in the source code in question itself.  That
   would have yielded my name and address.
 o If still unsuccessful, look through the git source tree.
 o If you don't have git, dig it up on git web at http://git.kernel.org;
   in this particular case
   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/net/hamradio/mkiss.c;h=7db0a1c3216c7b8dc86703ac23074b9afbe82867;hb=6b7b284958d47b77d06745b36bc7f36dab769d9b
   which will yield a list of people who last modified the the code or
   approved changes to it - that are the Signed-off-by:, Reviewed-by:,
   Tested-by: etc. headers at the bottom of commit messages.

>  A simple tweak would eliminate the possibility of some ASCI sequences
> kicking the Kenwood D7 or D700 radios out of KISS mode...
> 
> We really need to feed this info back to Kenwood so they correctly fix
> the D710.   I don't hold any hope in firmware updates for the D7/D700
> so it seems tweaking the KISS generator is the best answer.

I agree.

Kenwood has a tradition of shipping substandard TNC implementations, see
for example the TNC in the otherwise nice TH-D7 handheld.

> The 710 “bug” is not a violation of the KISS protocol…it is the result
> of trying to use the same serial port for both a TNC and a Front panel
> control. The problem is when in KISS mode (which sends binary packets
> “encapsulated in the KISS protocol”  it is possible to have the
> character sequence “TC 0<Cr>”  as binary or  character data within the
> KISS encapsulation. This sequence will be interpreted by the serial
> port controller in the Control head of the D710 as “escape to control
> mode” and which will switch the serial interface from TNC mode to
> front panel control mode.  This can have disastrous affects when
> trying to transfer binary files using KISS.

If you can't speak normal KISS to the interface I very well call it a 
violation of the KISS protocol.  And it's a terribly, terribly lame one.
Reminds me of the modems taking "+++" in the data stream for a command 
but those vendors at least had the excuse of Hayes' patents.

> One solution would be to entice Kenwood to modify the firmware in the
> control head to having entered the KISS protocol to ignore all mode
> control commands including “TC 0<Cr>”. This would require using the
> standardized escape KISS sequence {0xC0, 0xFF, 0xC0} prior to any
> control panel commands and then re enabling KISS to continue TNC
> operation…This gets tricky and is very likely to impact existing
> programs that now work.

The solution which Hayes has a patent on was to only accept the +++ escape
to command mode sequence if it is framed by a short delay.  Thankfully
Wikipedia has an article coverting this in details at
http://en.wikipedia.org/wiki/Time_Independent_Escape_Sequence

Note the expiry date of the patent so the approach should be possible for
a modem even in the united patent hell states of america.  Still a workaround
for existing firmware is needed.

> The solution we used and which appears to work well and is solid is to
> escape the “C” character.  So when any data is sent to the TNC in KISS
> mode if there is an ASCII “C” it is replaced by the sequence <0xDB>”C”
> which essentially escapes the “TC 0<Cr>” sequence. The KISS protocol
> (in the D710’s KISS TNC implementation) removes the <0xDB> which is
> the frame escape so no modification of the transmitted data stream is
> actually made. Thanks to Peter Woods for figuring this out.

It would be easy enough to add this to the escaping code in the mkiss.c
driver in the kernel - but I can't test this.

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-12-29 13:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-17 22:34 Linux AX25 KISS driver for Kenwood D700 Bill V WA7NWP
2009-12-18 19:23 ` Curt, WE7U
2009-12-29 13:49 ` Ralf Baechle DL5RB [this message]
2009-12-30 21:59   ` John Ronan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091229134941.GA23742@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-hams@vger.kernel.org \
    --cc=wa7nwp@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox