[linux-cifs-client] Re: RFC 1001/1002 support

[Christopher R. Hertel]

On Mon, Apr 26, 2004 at 10:37:26AM -0500, Steve French wrote:
> Chris Hertel wrote:
> > 
> > You really need both the CALLED and CALLING name.  The CALLED name should be
> 
> That is probably true, although for port 139 *SMBSERVER always is being
> used at the moment since it presumably fulfills the goals of getting
> Windows port 139 working (even to NT4 server presumably - although I am
> testing that today) although even older servers will not understand
> *SMBSERVER of course but then again they would not understand modern
> CIFS T2 infolevels either ...

W/9x doesn't recognize "*SMBSERVER".  I'm not sure about Millennium 
Edition.  I also don't know whether 9x and ME support T2 infolevels, but I 
do know that a lot of home and small office environments still use 9x and 
ME, and expect filesharing to work between them.

> >   1) the server's NetBIOS name
> >   2) if the server's NetBIOS name is not available (eg, DNS name was used)
> >      then "*SMBSERVER"
> >   3) if "*SMBSERVER" doesn't work, then there are tricks that can be tried,
> >      but these are probably more than the CIFS VFS should be using.
> > 
> > The CALLING name should be:
> >   1) The DNS hostname of the client.
> >   2) The first label of the DNS name assigned to the IP address of the
> >      interface from which the request is being sent.
> >   3) Anything you like.
> 
> You are probably right that I should allow override of either or both
> called and calling name - smbmount uses the mount parm "netbiosname" for
> the "source Netbios name" and for consistency I use the same meaning
> (although I allow a shorter form of the parm "netb" for users who, like
> I do, prefer to type shorter commands).  I understand the normal options
> for RFC1001 post NT4 SP3 session_initialize retries (1st component of
> UNC name being treated as netbios called name, or looking up the called
> name ie remote adapter status name lookup, or using a dummy called name
> "*SMBSERVER      \0x20") although I have only implemented the latter.

It would be really nice if the mount command would use SMB URI syntax.  :)

Take a look at the latest draft:
  http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-06.txt

I believe that it covers all of the requirements for making an SMB 
connection via 139 or 445.

> This, ie the implementation, is a little more difficult than it sounds
> to do right though - since this will require blocking the thread (and
> also blocking all dueling threads that might try to initialize the same
> connection since the kernel is preemptible and SMB enabled in many
> cases) doing the session_initialize request as it waits for a RFC1002
> session ACK or NACK or timeout (what is a rational timeout - 1 second or
> so?) - this is also tricky because there is no convenient id, like the
> smb mpx_id and smb pid, for the receiver thread to use to demultiplex to
> the right thread waiting on the session_init.   It would be (or will be)
> even trickier to code various retries with different target names if it
> is legal or meaningful to have two RFC1001/RFC1002 sessions over the
> same TCP connection from the same client to the same server (I realize
> that you can have to smb_uids, ie smb sessions, over the same tcp socket
> - but it would complicate the logic if there were a similar concept for
> multiplexing RFC1001 over the same socket, ie if the server special
> cased two rfc1001 session inits from the same client ip address to the
> same server service on the same socket).

All of that is stuff we'll have to handle if we create a NBT kernel module
for Linux (a long term goal I'm working on with some Wine-folk), so I'm
starting to understand the issues.

> > The CALLING name is sometimes used by Samba to identify the client (for
> > service selection and/or logging purposes).
> right

Fun, innit?  :)

Oh... about scopeID.  Here's why it isn't needed in the NBT SESSION 
REQUEST (you know most of this, but as it's a public list...):

- It's the NBT Name Service that creates the virtual NetBIOS LAN on top 
  of IP.  ScopeIDs are used to create separate NBT vLANs.  That is, nodes
  on ScopeID "A" should not be able to "see" nodes on ScopeID "B".

- The ScopeID *is* included when sending NBT datagrams.  This is because 
  datagrams are simply sent.  There is no name lookup before the datagram 
  is transmitted, so the ScopeID is required in order to ensure that the 
  datagram is sent via the correct NBT vLAN.  ScopeID is attached to both 
  the CALLED and CALLING name (so, in theory, a Datagram could cross NBT 
  vLAN boundaries).

- As you note above, an NBT name lookup must be performed before an NBT 
  Session can be established.  The name lookup itself includes the 
  ScopeID, so the correct NBT vLAN is being traversed to find the IP.  
  NetBIOS itself knows nothing whatsoever about ScopeIDs, so once you have
  the correct IP address the ScopeID is no longer relevant.

Chris -)-----

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