[jcifs] CIFS on Netware

Michael B Allen mballen at erols.com
Sat Jan 5 11:30:03 EST 2002

On Fri, 04 Jan 2002 14:13:36 -0700
"Jim Norman" <JNORMAN at novell.com> wrote:

> Hello all,
> I'm trying to use jCIFS to write a large file to a Netware CIFs enable
> volume.  
> I'm getting a error from jCIFs libraries as seen below,  'bad smb
> header':  (any ideas?)

There are two possibilites. Admittedly I didn't test an
ascii/SmbComOpenAndX type server last rev. Win98 is about the closest
thing I have to test this and it worked:

[miallen at nano jcifs]$ java -Djcifs.properties=../miallen.prp Put smb://hendrix/TEMP/test.bin
<snip hash marks>
6144813 bytes transfered in 13 seconds at 472Kbytes/sec

but I did notice two other bugs with regard to Win98 (share names
must be uppercase or I get invalid network name and I'm getting an
SmbAuthException trying to list the 'smb://'). Anyway, the point is
that it looks like the ascii/SmbComOpenAndX ilk have fallen behind
a little. This might be a bug that has krept in like the ones I just
found. Have you tried 0.5.1? That client was tested quite a bit and
there have been some fairly radical changes in the 0.6 series.

The other possibilty (very likely actually) is that NetWare is leaving a
few garbage bytes at the end of the SmbComWriteAndX response. We had this
problem with Sun's ASU. See, most C clients just read in a big buffers
worth of data whereas, for reasons not worth going into, jCIFS reads
exatly the number of bytes instructed by the presribed format of messages
and by the fields within the packet. So if there's some junk on the end
of a message jCIFS will pick it up the next time around and fail to see a
valid SMB header. This is why the first SmbComWriteAndX operation succeeds
and the *second* one fails (from looking at your -Dlog=ALL dump below).

The immediate solution here is to make the search algorithm much
smarter. The first four bytes of an SMB message are 0xFF 'S' 'M'
'B'. Right now, we read bytes until we get 0xFF (should be true on
the first attempt). Then we read three bytes, and if they match 'SMB'
we move on. If not, you get:

> Jan 4 13:50:51.532 - smb warning
> bad smb header, purging session message

I think NetWare is leaving some junk on the stream with an 0xFF byte in it.

So the moral of the story is, come monday morning try 0.6b6 and look
at the README for further instructions. If it doesn't work, I'll need a
packet trace of it or perhaps I can download NetWare to test against?


May The Source be with you.

More information about the jcifs mailing list