About 10 days ago, I started looking at the �getpeername failed. Error was Transport endpoint is not connected� message appearing on our logs. This message was being produced very frequently during the day and somewhat less frequently at night.
Our configuration is samba 3.0.2a as a PDC with WINS support. Our network has about 60 XP Pro PC�s and 100 W98 PC�s. The signorseal registry patch was applied to all the XP Pro PC�s last year while we were still running samba 2. It was quickly apparent that this message was only being issued for our XP Pro PC�s. Also, at night when the network was pretty idle, the message was being issued only on certain XP PRO PC�s, but the PC�s varied on a nightly basis. Furthermore, at night, for a particular XP Pro PC, the messages were occurring at intervals that were multiples of 15 minutes. After doing some reading and taking some network traces, I inferred that the XP PRO PC�s for which the message occurred at night were backup browsers getting their 15 minute refresh. By disabling the Computer Browsing service on a bunch of the XP Pro PC�s, the night time messages were reduced. In any event, I did some more reading and looked at some more network traces, without a real understanding. However, one of the items I read was that the XP Pro PC Client attempts to initially communicate with the server over both ports 445 and 139 and that whichever port responds first is used for further communication. So I decided to try disabling port 445 at the server by using iptables to force all session traffic across port 139. �iptables -I INPUT 1 -p tcp --dport 445 -j DROP� I did this last night and, since applying this iptables rule, there have been no �getpeername failed. Error was Transport endpoint is not connected� messages in the log. It is now midmorning with regular network traffic. I regard this as a circumvention rather than a fix. So I suspect that the production of this message is a software issue that is somehow related to the initial communication over both ports 445 and 139 rather than being any type of network hardware issue. If the samba group needs some network traces, I can supply them. Mark Orenstein East Granby School System (Connecticut, USA) > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 6 Apr 2004, Collen Blijenberg <MLHJ> wrote: > >> Just wandering, wether this bug is fixed in the 303 pre 2 ?? >> ------------------------------------------------------ >> [2004/02/19 14:03:00, 0] lib/util_sock.c:read_socket_data(342) >> read_socket_data: recv failure for 4. Error = Connection reset by >> peer >> [2004/02/19 14:06:18, 0] lib/util_sock.c:get_peer_addr(952) >> getpeername failed. Error was Transport endpoint is not connected >> [2004/02/19 14:06:18, 0] lib/util_sock.c:send_smb(605) >> Error writing 4 bytes to client. -1. (Connection reset by peer) >> ----------------------------------------------------- > > The client disconnected. This is not a Samba bug. Best to check > for bad network hardware, hubs, switches, mismatched duplex settings on > NICs, etc... > > Now if we did something to cause the client to disconnect (e.g. blue > screen the client), then we would need to fix that. > > > > > > > cheers, jerry > - ---------------------------------------------------------------------- > Hewlett-Packard ------------------------- http://www.hp.com > SAMBA Team ---------------------- http://www.samba.org > GnuPG Key ---- http://www.plainjoe.org/gpg_public.asc > "...a hundred billion castaways looking for a home." ----------- Sting > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > Comment: For info see http://quantumlab.net/pine_privacy_guard/ > > iD8DBQFAcm+LIR7qMdg1EfYRAiy1AJ9/kHvF125iphdpTpzhOTR3bGIk5wCfQiyC > DfuYD54GBUh+4irRyE/y6fI= > =Y2uI > -----END PGP SIGNATURE----- > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba > -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
