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.
--
Matthieu Patou
Samba Team http://samba.org
Private repo http://git.samba.org/?p=mat/samba.git;a=summary
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
