[1024] in linux-net channel archive
zero-length fragments strike again
daemon@ATHENA.MIT.EDU (Werner Almesberger)
Fri Sep 1 05:25:03 1995
From: Werner Almesberger <almesber@lrc.epfl.ch>
To: iialan@iifeak.swan.ac.uk, rzsfl@rz.uni-sb.de, jrs@world.std.com,
hjl@nynexst.com
Date: Thu, 31 Aug 1995 22:44:07 +0200 (MET DST)
Cc: linux-net@vger.rutgers.edu
Hi everybody,
remember that I've been complaining for a long time about spurious NFS
problems ? I've found one of the reasons and a sequence of bugs today:
Linux (at least 1.3.12) still generates zero-length fragments, which
Solaris 2.4 happily discards along with the rest of the packet. NFS
doesn't like this.
Repeat-by: dd if=/dev/zero bs=2818 of=foo count=1 (or 4298, etc.)
to a (soft-mounted, rsize/wsize=8192) file system exported by a Solaris
2.4 machine. It may also happen with other Solaris versions and/or
other operating systems.
The problem comes from the incorrect zero-length fragment check in
net/ipv4/ip.c, around line 2584 in 1.3.21:
fraglen = length - offset + fragheaderlen;
if(fraglen==0)
should probably be something like
fraglen = length - offset + fragheaderlen;
if(fraglen <= fragheaderlen)
(And maybe we want to panic if it's really < fragheaderlen :-)
The second (minor) problem is that fs/nfs/sock.c:do_nfs_rpc_call
overwrites the -EIO (for the NFS timeout) with a -EAGAIN (for the
recvfrom it attempts a bit later). The third (slightly nastier)
problem is that ld 2.5.2.6/BFD2.5 (or is it libc 4.6.27 ?) seems to
ignore the write error it gets when that bug hits ... oh well,
enjoy :-)
Cheers, Werner
--
_________________________________________________________________________
/ Werner Almesberger, DI-LRC,EPFL,CH werner.almesberger@lrc.di.epfl.ch /
/_IN_R_311__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
