udp协议还是无法正常更新IP。

yulinsoft commented 2 years ago

主路由下挂了一个armbian，开了两个tcp映射和一个udp映射，在主路由做好了端口转发。程序启动后都能正常工作，但当外部IP变动时，tcp都能正常更新，通过脚本能收到提醒，但udp根本没有提醒，也没有更新，导致外部连接失效，要关闭这个映射，重新启动程序才能正常工作。希望大佬能解决这个问题。

heiher commented 2 years ago

使用的版本是？

yulinsoft commented 2 years ago

20221111 arm32版本

yulinsoft commented 2 years ago

命令如下 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

heiher commented 2 years ago

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

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

yulinsoft commented 2 years ago

测试了一下。路由器是双线，线路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可以更新。建议大佬添加日志功能，方便查找问题。

heiher commented 2 years ago

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

natmap-linux-arm32.zip

heiher commented 2 years ago

@yulinsoft 请问有进展吗？

yulinsoft commented 1 year ago

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

foobartech commented 1 year ago

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

heiher commented 1 year ago

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 等等。

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

foobartech commented 1 year ago

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

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

heiher / natmap

udp协议还是无法正常更新IP。 #4