Errno 104 Connection reset by peer` error

Question

I have following code snippet. Previously it was working fine and was printing output

But after now when i did change my machine's phisical loaction location within same network I get error: [Errno 104] Connection reset by peer error IP is same for machine.

I am using Scientific Linux 6.1

 operation='GET'
 url="/apifactory/api"
 url_request = "%s HTTP/1.1" %url
 connect = httplib.HTTPSConnection('myhost.com')
 try:
      connect.request(operation,url_request,'')
 except Exception,obj:
      connect.close()
      print traceback.format_exc()


 response_obj=connect.getresponse()
 data=response_obj.read()
 connect.close()
 print data


Traceback:
  File "/usr/local/lib/python2.7/ssl.py", line 121, in __init__
  self.do_handshake()
  File "/usr/local/lib/python2.7/ssl.py", line 281, in do_handshake
  self._sslobj.do_handshake()
  error: [Errno 104] Connection reset by peer

I tried with openssl s_client -connect myhost.com:443 It gives:

  CONNECTED(00000003)
  write:errno=104
  no peer certificate available
  No client certificate CA names sent
  SSL handshake has read 0 bytes and written 113 bytes
  New, (NONE), Cipher is (NONE)
  Secure Renegotiation IS NOT supported
  Compression: NONE
  Expansion: NONE

All working fine before changing the location. What can be possible cause ? is there any change regarding opesssl configuration or certification?

Dimetric

Does your machine have a static IP? Does it have the same static IP after plugging it in at the new location? If you have DNS inside your network, does it still get the same DNS name? – Dusk

Yes , I tried with static IP it's working fine , previously it was configured with dncp. i got same ip from dhcp for new location, But it gives problem with dhcp IP and we need IP from dhcp. what would be the reason? – Dimetric

I'm not sure what the problem is, but my hunch was that it was related to an IP address change, and your comments seem to back that up. One possibility is that you've got a cached session, which is no longer valid because you no longer have the same host… but that should have fixed itself by now, so that's probably not it. And off the top of my head, I can't think of what else in the ClientHello would make the server drop you without even sending a protocol-level rejection. But maybe something will come to me (or, more likely, someone else reading this) later. – Dusk

this could be related with timeout ( #441874 ) or with private key generation ( #15954967 ) – Reach