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