Bug 3814 - subdirectory listing is duplicate of parent directory. cli3.0.22 server wrtsl54gs
subdirectory listing is duplicate of parent directory. cli3.0.22 server wrtsl...
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient
3.0.22
Other Other
: P3 major
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-30 09:33 UTC by Joakim Plate
Modified: 2006-06-22 14:59 UTC (History)
0 users

See Also:


Attachments
Full log 3.0.4 working (473.86 KB, text/plain)
2006-05-30 09:34 UTC, Joakim Plate
no flags Details
Full log 3.0.22 failing (335.70 KB, text/plain)
2006-05-30 09:34 UTC, Joakim Plate
no flags Details
Clean log 3.0.4 working (28.76 KB, text/plain)
2006-05-30 09:35 UTC, Joakim Plate
no flags Details
Clean log 3.0.22 working (35.56 KB, text/plain)
2006-05-30 09:35 UTC, Joakim Plate
no flags Details
pcap of failed listing if folder _ADULT in share MOVIES (157.51 KB, text/plain)
2006-06-05 16:17 UTC, Joakim Plate
no flags Details
pcap of old working listing of folder _ADULT in share MOVIES (44.98 KB, text/plain)
2006-06-05 16:17 UTC, Joakim Plate
no flags Details
pcap of failed listing of folder _ADULT in share MOVIES (157.51 KB, application/octet-stream)
2006-06-05 16:19 UTC, Joakim Plate
no flags Details
pcap of old working listing of folder _ADULT in share MOVIES (44.98 KB, application/octet-stream)
2006-06-05 16:19 UTC, Joakim Plate
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joakim Plate 2006-05-30 09:33:10 UTC
Hi, 

This is an issue that poped up after we upgraded to samba 3.0.22. It affects users of lan drives like linksys wich is using an old samba version ( think it is 3.0.2 ).

When listing files in root of a share, things work as expected. When entering a subdirectory of said share, the root share listing is once again returned. (you can even going into same subdir again and it keeps repeating.)

smb://WRTSL54GS/Music/test
or
smb://WRTSL54GS/Music/test/test/test....
gets identical listing as the file listing for the root share.
smb://WRTSL54GS/Music

I've attached 2 sets of logs, where identical (with minor exceptions) steps have been taken using libsmbclient 3.0.4 and 3.0.22. 3.0.4 gets correct listing back, 3.0.22 does not.

Full and original logs (rather huge)
samba-repeatlisting.3.0.4.txt
samba-repeatlisting.3.0.22.txt


Cleaned logs (parts snipped out that has little relevance) commented with <snip lines-x-y>
samba-repeatlisting-clean.3.0.4.txt
samba-repeatlisting-clean.3.0.22.txt

The cleaned logs can be diffed using some diff viewer to spot changes.
one thing to keep in mind thou is that the .22 version initially connects
with a username that fails, then falls back to anon wich works. that 
isn't the cause of the error.

only idea i have is that server gets the idea to resume some previous listing, so i suppose it could be a server bug. but since windows has no problem like 
this nor, old samba client. it should probably be fixed.

I've monitored svn changes since 3.0.22 and haven't been able to spot
anything relevant to this issue. but would be nice to get solved before 3.0.23. sorry it's so late in release cycle, didn't get ahold of good comparison logs from users before now.
Comment 1 Joakim Plate 2006-05-30 09:34:07 UTC
Created attachment 1923 [details]
Full log 3.0.4 working
Comment 2 Joakim Plate 2006-05-30 09:34:42 UTC
Created attachment 1924 [details]
Full log 3.0.22 failing
Comment 3 Joakim Plate 2006-05-30 09:35:07 UTC
Created attachment 1925 [details]
Clean log 3.0.4 working
Comment 4 Joakim Plate 2006-05-30 09:35:31 UTC
Created attachment 1926 [details]
Clean log 3.0.22 working
Comment 5 Joakim Plate 2006-05-30 09:39:11 UTC
Forgot.. we use a ported version of libsmbclient 3.0.22 on the microsoft xbox. Should have no changes in regard to this.
Comment 6 Derrell Lipman 2006-05-30 20:05:26 UTC
The text-based packet dumps are a bit too hard to work with.  Would you please generate separate raw packet dumps of the requests to 3.0.4 and 3.0.22.  This command line should get what I need:

  tcpdump -s 0 -w working-3.0.4.pcap

and

  tcpdump -s 0 -w failing-3.0.22.pcap

Note the "-s 0" to ensure that entire packets are saved and not truncated.

Thanks.

Derrell
Comment 7 Joakim Plate 2006-05-31 09:15:27 UTC
i will try to get ahold of it. doubt the user who has the issue is experienced enough to generate those dumps, nor has the tools. will check thou.
Comment 8 Joakim Plate 2006-06-05 16:17:02 UTC
Created attachment 1945 [details]
pcap of failed listing if folder _ADULT in share MOVIES
Comment 9 Joakim Plate 2006-06-05 16:17:41 UTC
Created attachment 1946 [details]
pcap of old working listing of folder _ADULT in share MOVIES
Comment 10 Joakim Plate 2006-06-05 16:19:12 UTC
Created attachment 1947 [details]
pcap of failed listing of folder _ADULT in share MOVIES
Comment 11 Joakim Plate 2006-06-05 16:19:47 UTC
Created attachment 1948 [details]
pcap of old  working listing of folder _ADULT in share MOVIES
Comment 12 Joakim Plate 2006-06-05 16:22:25 UTC
attached two packet traces, one with the old working version and one with the new non working. 

there is quite a few stat calls inbetween root listing of MOVIES share and, when a subdir is entered, that is a side effect of our application.
Comment 13 Joakim Plate 2006-06-05 16:30:30 UTC
by comparing the logs, the only diffs i can see in the FIND_FIRST2 request is that the failing one uses a larger search count and is setting the DFS flag in the smb header. ethereal calls it "Resolve pathnames with dfs" wich the older version doesn't. 

Seems logical, cause if the older samba didn't support that flag properly it could really return anything.
Comment 14 Derrell Lipman 2006-06-05 17:32:46 UTC
Gerry or Jeremy, I could use your help on this.  I have confirmed Joakim's evaluation that the two key differences between the 'working' request and the 'failing' request are that in the working one, the old search count value of 512 was used whereas in the failing one, the search count is set to 1366; and in the working one, the DFS flag is disabled whereas in the failing one, the DFS flag is enabled.

The TConX response indicates that DFS is not in use on this share.

The DFS flag is set up in cli_setup_packet() in clientgen.c:201.

Should the lines that say 

		if (cli->capabilities & CAP_DFS)
			flags2 |= FLAGS2_DFS_PATHNAMES;

instead say

		if ((cli->capabilities & CAP_DFS) && cli->dfsroot)
			flags2 |= FLAGS2_DFS_PATHNAMES;

cli->dfsroot is initialized based on the response to the TconX in cliconnect.c:1018.

Derrell
Comment 15 Joakim Plate 2006-06-18 13:03:09 UTC
i've not got it verified from our users that the fix proposed by darrell does indeed work. looks like there was some issue with older samba versions if that flag was set.
Comment 16 Joakim Plate 2006-06-18 19:10:03 UTC
(In reply to comment #15)
> i've not got it verified...

should have been "i've now got it verfied"...

Comment 17 Derrell Lipman 2006-06-22 14:59:47 UTC
Fixed.  Thanks for testing it!