From owner-freebsd-questions Fri Jun 18 17:20:22 1999 Delivered-To: freebsd-questions@freebsd.org Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (Postfix) with ESMTP id 58A571516F for ; Fri, 18 Jun 1999 17:19:59 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA81364; Sat, 19 Jun 1999 01:15:51 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA04336; Sat, 19 Jun 1999 01:15:03 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199906190015.BAA04336@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Amedeo Beck Peccoz Cc: Brian Somers , freebsd-questions@FreeBSD.org Subject: Re: ppp processes (bug report?) In-reply-to: Your message of "Fri, 18 Jun 1999 18:14:47 +0200." <376A7077.1B947550@yourbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jun 1999 01:15:03 +0100 From: Brian Somers Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message