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

オープン
  • 何か問題がありますか？
#6,236 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
java
領域
backend, networking

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Java
スター
927
フォーク
286
平均マージ
3日 17時間
マージ済み PR（30日）
94

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

RPTools/maptool のほかの issue

RPTools/maptool の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。