[BUG] Unhandled Network Unreachable Error When No Gateway Defined

[pgwipeout]

The bug

While running Upsnap in an isolated container with no defined gateway (the management subnet is not permitted to jump to other subnets) the wake command would immediately terminate instead of counting down. The following is logged:
upsnap[94]: [ERROR] 2025/12/25 06:56:25 handlers.go:37: write udp [::]:54242->255.255.255.255:9: sendto: network is unreachable

This error is not observed with the wakeonlan program in the same container.

The OS that UpSnap is running on

Debian Trixie

Version of UpSnap

5.2.4

Your docker-compose.yml content

N/A

Reproduction steps

1. Create a container / vm with a static IP and no gateway defined or dynamic assigned address with a blank DHCP option `3`.
2. Run `upsnap serve --http=0.0.0.0:8090`.
3. Issue a wake command from Upsnap, observe the timer does not trigger.
4. Observe the error in the Upsnap terminal.

Additional information

Container is running in Proxmox 9 via the Proxmox VE Helper Scripts Repo, located at https://community-scripts.github.io/ProxmoxVE/scripts?id=upsnap&category=Network+%26+Firewall.

[invario]

What are the relevant parts of your docker-compose? I'd like to try to reproduce this locally to try to help you out.

[pgwipeout]

Docker is not in use here. It could be replicated in Docker by using host networking, deleting the default gateway inside the container, or manually configuring docker networking. Or simply run this on bare metal, container, or vm with no default gateway.

[invario]

Trying to reproduce it in Docker without host network was too much trouble since if you remove the gateway, you can't access the web interface to configure things. I was able to reproduce it using host network and removing the gateway. It looks to me like the error is coming from the WOL dependency that UpSnap uses: https://github.com/mdlayher/wol/tree/master

Specifically, I think it's coming from the sendWake function at the very end, but I need to look into it a bit more:
https://github.com/mdlayher/wol/blob/b763a792253a2db40318be1a6c2088ff10c08da6/client.go#L65-L84

[invario]

Ahhh this makes sense.

UpSnap/backend/networking/magicpacket.go

Lines 51 to 60 in ed83590

	// send 4 magic packets to different addresses to enhance change of waking up
	destinations := []string{
	// default user-calculated broadcast to port 9
	fmt.Sprintf("%s:9", broadcastIp),
	// user-calculated broadcast to port alternative port 7
	fmt.Sprintf("%s:7", broadcastIp),
	// broadcast to port 9
	"255.255.255.255:9",
	// broadcast to alternative port 7
	"255.255.255.255:7",

UpSnap is attempting to send 4 packets. The first 2 will work fine since the broadcast address is derived from your subnet. The final two will fail since 255.255.255.255 isn't reachable due to there being no gateway.

[invario]

I'm considering the following:

1. Detect if there is a default gateway set and disable the last two packets if there isn't one OR
2. Give the user the ability to disable the last two packets by setting an environment variable UPSNAP_GATEWAY_DISABLED=1

I am favoring option 2 currently.

[pgwipeout]

255.255.255.255 is the link local broadcast address, it's not dependent on a gateway (it specifically cannot use one). If sending a packet to it requires a gateway, that's a bug.

[pgwipeout]

I'm going to try and recreate this with the dependency. If the dependency also experiences the issue, I'll file the bug report over there.

[invario]

255.255.255.255 is the link local broadcast address, it's not dependent on a gateway (it specifically cannot use one). If sending a packet to it requires a gateway, that's a bug.

I was not aware of that! Well, in the meantime, I tested it locally and implemented option 2 above and the error stopped showing up.

Also, I assume the WOL feature still works, it's just logging an error message? Because my device responds to the WOL even when it was getting the error.

The dependency's repo hasn't been updated in a very long time, so I don't know if there's going to be any response there unfortunately.

[pgwipeout]

Sometimes it would work, sometimes it wouldn't. I found I had to add a five minute timer to it for it to finally realize it needed to wake up.

The developer seems to still be active. I've posted the bug report.
mdlayher/wol#4

[invario]

Actually, I've been looking a bit and this might be normal behavior since it doesn't know which interface (in case of multiple) it should send the packet through.

[invario]

This is the post I came across documenting this behavior:
https://stackoverflow.com/a/40261663

I just ran into this issue. Everything worked fine until I removed the gateway and then I get a network unreachable error when trying to send from the socket.

Since I am using the broadcast messages to configure the network settings of my box it is not an alternative for me to configure the gateway address to get it working. However since my box only has a single network interface I found the following solution:

// Bind to the proper interface to be able to send without default gateway
char netif[] = "eth0";
setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, netif, sizeof(netif));

With this I am able to send to the broadcast 255.255.255.255 address on the socket regardless of any default gateway. This solution should work with multiple network interfaces as long as you know what interface you want to use.

[pgwipeout]

It would appear you're correct about it not knowing which port to broadcast on due to the lack of the default gateway. I've reproduced this several ways now. Binding to the interface would definitely solve the issue, and allow a bit of extra flexibility in designing containers.

[invario]

I've been trying to do something within UpSnap's code but I'm not sure if it's possible. I think the necessary work to bind to an interface would have to be implemented in the wol package instead.

[invario]

As a workaround, what happens if you add a route for 255.255.255.255 dev iface?

That seemed to work on my end using the wol command.