Bug 5617 - xp/2003 explorer freezes browsing shares on samba ipv6 hosts
xp/2003 explorer freezes browsing shares on samba ipv6 hosts
Status: RESOLVED FIXED
Product: Samba 3.2
Classification: Unclassified
Component: File services
3.2.0
All Linux
: P3 major
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-16 10:23 UTC by Pim Zandbergen
Modified: 2008-08-14 11:22 UTC (History)
2 users (show)

See Also:


Attachments
Wireshark log captured on XP client (45.89 KB, application/octet-stream)
2008-07-16 10:26 UTC, Pim Zandbergen
no flags Details
level 10 smbd log (709.25 KB, text/plain)
2008-07-16 10:27 UTC, Pim Zandbergen
no flags Details
/etc/resolv.conf of samba server (134 bytes, text/plain)
2008-07-16 10:28 UTC, Pim Zandbergen
no flags Details
freezing.pcap (166.04 KB, application/octet-stream)
2008-08-13 11:56 UTC, Bartosz Antosik
no flags Details
not freezing.pcap (112.44 KB, application/octet-stream)
2008-08-13 11:58 UTC, Bartosz Antosik
no flags Details
Patch from your code. (293 bytes, patch)
2008-08-13 17:49 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pim Zandbergen 2008-07-16 10:23:37 UTC
Windows 2003 and XP clients freeze when you type "\\server" in an explorer address bar where "server" is the name of the Samba 3.2 host running ipv6.

Windows 2000 clients don't freeze.

2003/XP clients don't freeze when you enter "\\server\share"

They un-freeze if you stop smbd, showing all the shares, most likely using the WebDAV client.

Here are some details on our network
- all samba 3.0 and 3.2 hosts are ipv6 capable
- some Windows clients are ipv6 capable
- DNS hostnames resolve to both ipv4 and ipv6 addresses
- NetBIOS over TCP is disabled, nmbd not running
- all samba servers are ADS clients in a 2003 domain

Here are some findings:
- it does not matter whether clients are ipv6 capable or not
- removing AAAA records for samba hosts does not help
- re-enabling NetBIOS over TCP does not help
- disabling ipv6 on the samba host does fix the problem
Comment 1 Pim Zandbergen 2008-07-16 10:26:30 UTC
Created attachment 3415 [details]
Wireshark log captured on XP client

captured on an XP client without ipv6 support
Comment 2 Pim Zandbergen 2008-07-16 10:27:40 UTC
Created attachment 3416 [details]
level 10 smbd log
Comment 3 Pim Zandbergen 2008-07-16 10:28:17 UTC
Created attachment 3417 [details]
/etc/resolv.conf of samba server
Comment 4 Pim Zandbergen 2008-07-16 10:32:26 UTC
Exact samba version is 3.2.0-2.17.fc9 from Fedora 9,
both i386 and x86_64.
Comment 5 Pim Zandbergen 2008-07-16 10:54:58 UTC
This is the sequence of events pertaining the attached logs:

- smbd is started
- explorer.exe is started
- wireshark capture started
- explorer.exe opens \\appel
- explorer.exe freezes
- smbd is stopped
- explorer.exe unfreezes
- wireshark capture stopped
Comment 6 Pim Zandbergen 2008-07-16 11:29:08 UTC
Freezing clients:
Windows XP Professional, ipv4 only
Windows XP Professional, ipv6 capable
Windows 2003 Server, ipv4 only
Windows 2003 Server, ipv6 capable

Non-freezing clients:
Windows 2000 Server, ipv4 only
Windows Vista Business, ipv6 capable

All clients are 32-bit
Comment 7 Pim Zandbergen 2008-07-16 11:41:18 UTC
Hmm, after having tried lots of things, and reverting things back to normal, my own desktop PC (ipv6 capable XP) does not freeze anymore.

I can't figure what's different. Other clients still freeze against the same server.
Comment 8 Bartosz Antosik 2008-08-13 11:56:03 UTC
Created attachment 3470 [details]
freezing.pcap
Comment 9 Bartosz Antosik 2008-08-13 11:58:03 UTC
Created attachment 3471 [details]
not freezing.pcap
Comment 10 Bartosz Antosik 2008-08-13 12:01:46 UTC
Gentlemen,

I have suffered from the situation described above and according to my best knowledge have figured out what the problem is plus made a patch to the code.

My particular setup has three XP machines of which two had no problem browsing the root level of the samba server and one of them freezes. 

1. First thing discovered was that the freeze is not forever, just for about one minute time number of printers that appear in the root folder of the server. The second thing is that when the printer shares (print$ and printers respectively) are removed from the served resources the freeze is gone.

2. The log analysis has lead to a conclusion that the machine that has the “freeze” problem is the only that is accessing the printer shares (both while reading the printers phantoms in root folder and the “Printers and Faxes” share) using the old LanMan style. 

You can see it in the wireshark capture attached. In the “xp-wireshark.cap” it is visible in the record 203, in the “freezing.pcap” 	in the record 132 you can see the Open Print File Request (SMBsplopen) SMB frame. To the contrary machines accessing the printer using more up-to-date MS-RPC method use OpenPrinterEx method (respectively record 70 in the first capture and record 32 in “not-freezing.pcap” attachement).

3. In the LanMan style method ends up by issuing Close Print File Request (SMBsplclose) to which the server should answer with Close Print File Request Response SMB. It does not do this.

4. I have made a correction in reply_printclose function located in smbd/reply.c. It appears that it has corrected the problem. The function before correction:

void reply_printclose(struct smb_request *req)
{
        connection_struct *conn = req->conn;
        files_struct *fsp;
        NTSTATUS status;

        START_PROFILE(SMBsplclose);

        if (req->wct < 1) {
                reply_nterror(req, NT_STATUS_INVALID_PARAMETER);
                END_PROFILE(SMBsplclose);
                return;
        }

        fsp = file_fsp(SVAL(req->inbuf,smb_vwv0));

        if (!check_fsp(conn, req, fsp, &current_user)) {
                END_PROFILE(SMBsplclose);
                return;
        }

        if (!CAN_PRINT(conn)) {
                reply_nterror(req, NT_STATUS_DOS(ERRSRV, ERRerror));
                END_PROFILE(SMBsplclose);
                return;
        }

        DEBUG(3,("printclose fd=%d fnum=%d\n",
                 fsp->fh->fd,fsp->fnum));

        status = close_file(fsp,NORMAL_CLOSE);

        if(!NT_STATUS_IS_OK(status)) {
                reply_nterror(req, status);
                END_PROFILE(SMBsplclose);
                return;
        }

        END_PROFILE(SMBsplclose);
        return;
}

And after correction (reply_outbuf and SSVAL right before the final return):

void reply_printclose(struct smb_request *req)
{
        connection_struct *conn = req->conn;
        files_struct *fsp;
        NTSTATUS status;

        START_PROFILE(SMBsplclose);

        if (req->wct < 1) {
                reply_nterror(req, NT_STATUS_INVALID_PARAMETER);
                END_PROFILE(SMBsplclose);
                return;
        }

        fsp = file_fsp(SVAL(req->inbuf,smb_vwv0));

        if (!check_fsp(conn, req, fsp, &current_user)) {
                END_PROFILE(SMBsplclose);
                return;
        }

        if (!CAN_PRINT(conn)) {
                reply_nterror(req, NT_STATUS_DOS(ERRSRV, ERRerror));
                END_PROFILE(SMBsplclose);
                return;
        }

        DEBUG(3,("printclose fd=%d fnum=%d\n",
                 fsp->fh->fd,fsp->fnum));

        status = close_file(fsp,NORMAL_CLOSE);

        if(!NT_STATUS_IS_OK(status)) {
                reply_nterror(req, status);
                END_PROFILE(SMBsplclose);
                return;
        }

        reply_outbuf(req, 1, 0);
        SSVAL(req->outbuf,smb_vwv0,fsp->fnum);

        END_PROFILE(SMBsplclose);
        return;
} 

--------
There is credit due to Gregorz Bis for help in pinpointing the problem.
Comment 11 Bartosz Antosik 2008-08-13 12:08:32 UTC
P.S. Due to small experience with git/samba developement environement I am unable however to commit the patch described above to the developement tree. 

Can anyone help?
Comment 12 Volker Lendecke 2008-08-13 12:09:46 UTC
Well.... Thanks for that analysis, your patch looks *almost* correct!

Can you try to not do the 

        reply_outbuf(req, 1, 0);
        SSVAL(req->outbuf,smb_vwv0,fsp->fnum);

but just a 

        reply_outbuf(req, 0, 0);

omitting the SSVAL line and see if that also works? This would make 3.2 reply exactly like 3.0.

Thanks a lot!

Volker
Comment 13 Volker Lendecke 2008-08-13 12:10:57 UTC
We can easily make a patch out of this :-)

Volker
Comment 14 Bartosz Antosik 2008-08-13 13:21:23 UTC
Yes, it does work without passing FID (as you corrected).

The frame was composed on the basis of some other trace made elsewhere where it showed up that the response should contain it.

P.S. By being unable to make a patch I mean that I have been trying for a couple of hours or so to make git commit changes to the database and ended up with "Access denied (publickey)" SSH message. Excuse me but I'd be very happy not having to fight through all of this to insert one line of code. If eventually you could do this would be great. Thank you.
Comment 15 Volker Lendecke 2008-08-13 16:08:57 UTC
Oh, you got *much* further with git than many other people :-)

That "access denied" is very deliberate, that's where only committers can write.

So feel free to attach that patch with "git format-patch HEAD^..HEAD" and attach it here. I'll push it then.

Volker
Comment 16 Pim Zandbergen 2008-08-13 16:13:45 UTC
Just out of curiousity, how is this problem ipv6 related?
Or isn't it?

Pim
Comment 17 Volker Lendecke 2008-08-13 16:15:29 UTC
If that patch fixes it: Not at all from Samba's side. There might however be some weird code paths in Windows that trigger it calling the broken call depending on IPv6. You never know.

Volker
Comment 18 Bartosz Antosik 2008-08-13 16:32:24 UTC
In all modesty, I think that it's absolutely not related in it's nature to IPv6. The observable results however - can be.

The timeout after which the connection gets disconnected (By TCP's FIN) in case of not receiving the Close Print File Request Response can be IPv6 dependent. Possibly also the way the socket interface behaves in such a case.

The patch tomorrow. Goodnight.
Comment 19 Jeremy Allison 2008-08-13 17:49:54 UTC
Created attachment 3475 [details]
Patch from your code.

This is what I pushed to 3.3 and 3.2.1. Thanks !
Jeremy.
Comment 20 Volker Lendecke 2008-08-14 04:11:01 UTC
Sorry, Bartosz, I would have waited for your patch so that you get credits in the git log, but Jeremy has already pushed the changed.

I hope this works better next time.

Volker
Comment 21 Bartosz Antosik 2008-08-14 07:28:29 UTC
Thank you. No problem.
Comment 22 Jeremy Allison 2008-08-14 10:30:08 UTC
Sorry, wasn't trying to deny credit. I gave pull credit in the commit message. I just don't like critical fixes being out of the tree just before a release, makes me nervous about them getting missed.
Jeremy.
Comment 23 Jeremy Allison 2008-08-14 10:34:09 UTC
Doh ! "gave pull credit" should of course be "gave full credit". Sorry.
Comment 24 Bartosz Antosik 2008-08-14 11:22:03 UTC
Sorry I couldn't prepare the patch yesterday. I was off the office at this time.

Yesterday, when I got the "master" branch of sources it seemed the flaw is also there. So a question comes to my mind - IS THE VERSION 4 BRANCH FREE OF THE PROBLEM? This is a reaction to what was said above, that the patch has been pushed to 3.2.1 and 3.3 branches. As I have stated earlier - I am not very fluent in SAMBA environment and sources tree...