From owner-freebsd-questions Sat Nov 23 16:38:31 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45D1537B401 for ; Sat, 23 Nov 2002 16:38:25 -0800 (PST) Received: from rotini.customfilmeffects.com (rotini.customfilmeffects.com [66.134.82.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4190643E6E for ; Sat, 23 Nov 2002 16:38:23 -0800 (PST) (envelope-from david@customfilmeffects.com) Received: from ethel (ethel.customfilmeffects.com [192.168.1.8]) by rotini.customfilmeffects.com (8.11.6/8.11.6) with SMTP id gAO0MUt22432; Sat, 23 Nov 2002 16:22:31 -0800 Message-ID: <00bf01c29351$c649baf0$0801a8c0@customfilmeffects.com> From: "David Smithson" To: Cc: References: <007101c2934a$8bad2b40$0801a8c0@customfilmeffects.com> <00a101c2934d$bfb43b60$0801a8c0@customfilmeffects.com> <1038097743.43256.45.camel@localhost> Subject: Re: Network connection dropping during file transfers Date: Sat, 23 Nov 2002 16:38:13 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Hi David, > By chance, is it possible for you to let the list know:- Yes. > 1]Client OS Clients are Windows 2000 Professional SP3 and Windows 2000 Server SP3. > 2] Are you using DHCP? Yes. A Windows 2000 domain controller also provides DHCP services to the Windows 2000 Pro clients. All servers are static. > 3] Are you using a Wins Server for your domain? The domain controller currently provides WINS and DNS services. > 4] For how long does the connection stay off-line before coming back? This period seems to be indefinite based on unquantified observations. I have not timed this period. A few times it seemed never to come back up. I even tried ifconfig nge0 down && ifconfig nge0 up to re-initialize the interface. This didn't help. Rebooting the server fixed the interface in these instances. > The reasoning behind the above is the fact that this might an issue of > how (if this is so) MS Windows clients on dhcp maintain respective > connections over the network during data transfer - You may well be > seeing cases of timeouts on the client end here. I'll do whatever it takes to get this working. Anything else I should look into? > Stacey > > > On Sun, 2002-11-24 at 00:09, David Smithson wrote: > > P.S. I'm using Samba 2.2.7. > > > > > > ----- Original Message ----- > > From: "David Smithson" > > To: > > Sent: Saturday, November 23, 2002 3:46 PM > > Subject: Network connection dropping during file transfers > > > > > > > Hi. I'm having trouble with a mission-critical file-server. Server is > > > FreeBSD 4.5, exporting the filesystem with Samba over gigabit copper. > > > Clients are Windows 2000. During multiple read/write operations between > > the > > > clients and the server, the network connection to the server will drop out > > > for an indefinite period of time and then somehow reconnect. This > > obviously > > > interrupts file transfers and foils all of the Windows clients' > > > explorers.exe processes. This also leads to incomplete files on the > > server > > > and frozen smbd processes. Dmesg outputs nothing of interest. Smbstatus > > > outputs this: > > > > > > Samba version 2.2.2 > > > Service uid gid pid machine > > > ---------------------------------------------- > > > W nobody wheel 1357 bunnicula (192.168.1.5) Sat Nov 23 > > > 15:27:19 2002 > > > X nobody wheel 1357 bunnicula (192.168.1.5) Sat Nov 23 > > > 15:27:19 2002 > > > W nobody wheel 1308 render-02 (192.168.1.12) Sat Nov 23 > > > 15:17:00 2002 > > > W nobody wheel 1312 render-01 (192.168.1.10) Sat Nov 23 > > > 15:17:09 2002 > > > W nobody wheel 1318 ethel (192.168.1.8) Sat Nov 23 > > > 15:17:36 2002 > > > W shaina wheel 1326 lucy (192.168.1.15) Sat Nov 23 > > > 15:18:09 2002 > > > W amani wheel 1283 bunnicula (192.168.1.5) Sat Nov 23 > > > 15:10:26 2002 > > > X amani wheel 1283 bunnicula (192.168.1.5) Sat Nov 23 > > > 15:10:30 2002 > > > X shaina wheel 1326 lucy (192.168.1.15) Sat Nov 23 > > > 15:21:09 2002 > > > W nobody wheel 1311 ricky-athlon (192.168.1.13) Sat Nov > > > 23 15:17:08 2002 > > > W nobody wheel 1309 render-03 (192.168.1.11) Sat Nov 23 > > > 15:17:04 2002 > > > W administrator wheel 1284 render-01 (192.168.1.10) Sat > > Nov > > > 23 15:10:26 2002 > > > X administrator wheel 1284 render-01 (192.168.1.10) Sat > > Nov > > > 23 15:10:33 2002 > > > > > > Locked files: > > > Pid DenyMode R/W Oplock Name > > > -------------------------------------------------- > > > 1284 DENY_ALL WRONLY EXCLUSIVE+BATCH > > > /array1/renders/Daredevil/film/OP34-02/OP34-02_0118.cin Sat Nov 23 > > > 15:10:53 2002 > > > 1283 DENY_ALL WRONLY EXCLUSIVE+BATCH > > > /array1/renders/Daredevil/film/OP34-02/OP34-02_0119.cin Sat Nov 23 > > > 15:10:54 2002 > > > > > > The two processes above (1284 and 1283) don't release their locks until > > they > > > are killed. > > > > > > log.smbd | tail -n 50 shows this: > > > > > > write_socket_data: write failure. Error = Broken pipe > > > [2002/11/23 12:19:13, 0] lib/util_sock.c:write_socket(566) > > > write_socket: Error writing 65534 bytes to socket 12: ERRNO = Broken > > pipe > > > [2002/11/23 12:19:13, 0] lib/util_sock.c:send_smb(730) > > > Error writing 65534 bytes to client. -1. (Broken pipe) > > > [2002/11/23 12:24:20, 0] smbd/nttrans.c:call_nt_transact_ioctl(1762) > > > call_nt_transact_ioctl: Currently not implemented. > > > [2002/11/23 12:32:07, 0] lib/util_sock.c:open_socket_in(830) > > > bind failed on port 139 socket_addr = 192.168.1.24. > > > Error = Can't assign requested address > > > [2002/11/23 13:05:23, 0] lib/util_sock.c:write_socket_data(542) > > > write_socket_data: write failure. Error = Broken pipe > > > [2002/11/23 13:05:23, 0] lib/util_sock.c:write_socket(566) > > > write_socket: Error writing 65534 bytes to socket 12: ERRNO = Broken > > pipe > > > [2002/11/23 13:05:23, 0] lib/util_sock.c:send_smb(730) > > > Error writing 65534 bytes to client. -1. (Broken pipe) > > > [2002/11/23 13:06:17, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 13:07:00, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 13:07:04, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 13:07:06, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:11:25, 0] lib/util_sock.c:read_socket_with_timeout(300) > > > read_socket_with_timeout: timeout read. read error = Connection reset by > > > peer. > > > [2002/11/23 15:11:26, 0] smbd/oplock.c:oplock_break(782) > > > oplock_break: receive_smb error (Connection reset by peer) > > > oplock_break failed for file Scans > > > In/daredevil/dd_op34_02_c34c_3/dd_op34_02_c34c_3.0110.cin (dev = 29300, > > > inode = 1063922). > > > [2002/11/23 15:11:26, 0] smbd/oplock.c:oplock_break(870) > > > oplock_break: client failure in break - shutting down this smbd. > > > [2002/11/23 15:11:55, 0] smbd/oplock.c:request_oplock_break(1026) > > > request_oplock_break: no response received to oplock break request to > > pid > > > 1285 on port 1371 for dev = 29300, inode = 1063922 > > > for dev = 29300, inode = 1063922, tv_sec = 3de00afe, tv_usec = 15342 > > > [2002/11/23 15:17:00, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:17:00, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:17:09, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:17:23, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:17:45, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:19:05, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:19:11, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > [2002/11/23 15:19:37, 0] lib/util_sock.c:read_socket_data(478) > > > read_socket_data: recv failure for 4. Error = Connection reset by peer > > > > > > > > > What does this indicate? Have I provided enough information here? > > > > > > By the way, the transfers that are taking place are initiated by a visual > > > effects / compositing program called Digital Fusion. The clients are > > render > > > engines that are currently being used to render shots for the upcoming > > > feature film "Chicago". I must deliver these rendered frames tomorrow by > > 9 > > > p.m. :( Your help will be much appreciated. > > > > > > -- > > > David Smithson - Systems Administrator > > > Custom Film Effects (http://www.customfilmeffects.com) > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-questions" in the body of the message > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > -- > Stacey Roberts > B.Sc (HONS) Computer Science > > Web: www.vickiandstacey.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message