Win10 throws Error Creating UDP socket

[GWustenstein]

On a win10 machine, when I

uhppote-cli -debug get-devices ... request ... 00000000 17 94 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ...

WARN: Error creating UDP socket (listen udp 169.254.98.230:0: bind: The requested address is not valid in its context.)

When doing this on a pi on the same net, uhppote-cli responds with the expected node data. Note: The controller is running across uppoted-tunnel with the tunnel source node running on the same windows pc (if that matters). I've yet to try moving the tunnel to the pi to see if the behavior changes (or follows the tunnel node)

Best, -GW

[uhppoted]

That particular error means it cannot bind to address 169.254.98.230 - is that the address of the Windows 10 machine?

You can try binding to a specific address:

uhppote-cli --bind 0.0.0.0:0 --debug get-devices

[GWustenstein]

lol, not even close! local private ip address is 192.168.1.9; I usually see the 169.254.x.x space pop up for uninitialized networks. So, here's what it does when I try:

uhppote-cli --bind 0.0.0.0:0 --debug get-devices ... request ... 00000000 17 94 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ...

... sent 64 bytes to 169.254.255.255:60000

Curiouser, and curiouser...

Here's an anecdote that may or may not be useful: So, trying to work with uhppoted-tunnel on the rpi in a way that was undocumented, I came across a weird interface conflict when I had the pi's ethernet plugged into the access controller and it's wlan0 (wifi) on the net. For some reason the pi's network stack would see eth0 (wired ethernet) come up and even though the route metric was set to a high number it became the default route over wlan0 and everything uhppoted-tunnel was trying to send to was going out to 169.254.x.x (typical of an unprovisioned net) rather than 192.168.x.x like it should. It would be nice to get tunnel to work in this way as it could be really useful as a very secure wireless controller bridge. On the rpi, it was the debian/bullseye and it was clearly the network driver/router that was messed up because you could not even ping out...bullseye has a number of documented issues in the network stack currently, mostly driver conflicts especially at boot or interface up/down when a machine is upgraded from stretch (clean installs are better but not immune from issues FWIW). But I find it an odd coincidence that the go network driver on windows would land on a 169.254.x.x net in a similar way yet on a completely different platform. No problems pinging out on this win10 machine, even posted this from here;^)

[uhppoted]

That sort of makes sense - uhppote-cli (actually almost all of uhppoted-xxx) has an internal algorithm to resolve the default bind and broadcast addresses. Which works ok for the network configurations most people have - for more advanced networking (and/or MacOS)you can override the defaults e.g.:

uhppote-cli --debug --bind 0.0.0.0:0 --broadcast 255.255.255.255:60000 --listen 0.0.0.0:60001 get-devices

(or whatever is appropriate for your network).

Having said which, the 169.254.xxx.xxx is odd - are the Pi and the Windows 10 machine getting their IP addresses from the same router/gateway?

And out of curiosity, what does the output of ipconfig /all on your Windows 10 machine look like?

[GWustenstein]

169.254.x.x appears nowhere, like I say, usually this is seen with an unconfigured interface. BTW, the invocation line you provided in the last post worked like a champ! Where is the application getting its defaults?

As requested:

ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : [redacted] Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No

Wireless LAN adapter Local Area Connection* 2:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter Physical Address. . . . . . . . . : [redacted] DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Local Area Connection* 4:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #3 Physical Address. . . . . . . . . : [redacted] DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

Ethernet adapter NETGEAR-VPN:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : [redacted] DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wi-Fi 3:

Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 8265 #2 Physical Address. . . . . . . . . : [redacted] DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : [redacted]%22(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.1.9(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Monday, September 26, 2022 3:18:59 PM Lease Expires . . . . . . . . . . : Thursday, September 29, 2022 3:19:30 AM Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.1 DHCPv6 IAID . . . . . . . . . . . : [redacted] DHCPv6 Client DUID. . . . . . . . : [redacted] DNS Servers . . . . . . . . . . . : 8.8.8.8 1.1.1.1 NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Bluetooth Network Connection 3:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network) #3 Physical Address. . . . . . . . . : [redacted] DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

[uhppoted]

It loops through the interfaces looking for the first IPv4 interface that isn't a loopback address:

https://github.com/uhppoted/uhppoted-lib/blob/master/config/config.go#L322-L343

I wonder if it's picking up one of your 'Media disconnected' interfaces ..

If you edit your uhppoted.conf file you can set the addresses there so that you don't have to specify them on the command line:

# SYSTEM
bind.address = 0.0.0.0
broadcast.address = 255.255.255.255:60000
listen.address = 0.0.0.0:60001
...

[uhppoted]

Going to close this - it's working as designed and there's no immediate intention to change the address resolution logic.

Feel free to reopen if necessary :-)