Bugzilla – Bug 105853
window_scaling broken when syn packet sent twice
Last modified: 2005-08-19 14:47:12 UTC
for example echo 4 > /proc/sys/net/ipv4/tcp_window_scaling (the bug happens with all window_scaling > 0) then setting up a connection will first send a SYN package, which contains window_scaling factor 2 (shoud this not be 4, might be another bug). In the attached sniff the window size is 5840 byte multiplied by 2^2. The other host is unreachabel, that's why we send another SYN package, this time, our window size is 23360 bytes still multiplied by 2^2 (!). This way all requested window sizes are double factored by the window_scaling value when the first SYN package gets lost.
Created attachment 46698 [details] dump of 3 tries of conntection setup with window_scaling = 4 set
The tcp_window_scaling sysctl is a yes/no affair, so it doesn't matter if you write 1, 4 or 4000 :) I also don't understand the other part of the report. The tcpdump shows three identical packets: win 5840 <mss 1460,sackOK,timestamp 33005845 0,nop,wscale 2> Which looks right to me. The initial congestion window defaults to 4, an with a MSS of 1460, that's a window of 5840. And as per the RFC 1323, the window in a SYN packet is never scaled (because we don't know yet whether the other end understands window scaling at all). Can you explain exactly what is wrong here?
The window scaling is determined by the socket buffer, not by the sysctl. The SYNs also look correct to me - they are all identical. Suggest INVALID.
urg, I looked with ethereal at it and ethereal showes the first package window size unscaled and the second and later SYN packages with window size scaled. You'r right the packages are identical, ethereal just fooled me, sorry.
Aw, thanks. Lucky I'm still a tcpdump guy :) You may want to send a notice to the ethereal folks though telling them about the problem in their code.