Part of UDP data is lost if the length of the UDP is larger than MTU - 28 - 10

[enuoCM]

Environment

• Android version: 7.1
• Device: Nexus6
• Shadowsocks version: v4.5.0
• Last version that did not exhibit the issue (if applicable): NA

Configuration

Put an x inside the [ ] that applies.

• [x] IPv4 server address
• IPv6 server address
• [x ] Client IPv4 availability
• Client IPv6 availability
• Encrypt method: AES-256-CFB
• Route
  • [x] All
  • Bypass LAN
  • Bypass China
  • Bypass LAN & China
  • GFW List
  • China List
  • Custom rules
• IPv6 route
• [x] Apps VPN mode
  • Bypass mode
• Remote DNS: 8.8.8.8
• DNS Forwarding
• Plugin configuration (if applicable):
• Auto Connect
• TCP Fast Open
• If you're not using VPN mode, please supply more details here:

What did you do?

Send an udp with 1472 bytes to an udp echo server(just return the received data back to client). tun2sokcs mtu is 1500.

What did you expect to see?

Client can receive 1472 bytes from the udp echo server.

What did you see instead?

Client only receives 1462 bytes.
following is the packet info caught by tcpdump: (MTU 1500, send 1472bytes)
1 0.000000 10.x.x.32 222.x.x.73 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=6325) [Reassembled in #2]
2 0.000024 10.x.x.32 222.x.x.73 UDP 57 44486 → 8388 Len=1495
3 0.233274 222.x.x.73 10.x.x.32 IPv4 57 Fragmented IP protocol (proto=UDP 17, off=1480, ID=d5b2) [Reassembled in #4]
4 0.233781 222.x.x.73 10.x.x.32 UDP 1514 8388 → 44486 Len=1495

BTW
following is the packet info caught by tcpdump: (MTU 1400, send 1372bytes)
1 0.000000 10.x.x.19 222.x.x.73 UDP 1437 42594 → 8388 Len=1395
2 0.005461 222.x.x.73 10.x.x.19 UDP 1437 8388 → 42594 Len=1395

[madeye]

It's expected. Any large UDP packets larger than this size will be dropped.

[enuoCM]

@madeye Thanks. But the behavior is a little odd. If the UDP packet length is larger than 1472, it's ok to drop it by tun2socks which rejects to relay it. But if the UDP packet length is [1463,1472] The UDP packets is not dropped, it can be relayed to remote server and received back by sslocal, but the data is trimmed. Maybe it's the issue of udprelay to tun2socks? 10 bytes socks header takes up the data?

[madeye]

There is a shadowsocks' header in each UDP packet.

[Mygod]

@madeye Hmm but trimming doesn't sound good though.

[madeye]

@Mygod I think shadowsocks didn't trim any UDP packet. Actually, trimmed data will cause authentication error on the remote.

[madeye]

BTW, we also don't support fragmentation in shadowsocks' UDP relay.

[enuoCM]

@madeye remote ss server/local received the whole data, so there should be no authentication error.

[madeye]

@linusyang Any suggestion for this?

I think it's related to https://github.com/shadowsocks/badvpn/blob/shadowsocks-android/protocol/udpgw_proto.h#L77

EDIT:

It looks we need to drop packets larger than udpgw_mtu here: https://github.com/shadowsocks/badvpn/blob/shadowsocks-android/tun2socks/SocksUdpGwClient.c#L232

[madeye]

@enuoCM Please try a smaller MTU for this: https://github.com/shadowsocks/shadowsocks-android/blob/master/mobile/src/main/java/com/github/shadowsocks/bg/VpnService.kt#L247

For example, 1480.

[linusyang]

@madeye The SockUdpGwClient was written by following UdpGwClient. It seems the assertion for checking the size of data_len was missing: https://github.com/shadowsocks/badvpn/blob/shadowsocks-android/udpgw_client/UdpGwClient.c#L335

[linusyang]

But the assertion is destructive and stops the whole program: https://github.com/shadowsocks/badvpn/blob/shadowsocks-android/misc/debug.h#L120. There should be a better mechanism for checking the condition.

[enuoCM]

@madeye Yes, I tried 1500 and 1400. Both have the issue.(Please refer to the "What did you see instead" section at the first floor).

[madeye]

Could you try aes-256-gcm crypto instead?