I have seen this phenomena once before where every other packet was missing.
I accidentally put in a second (invalid) static route on a Cisco router for
a network using an already existing functioning route. The Cisco, Trying to
optimize, tried to use both routes by sending packets to both routes in an
alternating fashion. When I tried to ping something, it gave me the
alternating success/failure messages because only the first route was valid.
Of course, the problem only occurred with outgoing packets.
When receiving a file, you are sending a status packet for every few packets
you receive. Depending on how often the receiving system sends these status
packets (which state how many bytes have been received in the stream) the
sending system may not have to stop sending if it receives every other
status packet. When the stream is negotiated, the buffer size for each side
is determined and the sender knows to send a buffer's worth of packets
before requiring a status packet stating that the receiver has received X
bytes so far. Then the sender will send up to X+buffersize bytes. If the
status packet isn't received that states that everything the sender has sent
has been received, the sender will (after a timeout) send again from where
the receiver says they have received. (This is an oversimplified explanation
I know)
When sending a file, you would obviously find the performance would be less
than half the normal speed because you will have to resend every other
packet after a given timeout period.
Anyway, something to look into would be to check the routes to the other
network (or default route) and make sure there is only one. A common mistake
would be to assign a default gateway going through both eth0 and ppp0.
Mike Childers
> 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]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
