Mike Wang

Natter 手搓实现了 UPnP 协议，但是目前在某些品牌路由器还存在兼容问题（头大）。 我觉得 NATMap 可以不必走这个老路，坑很大。 考虑下直接调用 `upnpc` 吧（miniupnp 的 client）。 https://manpages.debian.org/unstable/miniupnpc/upnpc.1.en.html ```bash upnpc -i -a 192.168.1.1 12345 12345 tcp ``` ↑ 这样就可以让路由器开放一个 `12345` 的 TCP 端口转发至 `192.168.1.1:12345` 不知道在通知脚本的时机调用是否能行，可能需要先调用...

这种情况比较少见，像是光猫没有返回标准的 HTTP 响应。 https://github.com/MikeWang000000/Natter/blob/f8257e8cff8f013202d9af9d0f9af4d986c1c718/natter.py#L1164 将 1164 行 `sock.close()` 临时改成 `sock.close(); print(response)` 然后发一下输出的内容呢？IP 地址等敏感信息可以隐去。

手动捂脸，`http://192.168.1.3:37443/upnpap.xml` 光猫响应的这个地址是不是打不开？ 然后再试试 `http://192.168.1.1:49652/49652gatedesc.xml`。

> 别用光猫 也不能说别用光猫，光猫的内置功能可能比较粗糙，我们对一些不正常的现象做一些容错处理，也是能用的。

``` TypeError: 'NoneType' object is not iterable ``` 这个问题在 https://github.com/MikeWang000000/Natter/commit/80f616de2a3d7e2831054eed60709863a4503c3a 中修复。

Natter 作为单文件的可移植小工具，不方便内置 Web 管理。 但是可以尝试使用 Docker 或者 Supervisor 等管理工具的 Web 功能达到类似的效果，可以尝试。

是的，这是 Windows 特有的一个已知 bug，并且很难解决。当 Natter 尝试复用 UDP 端口保活时，程序原有的通信会被中断（仅限 Windows）。并且 STUN 服务器的响应也有可能 “漏到” 应用程序上。 在保活的这一段时间，应用是无法与外界通信的，直至保活流程完成。而如果单纯取消保活，又有端口映射被自动关闭的可能。 由于受制于 Python 使用 Windows Socket 时的表现，这个 bug 不太可能被修复。Linux / macOS / FreeBSD 等没有这类问题，可以优先选择这类系统使用。或者使用 TCP 协议，这在 Windows...

这个不是线程的问题。而是两个UDP连接共用同一个来源端口，即使目的地址不同，在Windows上实际也只有一个连接能用（没法同时复用）。

Cloud you please send the full log? Add `-v` option to command line, and Natter will produce more verbose output.

如果 Natter 同样运行在路由器上，那么用 `-i` 选项绑定网络接口，可以不走到代理接口上。 如果 Natter 在路由器后面，那么需要分流让 `3478` 端口不走代理，`ifconfig.co:80` 和 `portcheck.transmissionbt.com:80` 不走代理。 即使是直连，部分代理实现也会改变 NAT 类型，导致打洞失败。所以省事办法就是不要将 Natter 放在代理后面。