| |
PA2AGA > TCPDIG 18.06.96 07:44l 174 Lines 6719 Bytes #-10979 (0) @ EU
BID : TCP_96_127
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/127
Path: DB0AAB<DB0KCP<OE9XPI<HB9EAS<F6KDL<F6KIM<F6KWP<LX0PAC<ON7RC<ON4AWP<
ON6AR<PI8HWB<PI8VAD<PI8VNW
Sent: 960618/0213Z @:PI8VNW.#ZH2.NLD.EU #:16795 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA11687 ; Tue, 18 Jun 96 01:44:55 UTC
Received: from pa2aga-10 by pa2aga (NET/Mac 2.3.60/7.1) with SMTP
id AA00008897 ; Mon, 17 Jun 96 19:23:45 MET
Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.60/7.1) with SMTP
id AA00005039 ; Mon, 17 Jun 96 19:15:10 MET
Date: Mon, 17 Jun 96 17:26:14 MET
Message-Id: <tcp_96_127>
From: pa2aga
To: tcp_broadcast@pa2aga-10
Subject: TCP-Group Digest 96/127
X-BBS-Msg-Type: B
TCP-Group Digest Mon, 17 Jun 96 Volume 96 : Issue 127
Today's Topics:
Back issues - Thanks!
KA9Q PPP connections
Radiomodems
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sun, 16 Jun 1996 19:17:50 +0000
From: D.N.Muir@massey.ac.nz (Dexter N. Muir)
Subject: Back issues - Thanks!
Thank you, Netizens!
Lou Meiss <lmeiss@themall.net> has given me the missing issue
--------------------------------------------------------------------------
| Dexter N. Muir Manufacturing Pilot Plant Technician |
| D.N.Muir@massey.ac.nz Department of Production Technology |
| Massey University, Palmerston North, New Zealand |
| http://www.massey.ac.nz/~DNMuir/ |
| "Honesty pays --- but not enough." "Modesty pays --- but even less!! " |
--------------------------------------------------------------------------
------------------------------
Date: Mon, 17 Jun 96 01:50:00 -0000
From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
Subject: KA9Q PPP connections
* Forwarded (from: DOS_INTERNET) by Mike Bilow using BilowMail0.2.
* Originally from Gerard van Essen (2:281/527) to All.
* Original dated: Jun 14 '96, 09:54
Hello, All!
Is anyone having problems with setting up PPP connections with KA9Q?
I am using KA9Q v2.16 (DIS) and was having big problems connecting to two
ISP's
running a Livingston portmaster (one of those being our own portmaster :-)
Whatever (combination of) options I chose, in 95% of the cases the carrier was
dropped after some negotiation between both sides. After turning on the
tracing
options and reading the PPP RFC, I traced it to be what seems to be a bug in
KA9Q (all settings 'default' for the negotiation below):
Wed Jun 12 15:08:51 1996 - sl0 PPP Physical layer up
Wed Jun 12 15:08:51 1996 - sl0 PPP/Lcp Listen ; Start
Wed Jun 12 15:08:51 1996 - sl0 PPP/Lcp Listen ; Sending Config Req, id: 0,
Wed Jun 12 15:08:53 1996 - sl0 PPP/Lcp Req Sent; Processing Config Req, id: 1
Wed Jun 12 15:08:53 1996 - sl0 PPP/Lcp Req Sent; Sending Config Ack, id: 1
Wed Jun 12 15:08:54 1996 - sl0 PPP/Lcp Ack Sent; Timeout
Wed Jun 12 15:08:54 1996 - sl0 PPP/Lcp Ack Sent; Sending Config Req, id: 1
Wed Jun 12 15:08:54 1996 - sl0 PPP/Lcp Req Sent; Processing Config Ack, id: 1
Wed Jun 12 15:08:54 1996 - sl0 PPP not ready for IPCP traffic
As you can see, after sending a Config Ack (and thus ending up in the Ack Sent
state), there is a Timeout and a Config Req is sent again (id 1).
However, the system then goes into the 'Req Sent' state! However, the state
transition table in RFC 1548 clearly shows that when a system gets a TO+ event
in the 'Ack Sent' state (state 8), it should do scr/8 (send configuration
request, stay in state 8).
I looked up this problem in the source, and changed it. After that, my
problems
were gone. Am I seeing ghosts, did I reinvent the wheel, or did I solve a
problem?
Comments are welcome!
Groetjes, ........ === Art ===
___ GEcho 1.20/beta+
- Origin: Te waar om mooi te zijn (2:281/527)
------------------------------
Date: Mon, 17 Jun 1996 09:59:12 +1000
From: Terry Dawson <terry@perf.no.itg.telecom.com.au>
Subject: Radiomodems
Ferko Bachleda wrote:
> I have three radiomodems (transceiver+modem) half duplex. They work on
> special frequency and I need to connect them. I had an idea to do it the
same
> way as Packet radio with connect to Linux. The radiomodems have only
> 9 pins COM port (serial interface) and for "turning on" of "carry" is
> used signal RTS. I don't know how to do it or I would like to know if there
> is not something similar already done.
>
> I have compiled Linux kernel for AX.25 protocol and I got some program where
> is ax25attach..... Parhaps there is something more appropriate.
The current Linux device drivers most commonly used by the AX.25 kernel code
all expect there to be some other hardware installed, whether that be an
SCC card or a KISS TNC.
I can't think of anything that exists that does precisely what you want. It
doesn't sound like too difficult an exercise to cobble something together
though.
You don't say much about the radiomodems themselves, (whether they are
expecting
an async data feed, or will accept something like an NRZI feed) but it is
possible that they might work when attached to an SCC card. The Linux drivers
for
the SCC cards already commands the SCC to raise RTS appropriately.
You could also take a look at the Baycom Kernel Module in the 2.0.0 kernel for
ideas, perhaps it could function as a skeleton you could use.
(/usr/src/linux/drivers/char/baycom.c)
If the radio modems will accept async data only, then you might want to look
at writing a small user process that open a PTY and a serial device that you
could route KISS frames to and would do the management of RTS before shuffling
the encapsulated datagram to the radio. No idea what you might need to do with
respect to error detection/correction other than rely on TCP and IP's own
methods or the radiomodems if it provides its own.
You might also ask on the linux-hams mailing list as a number of the Linux
kernel AX.25 developers listen there (probably here too :)
regards
Terry
------------------------------
End of TCP-Group Digest V96 #127
******************************
You can send your message for this bulletin
to: tcp-group@pa2aga on .AMPR.ORG-net
or: tcpaga@pi8vnw.#zh2.nld.eu on BBS-net
------
NOT TO: pa2aga@pa2aga or pa2aga@pi8vnw.#zh2.nld.eu PLEASE!!
It will get posted automatically within a few days
Read previous mail | Read next mail
| |
