I believe that I have isolated all the "getpeername failed. Error was Transport endpoint is not connected" messages in our logs to the XP Pro selection of port 445 rather than 139. If XP Pro sends a port 139 packet first and, if it also sends an NBSS over port 139, followed by a packet sequence to port 445, then the RST on port 139 results in the above message. If the XP Pro PC starts first with port 445 and then 139, then it never gets to sending the NBSS packet over port 139, and the RST packet on port 139 does not cause the error message to be output. Our configuration is samba 3.0.2a as a PDC with WINS support running on Fedora 1. We have W98 (2nd edition) PC's and XP Pro PC's We have no W2000 PC's I can supply ethernet traces of both sequences if you need them. I first started tracking this down by putting an iptables rule on our samba server which dropped port 445 traffic forcing all session traffic over port 139. With this rule installed, there were no getpeername failed messages. I then removed the rule and took some ethernet traces and noticed the difference. However, I really don't know anything about the protocols used. I believe that the many people reporting this message over the last few months are experiencing the above sequence of packets rather than experiencing a hardware problem. If I can be of any assistance, please email me. Mark Orenstein
Mark, several developers have confirmed this client behavior. There's nothing we can really do about this. The client connects and then disconnects. You can set 'smb ports = 445' to prevent the parallel connects.