On Sun, Nov 25, 2001 at 05:10:05PM -0500, guignot wrote: > Le Samedi 24 Novembre 2001 21:08, vous avez �crit : > > What happens with the tcpdump 3.7 beta version? > > same problem (I tried tcpdump-3.7.0-329.tar.gz ) > > > (By the way, "fn_printn()" is used to print file names, but there aren't > > any file names in NFS lookup replies; was it crashing on a lookup > > *reply*, or a lookup *request*?) > > on a request > > here is an excerpt from the output : > > [root@b tcpdump-3.7.0]# ./tcpdump -s 500 not port telnet > tcpdump: listening on eth0 > 17:07:29.856806 a.1202840314 > b.nfs: 100 getattr fh 0,1/83886848 > 17:07:29.856882 b.nfs > a.1202840314: reply ok 96 getattr DIR 40755 ids > 500/504 sz 8192 (DF) > 17:07:29.858295 a.1219617530 > b.nfs: 100 getattr fh 0,1/83886848 > 17:07:29.858383 b.nfs > a.1219617530: reply ok 96 getattr DIR 40755 ids > 500/504 sz 8192 (DF) > 17:07:29.859371 a.1236394746 > b.nfs: 108 readdir fh 0,1/83886848 4096 bytes > @ 0 > 17:07:29.859475 b > a: (frag 34010:1220@1480) > 17:07:29.859648 b.nfs > a.1236394746: reply ok 1472 readdir offset 1 size > 51222 eof (frag 34010:1480@0+) > 17:07:29.881730 a.1253171962 > b.nfs: 112 lookup fh 0,1/83886848 "a.gif" > 17:07:29.881799 b.nfs > a.1253171962: reply ok 128 lookup fh Unknown/1 (DF) > 17:07:29.883340 a.1269949178 > b.nfs: 156 lookup fh 0,1/83886848 > "blender-creator-2.22-linux-glibc2.1.2-i386-static" > 17:07:29.884119 b.nfs > a.1269949178: reply ok 128 lookup fh Unknown/1 (DF) > 17:07:29.888323 a.1286726394 > b.nfs: 112 lookup fh 0,1/83886848 > >"n.py^@.py<^@^Q5^@^@^@^@<^@^Q5^@^@^@^@ux-glibc2.1.2-i386-static^@^@^@.Xauthority^@^@^@^@`^@^@^@^A^@^@M-;M-c^@^@^@^I.kxmlrpcd^@^@^@^@^@^@t^@^@^@^A^@^@M-;M-R^@^@^@^P.DCOPserver_b_:0^@^@^@M-^L^@^@^@^A^@^CM-%M-L^@^@^@^Esofts^@^@^@^@^@^@M-^\^@^@^@^A^@^A9b^@^@^@^Nopenssl-0.9.6b^@^@^@^@^@M-4^@^@^@^A^@^@M-;M-O^@^@^@^Q.MCOP-random-seed^@^@^@^@^@^@M-P^@^@^@^A^@^@M-<^]^@^@^@^G.mcoprc^@^@^@^@M-`^@^@^@^A^@^A^NM- > > ^@^@^@^Fsource^@^@^@^@^@M-p^@^@^@^A^@^CM-4M-^E^@^@^@^F.xauth^@^@^@^@^A^@
Well, "parsefn()" does check whether the name, in its entirety, is contained within the packet, so I'm not sure why it's apparently running past the end of the packet. I infer from the "(frag 34010:1220@1480)" that this is NFS-over-UDP. Note also that not all of the lookup requests have problems. Just out of curiosity, what happens if you save the capture to a file, and, if it has one of the packets with a problem, you look at it with Ethereal? What does Ethereal show as the string length for the file name in the lookup request? - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
