Open Strunzdesign opened 4 years ago
Hi,
I saw that you added that behavior explicitly with commit https://github.com/bazwilliams/node-ssdp/commit/569e35d4ab3b343baa535b127fcfa771a2258f63. You mentioned that you had this issue:
Seems to cause issues with receiving messages when multiple interfaces are available (VM).
Can you please give some information what this problem was about? Maybe the correct fix is NOT to bind to an (arbitrary) interface. Maybe just a dedicated route for multicasts was missing... or something like that.
I want to help to get this issue fixed. Currently I see no reason to keep the current behavior as it definitly causes problems especially on systems with multiple interfaces. How can we iron that out?
Regards, Florian
Hi,
there is currently an issue with a software called the "Nanoleaf adaptor for ioBroker" that uses this library for handling UDP multicasts. Unfortunately, here on my system it didn't work as expected, and I started debugging. I discovered that there is a bug in node-upnp-ssdp that I'm going to describe here in the following.
At first, you can read the whole story with a detailed analysis of this issue in this bug report: https://github.com/daniel-2k/ioBroker.nanoleaf-lightpanels/issues/16.
Problem:
Your code binds a multicast listener to the first local IP address it finds, obtained via a call to ip.address(). On my system, I have two local interfaces: enp1s0 in direction to a PPPoE-driven ADSL modem, and br0 being my bridge towards my local LAN. In my setup, a call to ip.address() reveals the local IP address of enp1s0 instead of that of br0. This causes multicast communication to fail.
Furthermore, if i consider having multiple internal LAN segments (one for PCs, one for WLAN, one for gadgets...) this approach would also fail completely.
Solution:
The "addMembership" call should omit any IP address. Then the listener may bind to every suitable interface instead of just to a "random first local". By doing that, the interface selection ("ip mroute show") is performed on the basis of the current routing table. This is the expected behavior of an application dealing with UDP multicasts.
Fix:
The fix is trivial: please just remove the call to ip.address() while adding the multicast membership:
This fixes any of the observed misbehaviors of the referred ioBroker adaptor software and would also enable such software to run in setups having multiple internal LANs.
Thanks in advance for fixing this :-) Florian