Ticket #1001 (closed defect: fixed)

Opened 8 years ago

Last modified 7 years ago

Repy V2 semantics regarding openconn

Reported by: jeffra45 Owned by: vijay
Priority: major Milestone: RepyV2
Component: repyV2 Version:
Severity: Medium Keywords: repyv2, openconnection, semantics
Cc: justinc, hdanny, monzum Blocking:
Blocked By:

Description

Reported by Danny:

"""
I observed one situation in which the semantics of repy was broken. I
had a repy server listening bound to IP x. After it was started, I
changed the IP address to y. An openconnection on y would raise a
connection-refused error. On the other hand, openconnection on x gave
this error:
---
Uncaught exception!
---
Following is a full traceback, and a user traceback.
The user traceback excludes non-user modules. The most recent call is
displayed last.
Full debugging traceback:

"/tmp/seattle/namespace.py", line 1206, in wrapped_function
"/tmp/seattle/emulcomm.py", line 1373, in openconnection
"/tmp/seattle/emulcomm.py", line 1190, in _timed_conn_initialize
"<string>", line 1, in connect

User traceback:

"<string>", line 1, in connect

Exception (with class 'socket.error'): [Errno 113] No route to host

This problem concerns me. The mobility advertises the new IP address
whenever it changes, but there is a short gap between the detection of
this change and the successfully announcement of the new IP. If a
client connects during this gap, it will crash.
For now, I can avoid the problem by assuming this won't happen in the
evaluation.
"""

Change History

Changed 8 years ago by justinc

  • owner changed from jeffra45 to mkaplan
  • status changed from new to assigned

Changed 8 years ago by mkaplan

  • status changed from assigned to accepted

It appears that this ticket outlines two bugs:

State: After launching Repy, the interfaces IP changes.

Bug 1) It is 'possible' to bind to an IP that previously existed. This throws a 'no route to host' error.
Bug 2) Attempting to bind to the new IP throws a connection-refused error.

Bug 1 (possible) Explanation:
openconnection() appears to be safe - it first updates the list of interfaces (with update_ip_cache() ), and then checks if it is a valid IP (with _ip_is_allowed() ).

However, there is a boolean flag set in the begginning on Line 105:
allow_nonspecified_ips = True

This invalidates the checking done by _ip_is_allowed() (line 122, 139), and blindly returns True each time

Therefore, it is possible to bind to any IP, independent of the previous state.
This is currently true for r4888.

Changed 8 years ago by mkaplan

  • owner changed from mkaplan to vijay
  • status changed from accepted to assigned

Changed 7 years ago by vijay

When an IP address of the system is changed a simple TCP server listening on the system will continue to listen on the old IP address (and port), and the operating system does not appear to notify the socket or the program that its IP address changed. I observed that listening on and then disconnecting the ethernet interface would raise a SocketWouldBlockError? (Repyv2).

A possible solution to make the server program learn about the changed IP address would be to run another program or script that checks if the IP address changed and notifies the server program periodically about the change. Another solution would be to include the same piece of code in the server program itself. It appears that the Shims may have this capability.

TCP client behavior when the IP address of the server is changed :

Scenario 1: A client that is connected to the server sends messages until its send buffer is full and then blocks till the connection resumes.
Scenario 2: A client that attempts to connect to the servers old IP address timeout.
Scenario 3: A client that attempts to connect to the servers new IP address will get a "connection refused error".

UDP:

When an IP address of the system is changed a simple UDP server continue to be binded old IP,port and server will raise a SocketWouldBlockError?.

Changed 7 years ago by vijay

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.