[jcifs] Port 445 Transport

[Michael B Allen]

Christopher R. Hertel said:
> I outline a strategy in my book:
>
>   http://ubiqx.org/cifs/SMB.html#SMB.3
> and
>   http://ubiqx.org/cifs/figures/smb-02.html
>
> There are more notes at the end of the current SMB URI draft too.
>
> The problem, of course, is that I can only provide an outline in the book.
> The actual implementation is a candidate for a lot of fine tuning.
>
> Some notes:
>
> - If the SMB URL you get resolves as a NetBIOS name then 139 is your best
>   first-guess.  This may mean keeping some state info on the client side
>   (eg., did you start by looking up a workgroup name and then "descend"
>   to a server name).

Well just go for 139 straight away.

> - If port 139 or 445 are specified, then you have a clue.
>
> - If a nonstandard port is specified (common with SSH port redirection,
>   for example) then you have to do some guessing.
>
> - If you send an NBT Session Request to a non-NBT port (eg., 445) on a
>   Windows box the Windows box won't respond at all.  You wind up timing
>   out.  If you *don't* send the Session Request and one is expected, you
>   get an NBT Session Service error message *right away*.  That's faster,
>   and you now know what to do.  Samba doesn't care whether you send a
>   Session Request or not (on any port).

So if it's a non-standard port assume raw transport and retry with NetBIOS
if an error occurs (mmm, picking up that error is going to be odd).

> - You can't send RAP requests to port 445.  Samba will respond (we're odd
>   that way) but Windows won't.  The NetServerEnum2 doesn't make much sense
>   on port 445, and it seems that MS just doesn't run RAP on that port.
>
> Hope that's useful.

Very. I was going to go for 445 first and then 139. But we really want to
do it the other way around if for no other reason than we get better
functionality from 139.

I'm glad I asked!

Thanks,
Mike