dab@BERSERKLY.CRAY.COM (David Borman) (09/11/90)
> >Concerning the window field on a SYN packet, what does a value of 0 mean? > >Most machines (UNIX) that I have watched on the LANalyzer show a reasonable > >value for this field in the SYN packet: 2048, 4096 or something like that: > > > > UNIX A UNIX B > > ======== ====== > > SYN 4096 -> > > <- SYN ACK 4096 > > ACK 4096 -> > > > >I now am trying the talk to a MVS machine which sends me a SYN packet > >with a window size of 0. What does this mean? It certainly confuses my > >UNIX machines as they then send a SYN ACK with the window field having > >a value of 53000 or so: > > > > MVS UNIX > > ===== ============ > > SYN 0 -> > > <- SYN ACK 53215 > > ACK 0 -> > > > >Things seem to go downhill rapidly after this point; what is happening here? > >I would like to know what machine I need to do some fixing on. > > My first reaction is that a SYN with a window size of zero can't be > answered, since there's no window space in which to send the responding > SYN. But you are allowed to send a single byte to probe a zero window; > in this case, the responding SYN would be that byte. However, I can't > think of any good reason to try opening a connection if you can't offer > a reasonably sized window to start with. > > Now, the Unix system's response could be better, but this is definitely > an end case that is dealing with. So I would concentrate on the MVS system. > > Does the MVS system ever send another ACK with a non-zero window? > Actually, the window field in a TCP packet is an offset from the ack field, and the ack field is only valid if the ACK bit is set, and the ACK bit is never set in the initial SYN packet, so the ack field is meaningless, and hence the window field is also meaningless. However, it would seem logical that the window value in the initial SYN packet would indicate the number of data octets that the sender is willing to accept from whatever initial sequence number the receiver chooses to start with. But this is not what RFC-793 says, so you can't depend on it. The real question is after the MVS sends the "ACK 0", does it ever send a packet in which it actually opens the window? And does the UNIX side really have a window of 53215? 4.2BSD had a problem with the window field, but it was the reverse of this. 4.2BSD would belive the window value in the initial SYN, and when connecting to a TAC it was getting garbage in the window field in the initial SYN. This was usually some large number, and the 4.2 would overrun the TACs buffers. The TAC would just throw away the extra data, causing the 4.2 system to do lots of retransmits. The bottom line is that these three initial packets look just fine, the only potential problem is if the 53215 byte window being offered by the UNIX machine is wrong, and it really has a much smaller buffer. Then you could have the MVS system trying to send data that the UNIX system would throw away, causing the MVS to have to go into retransmit mode, or a later packet sent from the UNIX side with the correct window size would cause the MVS to see a shriking window that it might not deal with properly. But in either case, the main problem is on the UNIX side, not the MVS side. (Shrinking windows are a bad idea...). -David Borman, dab@cray.com