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

Bug#381262: marked as done (linux-image-2.6.17-1-686: TCP bug introduced in 2.6.17)

Your message dated Thu, 3 Aug 2006 12:09:08 +0000
with message-id <20060803120908.GA20350@wavehammer.waldi.eu.org>
and subject line Bug#381262: linux-image-2.6.17-1-686: TCP bug introduced in 2.6.17
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: linux-image-2.6.17-1-686
Version: 2.6.17-4
Severity: important

It is impossible to access the following URL using kernel 2.6.17:
http://icfp06.cs.uchicago.edu/

No data seems to be received, when running Debian's kernel 2.6.17, using any web brower (Konqueror, Firefox...), or even using telnet:
telnet icfp06.cs.uchicago.edu 80
GET / HTTP/1.1
host: icfp06.cs.uchicago.edu

This problem occurs always and only with that web site (I have found no other site that triggers that problem), and only when using kernel 2.6.17.

It must be noted that this problem disappears when running a previous kernel version (I re-tried running at least version 2.6.16 on the same Debian system).
This is not a problem tied to our network configuration: all other users of our network can access that URL without problem, using any other OS.
This is not a hardware problem: when running kernel 2.6.16 or Windows XP on the same hardware, I have no problem.

Running ethereal, I observed that the HTTP TCP data is actually received, but seems dropped by the kernel before being delivered to the client process (browser or telnet).
If you can't reproduce that problem, please tell me what additional information you would need.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.17-1-686 depends on:
ii  initramfs-tools [linux-initra 0.73       tools for generating an initramfs
ii  module-init-tools             3.2.2-3    tools for managing Linux kernel mo

Versions of packages linux-image-2.6.17-1-686 recommends:
ii  libc6-i686                    2.3.6-16   GNU C Library: Shared libraries [i

-- debconf information:
  linux-image-2.6.17-1-686/preinst/bootloader-initrd-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/old-dir-initrd-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/bootloader-test-error-2.6.17-1-686:
  linux-image-2.6.17-1-686/postinst/create-kimage-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/old-initrd-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/kimage-is-a-directory:
  linux-image-2.6.17-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.17-1-686/postinst/depmod-error-2.6.17-1-686: false
  linux-image-2.6.17-1-686/prerm/removing-running-kernel-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/old-system-map-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/elilo-initrd-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/overwriting-modules-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/already-running-this-2.6.17-1-686:
  linux-image-2.6.17-1-686/preinst/abort-overwrite-2.6.17-1-686:
  linux-image-2.6.17-1-686/postinst/bootloader-error-2.6.17-1-686:
  linux-image-2.6.17-1-686/preinst/lilo-initrd-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/failed-to-move-modules-2.6.17-1-686:
  linux-image-2.6.17-1-686/preinst/initrd-2.6.17-1-686:
  linux-image-2.6.17-1-686/postinst/depmod-error-initrd-2.6.17-1-686: false
  linux-image-2.6.17-1-686/preinst/abort-install-2.6.17-1-686:
  linux-image-2.6.17-1-686/prerm/would-invalidate-boot-loader-2.6.17-1-686: true

--- End Message ---
--- Begin Message --- 
On Thu, Aug 03, 2006 at 05:31:26PM +0900, Romain Lenglet wrote:
> This problem occurs always and only with that web site (I have found no other site that triggers that problem), and only when using kernel 2.6.17.

Since 2.6.17, Linux uses TCP window scaling which is specified in RFC 1323 in
an aggressive way. A connection to the specified server produces the following:

|     Sequence number: 0    (relative sequence number)
|     Flags: 0x0002 (SYN)
|     Window size: 5840
|     Options: (20 bytes)
[...]
|         Window scale: 7 (multiply by 128)

The client wants a window scale of 7.

|     Sequence number: 0    (relative sequence number)
|     Acknowledgement number: 1    (relative ack number)
|     Header length: 44 bytes
|     Flags: 0x0012 (SYN, ACK)
|     Window size: 1460
|     Options: (24 bytes)
[...]
|         Window scale: 0 (multiply by 1)

The server acknowledges the scale but announces one of 0 for itself. According
to http://lwn.net/Articles/92727/, this may be a broken packetfilter somewhere
in the route.

|     Sequence number: 1    (relative sequence number)
|     Acknowledgement number: 1    (relative ack number)
|     Flags: 0x0010 (ACK)

The 3-way handshake is finished.

|     Sequence number: 1    (relative sequence number)
|     Next sequence number: 398    (relative sequence number)
|     Acknowledgement number: 1    (relative ack number)
|     Flags: 0x0018 (PSH, ACK)
|     Window size: 5888 (scaled)
|     Options: (12 bytes)
[...]
| Hypertext Transfer Protocol
|     GET / HTTP/1.1\r\n
|         Request Method: GET
|         Request URI: /
|         Request Version: HTTP/1.1
|     Host: icfp06.cs.uchicago.edu\r\n
[...]

The request. Ethereal shows the real window as it saw the correct connection
setup. The value in the packet is (5888/128 =) 46, which is too small to send
one packet.

|     Sequence number: 2753    (relative sequence number)
|     Acknowledgement number: 398    (relative ack number)
|     Flags: 0x0010 (ACK)
|     Window size: 16512
|     Options: (12 bytes)
[...]
|     SEQ/ACK analysis
|         TCP Analysis Flags
|             A segment before this frame was lost

The next received frame. According to ethereal, there is a frame before
missing. No packets are received in the next 30 seconds, so a packetfilter
seems to drop it.

> Running ethereal, I observed that the HTTP TCP data is actually received, but seems dropped by the kernel before being delivered to the client process (browser or telnet).
> If you can't reproduce that problem, please tell me what additional information you would need.

It is a bug in the network infrastructure. One workaround is to set
/proc/sys/net/ipv4/tcp_window_scaling to 0.

Bastian

-- 
Prepare for tomorrow -- get ready.
		-- Edith Keeler, "The City On the Edge of Forever",
		   stardate unknown

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: