[jcifs] RE: jCIFS corrupt files
Christopher R. Hertel
crh at ubiqx.mn.org
Thu Oct 2 13:49:12 EST 2003
Michael B Allen wrote:
>
> -----Original Message-----
> From: Christopher R. Hertel [ <mailto:crh at ubiqx.mn.org>]
> >
> > bytes offset(calc) offset(real) error
> > 4930 0 0 0
> > 4930 4930 4864 66
> > 4930 9860 9728 132 (66 x 2)
> > 4930 14790 14592 198 (66 x 3)
> > 4930 19720 19712 8
> > 4930 24650 24576 74 (66 + 8)
> > 4930 29580 29440 140 ((66 x 2) + 8)
> > 4930 34510 34304 206 ((66 x 3) + 8)
> <snip>
> >Somewhere there is a one byte value being incremented by 66 with the
> >resulting value *subtracted* from the correct file offset.
> >
> >I'm not sure where the 66 is coming from.
>
> But all of the offsets and lengths are correct *and* the payload has the
> data. So I don't think this is a jCIFS encoding problem.
Hmmm... When I looked at the capture I saw that the offsets were incorrect.
Packet #52, for instance, reads:
52 0.313801 192.168.2.203 192.168.2.95 SMB Write AndX Request, FID:
0x2388, 4930 bytes at
offset 4864
The offset of 4864 is wrong. It should be offset 4930.
> I don't see how
> it can be. Nbt says 4993 - 63 = 4930 = smb.data_length = (0x5EA - 0x85) +
> (0x5EA - 0x42) + (0x5EA - 0x42) + (0x2CF - 0x42). Everything adds up.
If you use the correct offsets it does, but the correct offsets are wrong,
though.
> It sounds like it could be a server error. What types of servers have you
> tried that generate corruption Barry?
The server is correctly returning a count of 4930 in the Write&X Response
(packet 51) but the client is sending an offset of 4864 in the next Write&X
Request (packet 52). Also, if I look at the corrupted file the first error
occurs at offset 4864. It does appear that it's simply missing a handful of
characters.
Chris -)-----
> Or, here's a way to get 66 though:
>
> 0x5EA - 0x42 (size of an NBSS Continuation Message from one of the
> SMB_COM_WRITE_ANDX messages) = 1514
> 1514 + 32 for TCP header + 20 for IP header = 1566
>
> but IP header Total Length field claims the entire message is on 1500. Oops!
>
> 1566 - 1500 = 66.
>
> This 66 error would occur with each of the 4 messages per SMB though so
> this might be a poor conclusion.
>
> Can a network engineer out there confirm that an IP header 'Total Length'
> should require that the actual payload be that size or can it go over?
>
> This could be a framing error.
>
> Mike
--
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the jcifs
mailing list