Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Subscription problem after IP address change
04-02-2014, 05:22 PM
Post: #1
Subscription problem after IP address change
When my control point switches network adapter (on the same subnet), the server device is removed and a new server device is added. The control point (now with a new IP address) then subscribes to the new device.

The SUBSCRIBE message is received by the device and its OK 200 response is received by the control point. The device then attempts to send a NOTIFY, but the call to SocketTcpClient::Connect hangs for 3000 ms and then fails with this log message:

Os/OsWrapper.cpp:92: Os::NetworkConnect H = 3903256, RETURN VALUE = -1

The device then appears to give up on attempting to send the NOTIFY message.

At the point that the SocketTcpClient::Connect call is attempted by the device, the control point is already listening on the new IP address. It seems that the new IP address for the control point isn't yet reachable from the server for some networking reason that I don't fully understand.

Can anything be done to improve this situation?
Find all posts by this user
05-02-2014, 01:26 PM
Post: #2
RE: Subscription problem after IP address change
The device stack removing subscriptions for control points which can't be contacted is deliberate. This is the least undesirable option here - retaining the subscription risks all events being ponderously slow to be notified for the next 30 minutes; subscriptions for clients who were only briefly unavailable will get resumed after ~10 minutes (assuming the control point responds to a failed RENEW by resubscribing).

Its not desirable (or expected) that this behaviour kicks in when an adapter changes however. Can you give me any more information:
  • What OS/version is the control point on?
  • Is the device on the same or a different host?
  • Is the failure of the device to connect to the control point's event server reproducible?
Find all posts by this user
05-02-2014, 03:46 PM
Post: #3
RE: Subscription problem after IP address change
(05-02-2014 01:26 PM)simonc Wrote:  The device stack removing subscriptions for control points which can't be contacted is deliberate. This is the least undesirable option here - retaining the subscription risks all events being ponderously slow to be notified for the next 30 minutes; subscriptions for clients who were only briefly unavailable will get resumed after ~10 minutes (assuming the control point responds to a failed RENEW by resubscribing).

How should the control point know this has happened? Its subscribe completed successfully, but it didn't receive any property values. Should the control point application set a timeout and do an unsubscribe/resubscribe if the initial event doesn't arrive in some reasonable time? If this is the right thing to do, could ohNet include this logic to avoid the need for all control point applications to include this code?

Quote:Its not desirable (or expected) that this behaviour kicks in when an adapter changes however. Can you give me any more information:
  • What OS/version is the control point on?
  • Is the device on the same or a different host?
  • Is the failure of the device to connect to the control point's event server reproducible?

The control point is on Windows and the device is on a different host (Linux).

I can make this happen 100% of the time when the control point is subscribing to two devices and the control point switches from a wireless adapter to a wired adapter. The device that responds first has the problem I described, and the device that responds second is able to complete a successful subscription.

Is it possible that the control point is unable to accept the NOTIFY connection from the first device because it is busy with handling a GET request for device.xml from the second device?
Find all posts by this user
05-02-2014, 04:47 PM
Post: #4
RE: Subscription problem after IP address change
(05-02-2014 03:46 PM)simoncn Wrote:  
(05-02-2014 01:26 PM)simonc Wrote:  The device stack removing subscriptions for control points which can't be contacted is deliberate. This is the least undesirable option here - retaining the subscription risks all events being ponderously slow to be notified for the next 30 minutes; subscriptions for clients who were only briefly unavailable will get resumed after ~10 minutes (assuming the control point responds to a failed RENEW by resubscribing).

How should the control point know this has happened? Its subscribe completed successfully, but it didn't receive any property values. Should the control point application set a timeout and do an unsubscribe/resubscribe if the initial event doesn't arrive in some reasonable time? If this is the right thing to do, could ohNet include this logic to avoid the need for all control point applications to include this code?

The control point won't know this has happened. Things will correct themselves in no more than a third of the subscription's duration (the cp will attempt a RENEW; the device will reject this; the cp will respond by attempting an UNSUBSCRIBE followed by a new SUBSCRIBE).

ohNet attempts a resubscribe in response to many eventing errors. Resubscribing in response to a failed subscribe would risk a never-ending loop of activity but it should be possible to detect this and give up at some suitable point.

Rather than looking into this at present, I'd prefer to keep thinking about the underlying problem - an initial event not working after an adapter change...

(05-02-2014 03:46 PM)simoncn Wrote:  
Quote:Its not desirable (or expected) that this behaviour kicks in when an adapter changes however. Can you give me any more information:
  • What OS/version is the control point on?
  • Is the device on the same or a different host?
  • Is the failure of the device to connect to the control point's event server reproducible?

The control point is on Windows and the device is on a different host (Linux).

I can make this happen 100% of the time when the control point is subscribing to two devices and the control point switches from a wireless adapter to a wired adapter. The device that responds first has the problem I described, and the device that responds second is able to complete a successful subscription.
Thanks. I'll have a look through the code to see if I can think of any reasons for this behaviour.


(05-02-2014 03:46 PM)simoncn Wrote:  Is it possible that the control point is unable to accept the NOTIFY connection from the first device because it is busy with handling a GET request for device.xml from the second device?
NOTIFY and GET are handled by different sockets in different objects so I wouldn't expect them to interfere with each other in any way. (Something obviously isn't working. It could be this. I'd be tempted to search for other causes first however.)
Find all posts by this user
05-02-2014, 05:01 PM (This post was last modified: 05-02-2014 05:57 PM by simoncn.)
Post: #5
RE: Subscription problem after IP address change
(05-02-2014 04:47 PM)simonc Wrote:  NOTIFY and GET are handled by different sockets in different objects so I wouldn't expect them to interfere with each other in any way. (Something obviously isn't working. It could be this. I'd be tempted to search for other causes first however.)

Would debug logs of the control point and device sides be helpful?

Another point that might be relevant is that the problem never occurs when the control point switches from a wired connection to a wireless connection.

I will run a Wireshark trace on the control point to see whether it is receiving a SYN message from the device. I'm still inclined to suspect that the network is failing to deliver this because of the recent change to the control point's IP address.

(05-02-2014 05:01 PM)simoncn Wrote:  I will run a Wireshark trace on the control point to see whether it is receiving a SYN message from the device. I'm still inclined to suspect that the network is failing to deliver this because of the recent change to the control point's IP address.

The Wireshark capture shows that the SYN message from the device is being received by the control point, but the control point isn't responding with an ACK. Does this mean the control point's listener socket isn't ready to accept an incoming connection?

Could this possibly be the issue with Windows and SO_REUSEADDR allowing a second bind to the same port to snatch away the port from the owner of the first bind? In the failing case, the same port is used by the control point stack to receive subscription NOTIFY messages from multiple devices. Is it possible that the control point stack is binding this port multiple times?
Find all posts by this user
05-02-2014, 10:56 PM (This post was last modified: 05-02-2014 11:53 PM by simoncn.)
Post: #6
RE: Subscription problem after IP address change
I am attaching the latest control point debug log. This includes some extra debug logging information that I have added.

The relevant lines are:

1674-1676: socket 78964544 is bound, listener port is 55010
1823: thread 35 calls Socket::Accept on socket 78964544
2339-2387: successful subscription to device 192.168.0.11
(visible in Wireshark) device 192.168.0.11 sends SYN request for NOTIFY to port 55010
2486-2516: successful subscription to device 192.168.0.10
(visible in Wireshark) device 192.168.0.10 sends SYN request for NOTIFY to port 55010
2754: thread 35 receives NOTIFY from device 192.168.0.10 on socket 78964544

From everything I can see, the control point was waiting in an Accept for a socket listening on port 55010 at the time the SYN arrived from device 192.168.0.11, but the SYN was not accepted. Later, another SYN for the same port arrived from device 192.168.0.10 and the SYN was accepted.

I reran this to get Wireshark captures on both adapters as well as an ohNet debug log. This time, both devices sent SYN requests to the control point and neither of these requests was acknowledged. It seems there is something on the control point side that is stopping these SYN requests from being accepted.

Another thought: Windows 7 has a limit of 20 simultaneous inbound connections. Perhaps this number is being exceeded. I'm not sure how to check how many of these are in use at any given time.


Attached File(s)
.zip  minimwatch.log.zip (Size: 26.12 KB / Downloads: 0)
Find all posts by this user
06-02-2014, 12:08 AM
Post: #7
RE: Subscription problem after IP address change
I stopped the Windows UPnP and SSDP services in an attempt to reduce the number of inbound connections. This seems to have solved the problem.
Find all posts by this user


Forum Jump: