Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SSDP multicast listener socket becomes unbound
20-08-2012, 03:33 PM (This post was last modified: 20-08-2012 03:33 PM by simoncn.)
Post: #1
SSDP multicast listener socket becomes unbound
A user has reported a problem with the SSDP multicast listener socket 1900 becoming unbound from ohNet. The device stack is still running and sends out 'alive' messages, but no M_SEARCH messages can be received. This happens on both Windows and Linux and happens once every few days. When this happens, other UPnP applications on the same machine are still listening to port 1900 and are fully functional.

Do you have any ideas for what kind of error condition might cause this to happen?
Find all posts by this user
21-08-2012, 10:02 AM
Post: #2
RE: SSDP multicast listener socket becomes unbound
It'd be good to start by confirming that the user's network is behaving correctly. One common cause for this sort of problem is switches dropping a device from their IGMP snooping table. The easiest way to check this might be to explain how your user determines that msearches are received by some applications but not by ohNet (Minim Server). Have they checked that ohNet does not respond to msearch requests at a time when other applications do respond?

Assuming the switch is well behaved, it'd be useful to get a bit more info about the devices running ohNet:
  • What type of network connection (wired, wifi, powerline) are the devices on?
  • Do the devices ever change their active network adapters?
  • Is the network connection ever interrupted?
  • Are the devices ever hibernated/restarted?
Find all posts by this user
21-08-2012, 06:07 PM
Post: #3
RE: SSDP multicast listener socket becomes unbound
(21-08-2012 10:02 AM)simonc Wrote:  It'd be good to start by confirming that the user's network is behaving correctly. One common cause for this sort of problem is switches dropping a device from their IGMP snooping table. The easiest way to check this might be to explain how your user determines that msearches are received by some applications but not by ohNet (Minim Server). Have they checked that ohNet does not respond to msearch requests at a time when other applications do respond?

I've been through this with the user. On the PC, he has Twonky and Asset running at the same time as MinimServer/ohNet. When the problem occurs with MinimServer/ohNet, these other servers on the same PC are responding correctly to M-SEARCH requests, but MinimServer/ohNet doesn't respond. He has also traced incoming messages with WireShark to verify that M-SEARCH messages are being received by the PC from the switch.

Quote:Assuming the switch is well behaved, it'd be useful to get a bit more info about the devices running ohNet:
  • What type of network connection (wired, wifi, powerline) are the devices on?
  • Do the devices ever change their active network adapters?
  • Is the network connection ever interrupted?
  • Are the devices ever hibernated/restarted?

The devices that are having the problem are wired. I'll ask the user whether this is Ethernet or powerline. I'll also need to go back to the user to confirm answers to the other questions.
Find all posts by this user
22-08-2012, 06:21 AM (This post was last modified: 22-08-2012 06:23 AM by simoncn.)
Post: #4
RE: SSDP multicast listener socket becomes unbound
(21-08-2012 10:02 AM)simonc Wrote:  It'd be good to start by confirming that the user's network is behaving correctly. One common cause for this sort of problem is switches dropping a device from their IGMP snooping table. The easiest way to check this might be to explain how your user determines that msearches are received by some applications but not by ohNet (Minim Server). Have they checked that ohNet does not respond to msearch requests at a time when other applications do respond?

I forgot to say that the way they know which servers are responding is by closing and restarting Kinsky and seeing which servers are shown. Ony Asset and Twonky are shown. By doing a netstart -nab, they see that MinimServer/ohNet isn't bound to port 1900 but the other servers are bound. If they wait for about 15 minutes, they see MinimServer/ohNet show up when it sends out an 'alive' message.
Find all posts by this user
23-08-2012, 08:25 AM
Post: #5
RE: SSDP multicast listener socket becomes unbound
Thanks for the extra info. It sounds a bit like something is going wrong when the set of available network adapters changes. The remaining open questions should help confirm whether this is possible.
Find all posts by this user
23-08-2012, 08:40 AM
Post: #6
RE: SSDP multicast listener socket becomes unbound
(23-08-2012 08:25 AM)simonc Wrote:  Thanks for the extra info. It sounds a bit like something is going wrong when the set of available network adapters changes. The remaining open questions should help confirm whether this is possible.

The picture is a little confused at the moment. I've had answers to some of the questions but not all of them. Also, the user has sent me complete netstat -nab output from the working and failing cases which shows that the socket isn't unbound in the failing case, contrary to his earlier claim. So it's possible that in the failing case, the socket remains bound but ohNet doesn't respond to M-SEARCH for some reason.

Here is ithe information that I have at the moment, with [...] for my impressions where I haven't yet had a definite answer:

What type of network connection (wired, wifi, powerline) are the devices on? - wired [probably Ethernet, not powerline]

Do the devices ever change their active network adapters? - ??? [probably not]

Is the network connection ever interrupted? - he thinks it is always on

Are the devices ever hibernated/restarted? - no
Find all posts by this user
23-08-2012, 08:57 AM
Post: #7
RE: SSDP multicast listener socket becomes unbound
(23-08-2012 08:40 AM)simoncn Wrote:  
(23-08-2012 08:25 AM)simonc Wrote:  Thanks for the extra info. It sounds a bit like something is going wrong when the set of available network adapters changes. The remaining open questions should help confirm whether this is possible.

The picture is a little confused at the moment. I've had answers to some of the questions but not all of them. Also, the user has sent me complete netstat -nab output from the working and failing cases which shows that the socket isn't unbound in the failing case, contrary to his earlier claim. So it's possible that in the failing case, the socket remains bound but ohNet doesn't respond to M-SEARCH for some reason.

Thanks. For information, its also possible that ohNet does still respond to M-SEARCH requests but fails to serve (or serves inconsistent) device xml. I'll try running some tests to see if I can reproduce this. Since the bug takes a few days to appeat, it'll obviously take a while to resolve this...
Find all posts by this user
23-08-2012, 08:24 PM
Post: #8
RE: SSDP multicast listener socket becomes unbound
(23-08-2012 08:57 AM)simonc Wrote:  Thanks. For information, its also possible that ohNet does still respond to M-SEARCH requests but fails to serve (or serves inconsistent) device xml. I'll try running some tests to see if I can reproduce this. Since the bug takes a few days to appeat, it'll obviously take a while to resolve this...

I've had a response from the user to the other questions. The connections are direct Ethernet (not wifi or powerline). Both the devices that show this problem (PC and QNAP NAS) have a single network adapter, so they can't change their active network adapter.
Find all posts by this user
31-08-2012, 05:20 PM
Post: #9
RE: SSDP multicast listener socket becomes unbound
The user has sent me a WireShark trace of the failure scenario. This confirms that the MinimServer/ohNet process isn't sending any response to the control point's M-SEARCH requests, but other processes are sending responses. The listener port is still bound to the MinimServer/ohNet process when these responses aren't being sent.

I've now asked the user to produce a full native thread dump when the problem is occurring. I hope this will produce the necessary information to identify the cause of the problem.
Find all posts by this user
01-09-2012, 09:49 AM
Post: #10
RE: SSDP multicast listener socket becomes unbound
(31-08-2012 05:20 PM)simoncn Wrote:  The user has sent me a WireShark trace of the failure scenario. This confirms that the MinimServer/ohNet process isn't sending any response to the control point's M-SEARCH requests, but other processes are sending responses. The listener port is still bound to the MinimServer/ohNet process when these responses aren't being sent.

I've now asked the user to produce a full native thread dump when the problem is occurring. I hope this will produce the necessary information to identify the cause of the problem.

Thanks, that'd be a massive help!
Find all posts by this user


Forum Jump: