EVA-Discover: allow binding to local if address.

[enrikb]

Depending on the Windows network setup, it might be necessary to bind the UDP broadcast sender socket to an interface. By default, the limited broadcast (255.255.255.255) will be sent on the interface with the lowest metric route for this address.

Binding to the interface is done by (optionally) binding to the local IP address given as `-if_address'.

Using a directed broadcast (`-bc_address') did not help in my case. Even though it was sent on the intended subnet, the box's ADAM2 obviously ignored it.

[PeterPawn]

Thanks.

I've never tested it explicitly ... I would have expected, a local (IPv4) broadcast packet is sent out on each active interface with a local IPv4 configuration. The listener is bound to any interface already.

Did you test it with more than one Windows version? If not, could you please add a comment with the affected version?

Did you try, whether binding the sender to an "Any" address could solve the problem, too? (I'm asking, because the code from Discovery.cs could run into the same problems.)

Maybe that's the really intended solution - if not, I'd like to move the parameter to position 3 (EDIT: or 2), if a caller uses the position-dependent variant instead of keywords.

The broadcast address and the port number are (nearly) never really changed - their presence is more due to the intention "to be complete" with all possible variables.

[enrikb]

I have only tested on Windows 10 (17758.1) and don't have anything else readily available.

I found the following hint by Stevens saying the behavior changed with XP. I wouldn't expect binding to "Any" will change the behavior. (Isn't that the default, anyway?)

Moving the parameter is of course fine for me. I just didn't want to change the script behavior with my pull request.

[PeterPawn]

Thanks again for clarification.

I'll change to order of positional parameters soon ... according to my descriptions for "eva_discover" as shell script (where a (sort) order of INTERFACE, FROM, TO, ... is used), I'll shift the "from" value to the second position. It's more logical, if the local source address follows the wanted address of the target - and usually the (no)wait option is used seldom.

Looks like I have to provide an interface selection method, too (according to a short test of mine). If someone uses the current script on a multi-homed host, where the used interface stays deactivated, until a present cable was sensed (a static interface configuration with media sensing enabled, which gets initialized within 1-2 seconds), the attempt to "bind()" my sender fails now (tested with address on W7 in a first step). But it doesn't matter ... the next version is coming sooner or later.

[enrikb]

'Binding' to the interface like on Linux would be a better solution if that is supported on Windows, IMHO.

A crude workaround might be to retry the failed bind before each send attempt, until it hopefully will succeed when the link will come up again.

(BTW, in my case the link detection has no influence because the box in question is permanently attached to a switch and the PC even connected via WiFi (different equipment, of course). The other interface that is chosen to send the broadcasts by default is up because of a running docker daemon...)