Messages in this thread | | | Date | Fri, 3 Dec 1999 17:39:20 -0500 | From | "Gilbert Ramirez Jr." <> | Subject | 2.2.14-pre10 NFS bug: off by sizeof(int) |
| |
I have two identical Pentium II machines, both running the same image of kernel 2.2.14-pre10, freshly compiled this morning. Both use the 3c59x ethernet driver (10-Mbit), and are on the same ethernet switch, on the same IP subnet. Both use knfsd and autofs, and both are dual-CPU machines running an SMP kernel
I am using one machine (dewey) as the NFS server, and the other machine (louie) is the NFS client. The NFS client is compiling using source files from the NFS server, and writing the object files back to the NFS server.
I have some kind of synchronization problem; sometimes when a directory is made on the NFS server, the NFS client can't see it for a few seconds. The assembler on the NFS client fails because it thinks the output directory does not exist.
I've been doing some network traces (I'm one of the authors of Ethereal, BTW), and these strange "mkdir-latency" problems co-occur with another symptom: bad NFS packets.
The following NFS packet was sent from the NFS client to the NFS server. It's an NFS v2 LOOKUP packet. The RPC string, i.e., the NFS filename, is misplaced. It's off by 4 bytes. (hence the subject line of this e-mail) In my trace, the client sent over 2,000 *good* LOOKUP packets, but at this point it sent a few *bad* ones, including this one.
Notice at the end of the packet it looks like the filename "config.h" was memcpy()'ed in one location, then re-memcpy()'ed in another overlapping location.
BTW, dewey, the NFS server, correctly responds with ERR_NOENT in it's LOOKUP reply packet. The client then sends another badly-formed LOOKUP request, which is again replied to with "ERR_NOENT". Then the client goes on to ask for another file, sending another badly-formed packet.
I thought at first that there was a bug in Ethereal, but the format of the NFS packet is indeed bad.
Frame (170 on wire, 170 captured) Arrival Time: Dec 3, 1999 11:59:39.6631 Time delta from previous packet: 0.027926 seconds Frame Number: 51268 Packet Length: 170 bytes Capture Length: 170 bytes Ethernet II Destination: 00:c0:4f:6b:9f:e0 (00:c0:4f:6b:9f:e0) Source: 00:c0:4f:6b:9f:78 (00:c0:4f:6b:9f:78) Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Type of service: 0x00 (None) 000. .... = Precedence: routine (0) ...0 .... = Delay: Normal .... 0... = Throughput: Normal .... .0.. = Reliability: Normal .... ..0. = Cost: Normal Total Length: 156 Identification: 0xc3d8 Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x5919 Source: louie.dev.tivoli.com (146.84.28.92) Destination: dewey.dev.tivoli.com (146.84.28.91) User Datagram Protocol Source port: 793 (793) Destination port: 2049 (2049) Length: 136 Checksum: 0xabc3 Remote Procedure Call XID: 0x8265de80 (2187714176) Message Type: Call (0) RPC Version: 2 Program: NFS (100003) Program Version: 2 Procedure: LOOKUP (4) Credentials Flavor: AUTH_UNIX (1) Length: 44 Stamp: 0x000007ae Machine Name: louie.dev.tivoli.com length: 20 contents: louie.dev.tivoli.com UID: 4462 GID: 40 Auxiliary GIDs GID: 40 Verifier Flavor: AUTH_NULL (0) Length: 0 Network File System Program Version: 2 Procedure: LOOKUP (4) where dir file handle (opaque data) Name: ig.h length: 1668247142 contents: ig.h
0 00c0 4f6b 9fe0 00c0 4f6b 9f78 0800 4500 ..Ok....Ok.x..E. 10 009c c3d8 0000 4011 5919 9254 1c5c 9254 ......@.Y..T.\.T 20 1c5b 0319 0801 0088 abc3 8265 de80 0000 .[.........e.... 30 0000 0000 0002 0001 86a3 0000 0002 0000 ................ 40 0004 0000 0001 0000 002c 0000 07ae 0000 .........,...... 50 0014 6c6f 7569 652e 6465 762e 7469 766f ..louie.dev.tivo 60 6c69 2e63 6f6d 0000 116e 0000 0028 0000 li.com...n...(.. 70 0001 0000 0028 0000 0000 0000 0000 caba .....(.......... 80 ebfe 94b9 0000 5972 0000 0108 0000 0108 ......Yr........ 90 0000 718f 0000 c773 890b 0000 0000 636f ..q....s......co a0 6e66 6967 2e68 0067 2e68 nfig.h.g.h
(The NFS header starts at byte 0x7e, with "caba...")
--gilbert
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |