ipv4 udplite broken in >=linux-3.0 ?

ipv4 udplite broken in >=linux-3.0 ?

[Jinxin Zheng]

Hi,

I recently migrated my work from udp to udplite. Thanks for your great effort.

But after I upgraded the kernel from 2.6.38 to 3.0, the ipv4 version
of udplite stops working.
I tested the applications downloaded from Gerrit's udplite wiki, and
found that the ipv6 version works well, but not ipv4.

I did the tests on a Gentoo. The kernels are downloaded from the
official web site.

I don't know how to debug udplite. Can any one of you give me a tip on
how to get more debug info, then I can do further test and provide
with it?

Thanks!

--
Zheng Jinxin

Re: ipv4 udplite broken in >=linux-3.0 ?

[Hagen Paul Pfeifer]

* Jinxin Zheng | 2011-11-18 12:09:25 [+0800]:

>I don't know how to debug udplite. Can any one of you give me a tip on
>how to get more debug info, then I can do further test and provide
>with it?

net-next works for me:

$ sudo aptitude install netsend
$ sudo tcpdump -n -ttt -vv -i lo > pcap.trace &
$ netsend udplite receive &
$ netsend udplite transmit /etc/fstab 127.0.0.1

$ cat pcap.trace
00:00:00.000000 IP (tos 0x0, ttl 64, id 30602, offset 0, flags [DF], proto unknown (136), length 40) 127.0.0.1 > 127.0.0.1:  udplite 20
00:00:00.000074 IP (tos 0x0, ttl 64, id 30603, offset 0, flags [DF], proto unknown (136), length 1125) 127.0.0.1 > 127.0.0.1:  udplite 1105


Kernel version? What is the output of strace?

Re: ipv4 udplite broken in >=linux-3.0 ?

[Jinxin Zheng]

On Fri, Nov 18, 2011 at 8:04 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> * Jinxin Zheng | 2011-11-18 12:09:25 [+0800]:
>
>>I don't know how to debug udplite. Can any one of you give me a tip on
>>how to get more debug info, then I can do further test and provide
>>with it?
>
> net-next works for me:
>
> $ sudo aptitude install netsend
> $ sudo tcpdump -n -ttt -vv -i lo > pcap.trace &
> $ netsend udplite receive &
> $ netsend udplite transmit /etc/fstab 127.0.0.1
>
> $ cat pcap.trace
> 00:00:00.000000 IP (tos 0x0, ttl 64, id 30602, offset 0, flags [DF], proto unknown (136), length 40) 127.0.0.1 > 127.0.0.1:  udplite 20
> 00:00:00.000074 IP (tos 0x0, ttl 64, id 30603, offset 0, flags [DF], proto unknown (136), length 1125) 127.0.0.1 > 127.0.0.1:  udplite 1105
>
>
> Kernel version? What is the output of strace?
>

The kernel version is 3.0. I compiled it myself on a Gentoo i386.

I do not use Ubuntu or Debian. Cannot get netsend in Gentoo ...

But I did the test using the hello_world application downloaded from
Gerrit's wiki:
http://www.erg.abdn.ac.uk/~gerrit/udp-lite/

It contains a simple 'server' and a 'client' program.
The client sends a "Hello World" to the server, and when the server
receives the message it exits.

$ tcpdump -n -ttt -vv -i lo > pcap.trace &
$ ./server &
$ ./client

$ cat pcap.trace
00:00:00.000000 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
unknown (136), length 41)
   127.0.0.1 > 127.0.0.1:  ip-proto-136 21

the pcap trace seems ok. The sendto() in the client returns ok. But
the server just cannot return from recv() and echo the message...

I can't see anything suspicious from strace for the server or client either...

-- 
Zheng Jinxin

Re: ipv4 udplite broken in >=linux-3.0 ?

[Gerrit Renker]

Jinxin, -
| On Fri, Nov 18, 2011 at 8:04 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
| > * Jinxin Zheng | 2011-11-18 12:09:25 [+0800]:
| >
| >>I don't know how to debug udplite. Can any one of you give me a tip on
| >>how to get more debug info, then I can do further test and provide
| >>with it?
| >
| > net-next works for me:
That is very likely the point. Between 2.6.39 and 3.0 UDP-Lite checksum coverage was
broken and got only recently fixed. The correct kernel version should have the 
commit shown below. Alternatively, you can check include/net/udplite.h, which
should mention "Slow-path" and "Fast-Path" computation. UDP-Litev6 still uses the
slow path, that is why it is not affected.
    

commit f36c23bb9f822904dacf83a329518d0a5fde7968
Author: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date:   Mon Oct 17 19:07:30 2011 -0400

    udplite: fast-path computation of checksum coverage
    
    Commit 903ab86d195cca295379699299c5fc10beba31c7 of 1 March this year ("udp: Add
    lockless transmit path") introduced a new fast TX path that broke the checksum
    coverage computation of UDP-lite, which so far depended on up->len (only set
    if the socket is locked and 0 in the fast path).
    
    Fixed by providing both fast- and slow-path computation of checksum coverage.
    The latter can be removed when UDP(-lite)v6 also uses a lockless transmit path.
  

Re: ipv4 udplite broken in >=linux-3.0 ?

[Jinxin Zheng]

On Sat, Nov 19, 2011 at 7:27 AM, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Jinxin, -
> | On Fri, Nov 18, 2011 at 8:04 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> | > * Jinxin Zheng | 2011-11-18 12:09:25 [+0800]:
> | >
> | >>I don't know how to debug udplite. Can any one of you give me a tip on
> | >>how to get more debug info, then I can do further test and provide
> | >>with it?
> | >
> | > net-next works for me:
> That is very likely the point. Between 2.6.39 and 3.0 UDP-Lite checksum coverage was
> broken and got only recently fixed. The correct kernel version should have the
> commit shown below. Alternatively, you can check include/net/udplite.h, which
> should mention "Slow-path" and "Fast-Path" computation. UDP-Litev6 still uses the
> slow path, that is why it is not affected.
>
>
> commit f36c23bb9f822904dacf83a329518d0a5fde7968
> Author: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> Date:   Mon Oct 17 19:07:30 2011 -0400
>
>    udplite: fast-path computation of checksum coverage
>
>    Commit 903ab86d195cca295379699299c5fc10beba31c7 of 1 March this year ("udp: Add
>    lockless transmit path") introduced a new fast TX path that broke the checksum
>    coverage computation of UDP-lite, which so far depended on up->len (only set
>    if the socket is locked and 0 in the fast path).
>
>    Fixed by providing both fast- and slow-path computation of checksum coverage.
>    The latter can be removed when UDP(-lite)v6 also uses a lockless transmit path.
>
>

Thanks, Gerrit. Upgrading to the upstream linux-3.2-rc2 fixed the problem :)

-- 
Zheng Jinxin