tcp low window

[hcgoh]

we connected a DLink Print Server to the HP RP7400 on UX 11. When Print Server sent tcp window =0 (Record #163, the HP server still keep on sending a 1 byte packet to the Print server, and eventually the Print Server recover it's buffer (window=2092), and this time the HP Server had a window=0, and the tcp session hangup, thus spool queue incomplete... Please advice what could be the problem on the HP server ?

Attached please see a Agilent SW Ethernet LAN data captured.

Please advice.

Thank you.

[Steven E. Protter]

How did you hook this device up directly to the server? Through a crossover cable? Or are the devices on a switch/hub together?

If the device itself includes a hub or switch, make sure your speed and duplex setting match the device.

If the device is 100 BaseT Full Duplex then check as follows:

lanadmin -x 0

replace zero with the actual lan number, not the word lan

It should show 100 BaseT full duplex. If there is a mismatch, you'll need to correct it.

This can be done if the device is configurable, it should be set to 100 BaseT full duplex manual, not autonegotiate. If only the HP box is configurable this can be hard coded into the file /etc/rc.config.d/hpbtlanconf

SEP

[rick jones]

A duplex mismatch would be unlikely to manifest itself as a zero window hangup.

I tried to wade through the packet trace but the N line format was just too nasty - any chance you might get that into a oneline format like tcpdump ( you could run tcpdump on the HP-UX system - either compile from sources from www.tcpdump.org, or grab it from the porting centre).

The first part - zero window, the single-byte packets, sounds correct - that would be the UX system window probing. As for why no window probes the second time - i fyou can get the oneline trace we can take a look.

You can also see about looking to make sure you are up-to-date on patches to the HP-UX system (in particular ARPA transport patches) and then also on the DLink print server.

There may also be interesting data in the putout pf ndd /dev/tcp tcp_status - you would need to find the connection to the print server in that output and see what the RTO (retransmission timeout) and such are.

[hcgoh]

I have the captured data in this format, hope you can advice which device contributed the problem.

Thanks.

[rick jones]

sadly, the URL that comes-up when I click on the paperclip shows the same N line per packet format again - although it has _added_ a oneliner. Not quite what we were looking for... :) I'm searching for a way to filter it, but haven't had much luck thusfar.

[Ron Kinner]

Both records were truncated before reaching the area of interest. Can you break out just the portion you are interested in and post it?

Ron

[hcgoh]

This is a zip file. Hope you can download and open it.

Thanks.

[hcgoh]

In record# 164, where the print server had set the window=0, I wonder why the HP UX still kept sending the 1 byte data to the Print server ??? But in Record# 196, where the Print server set window=1388 (after about 105 seconds), the HP UX didn't response, and then the Print server FIN it after 55 seconds.

Does this looks like both the print server and the HP UX are not completely hand-shaking coorrectly ?

[Ron Kinner]

Sending the 1 byte is the only way it has to keep the connection open. If it sends 0 bytes then it won't know if the ack it gets is the correct one or a duplicate of an old one. Judging from its previous packets the HP was about to resend the 1 byte just when the printer decided to give up on the connection.

If you look at the times between retransmissions you will see that the HPUX is roughly doubling the time between packet resends. 6, 13, 27, 52 so the next one was scheduled at 104 seconds. It does this so as not to waste a lot of bandwidth when it is obvious that the other end has a problem that requires time to solve.

I still think the printer side has a problem.

Ron