[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