SagerNet / SagerNet/sing-box

打开sing-box后阻拦udp 123 导致扫地机器人无法连网

Open
#4,208 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

not following template
Dominant language
Go
Stars
38.2k
Forks
4.6k
Avg merge
19d 15h
Merged PRs (30d)
1

Description

操作系统

其他

系统版本

ImmortalWrt 25.12.0

安装类型

sing-box 原始命令行程序

如果您使用图形客户端程序,请提供该程序版本。

1.12.25

版本
sing-box version 1.12.25

Environment: go1.26.2 linux/amd64
Tags: with_acme,with_clash_api,with_dhcp,with_gvisor,with_quic,with_tailscale,with_utls,with_wireguard
CGO: enabled
描述

最近升级了ImmortalWrt(从24.10升级到25.12.0),发现家里的扫地机器人(大疆Romo P,ip固定192.168.10.103)无法通过app连接了。折腾了好久,发现只要把sing-box关了就可以了,sing-box是裸核跑在immortal上,在配置文件里尝试了把机器人的ip不走分流,走直连,把大疆的域名过滤出来,都不行。最后通过抓包发现在打开sing-box的时候,机器人请求的服务直接被拒绝(IP 192.168.10.1 > 192.168.10.103: ICMP 119.28.183.184 udp port 123 unreachable, length 84)

root@Will:~# tcpdump -i br-lan host 192.168.10.103 -n -c 30
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:04:33.862409 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 20, length 136
18:04:33.862437 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 20, length 136
18:04:34.055420 ARP, Request who-has 192.168.10.1 (e4:3a:6e:5f:39:19) tell 192.168.10.103, length 46
18:04:34.055427 ARP, Reply 192.168.10.1 is-at e4:3a:6e:5f:39:19, length 28
18:04:35.862416 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 21, length 136
18:04:35.862437 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 21, length 136
18:04:37.862403 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 22, length 136
18:04:37.862420 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 22, length 136
18:04:39.320903 ARP, Request who-has 192.168.10.103 tell 192.168.10.2, length 46
18:04:39.320950 ARP, Request who-has 192.168.10.103 tell 192.168.10.2, length 46
18:04:39.862426 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 23, length 136
18:04:39.862442 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 23, length 136
18:04:40.015469 IP 192.168.10.103.52990 > 119.28.183.184.123: NTPv4, Client, length 48
18:04:40.015488 IP 192.168.10.1 > 192.168.10.103: ICMP 119.28.183.184 udp port 123 unreachable, length 84
18:04:40.015473 IP 192.168.10.103.47158 > 162.159.200.1.123: NTPv4, Client, length 48
18:04:40.015500 IP 192.168.10.1 > 192.168.10.103: ICMP 162.159.200.1 udp port 123 unreachable, length 84
18:04:40.015476 IP 192.168.10.103.60781 > 106.55.184.199.123: NTPv4, Client, length 48
18:04:40.015510 IP 192.168.10.1 > 192.168.10.103: ICMP 106.55.184.199 udp port 123 unreachable, length 84
18:04:40.016336 IP 192.168.10.103.38017 > 118.31.3.89.123: NTPv4, Client, length 48
18:04:40.016348 IP 192.168.10.1 > 192.168.10.103: ICMP 118.31.3.89 udp port 123 unreachable, length 84
18:04:41.861400 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 24, length 136
18:04:41.861418 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 24, length 136
18:04:43.863395 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 25, length 136
18:04:43.863414 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 25, length 136
18:04:45.861396 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 26, length 136
18:04:45.861416 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 26, length 136
18:04:47.861389 IP 192.168.10.103 > 192.168.10.1: ICMP echo request, id 39940, seq 27, length 136
18:04:47.861405 IP 192.168.10.1 > 192.168.10.103: ICMP echo reply, id 39940, seq 27, length 136
18:04:48.913616 ARP, Request who-has 192.168.10.103 tell 192.168.10.1, length 28
18:04:48.981363 ARP, Reply 192.168.10.103 is-at 8c:58:23:e4:9b:b8, length 46
30 packets captured
30 packets received by filter
0 packets dropped by kernel

问了下AI如何解决,因为sing-box版本是1.12.25,最后通过在nft表中增加bypass机器人的mac地址解决该问题。

总感觉这个方法有点不正规,或者为啥sing-box会阻拦upd port 123的请求,有什么更优雅的解决办法嘛?

重现方式

如详细描述

日志

支持我们
完整性要求
  • 我保证阅读了文档,了解所有我编写的配置文件项的含义,而不是大量堆砌看似有用的选项或默认值。
  • 我保证提供了可以在本地重现该问题的服务器、客户端配置文件与流程,而不是一个脱敏的复杂客户端配置文件。
  • 我保证提供了可用于重现我报告的错误的最简配置,而不是依赖远程服务器、TUN、图形界面客户端或者其他闭源软件。
  • 我保证提供了完整的配置文件与日志,而不是出于对自身智力的自信而仅提供了部分认为有用的部分。

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source file or test is named. Start by reproducing the supplied ImmortalWrt setup with sing-box 1.12.25 and the tcpdump trace, then trace how the UDP port 123 request is handled; done means identifying the cause of the ICMP unreachable response and establishing a supported resolution without the reported MAC-address nft bypass.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.