[BUG] - App crashes (and can't be re-started) when starting VPN with Junk Packet Count > 128

[bobpaul]

Describe the bug
I'm going to go on a limb and guess that maybe the Junk Packet Count is getting cast as a char somewhere instead of an unsigned char. I notice the Amnezia project's kernel module says Junk Packet Count must be <= 127 , but I don't really see why it couldn't be a million... The junk packet parameters are peer-specific settings that don't have to match other peers.

But once the app crashes it cannot be restarted because the app remembers the VPN was open and tries to start it again when the app opens, which causes it to crash again. So I see this as 2 bugs:

• Either put range checking on the JC input field or fix the issue which prevents Junk Packet count from being larger than 127.
• Catch exceptions when starting tunnels so that the app doesn't get in a crash-loop

Smartphone (please complete the following information):

• Device: Samsung Galaxy S10e
• Android Version: Android 12
• App Version [e.g. 3.3.3]
• Backend: Userspace

To Reproduce

1. Create and test a Wireguard tunnel to verify it's working.
2. Disconnect and edit the tunnel. Choose "Show Amnezia properties" and set

• Junk Count: 128
• Junk Min: 5
• Junk Max: 20
• Init Magic: 1
• Response Magic: 2
• Underload Magic: 3
• Transport Packet: 4
• leave init packet junk and response packet junk unset. Save

4. Test the tunnel and confirm it works, but with some connection delay.
5. Disconnect and edit the tunnel settings. Change Junk Count to 129 and save settings.
6. Attempt to start the tunnel
7. Notice the app crashes. If you have wireshark running, you'll notice no packets were sent.
8. Attempt to open the app. Notice the app crashes. Sometimes the UI loads enough that you can see the broken tunnel link is active.
9. Go to Android Settings -> Connections -> More Connection Settings -> VPN and delete the WG Tunnel VPN profile.
10. You can now open WG Tunnel again.

Expected behavior

• The app shouldn't crash. Exceptions during tunnel start should be caught and an error message of some sort shown.

Additional Mitigations that might be good

• If the app does crash during tunnel start on app start, the tunnel should not be active the next time the app opens. Do something like set a flag or record a timestamp on app start, start the tunnel, then when the tunnel starts, clear the flag. If the flag is already set on app start, don't start the tunnel. Care should be taken to define "the tunnel started successfully" so that autostart isn't simply disabled due to lack of network connectivity the previous time the app was launched.

[zaneschepke]

Hey! Thanks for reporting this.

One of the next big improvements I'm am planning is a refactor of the config screen. With this, I'm planning on adding form validation to prevent issues like this.