Re: smbfs - still no-go

Bill Hawes (whawes@star.net)
Thu, 04 Dec 1997 23:23:02 -0500


Steven N. Hirsch wrote:
> Sorry to be the bringer of bad tidings, but the latest round of smbfs and
> smbclient patches haven't changed the behavior one iota :-(.

Hi Steve,
Just want to make sure we're in sync, as I did post two patches against
2.1.70 smbfs, and one other tester has reported success with WfW. The
size of the gunzipped file should be 31944.

> I just had a thought.. There is some code in smbclient that sets up
> parameters based on the CORE protocol level. How are you determining
> this? Is it based on dynamic information from the server, or are you
> reading it from the smb.conf file?

If you look through the recent patches, you'll see that I'm basically
trying to figure out some combination of SMB messages that will work
with the three different types of servers. Each server implements a
different subset, each has particular bugs, and the SMB docs are
woefully incomplete (when you're lucky) and just plain wrong (when
you're not.)

Example: the undocumented ERRDOS code 50 turns out to be due to Win 3.1
and 95 not allowing a value in the mtime field of the SMBsetatr message
if the attr field is set. Win NT allows it, Samba allows it, and the
docs show both fields in the message.

> Also, you didn't address the question I posed about the max_xmit setting
> that I've been using with the old smbmount under 2.0.32. If I recall, it
> needed to be scaled back to 1024, but no such option is available with the
> newer code. What is the max_xmit getting based upon if it is not
> user-settable?

I don't know the answer yet. You might check the smbclient man page --
if there's an argument to specify max xmit, give that a try. Smbclient
basically sets up and negotiates the connection for smbfs.

Regards,
Bill