The Samba-Bugzilla – Bug 5106
call_trans2qfilepathinfo - resolve_dfspath without FLAGS2_DFS_PATHNAMES
Last modified: 2013-02-19 15:39:43 UTC
Samba 3.0.27a (with some custom patches)
This issue causes the following command from Windows XP SP-2 - automatic patches:
net use u: \\192.168.31.191\ddaugher /USER:ddaugher
to fail. ddaugher is an smbpasswd account.
I think this has resurfaced because of some recent tighting up of DFS code.
I have a windows XP that is sending Trans2 QUERY_PATH_INFO - basic Info
path = \192.168.31.191\ddaugher
... but FLAGS2_DFS_PATHNAMES is NOT set!
So smbd/trans2.c: call_trans2qfilepathinfo line 3267
status = resolve_dfspath(conn, SVAL(inbuf,smb_flg2) & FLAGS2_DFS_PATHNAMES, fname);
Does nothing to the path, leading up to the failure.
Previous versions of Samba used to call resolve_dfspath() without checking the FLAGS2_DFS_PATHNAMESDFS. Forcing the second parameter to True - and ignoring any possible error works around the problem - it causes and empty path to be returned - same behavior as Samba 3.0.23b.
I have wireshark traces and can get a log if these would be helpful. Where should I put them?
Created attachment 3001 [details]
wireshark trace of failure.
Created attachment 3002 [details]
log of it working AFTER force dfs_path to ignore DFS_PATHNAMES flag
Is this reproducible with every version of WinXP with this patch set ? Or is it specific to one client ? That client is never setting the DFS bit in its packets.
Have you tried rebooting it ? I really don't want to force us through DFS code on every request if I don't have to. More info please....
Created attachment 3003 [details]
wireshark trace - connect by name instead of ID Addr
In this trace - its a different Samba, but the QueryPathInfo does have the DFS_PATHNAMES flag set. Do you suppose this is because a host name rather than IP address was used?
The command was net use \\dumpty\ddaugher /USER:ddaugher
Created attachment 3004 [details]
Stock samba 3.0.24
Here is another trace where stock samba 3.0.24 was used - by ipaddr
This one is slightly different in that the query path info did not supply a path! I don't know why that is
net use \\192.168.1.161\ddaugher /USER:ddaugher
or maybe it was
net use \\192.168.1.161\ddaugher
and I was prompted for the name and password?
Re Comment #3
1. I have only been testing with one winxp client, but it used to work consistantly - literally for years - until I upgraded to 3.0.27a.
The best I have right now is that it seems as though using the host name instead of the IP address influences if the DFS_PATHNAMES bit gets set or not for that QUERY PATH INFO call.
I haven't seen that before - but I'll have to wait until I'm in at work tomorrow to get my full test env available with multiple windows clients. I'm bet money this is a client caching the wrong info on a server though.
Created attachment 3005 [details]
Trace against same samba server by name instead of IP Address
This morning after a clean reboot of the windows XP machine
net use v: \\192.168.31.191\ddaugher
still behaves the same as last night's trace
So add to XP's \windows\system32\drivers\etc\hosts file:
net use v: /d
net use v: \\dd-rhes3\ddaugher
Sigh! Now the windows XP box still does not set the DFS path bit, but it no longer sends a path with the Query Path Info:
I can't explain it.
If you know of caches to flush on the XP side, I will be happy to flush.
windows xp doesn't set the FLAGS2_DFS_PATHNAMESDFS when it talks to a server that is kerberized. If you use security=domain and winbind rpc only=yes then XP sets the FLAGS2_DFS_PATHNAMESDFS again.
This is a Windows XP bug most probably.
Maybe your samba version you used before jsut didn't use kerberos.