tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

NetBSD 4.0 - RFC 1323 changes?

I recently upgraded one of my servers to NetBSD 4.0. Since then, I've experienced odd issues with TCP connections from two machines.

First off, worth mentioning is that both of these problem clients have been connected via Sprint PCS EVDO. There may be some issues with Sprint mucking with packets and screwing up RFC1323 window size negotiation, but I haven't found any way to prove it.

What was happening was this: a Vista machine, which had no previous issue communicating with NetBSD 3.1, suddenly began experiencing issues during initial TCP connection handshaking, particularily while using SSH or pvpgn. After capturing network traffic at both ends, I could see that the peers were attempting to negotiate TCP window size. However, shortly after handshaking was complete, a TCP RST message would be sent by the NetBSD machine. Eventually, disabling RFC1323 window scaling on the Vista machine was found to solve the issue, and a successful connection became possible without experiencing a reset. I assumed that Vista may have been too aggressive in scaling the window size.

Recently, I connected another machine using a different Sprint EVDO card, but this time the client was Linux. Again, I had issues establishing a SSH connection to the NetBSD host. The connection either became stuck in FIN_WAIT, or would receive an RST from NetBSD host, just as before with Vista. This time, I found that disabling RFC1323 on the NetBSD machine solved the issue.

It seems that disabling RFC1323 window scaling on either end of the connection solves the problem. However, I do find it more than a coincidence that I never experienced this behavior with NetBSD 3.1, with RFC1323 enabled. In both cases, the machine that initiated the reset of the connection was the NetBSD host. Either NetBSD is causing this problem, or it sees that the clients are trying insane window sizes and bails out.

While I am sure there have been changes to this code, has anyone else had similar issues?

Frankly, I find it very hard to believe that there could be a bug in NetBSD's TCP/IP stack :)

Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more.

Home | Main Index | Thread Index | Old Index