RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 843765 - DOS client stopped working after kernel update.
Summary: DOS client stopped working after kernel update.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: samba
Version: 6.2
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Andreas Schneider
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-27 09:58 UTC by antti
Modified: 2015-01-16 09:54 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-19 21:25:03 UTC
Target Upstream Version:
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
Samba Project 2662 0 None None None 2012-08-09 11:45:03 UTC

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

Here is the samba log of the problem.
Comment 8 antti 2012-08-08 13:39:43 UTC 
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 10:36:47 UTC 
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 10:48:33 UTC 
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 11:45:03 UTC 
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 05:34:20 UTC 
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 15:52:34 UTC 
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 17:28:36 UTC 
(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 21:25:03 UTC 
There are no plans to fix this issue. Closing.
Comment 18 antti 2014-03-14 10:45:49 UTC 
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 09:54:21 UTC 
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.