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
next prev 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