Bug 1257 - port 139/445/getpeername failed
port 139/445/getpeername failed
Status: RESOLVED WONTFIX
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.2a
All Windows XP
: P3 normal
: none
Assigned To: Samba Bugzilla Account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-11 09:29 UTC by Mark Orenstein
Modified: 2005-02-11 07:36 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Orenstein 2004-04-11 09:29:57 UTC
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
Comment 1 Gerald (Jerry) Carter 2005-02-11 07:36:59 UTC
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.