为什么新协议，重放规则必须是拒绝呢？

[dev4u]

关联代码：
30c4b83

不清楚新协议的重放规则，为什么只能是拒绝？
昨晚更新了代码并部署，今天上班路上体验了，路上直接全程断流，数据有上行但没下行。

[database64128]

Requests that are made less than 30 seconds ago are covered by the salt filter, which only stores the salt for 60 seconds. Older requests are filtered out by checking the timestamp.

The "replay policy" code was from Shadowsocks AEAD and only controls the salt filter. For Shadowsocks 2022, it makes no sense to disable the salt filter but not the timestamp checks.

Once again, what client did you use?

[dev4u]

我用的是rust版本的shadowsocks工具。
客户端是shadowsocks-android，其中libsslocal.so依赖于ss rust的master分支进行构建。
服务端就是直接编译master分支的rust ssserver。

[zonyitoo]

There is nothing related to your problem. The Replay Filter is only applied to TCP connections.

So if connection was rejected by the filter, then you will see connections being closed immediately after connect.

Which client are you using? Did you upgrade the sslocal in shadowsocks-android?

[dev4u]

是的，我已经更新了客户端代码进行构建。
或者中午我登录上服务端看看日志。
另外你提到的，重发过滤的规则只针对tcp连接。那言下之意是不影响udp的工作？
现在的情况是tcp、udp都没下行数据。当然，我现在暂时没办法确定，我指定的端口是否被屏蔽。
我主要的工作设备是手机，所以有时候，我谈的使用体验在你看来，好像并不符合逻辑。我真没抬杠，真的是我当下在手机上的体验。（最后一段仅为吐槽一下@zonyitoo 没有安卓手机ᥬ😂᭄）

[database64128]

Well, I don't have any Android devices either. So that's two of us. 😆

[zonyitoo]

Well yes, it only affects TCP connections.

[dev4u]

上服务器一轮操作后，终于恢复了。也的确没发现有报重发的异常情况。当时登录服务器前，我试了各种方式连接服务端口，通过ipv4、ipv6的地址都没办法连接到端口。从另一台境外服务器，也没办法连接指定的端口。应该可以排除端口被屏蔽的情况。

服务器在临死之前的日志如下，希望能帮助找到问题大概的位置在哪里。
可惜我当时不知如何收集能收集rust进程中的线程情况。

2022-05-18T07:15:04.483605898+08:00 TRACE shadowsocks::relay::udprelay::proxy_socket UDP server client send to, addr 142.250.114.138:443, control: UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 1744790698363098775, packet_id: 10 }, payload length 1244 bytes, packet length 1302 bytes
2022-05-18T07:15:04.483779728+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 <- 142.250.114.138:443 with 1244 bytes, control UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 1744790698363098775, packet_id: 10 }
2022-05-18T07:15:04.483905149+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 <- 142.250.114.138:443 received 124 bytes
2022-05-18T07:15:04.483957459+08:00 TRACE shadowsocks::relay::udprelay::proxy_socket UDP server client send to, addr 142.250.114.138:443, control: UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 1744790698363098775, packet_id: 11 }, payload length 124 bytes, packet length 182 bytes
2022-05-18T07:15:04.484042939+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 <- 142.250.114.138:443 with 124 bytes, control UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 1744790698363098775, packet_id: 11 }
2022-05-18T07:15:04.530684882+08:00 TRACE shadowsocks::relay::udprelay::proxy_socket UDP server client receive from [::ffff:****]:14572, addr 142.250.114.138:443, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 10 }), packet length 83 bytes, payload length 33 bytes
2022-05-18T07:15:04.530911753+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 -> 142.250.114.138:443 with 33 bytes, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 10 })
2022-05-18T07:15:04.569990520+08:00 TRACE shadowsocks::relay::udprelay::proxy_socket UDP server client receive from [::ffff:****]:14572, addr 142.250.114.138:443, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 11 }), packet length 83 bytes, payload length 33 bytes
2022-05-18T07:15:04.570223100+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 -> 142.250.114.138:443 with 33 bytes, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 11 })
2022-05-18T07:15:04.737390282+08:00 TRACE shadowsocks::relay::udprelay::proxy_socket UDP server client receive from [::ffff:****]:14572, addr 142.250.114.138:443, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 12 }), packet length 85 bytes, payload length 35 bytes
2022-05-18T07:15:04.737583153+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 -> 142.250.114.138:443 with 35 bytes, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 12 })
2022-05-18T07:15:04.760260012+08:00 TRACE shadowsocks::relay::udprelay::proxy_socket UDP server client receive from [::ffff:****]:14572, addr 142.250.114.138:443, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 13 }), packet length 83 bytes, payload length 33 bytes
2022-05-18T07:15:04.760463613+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 -> 142.250.114.138:443 with 33 bytes, control: Some(UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 0, packet_id: 13 })
2022-05-18T07:15:04.765059320+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 <- 142.250.114.138:443 received 25 bytes
2022-05-18T07:15:04.765228801+08:00 TRACE shadowsocks::relay::udprelay::proxy_socket UDP server client send to, addr 142.250.114.138:443, control: UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 1744790698363098775, packet_id: 12 }, payload length 25 bytes, packet length 83 bytes
2022-05-18T07:15:04.765342601+08:00 TRACE shadowsocks_service::server::udprelay udp relay [::ffff:****]:14572 <- 142.250.114.138:443 with 25 bytes, control UdpSocketControlData { client_session_id: 10966905283589496290, server_session_id: 1744790698363098775, packet_id: 12 }
2022-05-18T07:16:04.553443537+08:00 DEBUG shadowsocks_service::server::udprelay udp association for [::ffff:****]:14561 is closed
2022-05-18T07:16:04.553683407+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:17:04.554593781+08:00 DEBUG shadowsocks_service::server::udprelay udp association for [::ffff:****]:14572 is closed
2022-05-18T07:17:04.556149587+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:19:09.583773744+08:00 TRACE shadowsocks_service::server::tcprelay tcp tunnel [::ffff:****]:29251 <-> 142.250.114.138:443 closed, L2R 581 bytes, R2L 5418 bytes
2022-05-18T07:19:09.583967135+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:19:09.584000085+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:20:09.380347216+08:00 TRACE shadowsocks_service::server::tcprelay tcp tunnel [::ffff:****]:23433 <-> 142.250.138.188:5228 closed with error: Connection timed out (os error 110)
2022-05-18T07:20:09.380631057+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:20:09.380707757+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:20:09.572283427+08:00 TRACE shadowsocks_service::server::tcprelay tcp tunnel [::ffff:****]:28968 <-> 127.0.0.53:53 closed with error: Connection timed out (os error 110)
2022-05-18T07:20:09.572342817+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:20:09.572372557+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:20:09.892284074+08:00 TRACE shadowsocks_service::server::tcprelay tcp tunnel [::ffff:****]:28980 <-> 142.250.138.188:5228 closed with error: Connection timed out (os error 110)
2022-05-18T07:20:09.892327654+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:20:09.892371714+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:36:21.156450569+08:00 TRACE shadowsocks_service::server::tcprelay tcp tunnel [::ffff:****]:27380 <-> 91.108.56.188:443 closed with error: Connection timed out (os error 110)
2022-05-18T07:36:21.156660569+08:00 TRACE mio::poll deregistering event source from poller
2022-05-18T07:36:21.156707099+08:00 TRACE mio::poll deregistering event source from poller
<--下面再无日志-->

[dev4u]

你这个真的太简陋了，连个帮忙文档也没。真的是用爱发电。🐂🍺

[dev4u]

you can try https://github.com/SagerNet/sing.

试了一下，与rust的客户端有兼容性冲突。一直报packet id not unique，看来只能成对使用了。

[zonyitoo]

Maybe it should be the same as the log that you showed above, some packet_id: 0 packets are continously resend to the server's port?

[database64128]

We have mixed deployments of both implementations. I'm very confident they are compatible.

packet id not unique from sing is the same thing as out of window from shadowsocks-rust: The packet is being rejected by the sliding window filter. Like I said in #841, your network is probably duplicating the first packet of these UDP sessions. Duplicate packets are just discarded and won't affect your use.

I've been using Shadowsocks 2022 for months and I've only seen this error once or twice during high speed transfers. Your situation is very unique and kind of interesting.

[dev4u]

嗯嗯，我用的更是被誉为墙中墙的移动网络，这让我很妈蛋的头疼。或者我自己尝试在握手前，先发一个敲门的包……

[dev4u]

做了个小手术：把packet_id为0的包，直接返回校验有效。
虽然不太清楚为什么会这样，现在使用起来，除了偶尔会出现没流量外，比之前要稳定多了。

[zonyitoo]

shadowsocks-rust/crates/shadowsocks-service/src/local/net/udp/association.rs

Line 275 in 4605783

client_packet_id: 1,

client_packet_id starts from 1. So for normal sslocal, it won't send packet_id: 0 in most cases, except that client_packet_id is overflowed.

shadowsocks-rust/crates/shadowsocks-service/src/local/net/udp/association.rs

Lines 555 to 567 in 4605783

	// Increase Packet ID before send
	self.client_packet_id = match self.client_packet_id.checked_add(1) {
	Some(i) => i,
	None => {
	warn!(
	"{} -> {} (proxied) sending {} bytes failed, packet id overflowed",
	self.peer_addr,
	target_addr,
	data.len(),
	);
	return Ok(());
	}
	};

Because it is increased before send, so the ssserver received packet id should be >= 2.

[dev4u]

谢谢你的努力。
我第一时间也马上更新部署，结果还是让人很沮丧。
我有个想法，不知是否可行。程序能不能检测到重放后，予以响应一段长度不定、内容不定、小区间内随机时延的报文，以此替代现有不响应请求的表现？

[database64128]

Are you still seeing packets with a 0 packet id? You said you are using shadowsocks-rust as the client, but it's impossible to happen in this setup.

[dev4u]

没有在packet 0的问题上纠结。因为我认同你们两位的看法，在代码上应该是不会有packet 0出现。