* jme: UDP checksum error, and lots of them
@ 2010-12-02 3:39 Jan Engelhardt
2010-12-02 3:53 ` Guo-Fu Tseng
2010-12-02 4:09 ` David Miller
0 siblings, 2 replies; 8+ messages in thread
From: Jan Engelhardt @ 2010-12-02 3:39 UTC (permalink / raw)
To: netdev; +Cc: Guo-Fu Tseng
On 2.6.36-rc8 (somewhat older, but the message is still there in recent
kernels), for almost all UDP packets transmitted/receive, I get a kernel
warning
Dec 2 04:30:52 localhost kernel: [ 495.235252] jme 0000:02:00.5: eth0:
UDP Checksum error.
Apparently this has something to do with the "vpnc" connector program
I am using, given tcpdump reports this too.
Other than that nothing seems wrong; the VPN connection works as
expected.
04:31:30.700682 IP (tos 0x0, ttl 64, id 1981, offset 0, flags [DF], proto UDP
(17), length 128)
192.168.13.39.4500 > 134.76.22.1.4500: [bad udp cksum 9510!] UDP-encap:
ESP(spi=0xf531cf9c,seq=0x6545), length 100
0x0000: 4500 0080 07bd 4000 4011 c893 c0a8 0d27 E.....@.@......'
0x0010: 864c 1601 1194 1194 006c 6a9a f531 cf9c .L.......lj..1..
0x0020: 0000 6545 6b65 ec1a 5cad 484d 96ae a596 ..eEke..\.HM....
0x0030: 5db7 1e93 0c15 c4d4 510b 7206 e821 1d56 ].......Q.r..!.V
0x0040: c91b 1710 a8b9 6181 046a 210e 7804 c2fa ......a..j!.x...
0x0050: 6319 756c 1909 27be 4086 c1d2 01eb 241a c.ul..'.@.....$.
0x0060: 41c9 0548 dea7 2496 c633 abde a601 3253 A..H..$..3....2S
0x0070: 7585 7b75 b587 c008 ee05 880a dc4b a3e7 u.{u.........K..
04:31:30.721666 IP (tos 0x0, ttl 62, id 28480, offset 0, flags [DF], proto UDP
(17), length 1488)
134.76.22.1.4500 > 192.168.13.39.4500: [no cksum] UDP-encap:
ESP(spi=0x9d511170,seq=0x77eb), length 1460
0x0000: 4500 05d0 6f40 4000 3e11 5dc0 864c 1601 E...o@@.>.]..L..
0x0010: c0a8 0d27 1194 1194 05bc 0000 9d51 1170 ...'.........Q.p
Why does the JME driver care so much about this that it needs to print
this for every packet? It does not look like it has any offloading
features.
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pg
Wake-on: g
Current message level: 0x000020c6 (8390)
Link detected: yes
# lspci
02:00.5 Ethernet controller: JMicron Technology Corp. JMC260 PCI
Express Fast Ethernet Controller (rev 02)
02:00.5 0200: 197b:0260 (rev 02)
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: jme: UDP checksum error, and lots of them
2010-12-02 3:39 jme: UDP checksum error, and lots of them Jan Engelhardt
@ 2010-12-02 3:53 ` Guo-Fu Tseng
2010-12-02 4:09 ` David Miller
1 sibling, 0 replies; 8+ messages in thread
From: Guo-Fu Tseng @ 2010-12-02 3:53 UTC (permalink / raw)
To: Jan Engelhardt, netdev
On Thu, 2 Dec 2010 04:39:34 +0100 (CET), Jan Engelhardt wrote
> On 2.6.36-rc8 (somewhat older, but the message is still there in
> recent kernels), for almost all UDP packets transmitted/receive, I get
> a kernel warning
>
> Dec 2 04:30:52 localhost kernel: [ 495.235252] jme 0000:02:00.5:
> eth0: UDP Checksum error.
>
> Apparently this has something to do with the "vpnc" connector program
> I am using, given tcpdump reports this too.
> Other than that nothing seems wrong; the VPN connection works as
> expected.
>
> 04:31:30.700682 IP (tos 0x0, ttl 64, id 1981, offset 0, flags [DF],
> proto UDP
> (17), length 128) 192.168.13.39.4500 > 134.76.22.1.4500: [bad udp
> cksum 9510!] UDP-encap: ESP(spi=0xf531cf9c,seq=0x6545), length 100
> 0x0000: 4500 0080 07bd 4000 4011 c893 c0a8 0d27 E.....@.@......'
> 0x0010: 864c 1601 1194 1194 006c 6a9a f531 cf9c
> .L.......lj..1.. 0x0020: 0000 6545 6b65 ec1a 5cad 484d 96ae
> a596 ..eEke..\.HM.... 0x0030: 5db7 1e93 0c15 c4d4 510b 7206
> e821 1d56 ].......Q.r..!.V 0x0040: c91b 1710 a8b9 6181 046a
> 210e 7804 c2fa ......a..j!.x... 0x0050: 6319 756c 1909 27be
> 4086 c1d2 01eb 241a c.ul..'.@.....$. 0x0060: 41c9 0548 dea7
> 2496 c633 abde a601 3253 A..H..$..3....2S 0x0070: 7585 7b75
> b587 c008 ee05 880a dc4b a3e7 u.{u.........K..
> 04:31:30.721666 IP (tos 0x0, ttl 62, id 28480, offset 0, flags [DF],
> proto UDP
> (17), length 1488) 134.76.22.1.4500 > 192.168.13.39.4500: [no
> cksum] UDP-encap: ESP(spi=0x9d511170,seq=0x77eb), length 1460
> 0x0000: 4500 05d0 6f40 4000 3e11 5dc0 864c 1601 E...o@@.>.]..L..
> 0x0010: c0a8 0d27 1194 1194 05bc 0000 9d51 1170 ...'.........Q.p
>
> Why does the JME driver care so much about this that it needs to print
> this for every packet? It does not look like it has any offloading
> features.
I thought the error should be printed out due to it shouldn't be
happen in normal case.
It can be removed if not wanted, or change the printing to different
msglvl.
How does the Linux world prefer?
Guo-Fu Tseng
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: jme: UDP checksum error, and lots of them
2010-12-02 3:39 jme: UDP checksum error, and lots of them Jan Engelhardt
2010-12-02 3:53 ` Guo-Fu Tseng
@ 2010-12-02 4:09 ` David Miller
2010-12-02 4:33 ` Guo-Fu Tseng
1 sibling, 1 reply; 8+ messages in thread
From: David Miller @ 2010-12-02 4:09 UTC (permalink / raw)
To: jengelh; +Cc: netdev, cooldavid
From: Jan Engelhardt <jengelh@medozas.de>
Date: Thu, 2 Dec 2010 04:39:34 +0100 (CET)
> Why does the JME driver care so much about this that it needs to print
> this for every packet? It does not look like it has any offloading
> features.
Well I'm glad it let us know about the bad checksum which would otherwise
have been unnoticed.
Please try to pinpoint why the checksum is bad, because it seems that
tcpdump agrees with the driver. Perhaps it's some side effect of how
vpnc uses TUN/TAP, or something like that.
Seeing the bad checksum even in tcpdump, and then seeing proper replies
going back, that is very suspicious and should be looked into.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: jme: UDP checksum error, and lots of them
2010-12-02 4:09 ` David Miller
@ 2010-12-02 4:33 ` Guo-Fu Tseng
2010-12-02 5:59 ` David Miller
0 siblings, 1 reply; 8+ messages in thread
From: Guo-Fu Tseng @ 2010-12-02 4:33 UTC (permalink / raw)
To: David Miller, jengelh; +Cc: netdev
On Wed, 01 Dec 2010 20:09:35 -0800 (PST), David Miller wrote
> From: Jan Engelhardt <jengelh@medozas.de>
> Date: Thu, 2 Dec 2010 04:39:34 +0100 (CET)
>
> > Why does the JME driver care so much about this that it needs to print
> > this for every packet? It does not look like it has any offloading
> > features.
>
> Well I'm glad it let us know about the bad checksum which would otherwise
> have been unnoticed.
>
> Please try to pinpoint why the checksum is bad, because it seems that
> tcpdump agrees with the driver. Perhaps it's some side effect of how
> vpnc uses TUN/TAP, or something like that.
>
> Seeing the bad checksum even in tcpdump, and then seeing proper replies
> going back, that is very suspicious and should be looked into.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Indeed... It is suspicious to reply proper response against the packet
with bad checksum.
Jan: Would you try to turn off the rx-checksum offloading with ethtool
and see how it goes?
I suspect that there might be some the HW-Checksum behavior error.
ex: Replaced the UDP checksum field while it's all zero(no need to checksum)
Guo-Fu Tseng
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: jme: UDP checksum error, and lots of them
2010-12-02 4:33 ` Guo-Fu Tseng
@ 2010-12-02 5:59 ` David Miller
2010-12-02 23:15 ` Francois Romieu
0 siblings, 1 reply; 8+ messages in thread
From: David Miller @ 2010-12-02 5:59 UTC (permalink / raw)
To: cooldavid; +Cc: jengelh, netdev
From: "Guo-Fu Tseng" <cooldavid@cooldavid.org>
Date: Thu, 2 Dec 2010 12:33:01 +0800
> I suspect that there might be some the HW-Checksum behavior error.
> ex: Replaced the UDP checksum field while it's all zero(no need to checksum)
I checked the VPNC code and it receives UDP encapsulated traffic using
a normal UDP socket. So any bad checksums should show up in the
statistics and in fact the packets should be dropped by the IPv4
stack before making it to the vpnc application.
Something isn't right here. The only thing that makes sense is if
the tcpdump checksum validation is wrong for some reason. Because
only then could we give a reason for the UDP frames to not be
dropped before vpnc can see them.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: jme: UDP checksum error, and lots of them
2010-12-02 5:59 ` David Miller
@ 2010-12-02 23:15 ` Francois Romieu
2010-12-02 23:54 ` Jan Engelhardt
0 siblings, 1 reply; 8+ messages in thread
From: Francois Romieu @ 2010-12-02 23:15 UTC (permalink / raw)
To: David Miller; +Cc: cooldavid, jengelh, netdev
David Miller <davem@davemloft.net> :
[...]
> Something isn't right here. The only thing that makes sense is if
> the tcpdump checksum validation is wrong for some reason. Because
> only then could we give a reason for the UDP frames to not be
> dropped before vpnc can see them.
Wild guess : 192.168... is the local address and tcpdump chokes on
an outgoing, yet-not-checksummed packet.
--
Ueimor
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: jme: UDP checksum error, and lots of them
2010-12-02 23:15 ` Francois Romieu
@ 2010-12-02 23:54 ` Jan Engelhardt
2010-12-03 23:02 ` Francois Romieu
0 siblings, 1 reply; 8+ messages in thread
From: Jan Engelhardt @ 2010-12-02 23:54 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Miller, cooldavid, netdev
On Friday 2010-12-03 00:15, Francois Romieu wrote:
>David Miller <davem@davemloft.net> :
>[...]
>> Something isn't right here. The only thing that makes sense is if
>> the tcpdump checksum validation is wrong for some reason. Because
>> only then could we give a reason for the UDP frames to not be
>> dropped before vpnc can see them.
>
>Wild guess : 192.168... is the local address and tcpdump chokes on
>an outgoing, yet-not-checksummed packet.
Then the checksums of all other packets I am emitting would also be 0000
or wrong, which isn't the case.
Also, when I am running vpnc on my desktop machine (unlike the
laptop, it has sis900 and is i586), tcpdump agrees with the checksum
it seems.
So either it's due to x86_64, or it is in fact jme..
00:48:10.954007 IP 192.168.13.37.4500 > 134.76.22.1.4500: UDP-encap:
ESP(spi=0x2224e306,seq=0x225a), length 164
0x0000: 4500 00c0 4582 4000 4011 8a90 c0a8 0d25 E...E.@.@......%
0x0010: 864c 1601 1194 1194 00ac b0e4 2224 e306 .L.........."$..
0x0020: 0000 225a 70d8 8311 d5f4 0936 1a1c 1664 .."Zp......6...d
0x0030: f4b9 9281 a9a3 6b91 41eb 1deb 737e defd ......k.A...s~..
0x0040: d5cc 9a76 976c 4216 bdf3 4f23 50b7 deda ...v.lB...O#P...
0x0050: dcf2 489f 223d 9e24 21fb b5f4 5829 ec4c ..H."=.$!...X).L
0x0060: f90b 25b2 588f 82e1 131c b273 07e0 7234 ..%.X......s..r4
0x0070: 957c 69e8 6e56 353c 7ce8 446a 52a2 fe2f .|i.nV5<|.DjR../
0x0080: ea75 c9ac e7e3 df40 bca5 2ca9 e376 29ea .u.....@..,..v).
0x0090: 080b 2329 c1b7 1111 0e4b 8c13 af98 4d5e ..#).....K....M^
0x00a0: 1708 a911 9962 d023 9dff 4df6 58fd e035 .....b.#..M.X..5
0x00b0: 5386 4198 ea07 376d 8c96 3466 394d c7e6 S.A...7m..4f9M..
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: jme: UDP checksum error, and lots of them
2010-12-02 23:54 ` Jan Engelhardt
@ 2010-12-03 23:02 ` Francois Romieu
0 siblings, 0 replies; 8+ messages in thread
From: Francois Romieu @ 2010-12-03 23:02 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: David Miller, cooldavid, netdev
Jan Engelhardt <jengelh@medozas.de> :
> On Friday 2010-12-03 00:15, Francois Romieu wrote:
> >David Miller <davem@davemloft.net> :
> >[...]
> >> Something isn't right here. The only thing that makes sense is if
> >> the tcpdump checksum validation is wrong for some reason. Because
> >> only then could we give a reason for the UDP frames to not be
> >> dropped before vpnc can see them.
> >
> >Wild guess : 192.168... is the local address and tcpdump chokes on
> >an outgoing, yet-not-checksummed packet.
>
> Then the checksums of all other packets I am emitting would also be 0000
> or wrong, which isn't the case.
No. :o)
net/ipv4/udp.c::udp4_hwcsum_outgoing provides a packet data length
dependent partial checksum and it checksums fragments.
--
Ueimor
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-12-03 23:03 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-02 3:39 jme: UDP checksum error, and lots of them Jan Engelhardt
2010-12-02 3:53 ` Guo-Fu Tseng
2010-12-02 4:09 ` David Miller
2010-12-02 4:33 ` Guo-Fu Tseng
2010-12-02 5:59 ` David Miller
2010-12-02 23:15 ` Francois Romieu
2010-12-02 23:54 ` Jan Engelhardt
2010-12-03 23:02 ` Francois Romieu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).