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

[Steve French]

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

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

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


<snip>
> 
> Cool!
> 
> Chris -)-----