improved devices discovery when dealing with multiple NICs

[donhk]

Hello,

first I want to thank you for this awesome lib, it is pretty nice :)

On my system I have multiple NICs, some of them are virtual, originally I thought I was facing the issue described here

#28

but later I realized that my case was a little different due to a VPN.

Even though this may not totally fix the issue, it certainly gives you a workaround and combined with business-specific code could help to totally avoid this situation.

For example, in my case I only want to scan the cameras on one specific network, but, if I wanted to scan more NICs I would combine this with code to scan the NICs and discard the virtuals.

Here is my current system NICs

[donhk@workstation cmds]$ ls -l /sys/class/net
total 0
lrwxrwxrwx 1 root root 0 Jan 26 16:32 enp0s3 -> ../../devices/pci0000:00/0000:00:03.0/net/enp0s3
lrwxrwxrwx 1 root root 0 Jan 26 16:32 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 Jan 26 16:32 tun0 -> ../../devices/virtual/net/tun0
lrwxrwxrwx 1 root root 0 Jan 26 16:32 virbr0 -> ../../devices/virtual/net/virbr0
lrwxrwxrwx 1 root root 0 Jan 26 16:32 virbr0-nic -> ../../devices/virtual/net/virbr0-nic

[donhk@workstation cmds]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:b7:0a:de brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:c1:12:b1 brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:c1:12:b1 brd ff:ff:ff:ff:ff:ff
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
    link/none

Execution without the fix:

[donhk@workstation ztest]$ node discover.js 
Start the discovery process.
listening on 0.0.0.0:46646
0 devices were found.

Execution without the workaround:

[donhk@workstation ztest]$ node discover.js 
Start the discovery process.
listening on 192.168.1.97:50129
1 device was found.
- urn:uuid:2419d68a-2dd2-224b-ab35-45011D24163D
  - IPC 8741116
  - http://192.168.1.93:5000/onvif/device_service

and the change is no disruptive

const onvif = require('node-onvif');
onvif.startProbe({ bind_address: '192.168.1.97' }).then((device_info_list) => {..});

Regarding the bind_port, I also figured that the firewall may be preventing the socket to work properly and since it is randomly assigned it is hard to automate, by giving the option of setting it beforehand it gains automation points :)

just wanted to give you some ideas, thanks :)

[gregksurveillus]

On windows, the interface that the operating system chooses to get to a particular IP is based on routing tables, etc.

This link may help you understand that:
https://www.windowscentral.com/how-change-priority-order-network-adapters-windows-10

My advice at this point is to code for using specific interfaces both sending and listening.