Date: Tue, 28 Jan 1997 14:30:55 -0800 From: Jim Shankland <jas@flyingfox.COM> To: brian@burton-computer.com, terry@lambert.org Cc: freebsd-isp@freebsd.org, freebsd-questions@freebsd.org, robert@nanguo.chalmers.com.au, shovey@buffnet.net Subject: Re: progress report on connection problems Message-ID: <199701282230.OAA16081@saguaro.flyingfox.com>
next in thread | raw e-mail | index | archive | help
Jeez, I'm not sure why I'm getting involved in this, but Terry's
exegesis of Brian's packet traces is incorrect. What's really
happening is that one packet from Caldera (the one containing bytes
2485:3945) is consistently getting dropped somewhere between Brian's
ISP and Brian. I'd look closely at the link between Brian and his
ISP (Ascend Pipe50 <--> Livingston Portmaster, over 2 ISDN B-channels).
Possible causes include:
* flakey hardware;
* buggy MLPPP on either the Ascend or Livingston ends;
* buggy V-J compression on either the Ascend or Livingston ends;
* (your good idea goes here).
My bet would be that the Ascend is dropping the packet because it
thinks (correctly or not) that it has a bad PPP-CRC.
For masochists, here is my annotation of Terry's packet exegesis; my
comments are marked with -->, and Terry's with XXX, where I think he
went astray:
> 15:25:16.874058 caldera.com.ftp-data >
> bcc01.burton-computer.com.40001: S 4117168473:4117168473(0) win 512 <mss
> 1460> [tos 0x8]
> 15:25:16.874257 bcc01.burton-computer.com.40001 >
> caldera.com.ftp-data: S 3890833409:3890833409(0) ack 4117168474 win
> 17520 <mss 1460> (DF)
> 15:25:17.025729 caldera.com.ftp-data >
> bcc01.burton-computer.com.40001: . ack 1 win 31744 [tos 0x8]
*****
Caldera acks us...
> 15:25:19.873299 caldera.com.ftp-data >
> bcc01.burton-computer.com.40001: P 1:1025(1024) ack 1 win 31744 (DF)
> [tos 0x8]
Caldera sends us data...
> 15:25:19.921828 bcc01.burton-computer.com.40001 >
> caldera.com.ftp-data: . ack 1025 win 17520 (DF) [tos 0x8]
We ack Caldera (successfully for 1..1024, next send from offset 1025)...
> 15:25:19.969787 caldera.com.ftp-data >
> bcc01.burton-computer.com.40001: P 1025:2485(1460) ack 1 win 31744 (DF)
> [tos 0x8]
Caldera sends us more data...
> 15:25:20.121842 bcc01.burton-computer.com.40001 >
> caldera.com.ftp-data: . ack 2485 win 17520 (DF) [tos 0x8]
We ack Caldera (successfully for 1024..2484, next send from offset 2485)...
> 15:25:20.313058 caldera.com.ftp-data >
> bcc01.burton-computer.com.40001: P 3945:4450(505) ack 1 win 31744 (DF)
> [tos 0x8]
XXX Caldera skips 2485..3944 (THEY ARE BROKEN!)...
--> No, the packet just got dropped in transit.
> 15:25:20.313167 bcc01.burton-computer.com.40001 >
> caldera.com.ftp-data: . ack 2485 win 17520 (DF) [tos 0x8]
We ack Caldera (successfully for 1024..2484, next send from offset 2485)
to get it to back up to that offset and resend...
> 15:25:20.497450 caldera.com.ftp-data >
> bcc01.burton-computer.com.40001: F 4450:4450(0) ack 1 win 31744 [tos
> 0x8]
XXX Caldera loses its mind and sends us totally bogus crap...
--> No, another packet just got lost, Caldera has not yet received
our out-of-sequence ACK telling them to start retransmitting at 2485.
> 15:25:20.497542 bcc01.burton-computer.com.40001 >
> caldera.com.ftp-data: . ack 2485 win 17520 (DF) [tos 0x8]
We ack Caldera (successfully for 1024..2484, next send from offset 2485)
to get it to back up to that offset and resend...
XXX <where is Caldera???>
--> Caldera is repeatedly trying to send us the 2485:3944 segment,
--> and it's repeatedly getting dropped en route.
> 15:26:33.252421 bcc01.burton-computer.com.40001 >
> caldera.com.ftp-data: F 1:1(0) ack 2485 win 17520 (DF) [tos 0x8]
XXX We ack Caldera (successfully for 1024..2484, next send from offset 2485)
XXX to get it to back up to that offset and resend...
--> Yes, but we're also sending a FIN telling them we're done sending.
> 15:26:33.443142 caldera.com.ftp-data >
> bcc01.burton-computer.com.40001: . ack 2 win 31744 [tos 0x8]
XXX Caldera ack 2's us back for no good reason...
--> No, they're just ACKing our FIN.
***
***
***
*** It is apparrent that someone in the link can not handle
*** piggyback ack data.
***
***
***
> Here is an excerpt from my ISP's side of the failed ftp.
>
> 20:27:16.862191 caldera.com.20 > bcc01.burton-computer.com.40001: S
> 4117168473:4117168473(0) win 512 <mss 1460> [tos 0x8]
Negotiate...
> 20:27:16.889774 bcc01.burton-computer.com.40001 > caldera.com.20: S
> 3890833409:3890833409(0) ack 4117168474 win 17520 <mss 1460> (DF)
Negotiate back at them...
> 20:27:17.014076 caldera.com.20 > bcc01.burton-computer.com.40001: .
> ack 1 win 31744 [tos 0x8]
They ack ISP...
> 20:27:19.793237 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 1:1025(1024) ack 1 win 31744 (DF) [tos 0x8]
They send ISP 1..1024
> 20:27:19.825641 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 1025:2485(1460) ack 1 win 31744 (DF) [tos 0x8]
They send ISP 1025..2484
> 20:27:19.937915 bcc01.burton-computer.com.40001 > caldera.com.20: .
> ack 1025 win 17520 (DF) [tos 0x8]
ISP acks for 1..1024, next send from offset 1025...
<MORE MISSING DUMP DATA?>
> 20:27:20.140595 bcc01.burton-computer.com.40001 > caldera.com.20: .
> ack 2485 win 17520 (DF) [tos 0x8]
ISP acks for 1024..2484, next send from offset 2485...
> 20:27:20.170151 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 2485:3945(1460) ack 1 win 31744 [tos 0x8]
Caldera sends 2485..3944 (why didn't the ISP send it to us?!?)
> 20:27:20.173851 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 3945:4450(505) ack 1 win 31744 (DF) [tos 0x8]
XXX Caldera sends 3945..4449 (but they send it without an ack...)
--> Sure. They don't need to wait for an ACK; we advertised a window
--> of 17520 bytes.
> 20:27:20.329662 bcc01.burton-computer.com.40001 > caldera.com.20: .
> ack 2485 win 17520 (DF) [tos 0x8]
ISP acks for 1024..2484, next send from offset 2485...
> 20:27:20.477486 caldera.com.20 > bcc01.burton-computer.com.40001: F
> 4450:4450(0) ack 1 win 31744 [tos 0x8]
XXX Caldera loses its mind and sends us totally bogus crap...
--> No, they're just sending the next segment in sequence; they have
--> not yet received and processed our out-of-sequence ACK, telling
--> them to resend starting at 2485.
> 20:27:20.516980 bcc01.burton-computer.com.40001 > caldera.com.20: .
> ack 2485 win 17520 (DF) [tos 0x8]
ISP acks for 1024..2484, next send from offset 2485...
> 20:27:21.956979 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 2485:3945(1460) ack 1 win 31744 [tos 0x8]
Caldera resends 2485..3945
> 20:27:25.612874 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 2485:3945(1460) ack 1 win 31744 [tos 0x8]
XXX Caldera sends 3945..4449 (but they send it without an ack...)
--> Sure. Why should they have to wait for an ACK?
> 20:27:32.965838 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 2485:3945(1460) ack 1 win 31744 [tos 0x8]
XXX Caldera resends 2485..3945 without being asked to do so...
No, they're responding to our second out-of-sequence ACK, and again
backing up to 2485.
> 20:27:47.853712 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 2485:3945(1460) ack 1 win 31744 [tos 0x8]
XXX Caldera resends 2485..3945 without being asked to do so...
--> Retransmit timeout.
> 20:28:16.896253 caldera.com.20 > bcc01.burton-computer.com.40001: P
> 2485:3945(1460) ack 1 win 31744 [tos 0x8]
XXX Caldera resends 2485..3945 without being asked to do so...
--> Retransmit timeout.
> 20:28:33.290671 bcc01.burton-computer.com.40001 > caldera.com.20: F
> 1:1(0) ack 2485 win 17520 (DF) [tos 0x8]
XXX ISP loses its mind and sends bogus crap...
No, our end sent a FIN; nothing wrong with that.
> 20:28:33.451976 caldera.com.20 > bcc01.burton-computer.com.40001: .
> ack 2 win 31744 [tos 0x8]
XXX Caldera ack 2's ISP back for no good reason...
--> No, they're ACKing our FIN.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701282230.OAA16081>