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.... Jeremy.
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. Jeremy.
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: 192.168.31.191 dd-rhes3 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.