[cifs-protocol] [REG:111051779565831] RE: dfs referral for sysvol and windows XP

[Hongwei Sun]

Matthieu,

  I will update you Monday or Tuesday.

Thanks!

Hongwei

-----Original Message-----
From: Matthieu Patou [mailto:mat at matws.net] 
Sent: Friday, June 17, 2011 1:50 PM
To: cifs-protocol at cifs.org; Hongwei Sun; pfif at tridgell.net; MSSolve Case Email
Subject: Re: [cifs-protocol] [REG:111051779565831] RE: dfs referral for sysvol and windows XP

Hello Hongwei,
Any news on this ?

Matthieu.
On 08/06/2011 11:22, Matthieu Patou wrote:
> On 08/06/2011 02:01, Hongwei Sun wrote:
>> Matthieu,
>>
>>    I confirmed that there is a problem with the Netmon parser when 
>> displaying ReferralEntryFlag.  The ReferralEntryFlags should be in 
>> little endian.  In the packet, it should be parsed as 0x0004 that has 
>> TargetSetBoundary bit set for the first entry.  So this is not the
>> problem.   I will file a Netmon parser bug for that.
> Ok good !
>>
>>    After looking further at the traces (XP to Samba and XP to Windows 
>> server 2008R2), I think that the DFS referral v4 returned by Samba 
>> doesn't seem to have any problem.  The only differences between two 
>> responses are if the DFSPath and DFSAlternativePath are shared
>> between ReferralEntries.      This should not be the problem if  the 
>> correct offsets are used.   The details are shown as below:
>>
>>    Response from Samba:
>>
>>       DfsPath: Index:1 \w2k8r2.home.matws.net\sysvol
>>       DfsAlternatePath: Index:1 \w2k8r2.home.matws.net\sysvol
>>       TargetPath: Index:1 \s2-w2k8r2.w2k8r2.home.matws.net\sysvol
>>       DfsPath: Index:2 \w2k8r2.home.matws.net\sysvol
>>       DfsAlternatePath: Index:2 \w2k8r2.home.matws.net\sysvol
>>       TargetPath: Index:2 \ares.w2k8r2.home.matws.net\sysvol
>>
>> Response from Windows:
>>
>>       DfsPath: \w2k8r2.home.matws.net\sysvol
>>       DfsAlternatePath: \w2k8r2.home.matws.net\sysvol
>>       TargetPath: Index:1 \s2-w2k8r2.w2k8r2.home.matws.net\sysvol
>>       TargetPath: Index:2 \ares.w2k8r2.home.matws.net\sysvol
> Yeah I noticed this before, it's a limitation in our IDL compiler at 
> the moment and it's uneasy to fix, but as far as I understand it's 
> should be so much of a problem as the structure of the packet is 
> correct (offset are correctly pointing to paths).
>
>>     It seems  that  XP client did  process  the DFS Referral Response 
>> v4 from Samba server correctly.   The following is the analysis of 
>> the events.
>>
>>       Packet  339    XP      ARES      DFSC    DFSC:Get DFS Referral 
>> Request, FileName: \w2k8r2.home.matws.net\sysvol, MaxReferralLevel: 4
>>       Packet   340    ARES      XP      DFSC    DFSC:Get DFS Referral 
>> Response, NumberOfReferrals: 2 VersionNumber: 4
>>
>>                     Two  TargetPaths returned :  
>> \s2-w2k8r2.w2k8r2.home.matws.net\sysvol,   
>> \ares.w2k8r2.home.matws.net\sysvol
>>
>>      Packet  345    XP      ARES      DNS    DNS:QueryId = 0xB8C8, 
>> QUERY (Standard query), Query  for s2-w2k8r2.w2k8r2.home.matws.net
>>      Packet  346    ARES      XP      DNS    DNS:QueryId = 0xB8C8, 
>> QUERY (Standard query), Response - Success, 172.16.100.27
>>       Packet 442    ARES      XP      ICMP    ICMP:Destination 
>> Unreachable Message, Host Unreachable, 172.16.100.27
>>
>>                             The client goes to the first target 
>> (s2-w2k8r2.w2k8r2.home.matws.net), but it is not reachable.   Why 
>> was  s2-w2k8r2.w2k8r2.home.matws.net not accessible ?  Was this 
>> intended because you were testing the DFS target failover ?
> Well I tried to check that XP is a happy with samba4 as well as I 
> expect him to be ok with Windows 2008R2.
>>     Packet 634    XP      ARES      ICMP    ICMP:Echo Request 
>> Message, From 172.16.101.16 To 172.16.101.1
>>     Packet 657    XP      ARES      KerberosV5    KerberosV5:TGS 
>> Request Realm: W2K8R2.HOME.MATWS.NET Sname: 
>> cifs/ares.w2k8r2.home.matws.net
>>     Packet 659    ARES      XP      KerberosV5    KerberosV5:TGS 
>> Response Cname: Administrator
>>     Packet 668    XP      ARES      SMB    SMB:C; Tree Connect Andx, 
>> Path = \\ARES.W2K8R2.HOME.MATWS.NET\SYSVOL, Service = ?????
>>
>>                           The client fails over to the second target
>> (ares.w2k8r2.home.matws.net) and use the Kerberos to do session setup.
>>
>>      It seems to me that when it fell back to NTLM, it was trying to 
>> access IPC$ for srvsrc service, not to access SYSVOL or NETLOGON. I
>> don't see this in the trace between Windows.   I am not sure if it is 
>> related to the DFS Referral Response v4.
> The thing is that XP is very slow with DFS referral response v4, and 
> not only the first call (as you might expect with the first call as it 
> is testing first the s2-w2k8r2 server). With a DFS referral response
> v3 it's very quick and responsive.
>
> Also I noticed that most of the time XP comes to Windows server with 
> level 3 request and not a level 4, is there anything in Windows server 
> that trigger this behavior ?.
>
> Matthieu.
>
>