Don Lewis wrote: > > --------------------------------------------------------------------------- > > Packet 90 > > TIME: 12:06:51.278337 (0.279509) > > LINK: 00:90:27:AB:08:88 -> 00:90:27:35:05:1B type=IP > > IP: www -> kost hlen=20 TOS=00 dgramlen=41 id=64CE > > MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=A7ED > > TCP: port http -> 2134 seq=1179931920 ack=1524903532 > > hlen=20 (data=1) UAPRSF=010000 wnd=58400 cksum=FC43 urg=0 > > DATA: t > > --------------------------------------------------------------------------- > > Packet 91 > > TIME: 12:06:51.278615 (0.000278) > > LINK: 00:90:27:35:05:1B -> 00:90:27:AB:08:88 type=IP > > IP: kost -> www hlen=20 TOS=00 dgramlen=40 id=10E6 > > MF/DF=0/1 frag=0 TTL=128 proto=TCP cksum=BBD6 > > TCP: port 2134 -> http seq=1524903532 ack=1179931920 > > hlen=20 (data=0) UAPRSF=010000 wnd=0 cksum=5466 urg=0 > > DATA: <No data> > > > > As you see, last pair of packets repeats many times > > and transfer is stalled here. What's wrong and who is guilty? > > It looks like the client is the guilty party. The server is sending > 1-byte long window probes, and the client is responding with an ACK > packet that is advertising a receive window of 0. > > I'd be suspicious of the application software on the client. Can you > try a different web browser, or even fetch the same URL using something > like telnet?
I've tried using Netscape Communicator 4.8 and MSIE 6.0 The picture is the same. Eugene Grosbein _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
