[Bug]: UPnP fails on most routers, and discovery can flood the log

Aperta
  • Qualcosa non va?
#6,236 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend, networking

Direzione di ricerca

The report names UPnPUtil for the MapTool changes and describes a separate fallback bug in upnplib's InternetGatewayDevice. Start by tracing UPnP interface discovery in UPnPUtil and how it invokes the library's listener; check the existing tests for those paths. Done means IPv6-only interfaces are skipped and sequential searches do not flood logs, with the gateway fallback handled in upnplib.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Describe the Bug

UPnP port mapping has three problems. The first means it fails on most home routers.

1. Ordinary routers aren't recognised (upnplib 1.2.0). upnplib 1.2.0 added support for version 2 gateways (upnplib PR #9, for #5123). InternetGatewayDevice now looks for WANIPConnection:2 first and is meant to fall back to :1, but the fallback checks the wrong variable:

UPNPService wanIPSrv = myIGDWANConnDevice.getService("urn:schemas-upnp-org:service:WANIPConnection:2");
if (myIGDWANConnDevice == null) {   // should be wanIPSrv == null
    ...
    wanIPSrv = myIGDWANConnDevice.getService("urn:schemas-upnp-org:service:WANIPConnection:1");
}

myIGDWANConnDevice can't be null there, so the fallback never runs. A router that offers WANIPConnection:1 and no WANPPPConnection is rejected without a message, and MapTool reports 0 gateways. That's the most common setup there is: my ASUS router describes InternetGatewayDevice:1 → WANConnectionDevice:1 → WANIPConnection:1. This affects every MapTool release that ships upnplib 1.2.0, in the client as well as the server.

2. Discovery can flood the log. MapTool searches each network interface in turn. For each search, upnplib's DiscoveryListener starts a listening thread. The thread keeps its socket in a shared field and is told to stop through a shared flag, which it only checks when the socket times out, every 250 ms. The next search starts within milliseconds, replaces the socket and raises the flag again, so the old thread carries on. When one thread finally exits, it closes the socket the other is still reading, and that thread then fails on every read without pausing, logging each failure. On a machine with Docker's virtual interfaces, two of three runs logged 332,401 and 439,777 copies of IO Exception during UPNP DiscoveryListener messages listening thread (285 and 377 MB) in about 20 seconds. Any PC with several network adapters (VPNs, Hyper-V, VirtualBox) could see the same.

3. Start-up waits on interfaces it can't search. upnplib only sends its search from IPv4 addresses, but it still waits out the whole discovery timeout on every interface it's given, including ones with only IPv6 addresses. Docker creates one of those per container. This is a remaining case of #4902.

To Reproduce
  1. Use a router that offers WANIPConnection:1 (most home routers).
  2. Start a server with UPnP on.
  3. The log says no gateways were found, and no port is mapped.

For 2 and 3, start the server with UPnP on a machine with several network interfaces, for example one running Docker.

Expected Behaviour
  1. The router is found and the port is mapped.
  2. Discovery logs no errors.
  3. Interfaces with no IPv4 address are skipped.
MapTool Info

develop (62b6b4a3c), upnplib 1.2.0

Desktop

Ubuntu 24.04 LTS (dedicated server), ASUS router

Additional Context

I tested fixes for all three on 2026-11-03, with a copy of upnplib patched for problem 1:

  • Problem 1: with the fix, the server logged Found IGD: ASUS Wireless Router and Port 51243 mapped. The router showed the mapping while the server ran, and it was gone after a normal stop.
  • Problem 2: waiting half a second after each interface, so each listening thread exits before the next search starts, gave three runs with no errors.
  • Problem 3: skipping interfaces with no IPv4 address took start-up from 83 seconds to 30.

The router answered the search twice, so MapTool counted it as two gateways and mapped the port twice. That's harmless, since it's one mapping, but worth knowing.

I'll open a PR to RPTools/upnplib for problem 1. The proper fix for problem 2 also belongs in upnplib: each listening thread should have its own socket and its own stop signal. Meanwhile I'll open a MapTool PR for 2 and 3, which only change UPnPUtil. Once upnplib has a release with the fix, MapTool needs a version bump.

#4049 ("UPnP scanning never finishes") might be problem 2, but I can't tell from the report.

Since problem 1 affects released versions, the fix may be worth a 1.19 backport.

Lingua principale
Java
Stelle
927
Fork
286
Merge medio
3g 17h
PR unite (30g)
94

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RPTools/maptool

Tutte le issue di RPTools/maptool

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.