Summary: | sys-kernel/gentoo-sources-2.6.19-r5: lots of UDP bad checksum | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | VERIFIED UPSTREAM | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=7938 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Toralf Förster
2007-01-31 12:25:18 UTC
For the NTP protocol: all server packets are ok, all NTP client packets have wrong checksum in general: all UDP packets created by my localhost have a wrong check sum whereas the received UDP packets are ok Which network hardware and driver is this? Is it reproducible on the latest development kernel, currently 2.6.20-rc6? (In reply to comment #3) > Which network hardware and driver is this? 22 ~ # lspci | grep Ether 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) dmesg gives: n22 ~ # dmesg | grep e100 e1000: 0000:02:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:0d:60:7b:2d:9b e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex n22 ~ # dmesg | grep Think radeonfb: IBM Thinkpad R50/R51/T40/T41 detected, enabling workaround ibm_acpi: ThinkPad EC firmware 1RHT71WW-3.04 ibm_acpi: IBM ThinkPad ACPI Extras v0.13 It's an T41 which works like a charm with Linux (except this already solved bug: http://bugzilla.kernel.org/show_bug.cgi?id=7207) > Is it reproducible on the latest development kernel, currently 2.6.20-rc6? Unfortunately yes, I tested it with latest sources : 2.6.20-rc7-g190ff5b3 I switched back to 2.6.18-gentoo-r6. b/c it's a problem of the vanilla kernel I filed a bug here : http://bugzilla.kernel.org/show_bug.cgi?id=7938 Thanks. It would be good to describe what makes you think the checksums are bad (i.e. describe the process you are using with wireshark) on the upstream bug as well. As noted on the upstream bug, this is related to iptables_nat. It's not a 2.6.19 regression and it's not really a bug at all |