udp协议还是无法正常更新IP。 about natmap HOT 11 CLOSED

使用的版本是？

from natmap.

20221111 arm32版本

from natmap.

命令如下
natmap -d -u -s stun.stunprotocol.org -b 53490 -e /root/myv4update.sh
系统是
Armbian 22.11.0-trunk Jammy with Linux 5.15.67-meson

from natmap.

20221111这个版本修过udp更新问题的，之前报过PPPoE重拨不能捕获IP变更。

跑在前台看看，当问题发生时，natmap有报错误信息吗？

from natmap.

测试了一下。路由器是双线，线路1有nat1，线路2没有。路由器中armbian设定只走线路1。开两个终端，一个运行tcp，一个运行UDP。都能同时映射。登陆路由器断掉线路1后重拨。Tcp输出如下：
root@YF-BOX:~# natmap -s stun.stunprotocol.org -h qq.com -b 80 -e /root/updatei p.sh
save ok!
[E] get_addr src/hev-sock.c:38
[E] hev_sock_client_tcp src/hev-sock.c:123
[E] tnsk_run src/hev-tnsk.c:93
[E] get_addr src/hev-sock.c:38
[E] hev_sock_client_tcp src/hev-sock.c:123
[E] tnsk_run src/hev-tnsk.c:93
[E] get_addr src/hev-sock.c:38
[E] hev_sock_client_tcp src/hev-sock.c:123
[E] tnsk_run src/hev-tnsk.c:93
[E] get_addr src/hev-sock.c:38
[E] hev_sock_client_tcp src/hev-sock.c:123
[E] tnsk_run src/hev-tnsk.c:93
[E] get_addr src/hev-sock.c:38
[E] hev_sock_client_tcp src/hev-sock.c:123
[E] tnsk_run src/hev-tnsk.c:93
[E] get_addr src/hev-sock.c:38
[E] hev_sock_client_tcp src/hev-sock.c:123
[E] tnsk_run src/hev-tnsk.c:93
save ok!
“save ok!”是我的更新脚本的输出。
UDP终端完全无输出。
说结果：
UDP映射更新了两次（根据脚本提示判断），第一次映射到了线路2，线路1恢复后又映射到线路1，可以正常访问。
TCP映射更新了一次，直接映射恢复后的线路1，日志如上。
长时间后无法测试，一般24小时甚至更长时间后，UDP似乎是睡死了，不会更新，tcp可以更新。建议大佬添加日志功能，方便查找问题。

from natmap.

试试这个程序，把日志重定向到文件中。如果问题触发了，请将日志完整上传，我们再看看是怎么回事吧。

natmap-linux-arm32.zip

from natmap.

@yulinsoft 请问有进展吗？

from natmap.

是我的问题，新版很稳定。

from natmap.

natmap-linux-mips32el v20221203 在运营商分配的 ip 自动变化的时候，tcp 正常，udp 不能正常更新，看日志似乎在 stun 那一步卡住了；但是手动触发 pppoe 重连又都能正常工作。

# 命令
./natmap -s stun.stunprotocol.org -h qq.com -b 444 -t 127.0.0.1 -p 443 -e ./notify.sh # tcp
./natmap -u -s stun.stunprotocol.org -b 3001 -t 127.0.0.1 -p 3000 -e ./notify.sh # udp

# 日志
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305

# 系统内核
uname -a
Linux OpenWrt 5.10.138 #0 SMP Sat Sep 3 02:55:34 2022 mips GNU/Linux

from natmap.

natmap-linux-mips32el v20221203 在运营商分配的 ip 自动变化的时候，tcp 正常，udp 不能正常更新，看日志似乎在 stun 那一步卡住了；但是手动触发 pppoe 重连又都能正常工作。

# 命令
./natmap -s stun.stunprotocol.org -h qq.com -b 444 -t 127.0.0.1 -p 443 -e ./notify.sh # tcp
./natmap -u -s stun.stunprotocol.org -b 3001 -t 127.0.0.1 -p 3000 -e ./notify.sh # udp

# 日志
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305
natmap: [E] stun_bind src/hev-stun.c:252
natmap: [E] task_entry src/hev-stun.c:305

# 系统内核
uname -a
Linux OpenWrt 5.10.138 #0 SMP Sat Sep 3 02:55:34 2022 mips GNU/Linux

从日志上看是UDP发送成功，但接收超时了。我本地模拟不能复现这种情况，不排除一种可能性是STUN服务器主动不响应，这个现象之前在调试程序过程中也遇到过，比如频繁的STUN请求下。UDP模式建议使用国内的服务器，比如 stun.qq.com 等等。

我建议再观察看看，自动重拨时业务中断的时间窗口大概会有多久。

from natmap.

我建议再观察看看，自动重拨时业务中断的时间窗口大概会有多久。

好的，udp 模式已切换成 stun.qq.com，如果还有问题估计也要几天才能复现，到时候再反馈。

from natmap.