Created attachment 3415 [details]
Wireshark log captured on XP client

captured on an XP client without ipv6 support

Created attachment 3416 [details]
level 10 smbd log

Created attachment 3417 [details]
/etc/resolv.conf of samba server

Exact samba version is 3.2.0-2.17.fc9 from Fedora 9,
both i386 and x86_64.

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

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

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.

Created attachment 3470 [details]
freezing.pcap

Created attachment 3471 [details]
not freezing.pcap

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.

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?

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

We can easily make a patch out of this :-)

Volker

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.

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

Just out of curiousity, how is this problem ipv6 related?
Or isn't it?

Pim

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

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.

Created attachment 3475 [details]
Patch from your code.

This is what I pushed to 3.3 and 3.2.1. Thanks !
Jeremy.

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

Thank you. No problem.

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.

Doh ! "gave pull credit" should of course be "gave full credit". Sorry.

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...