[jcifs] RE: jCIFS corrupt files

[barry.roberts at xactsites.com]

The reason I haven't suspected the servers (Samba 2.2.3a-12.3 and 2.0beta2 on Debian, 2.2.7-1.7.3 on RH 7.3) is because they haven't been re-started for months.  I have multiple app servers and only one at a time starts getting errors, and re-starting the app server fixes the problem.  Other app servers just keep working along without errors simultaneously.

But if jCIFS keeps a connection open to the samba server and something on the server side related to that connection is getting corrupted, that would explain the behavior.  Does jCIFS do that?  I looked for properties relating to that kind of thing, but all I found was for the naming connection, and AFAIK, that's different.  If jCIFS does keep the connection to the server open  are there api calls to force it to close and re-connect?  That would be something to try and faster than shutting down the app server and re-starting it.  Or properties to set would be fun to try, too.


Thanks,
Barry Roberts

-----Original Message-----
From:	Michael B Allen [mailto:mba2000 at ioplex.com]
Sent:	Wed 10/1/2003 5:44 PM
To:	Barry Roberts; crh at ubiqx.mn.org
Cc:	jcifs at samba.org
Subject:	RE: [jcifs] RE: jCIFS corrupt files


-----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. 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.

It sounds like it could be a server error. What types of servers have you
tried that generate corruption Barry?

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

-- 
A program should be written to  model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the  potential for it  to be applied  to tasks that are
conceptually similar and, more  important, to tasks that have not
yet been conceived.



-------------- next part --------------
HTML attachment scrubbed and removed