All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found] ` <alpine.DEB.2.00.1011301428530.15277-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
@ 2010-11-30 15:45   ` Shirish Pargaonkar
       [not found]     ` <AANLkTinHDfxNhKLSEwHtH7oM+EUCj_HB97Ch-9RQXjTj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Shirish Pargaonkar @ 2010-11-30 15:45 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, Nov 30, 2010 at 7:35 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
> Hi Shirish,
>
> Find attached some detailed problem info and pcaps on the different failing
> scenario's.
>
> Please note our setup is not standard, as we're using a BIND DNS server, and
> we have a mix of 3 DC's where only 2 are DFS root.
>
> Do note however that Windows clients do not have any problem with this
> setup.
>
> If I can be of more help/need to test something, please let me know.
>
> Thanks!
> --
> Robbert
>
> ---------- Forwarded message ----------
> Date: Tue, 30 Nov 2010 14:18:37 +0100 (CET)
> From: Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org>
> To: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: Can't mount Windows DFS root using NTLMv2
>
> Hi Shirish,
>
> On Mon, 29 Nov 2010, Shirish Pargaonkar wrote:
>
>> Robert, does sec=ntlmssp without  dom=sox helps?
>> A wireshark trace when you issue mount command would be useful.
>
> With or wihout dom=sox does not make a difference.
>
> Here is an overview of what I tested:
>
>                2003sp2         2008r2 (+DFS)   2008 (+DFS)
> NTLM            (1)             OK              OK
> NTLMv2          (1)             (2)             (2)
> NTLMSSP         (3)             (3)             (3)
>
>
> 1 = Fails with "Required key not available"
> 2 = Fails with "NT_STATUS_INVALID_PARAMETER"
> 3 = Fails with "NT_STATUS_NOT_SUPPORTED"
>
> I will send you some detailed logs and pcaps off-list.
>
> Regards,
> Robbert

This is strange wrt ntlmssp.  In negotiate protocol response, server
does state NTLMSSP as one of the mechanism types.
It must be related to bits in flag2 that that client sends in type 1 ntlmssp
session setup that server eitther expects from client but is missing or
does not support/like one of the flags2 bits.
Is 10.0.0.7 a box that runs cifs client?

ntlmv2 is not going to work as it is against Windows 2008, it will return
invalid parameter error.
Jeff Layton had pointed to this which you can try (I have not tried it yet)
 http://support.microsoft.com/kb/957441/en-us

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]     ` <AANLkTinHDfxNhKLSEwHtH7oM+EUCj_HB97Ch-9RQXjTj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2010-11-30 16:38       ` Shirish Pargaonkar
       [not found]         ` <AANLkTi=c11fiqZkOkdrdNB6KbsDLV4XSfmPjE3_SScOj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2010-11-30 17:00       ` Robbert Kouprie
  1 sibling, 1 reply; 14+ messages in thread
From: Shirish Pargaonkar @ 2010-11-30 16:38 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, Nov 30, 2010 at 9:45 AM, Shirish Pargaonkar
<shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Nov 30, 2010 at 7:35 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
>> Hi Shirish,
>>
>> Find attached some detailed problem info and pcaps on the different failing
>> scenario's.
>>
>> Please note our setup is not standard, as we're using a BIND DNS server, and
>> we have a mix of 3 DC's where only 2 are DFS root.
>>
>> Do note however that Windows clients do not have any problem with this
>> setup.
>>
>> If I can be of more help/need to test something, please let me know.
>>
>> Thanks!
>> --
>> Robbert
>>
>> ---------- Forwarded message ----------
>> Date: Tue, 30 Nov 2010 14:18:37 +0100 (CET)
>> From: Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org>
>> To: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Subject: Re: Can't mount Windows DFS root using NTLMv2
>>
>> Hi Shirish,
>>
>> On Mon, 29 Nov 2010, Shirish Pargaonkar wrote:
>>
>>> Robert, does sec=ntlmssp without  dom=sox helps?
>>> A wireshark trace when you issue mount command would be useful.
>>
>> With or wihout dom=sox does not make a difference.
>>
>> Here is an overview of what I tested:
>>
>>                2003sp2         2008r2 (+DFS)   2008 (+DFS)
>> NTLM            (1)             OK              OK
>> NTLMv2          (1)             (2)             (2)
>> NTLMSSP         (3)             (3)             (3)
>>
>>
>> 1 = Fails with "Required key not available"
>> 2 = Fails with "NT_STATUS_INVALID_PARAMETER"
>> 3 = Fails with "NT_STATUS_NOT_SUPPORTED"
>>
>> I will send you some detailed logs and pcaps off-list.
>>
>> Regards,
>> Robbert
>
> This is strange wrt ntlmssp.  In negotiate protocol response, server
> does state NTLMSSP as one of the mechanism types.
> It must be related to bits in flag2 that that client sends in type 1 ntlmssp
> session setup that server eitther expects from client but is missing or
> does not support/like one of the flags2 bits.
> Is 10.0.0.7 a box that runs cifs client?
>
> ntlmv2 is not going to work as it is against Windows 2008, it will return
> invalid parameter error.
> Jeff Layton had pointed to this which you can try (I have not tried it yet)
>  http://support.microsoft.com/kb/957441/en-us
>

I think more than fields flags and flags2 in the smb header, it could be
something to do with flags field in ntlmssp_negotiate (type 1) packet
sent by the cifs client to Windows server that server does not support.
But then server would return the flags it supports in ntlmssp_challenge
(type 2) response instead of returning an error.
So it is perhaps something else that is not supported by the server.

I just mounted a share using sec=ntlmssp from a Windows 2008 server.
The flags field in ntlmssp_negotiate request from client has same exact
value that is in the file 3.pcap capture (0xa0000205), entire
ntlmssp_negotiate request in both the cases is same yet it fails in
your installation and it succeeds at the installation I have.

It would be useful to compare with the ntlmssp_negotiate packet that a
Windows client sends to this Windows server.
And something could be logged in Event Logger on the Windows server.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]         ` <AANLkTi=c11fiqZkOkdrdNB6KbsDLV4XSfmPjE3_SScOj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2010-11-30 16:59           ` Shirish Pargaonkar
  2010-11-30 17:04             ` Robbert Kouprie
  0 siblings, 1 reply; 14+ messages in thread
From: Shirish Pargaonkar @ 2010-11-30 16:59 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, Nov 30, 2010 at 10:38 AM, Shirish Pargaonkar
<shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Nov 30, 2010 at 9:45 AM, Shirish Pargaonkar
> <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Tue, Nov 30, 2010 at 7:35 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
>>> Hi Shirish,
>>>
>>> Find attached some detailed problem info and pcaps on the different failing
>>> scenario's.
>>>
>>> Please note our setup is not standard, as we're using a BIND DNS server, and
>>> we have a mix of 3 DC's where only 2 are DFS root.
>>>
>>> Do note however that Windows clients do not have any problem with this
>>> setup.
>>>
>>> If I can be of more help/need to test something, please let me know.
>>>
>>> Thanks!
>>> --
>>> Robbert
>>>
>>> ---------- Forwarded message ----------
>>> Date: Tue, 30 Nov 2010 14:18:37 +0100 (CET)
>>> From: Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org>
>>> To: Shirish Pargaonkar <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Subject: Re: Can't mount Windows DFS root using NTLMv2
>>>
>>> Hi Shirish,
>>>
>>> On Mon, 29 Nov 2010, Shirish Pargaonkar wrote:
>>>
>>>> Robert, does sec=ntlmssp without  dom=sox helps?
>>>> A wireshark trace when you issue mount command would be useful.
>>>
>>> With or wihout dom=sox does not make a difference.
>>>
>>> Here is an overview of what I tested:
>>>
>>>                2003sp2         2008r2 (+DFS)   2008 (+DFS)
>>> NTLM            (1)             OK              OK
>>> NTLMv2          (1)             (2)             (2)
>>> NTLMSSP         (3)             (3)             (3)
>>>
>>>
>>> 1 = Fails with "Required key not available"
>>> 2 = Fails with "NT_STATUS_INVALID_PARAMETER"
>>> 3 = Fails with "NT_STATUS_NOT_SUPPORTED"
>>>
>>> I will send you some detailed logs and pcaps off-list.
>>>
>>> Regards,
>>> Robbert
>>
>> This is strange wrt ntlmssp.  In negotiate protocol response, server
>> does state NTLMSSP as one of the mechanism types.
>> It must be related to bits in flag2 that that client sends in type 1 ntlmssp
>> session setup that server eitther expects from client but is missing or
>> does not support/like one of the flags2 bits.
>> Is 10.0.0.7 a box that runs cifs client?
>>
>> ntlmv2 is not going to work as it is against Windows 2008, it will return
>> invalid parameter error.
>> Jeff Layton had pointed to this which you can try (I have not tried it yet)
>>  http://support.microsoft.com/kb/957441/en-us
>>
>
> I think more than fields flags and flags2 in the smb header, it could be
> something to do with flags field in ntlmssp_negotiate (type 1) packet
> sent by the cifs client to Windows server that server does not support.
> But then server would return the flags it supports in ntlmssp_challenge
> (type 2) response instead of returning an error.
> So it is perhaps something else that is not supported by the server.
>
> I just mounted a share using sec=ntlmssp from a Windows 2008 server.
> The flags field in ntlmssp_negotiate request from client has same exact
> value that is in the file 3.pcap capture (0xa0000205), entire
> ntlmssp_negotiate request in both the cases is same yet it fails in
> your installation and it succeeds at the installation I have.
>
> It would be useful to compare with the ntlmssp_negotiate packet that a
> Windows client sends to this Windows server.
> And something could be logged in Event Logger on the Windows server.
>

security blob in ntlmssp negotiate request between what cifs client sends
and what Windows client sends is little different.
cifs client does not encode OIDs for SPNEGO and NTLMSSP mech type
in the request. That could be a cause of error at the setup you have but at
the setup I have, Windows 2008 server seems to be OK with it.

I can make that change, encode them using asn.1 and see if that helps.
But meanwhile  if even logger is flagging anything, that would be
useful to know.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]     ` <AANLkTinHDfxNhKLSEwHtH7oM+EUCj_HB97Ch-9RQXjTj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2010-11-30 16:38       ` Shirish Pargaonkar
@ 2010-11-30 17:00       ` Robbert Kouprie
       [not found]         ` <alpine.DEB.2.00.1011301739010.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
  1 sibling, 1 reply; 14+ messages in thread
From: Robbert Kouprie @ 2010-11-30 17:00 UTC (permalink / raw)
  To: Shirish Pargaonkar; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1878 bytes --]

Hi Shirish,

On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:

> On Tue, Nov 30, 2010 at 7:35 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
>>
>> Here is an overview of what I tested:
>>
>>           2         )   2008 (+DF   2008 (+DFS)
>> NTLM        (1)      OK                 OK
>> NTLMv2      (1)      (2)                (2)
>> NTLMSSP     (3)      (3)                (3)
>>
>> 1 = Fails with "Required key not available"
>> 2 = Fails with "NT_STATUS_INVALID_PARAMETER"
>> 3 = Fails with "NT_STATUS_NOT_SUPPORTED"
>>
>> I will send you some detailed logs and pcaps off-list.
>>
>> Regards,
>> Robbert
>
> This is strange wrt ntlmssp.  In negotiate protocol response, server
> does state NTLMSSP as one of the mechanism types.
> It must be related to bits in flag2 that that client sends in type 1 ntlmssp
> session setup that server eitther expects from client but is missing or
> does not support/like one of the flags2 bits.
> Is 10.0.0.7 a box that runs cifs client?

Yes, 10.0.0.7 is an Debian box with vanilla 2.6.37-rc3 kernel and 
mount.cifs 4.5.

> ntlmv2 is not going to work as it is against Windows 2008, it will return
> invalid parameter error.
> Jeff Layton had pointed to this which you can try (I have not tried it yet)
> http://support.microsoft.com/kb/957441/en-us

Ok, this registry fix indeed fixes mount.cifs sec=ntlmv2 auth on 
both my 2008 and 2008R2 DC's.

So, now I have:

           2003sp2   2008r2 (+DFS)   2008 (+DFS)
NTLM        (1)      OK                 OK
NTLMv2      (1)      OK(2)              OK(2)
NTLMSSP     (3)      (3)                (3)

  1 = Fails with "Required key not available"
  2 = Works after applying KB957441 regfix on DC's
  3 = Fails with "NT_STATUS_NOT_SUPPORTED"

Do you also have an idea on (1), the resolving problem?

Best regards,
Robbert

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
  2010-11-30 16:59           ` Shirish Pargaonkar
@ 2010-11-30 17:04             ` Robbert Kouprie
  0 siblings, 0 replies; 14+ messages in thread
From: Robbert Kouprie @ 2010-11-30 17:04 UTC (permalink / raw)
  To: Shirish Pargaonkar; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:

> security blob in ntlmssp negotiate request between what cifs client sends
> and what Windows client sends is little different.
> cifs client does not encode OIDs for SPNEGO and NTLMSSP mech type
> in the request. That could be a cause of error at the setup you have but at
> the setup I have, Windows 2008 server seems to be OK with it.
>
> I can make that change, encode them using asn.1 and see if that helps.
> But meanwhile  if even logger is flagging anything, that would be
> useful to know.

I'm really hard trying to follow you here, but not sure I am :)

But anyway, if you would like me to test a patch, I'd be happy to.

Regards,
Robbert

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]         ` <alpine.DEB.2.00.1011301739010.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
@ 2010-11-30 17:04           ` Shirish Pargaonkar
       [not found]             ` <AANLkTinwtjkL_Exr57wDjRiKQTzVFwjuv=kBOw7s5mgS-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Shirish Pargaonkar @ 2010-11-30 17:04 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, Nov 30, 2010 at 11:00 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
> Hi Shirish,
>
> On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:
>
>> On Tue, Nov 30, 2010 at 7:35 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
>>>
>>> Here is an overview of what I tested:
>>>
>>>          2         )   2008 (+DF   2008 (+DFS)
>>> NTLM        (1)      OK                 OK
>>> NTLMv2      (1)      (2)                (2)
>>> NTLMSSP     (3)      (3)                (3)
>>>
>>> 1 = Fails with "Required key not available"
>>> 2 = Fails with "NT_STATUS_INVALID_PARAMETER"
>>> 3 = Fails with "NT_STATUS_NOT_SUPPORTED"
>>>
>>> I will send you some detailed logs and pcaps off-list.
>>>
>>> Regards,
>>> Robbert
>>
>> This is strange wrt ntlmssp.  In negotiate protocol response, server
>> does state NTLMSSP as one of the mechanism types.
>> It must be related to bits in flag2 that that client sends in type 1
>> ntlmssp
>> session setup that server eitther expects from client but is missing or
>> does not support/like one of the flags2 bits.
>> Is 10.0.0.7 a box that runs cifs client?
>
> Yes, 10.0.0.7 is an Debian box with vanilla 2.6.37-rc3 kernel and mount.cifs
> 4.5.
>
>> ntlmv2 is not going to work as it is against Windows 2008, it will return
>> invalid parameter error.
>> Jeff Layton had pointed to this which you can try (I have not tried it
>> yet)
>> http://support.microsoft.com/kb/957441/en-us
>
> Ok, this registry fix indeed fixes mount.cifs sec=ntlmv2 auth on both my
> 2008 and 2008R2 DC's.
>
> So, now I have:
>
>          2003sp2   2008r2 (+DFS)   2008 (+DFS)
> NTLM        (1)      OK                 OK
> NTLMv2      (1)      OK(2)              OK(2)
> NTLMSSP     (3)      (3)                (3)
>
>  1 = Fails with "Required key not available"
>  2 = Works after applying KB957441 regfix on DC's
>  3 = Fails with "NT_STATUS_NOT_SUPPORTED"
>
> Do you also have an idea on (1), the resolving problem?
>
> Best regards,
> Robbert

That is good to know.  Thanks Jeff.

Robbert, did you send me a wireshark trace with that error?
I do not see that error in any of the trace files you sent.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]             ` <AANLkTinwtjkL_Exr57wDjRiKQTzVFwjuv=kBOw7s5mgS-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2010-11-30 17:11               ` Robbert Kouprie
       [not found]                 ` <alpine.DEB.2.00.1011301809050.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Robbert Kouprie @ 2010-11-30 17:11 UTC (permalink / raw)
  To: Shirish Pargaonkar; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

Hi,

>> Do you also have an idea on (1), the resolving problem?
>>
>
> Robbert, did you send me a wireshark trace with that error?
> I do not see that error in any of the trace files you sent.

The trace is in 1.pcap. It is also the first log exempt in the text file I 
sent you.

First, a "NT_STATUS_PATH_NOT_COVERED" (which is in the trace), and after 
this resolving is tried.

Regards,
Robbert

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]                 ` <alpine.DEB.2.00.1011301809050.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
@ 2010-11-30 17:20                   ` Shirish Pargaonkar
       [not found]                     ` <AANLkTin3-k4AJRYvL4p8VQqvnnL5mLJJZXNf5mC1RBKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Shirish Pargaonkar @ 2010-11-30 17:20 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, Nov 30, 2010 at 11:11 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
> Hi,
>
>>> Do you also have an idea on (1), the resolving problem?
>>>
>>
>> Robbert, did you send me a wireshark trace with that error?
>> I do not see that error in any of the trace files you sent.
>
> The trace is in 1.pcap. It is also the first log exempt in the text file I
> sent you.
>
> First, a "NT_STATUS_PATH_NOT_COVERED" (which is in the trace), and after
> this resolving is tried.
>
> Regards,
> Robbert
>

Robbert, I do not think this error has anything to do with the authentication.
This error in response to a Tree Connect request seems related to MS-DFS
implementations on Windows 2003 server and on Windows 2008 servers.
I think you would see this error with sec=ntlmssp also (if that auth
mech was working).

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]                     ` <AANLkTin3-k4AJRYvL4p8VQqvnnL5mLJJZXNf5mC1RBKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2010-11-30 17:31                       ` Robbert Kouprie
       [not found]                         ` <alpine.DEB.2.00.1011301827580.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Robbert Kouprie @ 2010-11-30 17:31 UTC (permalink / raw)
  To: Shirish Pargaonkar; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:

> Robbert, I do not think this error has anything to do with the authentication.
> This error in response to a Tree Connect request seems related to MS-DFS
> implementations on Windows 2003 server and on Windows 2008 servers.
> I think you would see this error with sec=ntlmssp also (if that auth
> mech was working).

I agree with you that this is a different problem, probably not 
authentication related.

But it is still a problem, because the mount fails. So there 
seems to be a mount.cifs problem resolving the DFS target.

Remember, Windows clients are able to connect correctly to this share.

Regards,
Robbert

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]                         ` <alpine.DEB.2.00.1011301827580.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
@ 2010-11-30 17:44                           ` Shirish Pargaonkar
       [not found]                             ` <AANLkTinneo5HQxeOoCKVXyBZ2_i0AYWj9gqauBWoVAhn-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Shirish Pargaonkar @ 2010-11-30 17:44 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, Nov 30, 2010 at 11:31 AM, Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
> On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:
>
>> Robbert, I do not think this error has anything to do with the
>> authentication.
>> This error in response to a Tree Connect request seems related to MS-DFS
>> implementations on Windows 2003 server and on Windows 2008 servers.
>> I think you would see this error with sec=ntlmssp also (if that auth
>> mech was working).
>
> I agree with you that this is a different problem, probably not
> authentication related.
>
> But it is still a problem, because the mount fails. So there seems to be a
> mount.cifs problem resolving the DFS target.
>
> Remember, Windows clients are able to connect correctly to this share.
>
> Regards,
> Robbert
>

Wondering why the very same cifs client does not encounter this error against
a Windows 2008 server but does against a Windows 2003 server!
Perhaps a Windows client also runs into this error against a Windows 2003 server
but does handle/resolve it.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]                             ` <AANLkTinneo5HQxeOoCKVXyBZ2_i0AYWj9gqauBWoVAhn-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2010-11-30 17:56                               ` Robbert Kouprie
       [not found]                                 ` <alpine.DEB.2.00.1011301852040.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Robbert Kouprie @ 2010-11-30 17:56 UTC (permalink / raw)
  To: Shirish Pargaonkar; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:

> Wondering why the very same cifs client does not encounter this error against
> a Windows 2008 server but does against a Windows 2003 server!
> Perhaps a Windows client also runs into this error against a Windows 2003 server
> but does handle/resolve it.

Well from the kernel logs, it looks like the kernel does try to handle 
it, but fails when trying to resolve a servername that still has part of 
the share name attached to it.

Look:

  fs/cifs/cifssmb.c: Decoding GetDFSRefer response BCC: 261  Offset 56
  fs/cifs/cifssmb.c: num_referrals: 2 dfs flags: 0x3 ...
  cifs.upcall: key description: dns_resolver;0;0;3f000000;FOXDFT13\C
  cifs.upcall: unable to resolve hostname: FOXDFT13\C [Name or service not known]
  kernel: [94358.873289] CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: FOXDFT13\C
  CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of 
\\FOXDFT13\Company to IP: -126

The full server + share name is "FOXDFT13\Company". It should just resolve 
the server name "FOXDFT13", and not leave the "\C" attached to it.

Regards,
Robbert

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]                                 ` <alpine.DEB.2.00.1011301852040.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
@ 2010-11-30 19:37                                   ` Jeff Layton
       [not found]                                     ` <20101130143747.1fabcc37-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Jeff Layton @ 2010-11-30 19:37 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: Shirish Pargaonkar, linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, 30 Nov 2010 18:56:49 +0100 (CET)
Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:

> On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:
> 
> > Wondering why the very same cifs client does not encounter this error against
> > a Windows 2008 server but does against a Windows 2003 server!
> > Perhaps a Windows client also runs into this error against a Windows 2003 server
> > but does handle/resolve it.
> 
> Well from the kernel logs, it looks like the kernel does try to handle 
> it, but fails when trying to resolve a servername that still has part of 
> the share name attached to it.
> 
> Look:
> 
>   fs/cifs/cifssmb.c: Decoding GetDFSRefer response BCC: 261  Offset 56
>   fs/cifs/cifssmb.c: num_referrals: 2 dfs flags: 0x3 ...
>   cifs.upcall: key description: dns_resolver;0;0;3f000000;FOXDFT13\C
>   cifs.upcall: unable to resolve hostname: FOXDFT13\C [Name or service not known]
>   kernel: [94358.873289] CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: FOXDFT13\C
>   CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of 
> \\FOXDFT13\Company to IP: -126
> 
> The full server + share name is "FOXDFT13\Company". It should just resolve 
> the server name "FOXDFT13", and not leave the "\C" attached to it.
> 

I can reproduce this too. Looks like a recent regression, but I don't
see what broke it right offhand. 

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]                                     ` <20101130143747.1fabcc37-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
@ 2010-11-30 19:56                                       ` Jeff Layton
       [not found]                                         ` <20101130145608.59840ea1-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Jeff Layton @ 2010-11-30 19:56 UTC (permalink / raw)
  To: Robbert Kouprie; +Cc: Shirish Pargaonkar, linux-cifs-u79uwXL29TY76Z2rM5mHXA

On Tue, 30 Nov 2010 14:37:47 -0500
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> On Tue, 30 Nov 2010 18:56:49 +0100 (CET)
> Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
> 
> > On Tue, 30 Nov 2010, Shirish Pargaonkar wrote:
> > 
> > > Wondering why the very same cifs client does not encounter this error against
> > > a Windows 2008 server but does against a Windows 2003 server!
> > > Perhaps a Windows client also runs into this error against a Windows 2003 server
> > > but does handle/resolve it.
> > 
> > Well from the kernel logs, it looks like the kernel does try to handle 
> > it, but fails when trying to resolve a servername that still has part of 
> > the share name attached to it.
> > 
> > Look:
> > 
> >   fs/cifs/cifssmb.c: Decoding GetDFSRefer response BCC: 261  Offset 56
> >   fs/cifs/cifssmb.c: num_referrals: 2 dfs flags: 0x3 ...
> >   cifs.upcall: key description: dns_resolver;0;0;3f000000;FOXDFT13\C
> >   cifs.upcall: unable to resolve hostname: FOXDFT13\C [Name or service not known]
> >   kernel: [94358.873289] CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: FOXDFT13\C
> >   CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of 
> > \\FOXDFT13\Company to IP: -126
> > 
> > The full server + share name is "FOXDFT13\Company". It should just resolve 
> > the server name "FOXDFT13", and not leave the "\C" attached to it.
> > 
> 
> I can reproduce this too. Looks like a recent regression, but I don't
> see what broke it right offhand. 
> 

I think I found it. Does this patch fix it for you?

--------------------------[snip]----------------------------

[PATCH] cifs: fix parsing of hostname in dfs referrals

The DFS referral parsing code does a memchr() call to find the '\\'
delimiter that separates the hostname in the referral UNC from the
sharename. It then uses that value to set the length of the hostname via
pointer subtraction.  Instead of subtracting the start of the hostname
however, it subtracts the start of the UNC, which causes the code to
pass in a hostname length that is 2 bytes too long.

Regression introduced in commit 1a4240f4.

Reported-by: Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org>
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Wang Lei <wang840925-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
---
 fs/cifs/dns_resolve.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/dns_resolve.c b/fs/cifs/dns_resolve.c
index 0eb8702..548f062 100644
--- a/fs/cifs/dns_resolve.c
+++ b/fs/cifs/dns_resolve.c
@@ -66,7 +66,7 @@ dns_resolve_server_name_to_ip(const char *unc, char **ip_addr)
 	/* Search for server name delimiter */
 	sep = memchr(hostname, '\\', len);
 	if (sep)
-		len = sep - unc;
+		len = sep - hostname;
 	else
 		cFYI(1, "%s: probably server name is whole unc: %s",
 		     __func__, unc);
-- 
1.7.3.2



-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: Can't mount Windows DFS root using NTLMv2 (fwd)
       [not found]                                         ` <20101130145608.59840ea1-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
@ 2010-11-30 20:08                                           ` Robbert Kouprie
  0 siblings, 0 replies; 14+ messages in thread
From: Robbert Kouprie @ 2010-11-30 20:08 UTC (permalink / raw)
  To: Jeff Layton; +Cc: Shirish Pargaonkar, linux-cifs-u79uwXL29TY76Z2rM5mHXA

Hi Jeff,

Op 30-11-2010 20:56, Jeff Layton schreef:
> 
> I think I found it. Does this patch fix it for you?
> 
> --------------------------[snip]----------------------------
> 
> [PATCH] cifs: fix parsing of hostname in dfs referrals

Yep, verified fixed with sec=ntlm as well as sec=ntlmv2.

Thanks!

BTW, I will follow up with another bugreport concerning DFS of the bug I
was *originally* chasing before this got in the way ;)

Regards,
Robbert

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2010-11-30 20:08 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <alpine.DEB.2.00.1011301428530.15277@awakenings.cable.ziggo.nl>
     [not found] ` <alpine.DEB.2.00.1011301428530.15277-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
2010-11-30 15:45   ` Can't mount Windows DFS root using NTLMv2 (fwd) Shirish Pargaonkar
     [not found]     ` <AANLkTinHDfxNhKLSEwHtH7oM+EUCj_HB97Ch-9RQXjTj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-11-30 16:38       ` Shirish Pargaonkar
     [not found]         ` <AANLkTi=c11fiqZkOkdrdNB6KbsDLV4XSfmPjE3_SScOj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-11-30 16:59           ` Shirish Pargaonkar
2010-11-30 17:04             ` Robbert Kouprie
2010-11-30 17:00       ` Robbert Kouprie
     [not found]         ` <alpine.DEB.2.00.1011301739010.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
2010-11-30 17:04           ` Shirish Pargaonkar
     [not found]             ` <AANLkTinwtjkL_Exr57wDjRiKQTzVFwjuv=kBOw7s5mgS-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-11-30 17:11               ` Robbert Kouprie
     [not found]                 ` <alpine.DEB.2.00.1011301809050.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
2010-11-30 17:20                   ` Shirish Pargaonkar
     [not found]                     ` <AANLkTin3-k4AJRYvL4p8VQqvnnL5mLJJZXNf5mC1RBKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-11-30 17:31                       ` Robbert Kouprie
     [not found]                         ` <alpine.DEB.2.00.1011301827580.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
2010-11-30 17:44                           ` Shirish Pargaonkar
     [not found]                             ` <AANLkTinneo5HQxeOoCKVXyBZ2_i0AYWj9gqauBWoVAhn-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-11-30 17:56                               ` Robbert Kouprie
     [not found]                                 ` <alpine.DEB.2.00.1011301852040.31075-56sTcPfcKMhJlCS1zhbguEjk2N/pv5CcZkel5v8DVj8@public.gmane.org>
2010-11-30 19:37                                   ` Jeff Layton
     [not found]                                     ` <20101130143747.1fabcc37-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2010-11-30 19:56                                       ` Jeff Layton
     [not found]                                         ` <20101130145608.59840ea1-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2010-11-30 20:08                                           ` Robbert Kouprie

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.