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
On Fri, Nov 18, 2011 at 8:04 PM, Hagen Paul Pfeifer [off-list ref] wrote:
* Jinxin Zheng | 2011-11-18 12:09:25 [+0800]:
quoted
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
Jinxin, -
| On Fri, Nov 18, 2011 at 8:04 PM, Hagen Paul Pfeifer [off-list ref] 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 [off-list ref]
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.
On Sat, Nov 19, 2011 at 7:27 AM, Gerrit Renker [off-list ref] wrote:
Jinxin, -
| On Fri, Nov 18, 2011 at 8:04 PM, Hagen Paul Pfeifer [off-list ref] 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 [off-list ref]
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