Date: Sat, 19 Jun 1999 01:15:03 +0100 From: Brian Somers <brian@Awfulhak.org> To: Amedeo Beck Peccoz <gea@yourbox.net> Cc: Brian Somers <brian@Awfulhak.org>, freebsd-questions@FreeBSD.org Subject: Re: ppp processes (bug report?) Message-ID: <199906190015.BAA04336@keep.lan.Awfulhak.org> In-Reply-To: Your message of "Fri, 18 Jun 1999 18:14:47 %2B0200." <376A7077.1B947550@yourbox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I've re-cc'd freebsd-questions 'cos I think this is probably a
valuable diagnosis :-) Hope you don't mind.
> Brian Somers wrote:
>
> > > > Otherwise, I'm beginning to suspect the modem :-/
> > >
> > > Mmmmhhh... that's the real bad news... Can you suggest some more
> > > tests to do? Maybe it's just a modem config problem. I tried
> > > to report the problem to the modem manufacturer but with
> > > scarse informations, so all they said is that it's a software
> > > problem (they don't even know how to spell UNIX...) now how do
> > > I come out of this? Any idea? Can I collect some other infos to
> > > pass to the manufacturer assistance?
> >
> > As you have access to both sides, we should be able to nail this :-)
> > Most people don't, so a lot of the time is spent trying to determine
> > what the other side is doing :-/
> >
> > If you're running a recent version of ppp, try enabling physical
> > logging on both sides (``set log +physical'') - if the version
> > -stable or before, use ``async'' logging instead.
>
> On the server side I run the latest, so I could enable physical
> while on the client side there is an older version (March I belive)
> and I enabled async (now I'm making a new "world")
>
> The log files actually differ in the written and read data. :-(
>
> The test I've done is very simple:
> 1) launched the ppp on the client
> 2) when the link went up I made a single "ping -c 1 server", no
> user level response
> 3) then I did a "ping -c 1 client" from the server, again no user
> level response
> 4) then I "close"d the ppp client connection.
>
> Attached are both the log files, shoud you be willing to have
> a look at them. Note: the time on the two machines should be
> the same with a diff < 1 sec.
>
> The server is named "pitagora" and the client "platone", so you
> can understand which log file refers to one and wich to the other.
[.....]
Here's the clue (from platone.log):
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: 97 04 80 01 97 04 80 c4 00 00 ce 54 7b 01 00 00
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: 8f 61 6a 37 d2 0d 00 00 08 09 0a 0b 0c 0d 0e 0f
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: 10 12 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: 22 23 24 25 26 27 28 29
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: ReadFromModem
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: ReadFromModem
Jun 18 17:11:11 platone ppp.old[334]: tun0: Async: 94 7a 7e
Jun 18 17:11:39 platone ppp.old[334]: tun0: Command: /dev/tty: close
If you look at the server log, you'll see that it's sending standard
ping packets with incrementing numbers in the packets. This packet
is mysteriously missing 0x11 & 0x13 - ^Q and ^S. This means that the
data being transmitted by pitagora is dropping these characters
(after it reports them as being sent). Looking at the data
travelling the other way, the problem isn't there.
The answer ? Try to figure out how to get pitagora to keep doing
hardware flow control (I presume this is the end doing the fax
answering). If it can't, the modem is broken (my USR Sportster does
this ok - and it's a pretty cheap modem). This'll have to be done
with the AT commands before setting the modem to fax/data answer mode
as you have no control after the modem picks up - *but* you may get
better mileage from mgetty (it may actively know how to turn on
hardware flow control after seeing the RING and before doing the
ATA). I'm not really sure though.
The workaround ? Do a ``set accmap 000a0000'' and a ``set ctsrts
off'' in pitagora's ppp.conf. This'll convince ppp to dodge sending
these packets on both sides and will tell pitagora to talk software
flow control to the modem. Note, in this case, the client side is
now smart enough to know not to send the ^Qs and ^Ss because the
server side has the appropriate accmap. Older versions of ppp
didn't, and require the accmap setting locally too.
--
Brian <brian@Awfulhak.org> <brian@FreeBSD.org>
<http://www.Awfulhak.org>; <brian@OpenBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@FreeBSD.org.uk>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906190015.BAA04336>