Red Hat Bugzilla – Bug 843765
DOS client stopped working after kernel update.
Last modified: 2015-01-16 04:54:21 EST
Description of problem:
We have older MSDOS client in network of our company. After updating server's kernel with yum (version 2.6.32-279.1.1), some software on DOS client stopped working. I can connect to samba share, but typing 'dir' makes infinite loop displaying the first filename again and again. Windows XP / Windows 2000 / Windows 7 clients works ok.
Version-Release number of selected component (if applicable):
with kernel 2.6.32-279.1.1.el6.x86_64
Steps to Reproduce:
1. Update kernel to above mentioned version
2. Connect to samba share using MSDOS client
3. Try 'dir' command on client
Infinite loop displaying the first filename of directory
Correct directory listing
Downgrading server's kernel back to previous version 2.6.32-220.23.1 resolves the problem.
I don't know if this is Samba or kernel bug, but forgive me, this is my first bug report. Unfortunately this server is real production server in active use, so I cannot make too much testing with it.
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:
[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:
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.