lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 08 Feb 2007 18:58:07 -0600
From:	"Christopher R. Hertel" <crh@...qx.mn.org>
To:	Shirish S Pargaonkar <shirishp@...ibm.com>
CC:	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Steve French <smfrench@...il.com>,
	linux-cifs-client@...ts.samba.org,
	linux-cifs-client-bounces+shirishp=us.ibm.com@...ts.samba.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [linux-cifs-client] Re: SMB support still missing?

Shirish S Pargaonkar wrote:
:
> This is what Steve had mailed me once, a while ago....
> 
> Win9x and Windows ME and OS/2 only listen on port 139
> 
> WindowsNT 4 (?) and later listen on port 445 and port 139.
> 
> When you connect on the older port 139, you are supposed to send a
> RFC1001 (NBSS Session Request to indicate your client netbios name, but
> the problem is that you don't know the target netbios name of the server
> - which is why the either needs to support the fake name "*SMBSERVER" or
> the client needs to specify the "servernetbiosname=<name>" option on
> mount to identify which name on the server to try to connect to.
> 
> So
> 1) try tcp  connection on  445,
>     then if it works send SMB negprot
> 2) else try tcp connection on port 139
>     then if it works send nbss request to *SMBSERVER or to the name
> specified on servernetbiosname
>     (cifs really should do an ASTAT command and list the valid names and
> find one if that approach fails but we don't have code for this yet)

This is all correct, and also note that W/9x systems do not support the
"*SMBSERVER" name.

On the other hand, the name was resolved somehow.  The typical work-arounds
to not knowning the NBT name of the server are:
1) Use the name you just resolved (in this case, "CL0").
2) Send a Node Status Query and look for the first unique <20> name.

The second (as Steve explained to me a long time ago) is less reliable
because there are some applications out there which (incorrectly) register
names with a suffix byte of <20>.

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@...qx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh@...qx.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ