Bug 5106 - call_trans2qfilepathinfo - resolve_dfspath without FLAGS2_DFS_PATHNAMES
call_trans2qfilepathinfo - resolve_dfspath without FLAGS2_DFS_PATHNAMES
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.9
Other Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-25 18:19 UTC by David Daugherty
Modified: 2013-02-19 15:39 UTC (History)
1 user (show)

See Also:


Attachments
wireshark trace of failure. (172.07 KB, application/octet-stream)
2007-11-25 18:23 UTC, David Daugherty
no flags Details
log of it working AFTER force dfs_path to ignore DFS_PATHNAMES flag (491.33 KB, application/octet-stream)
2007-11-25 18:29 UTC, David Daugherty
no flags Details
wireshark trace - connect by name instead of ID Addr (21.89 KB, application/octet-stream)
2007-11-25 19:41 UTC, David Daugherty
no flags Details
Stock samba 3.0.24 (27.15 KB, application/octet-stream)
2007-11-25 19:43 UTC, David Daugherty
no flags Details
Trace against same samba server by name instead of IP Address (34.68 KB, application/octet-stream)
2007-11-26 12:49 UTC, David Daugherty
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Daugherty 2007-11-25 18:19:38 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?
Comment 1 David Daugherty 2007-11-25 18:23:42 UTC
Created attachment 3001 [details]
wireshark trace of failure.
Comment 2 David Daugherty 2007-11-25 18:29:16 UTC
Created attachment 3002 [details]
log of it working AFTER force dfs_path to ignore DFS_PATHNAMES flag
Comment 3 Jeremy Allison 2007-11-25 19:15:25 UTC
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.
Comment 4 David Daugherty 2007-11-25 19:41:23 UTC
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
Comment 5 David Daugherty 2007-11-25 19:43:32 UTC
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?
Comment 6 David Daugherty 2007-11-25 19:46:53 UTC
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.
Comment 7 Jeremy Allison 2007-11-25 20:03:03 UTC
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.
Comment 8 David Daugherty 2007-11-26 12:49:52 UTC
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.
Comment 9 Björn Jacke 2013-02-19 15:39:43 UTC
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.