Bug 843765

Jeff, do you have an idea if this an issue with the kernel or with samba?

Unclear. Maybe get some captures between client and server and see what's happening on the wire?

Created attachment 601948 [details]
tcpdump capture of problem

Here is the capture between client and server.
192.168.0.1 = server
192.168.0.73 = client

During the capture, there was directory '/foo' on the share containing files file1.txt, file2.txt and file3.txt

DOS command 'dir' was entered during the capturing traffic.

Created attachment 601951 [details]
tcpdump capture of working kernel

Here is the capture when everything is working ok. Only difference is kernel version of the server.

Can you also send the samba logs with debug level 10 or higher? Thank you.

Created attachment 603041 [details]
samba log (problem case)

Here is the samba log of the problem.

Created attachment 603042 [details]
samba log (working case)

...and this is the samba log when server running the previous kernel version.

It looks like the offset returned by telldir() changed from 32bits to 64bits:

- working:
    [2012/08/08 16:08:35.966499,  6] smbd/dir.c:921(smbd_dirptr_get_entry)
     smbd_dirptr_get_entry: dirptr 0x7fbcc287df40 now at offset 1082170075

- not working:
    [2012/08/08 16:24:37.895077,  6] smbd/dir.c:921(smbd_dirptr_get_entry)
     smbd_dirptr_get_entry: dirptr 0x7f15e6497d30 now at offset 4647885084463332208

Jeff, are you aware of kernel changes if this area?

I'm going to assume that you're exporting ext3 or ext4? If so, then yes, there were some changes in this area in ext3/4 in RHEL6 for bug 813070.

However, telldir() returns a long. Is samba expecting an int there? If so then that seems like a bug...

Thank you for the quick response. I think it turns out that this is a samba issue.

dptr_fill() and dptr_fetch() assumes that the offset is 32bit. It looks there is already an upstream bug for this https://bugzilla.samba.org/show_bug.cgi?id=2662 . Let's see if it can be revitalized.

Any update for this issue?

I know, DOS clients are minority on these days. But still, you can easily found DOS running on special machines used on industry factories, for example.

Unfortunately, this bug prevents kernel update of server now, and I don't know practical solution for this.

However, here is another bug report for the same issue found on bugilla.samba.org:
https://bugzilla.samba.org/show_bug.cgi?id=9082

Thank you for your effort!

This issue is a known issue upstream for quite a while. If that would have been a significant issue for many deployments it would already have been fixed (7 years after or so), however it is not deemed to be significant to fix so far.

If you want to escalate this issue the best avenue is to open a support case and escalate it via the support organization or via your TAM.

(In reply to comment #13)
> This issue is a known issue upstream for quite a while. If that would have
> been a significant issue for many deployments it would already have been
> fixed (7 years after or so), however it is not deemed to be significant to
> fix so far.

They only ran across this on a recent update.  So, Samba may have had a bug for 7 years, but nfsd just started tickling it recently.  We may therefore want to reconsider the nfsd change that has it returning 64-bit cookies on ext4.

Note turning off dir_index on the ext4 filesystem may work around the problem.

> If you want to escalate this issue the best avenue is to open a support case
> and escalate it via the support organization or via your TAM.

But this may still be true.

There are no plans to fix this issue. Closing.

The upstream bug https://bugzilla.samba.org/show_bug.cgi?id=2662 seems to be fixed now in samba 4.
Stupid question maybe, but is there any possibility to backport this to samba 3.6 used in Red Hat 6.x?

The patch from bso #2662 is incomplete. I'm not sure if someone will fix DOS clients upstream. We still do not plan to fix this issue.