Tailscale fails to detect/use Eero's UPnP

[danderson]

What is the issue?

My network uses an Eero gateway, which supports UPnP. tailscale netcheck and node hostinfo both report that no portmapping protocols are available on my LAN.

Steps to reproduce

Get an eero network, turn on UPnP in network settings, use tailscale.

Are there any recent changes that introduced the issue?

No response

OS

Linux, macOS, Windows, Android

OS version

No response

Tailscale version

No response

Bug report

BUG-7f282f26c77f1efeb8d494a99187c1d55a4346b814e69cd004df6dda231794b1-20211027204508Z-4920474da648f13d

[DentonGentry]

Does tailscale netcheck --verbose show anything interesting?

[danderson]

Nothing useful, just STUN spam to DERP servers. The only portmap-related log is netcheck: portMap done.

[danderson]

tailscaled debug --portmap says:

2021/10/27 13:55:47 gw=192.168.4.1; self=192.168.4.32
2021/10/27 13:55:48 Probe: {PCP:false PMP:false UPnP:false}
2021/10/27 13:55:48 no portmapping services available

[danderson]

nmap on my eero router shows that tcp/1900 is open, so UPnP is present. My guess is that eero's implementation doesn't response to the HTTP discovery query if it's directed at its unicast address, instead responding only to a correct multicast query - which we don't do.

[danderson]

Interesting: miniupnpc also cannot find the UPnP service on the eero.

[danderson]

tcpdump says the eero is correctly responding to miniupnpc's multicast discovery queries, albeit apparently not with something that pleases miniupnpc. Tailscale's probes elicit no response from eero, which seems to confirm that it will only respond to correct multicast queries per the spec, not the spec-bending violation we've been doing.

[danderson]

upnpc makes both a unicast request to the gateway, and a multicast request. The unicast request is identical to the one Tailscale makes, and is ignored. The multicast request is differently formed (asking only UPnP IGD devices to respond), and elicits a lot of response from the eero. Digging into diff now, and why the response still doesn't please upnpc.

[danderson]

TL;DR: eero is implementing UPnP correctly, but declines to implement some optional behavior, and we rely on that optional behavior to correctly detect UPnP.

Sent https://www.reddit.com/r/eero/comments/qh6xiq/feature_request_respond_to_upnp_ssdp_queries_on/ into the void to see if they might fix it, but in the meantime, the fix on our end would be to follow the UPnP spec and direct our UPnP probes at the SSDP multicast address.

[danderson]

woot, found a 2-line fix that might do the trick.