IP address selection misbehaviour about libhdhomerun HOT 10 OPEN

With this setup the library will insist on using the IP address of the untunneld interface.

Are you talking about the discover command or something else?

from libhdhomerun.

When using the discover command packets leave the untunneld interface. This is because it is using multicast which wont work on the tunnel interface. Could this be the reason it will try to use this address? The hdhr device will reply on this interface with the locally configured IP address (the one that will later not be routed). I am about to wrap this library for use with Go and discovered this without using the discovery mechanism (at least not explicitly) but by explicitly setting the IP address on the call to hdhomerun_device_create.

from libhdhomerun.

If you want a pure-Go discovery use https://github.com/mh-orange/hdhomerun

from libhdhomerun.

While this would allow me to have more control on how the socket is created (i.e. by specifying an IP address) i think you should still consider to allow users of this library to do same. I guess now that you mentioned it, hdhomerun_device_create will still try to use the discovery even if an IP address has been given explicitly and use whatever address was used to receive the reply of the device. Whats interesting is that it will work when i am not connected through a network on the same subnet as the hdhr device. Does it skip discovery (only) in this case?

from libhdhomerun.

AFAIK the IP lookup stuff is only used during discovery due to multicast. If you specify an IP explicitly none of that stuff should happen.

from libhdhomerun.

I tried to follow the code path and it looks like in both cases the same code path is taken.

https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_device.c#L160
https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_device.c#L37
https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_device.c#L57
https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_control.c#L49
https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_control.c#L96
https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_discover.c#L449
https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_discover.c#L119
https://github.com/Silicondust/libhdhomerun/blob/master/hdhomerun_sock_posix.c#L40

this is where i lost it (read: i don't understand the code) but it sure looks to me as the same path is taken in either case. Please don't get me wrong i don't want to bother you too much about this and if you are confident this is an issue with my system i will accept this but otherwise i would like to at least understand this behavior.

from libhdhomerun.

It's possible I am mistaken. I am just another user of this library and did not write any of this code. I certainly don't have the unique network setup you do so I have not experienced the issue you are describing.

from libhdhomerun.

Ok understood, thanks for trying to help me :)
I will try to debug this tomorrow some more with a fresh mind (and probably a debugger ;D).

from libhdhomerun.

Hi, as of the most recent libhdhomerun the discover approach is to bind a socket to each local IP address found and send a global broadcast (255.255.255.255) from each one. This should send a broadcast packet out from each local IP address, including where there are multiple interfaces with isolated networks sharing an overlapping IP subnet as with AutoIP. Previous versions sent subnet broadcast packets which was required to work around the network stack in Windows XP.

The first thing that comes to mind is maybe the tunnel interface you are using is being filtered out for some reason. If you can step through things with a debugger it should be possible to check.

from libhdhomerun.

I did not yet take the time to debug this further but here is some clarification on what i think what it is that is happening here.

The tunnel interface is not capable of handling non unicast traffic. So no matter which approach is taken on my system the discovery process is not expected to work using this interface alone. To be clear, what i would like to do is to skip the discovery if i explicitly tell the library to which device it should connect to by specifying the address of the device explicitly.

Now what appears to happen when i am connected to the same subnet as the hdhr device is that discovery will actually work just fine and the device is found as it should be. This is because broadcast and multicast traffic is allowed to leave the plain untunneled ethernet interface. The problem i face is that after the device was discovered this way the library appears to be setting the source address explicitly to the address that received the discovery response. When the packet of the following connection attempt tries to leave this device the routing table is consulted and results in this packet being sent via the tunnel interface. This interfaces remote endpoint in turn has some strict rules about what source address packets are allowed to have and the address of the plain ethernet device that received the discovery reply packet is not one of them. If i am not connected to the same network as the hdhr device at all none of this happens. It looks like in this case the discovery is not even attempted and the library connects straight to the specified address as it is intended. Even if the code would attempt to try the discovery process it would fail as the hdhr device is not directly connected at all.

I understand that this is pretty specific to my setup and probably not very likely to happen on almost any other system. However, i think allowing users of this library to skip the discovery and directly connect to a specified address should be considered. There might also be some other reasons one wants to skip the discovery process too.

from libhdhomerun.