Bug 843765 - DOS client stopped working after kernel update.
DOS client stopped working after kernel update.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: samba (Show other bugs)
6.2
x86_64 Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Andreas Schneider
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-27 05:58 EDT by antti
Modified: 2015-01-16 04:54 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-19 17:25:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tcpdump capture of problem (19.95 KB, text/plain)
2012-08-02 09:30 EDT, antti
no flags Details
tcpdump capture of working kernel (13.38 KB, text/plain)
2012-08-02 09:33 EDT, antti
no flags Details
samba log (problem case) (38.71 KB, text/plain)
2012-08-08 09:37 EDT, antti
no flags Details
samba log (working case) (34.67 KB, text/plain)
2012-08-08 09:39 EDT, antti
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Samba Project 2662 None None None 2012-08-09 07:45:03 EDT

  None (edit)
Description antti 2012-07-27 05:58:38 EDT
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):
Samba 3.5.10-116.el6_2.x86_64
with kernel 2.6.32-279.1.1.el6.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Update kernel to above mentioned version
2. Connect to samba share using MSDOS client
3. Try 'dir' command on client
  
Actual results:
Infinite loop displaying the first filename of directory

Expected results:
Correct directory listing

Additional info:
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.
Comment 2 Sumit Bose 2012-08-01 14:59:47 EDT
Jeff, do you have an idea if this an issue with the kernel or with samba?
Comment 3 Jeff Layton 2012-08-01 15:26:02 EDT
Unclear. Maybe get some captures between client and server and see what's happening on the wire?
Comment 4 antti 2012-08-02 09:30:04 EDT
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.
Comment 5 antti 2012-08-02 09:33:42 EDT
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.
Comment 6 Sumit Bose 2012-08-07 10:27:05 EDT
Can you also send the samba logs with debug level 10 or higher? Thank you.
Comment 7 antti 2012-08-08 09:37:35 EDT
Created attachment 603041 [details]
samba log (problem case)

Here is the samba log of the problem.
Comment 8 antti 2012-08-08 09:39:43 EDT
Created attachment 603042 [details]
samba log (working case)

...and this is the samba log when server running the previous kernel version.
Comment 9 Sumit Bose 2012-08-09 06:36:47 EDT
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?
Comment 10 Jeff Layton 2012-08-09 06:48:33 EDT
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...
Comment 11 Sumit Bose 2012-08-09 07:45:03 EDT
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.
Comment 12 antti 2012-09-11 01:34:20 EDT
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!
Comment 13 Dmitri Pal 2012-09-12 11:52:34 EDT
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.
Comment 15 J. Bruce Fields 2012-09-12 13:28:36 EDT
(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.
Comment 17 Dmitri Pal 2013-03-19 17:25:03 EDT
There are no plans to fix this issue. Closing.
Comment 18 antti 2014-03-14 06:45:49 EDT
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?
Comment 19 Andreas Schneider 2015-01-16 04:54:21 EST
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.

Note You need to log in before you can comment on or make changes to this bug.