Re: [linux-cifs-client] Re: SMB support still missing?

Re: [linux-cifs-client] Re: SMB support still missing?

[Christopher R. Hertel]

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@ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh@ubiqx.org

Re: [linux-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

On Feb 8 2007 18:58, Christopher R. Hertel wrote:
>Shirish S Pargaonkar wrote:
>> 
>> 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.

I'd just do this:

 (1) try 445/tcp
 (2) try 139/tcp
 (3) try 139/tcp with uppercase hostname (mount //hostname/share) as
     default servernetbiosname



Jan
-- 
ft: http://freshmeat.net/p/chaostables/

Re: [linux-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

On Feb 8 2007 18:53, Christopher R. Hertel wrote:
>>>
>>> It does seem to me that it is some sort of name resolution issue, but it may
>>> have more to do with the multi-homed nature of your setup.
>>>
>>> Did you try:
>>>
>>>  mount.cifs //CL0/c /mnt
>> 
>> Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump
>> _does_ show that cifs connects to port 139 and then disconnects using FIN)
>
>It would be interesting to see that capture.

01:39:02.089070 IP 192.168.222.94.2019 > 192.168.222.33.445: S 870214128:870214128(0) win 5840 <mss 1460,sackOK,timestamp 828349 0,nop,wscale 1>
	0x0000:  4500 003c ca4d 4000 4006 329d c0a8 de5e  E..<.M@.@.2....^
	0x0010:  c0a8 de21 07e3 01bd 33de 69f0 0000 0000  ...!....3.i.....
	0x0020:  a002 16d0 a82c 0000 0204 05b4 0402 080a  .....,..........
	0x0030:  000c a3bd 0000 0000 0103 0301            ............
01:39:02.092572 IP 192.168.222.33.445 > 192.168.222.94.2019: R 0:0(0) ack 870214129 win 0
	0x0000:  4500 0028 f300 0000 8006 09fe c0a8 de21  E..(...........!
	0x0010:  c0a8 de5e 01bd 07e3 0000 0000 33de 69f1  ...^........3.i.
	0x0020:  5014 0000 ca8f 0000 0000 0000 0000       P.............
01:39:02.096738 IP 192.168.222.94.1343 > 192.168.222.33.139: S 870214131:870214131(0) win 5840 <mss 1460,sackOK,timestamp 828352 0,nop,wscale 1>
	0x0000:  4500 003c ca33 4000 4006 32b7 c0a8 de5e  E..<.3@.@.2....^
	0x0010:  c0a8 de21 053f 008b 33de 69f3 0000 0000  ...!.?..3.i.....
	0x0020:  a002 16d0 abfc 0000 0204 05b4 0402 080a  ................
	0x0030:  000c a3c0 0000 0000 0103 0301            ............
01:39:02.102544 IP 192.168.222.33.139 > 192.168.222.94.1343: S 4435509:4435509(0) ack 870214132 win 8760 <mss 1460,nop,nop,sackOK>
	0x0000:  4500 0030 f400 4000 8006 c8f5 c0a8 de21  E..0..@........!
	0x0010:  c0a8 de5e 008b 053f 0043 ae35 33de 69f4  ...^...?.C.53.i.
	0x0020:  7012 2238 d0f0 0000 0204 05b4 0101 0402  p."8............
01:39:02.104880 IP 192.168.222.94.1343 > 192.168.222.33.139: . ack 1 win 5840
	0x0000:  4500 0028 ca34 4000 4006 32ca c0a8 de5e  E..(.4@.@.2....^
	0x0010:  c0a8 de21 053f 008b 33de 69f4 0043 ae36  ...!.?..3.i..C.6
	0x0020:  5010 16d0 091d 0000                      P.......
01:39:02.117326 IP 192.168.222.94.1343 > 192.168.222.33.139: P 1:73(72) ack 1 win 5840 NBT Session Packet: Session Request
	0x0000:  4500 0070 ca35 4000 4006 3281 c0a8 de5e  E..p.5@.@.2....^
	0x0010:  c0a8 de21 053f 008b 33de 69f4 0043 ae36  ...!.?..3.i..C.6
	0x0020:  5018 16d0 3e34 0000 8100 0044 2043 4b46  P...>4.....D.CKF
	0x0030:  4445 4e45 4346 4445 4646 4346 4745 4646  DENECFDEFFCFGEFF
	0x0040:  4343 4143 4143 4143 4143 4143 4100 2046  CCACACACACACA..F
	0x0050:  4445 4c44 4143 4143 4143 4143 4143 4143  DELDACACACACACAC
	0x0060:  4143 4143 4143 4143 4143 4143 4141 4100  ACACACACACACAAA.
01:39:02.121140 IP 192.168.222.33.139 > 192.168.222.94.1343: FP 1:6(5) ack 73 win 8688 NBT Session Packet: [|SMB]
	0x0000:  4500 002d f500 4000 8006 c7f8 c0a8 de21  E..-..@........!
	0x0010:  c0a8 de5e 008b 053f 0043 ae36 33de 6a3c  ...^...?.C.63.j<
	0x0020:  5019 21f0 f8a4 0000 8300 0001 8253       P.!..........S
01:39:02.162638 IP 192.168.222.94.1343 > 192.168.222.33.139: . ack 7 win 5840
	0x0000:  4500 0028 ca36 4000 4006 32c8 c0a8 de5e  E..(.6@.@.2....^
	0x0010:  c0a8 de21 053f 008b 33de 6a3c 0043 ae3c  ...!.?..3.j<.C.<
	0x0020:  5010 16d0 08cf 0000                      P.......
01:39:02.173013 IP 192.168.222.94.1343 > 192.168.222.33.139: P 73:155(82) ack 7 win 5840 NBT Session Packet: Session Message
	0x0000:  4500 007a ca37 4000 4006 3275 c0a8 de5e  E..z.7@.@.2u...^
	0x0010:  c0a8 de21 053f 008b 33de 6a3c 0043 ae3c  ...!.?..3.j<.C.<
	0x0020:  5018 16d0 3e3e 0000 0000 004e ff53 4d42  P...>>.....N.SMB
	0x0030:  7200 0000 0000 0180 0000 0000 0000 0000  r...............
	0x0040:  0000 0000 0000 950d 0000 0100 002b 0002  .............+..
	0x0050:  4c4d 312e 3258 3030 3200 024c 414e 4d41  LM1.2X002..LANMA
	0x0060:  4e32 2e31 0002 4e54 204c 4d20 302e 3132  N2.1..NT.LM.0.12
	0x0070:  0002 504f 5349 5820 3200                 ..POSIX.2.
01:39:02.317447 IP 192.168.222.94.1343 > 192.168.222.33.139: R 155:155(0) ack 7 win 5840
	0x0000:  4500 0028 ca38 4000 4006 32c6 c0a8 de5e  E..(.8@.@.2....^
	0x0010:  c0a8 de21 053f 008b 33de 6a8e 0043 ae3c  ...!.?..3.j..C.<
	0x0020:  5014 16d0 0879 0000                      P....y..



Jan
-- 
ft: http://freshmeat.net/p/chaostables/

Re: [linux-cifs-client] Re: SMB support still missing?

[Christopher R. Hertel]

Jan Engelhardt wrote:
> On Feb 8 2007 18:29, Christopher R. Hertel wrote:
>> Jan Engelhardt wrote:
>>
>> It does seem to me that it is some sort of name resolution issue, but it may
>> have more to do with the multi-homed nature of your setup.
>>
>> Did you try:
>>
>>  mount.cifs //CL0/c /mnt
> 
> Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump
> _does_ show that cifs connects to port 139 and then disconnects using FIN)

It would be interesting to see that capture.

- The client is clearly finding the server (via NBT lookup or DNS
  lookup--doesn't matter, it's being found).

- The client is creating the TCP connection.

- The server (W9x) is closing the connection.  Why?

  + The most likely reason is 0x82: Called Name Not Present

That's my guess, anyway.  My bet is that W9x is being picky about the case
of the CALLED NAME.

It would not surprise me that the NBT name resolution code *does* convert
the case as part of the NBT encoding (that weird string that reads
EDEMDACACACACACACACACACACACACACA).  It would also not surprise me if the NBT
Session Request code *doesn't* convert the case.  The Session Request uses
the un-encoded string (in this case, "cl0").

The Windows 9x implementation of the NBT layer tends to be much more
"correct" than the NT family and its descendants.  As a result, W9x is
pickier about things like exact matches to the CALLED NAME.

That's all a guess, mind you, but it's something more to go on.

Again, the capture would hold the answer.

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@ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh@ubiqx.org

Re: [linux-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

On Feb 8 2007 18:29, Christopher R. Hertel wrote:
>Jan Engelhardt wrote:
>
>It does seem to me that it is some sort of name resolution issue, but it may
>have more to do with the multi-homed nature of your setup.
>
>Did you try:
>
>  mount.cifs //CL0/c /mnt

Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump
_does_ show that cifs connects to port 139 and then disconnects using FIN)

>If mount.cifs is not converting the case, that should fix the problem.
>Curious to know...


Jan
-- 
ft: http://freshmeat.net/p/chaostables/

Re: [linux-cifs-client] Re: SMB support still missing?

[Christopher R. Hertel]

Jan Engelhardt wrote:
> Hi,
> 
> 
> I tried the various suggestions from the last mails, but nothing of 
> that worked. --verbose did not return anything useful. It's the kernel 
> module that returns -EHOSTDOWN.
> 
> ...
> 
> Eventually I found out that this one works:
> 
> 	mount.cifs //cl0/c /mnt -o servernetbiosname=CL0
> 
> So what did I change? Casing. Note that "CL0" is entirely uppercase. 
> Although strange, it actually coincides with how LANMAN works. 
> Everything is uppercased in lanman, hostnames, usernames, heck, even 
> plaintext passwords (samba-smbd has a good time trying a ton of 
> combinations in such setups).
> 
> No other options like sec=none or thelike were needed. Login as 
> anonymous worked directly.
> 
> 
> Please consider updating the cifs kernel module to account for the LM 
> oddity of uppercasing things. (Then, smbfs can finally be ripped out I 
> hope.)

...assuming that's really the problem.

It does seem to me that it is some sort of name resolution issue, but it may
have more to do with the multi-homed nature of your setup.

Did you try:

  mount.cifs //CL0/c /mnt

?

If mount.cifs is not converting the case, that should fix the problem.

Curious to know...

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@ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh@ubiqx.org

[linux-cifs-client] Re: SMB support still missing?

[Jan Engelhardt]

Hi,


I tried the various suggestions from the last mails, but nothing of 
that worked. --verbose did not return anything useful. It's the kernel 
module that returns -EHOSTDOWN.

...

Eventually I found out that this one works:

	mount.cifs //cl0/c /mnt -o servernetbiosname=CL0

So what did I change? Casing. Note that "CL0" is entirely uppercase. 
Although strange, it actually coincides with how LANMAN works. 
Everything is uppercased in lanman, hostnames, usernames, heck, even 
plaintext passwords (samba-smbd has a good time trying a ton of 
combinations in such setups).

No other options like sec=none or thelike were needed. Login as 
anonymous worked directly.


Please consider updating the cifs kernel module to account for the LM 
oddity of uppercasing things. (Then, smbfs can finally be ripped out I 
hope.)



Jan
-- 
ft: http://freshmeat.net/p/chaostables/