On Thu, Oct 07, 1999 at 05:29:00AM +0100, Steve Dodd wrote:
> On Thu, Oct 07, 1999 at 11:22:36AM +1000, Paul Mackerras wrote:
>
> > I would love to see what characters the remote reads from its serial
> > port.
>
> Hah! So would I. Unfortunately the end point of the PPP link is an Ascend NAS
> at my ISP. When Isaid 'remote host' in my dumps above, I was referring to
> a host on a network remote from my ISP which I was trying to reach. I suppose
> it's remotely possible that something inbetween is throwing away packets in
> exactly this peculiar pattern, ...
Could you ask that ISP where you encounter there problems, what
exact hardware (base unit and cards) they run at their Ascend, and
what software revisions ? I could try to reproduce the effect,
and escalate it thru Ascend EMEA software service - if it appears
to be at Ascends, that is.
... oh, also, what kind of modem you have ? And what hardware is
the serial port it is connected at ? And how is the cable ?
> ... but I can't trigger the problem accessing
> through other ISPs (albeit using different hardware).
Different hardware at *your* end ?
> Anyway, I hacked pppdump to output in a format that pcap/tcpdump could
> understand (after learning quickly about all the weird byte-saving compression
> options -- eww), and the packets seem to be reaching the tty alright. If
> *my* serial port/modem was overrunning, something would log a message, wouldn't
> it? Can modems overrun when sending?
Sure, say your ASYNC port speed is 115k, but your modem is mere
V.34/V.90 (33400 bps from your end out). If you don't run the
connection with working hardware flow-control, then it is very
likely that the modem can pick the first packet full of data, but
overflow the rest. (Modems seem to have about 2 kB buffer for
incoming characters, which are then wrapped into V.42bis/V.42
and piped down the modulation link to the remote end in HDLC
frames.)
Receiving server will then see incomplete PPP frame(s) after the
first successfull one, and throw it/them away.
> > At first glance this looks like the second packet is getting
> > corrupted by a serial overrun or something like that. Does the remote run
> > Linux? Could you use the `record' option on pppd at that end to see
> > whether the second packet is just not there, or if it is there but
> > corrupted?
Same thinking as mine..
> Hmm, no, not easily. I can see if connecting to different equipment makes
> a difference -- I think there are some 3com boxes on a different line.
Should not make difference, if the problem in reality is at your
xmit side. If it *does* matter, I am all the more interested
about ISP's server hardware and software versions involved.
> --
/Matti Aarnio <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
