[16006] in Athena Bugs
Netscape tcp weirdness?
daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Jun 29 09:27:51 1998
Date: Mon, 29 Jun 1998 09:27:47 -0400
To: bugs@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>
Having run /mit/infoagents/arch/sun4x_55/bin/Mozilla by hand from an
8.2 Sun machine [Hmm, also happens from an 8.1 Sun], and accessing an
https: URL (which unfortunately is not publically accessible, and I
haven't been able to duplicate the problem elsewhere), Netscape
downloads the beginning of the document, and then produces the error:
"There has been a communications error: (Network Error: -8192)
Try connecting again or contact your system administrator."
While the rendered netscape window only has about ~2k or so of the document,
View Source shows substantially more. Presumably a minor formatting
suboptimality.
Anyhow, running tcpdump, we see behavior as:
...
09:11:08.066501 GNI-WEB.443 > x15-cruise-basselope.32850:
. 19418:20878(1460) ack 439 win 64240 (DF)
09:11:08.068021 GNI-WEB.443 > x15-cruise-basselope.32850:
. 20878:22338(1460) ack 439 win 64240 (DF)
09:11:08.071417 x15-cruise-basselope.32850 > GNI-WEB.443:
. ack 16498 win 8760 (DF)
09:11:08.072320 x15-cruise-basselope.32850 > GNI-WEB.443:
. ack 19418 win 8760 (DF)
09:11:08.072342 x15-cruise-basselope.32850 > GNI-WEB.443:
. ack 22338 win 8760 (DF)
09:11:08.072360 x15-cruise-basselope.32850 > GNI-WEB.443:
F 439:439(0) ack 22338 win 8760 (DF)
09:11:08.088179 GNI-WEB.443 > x15-cruise-basselope.32850:
. 22338:23798(1460) ack 439 win 64240 (DF)
09:11:08.088254 x15-cruise-basselope.32850 > GNI-WEB.443:
R 4284390859:4284390859(0) win 8760 (DF)
Where the server is clearly sending more data to the client. The
client is delaying acks, and then finally sends it's 3 delayed acks at
:08.072342, acking all received data. It then (for some reason)
decides to send a FIN. I can't imagine why, since it hasn't received
one from the far end.
Then the server sends the next chunk of data, and of course the client
has closed the connection so it RSTs it, and we lose in the expected
fashion from there on out.
lynx-cert doesn't have this problem.
Given the supportedness of netscape 3.0 it's probably not worth
going anywhere with this. I only took the time to write it up since I
mistakenly assumed it was a Solaris 2.6 interaction, but since it
also happens on an 8.1 machine, it's probably not worth looking into,
at least unless someone else sees this problem.
I tried to replicate it on another https server (www.c2.org) with
no success.
--jhawk
