jme: UDP checksum error, and lots of them

jme: UDP checksum error, and lots of them

[Jan Engelhardt]

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)

Re: jme: UDP checksum error, and lots of them

[Guo-Fu Tseng]

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

Re: jme: UDP checksum error, and lots of them

[David Miller]

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.

Re: jme: UDP checksum error, and lots of them

[Guo-Fu Tseng]

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

Re: jme: UDP checksum error, and lots of them

[David Miller]

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.

Re: jme: UDP checksum error, and lots of them

[Francois Romieu]

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

Re: jme: UDP checksum error, and lots of them

[Jan Engelhardt]

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..

Re: jme: UDP checksum error, and lots of them

[Francois Romieu]

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