fix(vpn): IPv6 CONNECT parse, native Int port storage, malformed-intent guard (#019) - #45
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three independent latent bugs that fail silently or with confusing
symptoms on the internet-sharing + connect paths:
IPv6-literal HTTP CONNECT: the HTTP proxy split
CONNECT [::1]:443on
:and tookhost = "[", silently failing every IPv6-literalCONNECT (browser showed "connection failed" with no diagnostic).
Replaced the inline split with a
parseConnectTargethelper onMasterDnsVpnService.companion that handles bracketed IPv6 literals
and a missing port (defaults to 80). The helper is
internalso aJVM unit test can exercise it without Robolectric.
Non-numeric / out-of-range sharing ports: GlobalSettingsStore stored
internetSharingSocksPort/HttpPort as String and parsed with
toIntOrNull() ?: 8090/8091on load. A corrupted DataStore valuesilently fell back to defaults; an out-of-range integer (e.g. 99999)
loaded fine and threw IllegalArgumentException only when ServerSocket
bound at connect time, surfacing as a generic "Go core error".
Switched both keys to native intPreferencesKey, coerced to 1..65535
on save. Existing on-device String entries are migrated cleanly by
renaming the keys to
..._v2(option a): old String entries aresimply absent on first load and the 8090/8091 default re-applies —
no Migration code, one-time settings reset for users who had set a
non-default port (call out in release notes).
Malformed ACTION_CONNECT: onStartCommand swallowed profileId <= 0
with no log, no state update, no stopSelf. The service stayed in
START_STICKY foreground with a "Connecting..." notification and
VpnState.CONNECTING forever; the user had to force-stop the app.
Added an else branch that calls VpnManager.appendLog + setError
(UI already observes both), stopForeground (API-24-guarded with
@Suppress("DEPRECATION") fallback), and stopSelf so START_STICKY
doesn't keep the service alive with no work.
Added 5 JVM unit tests for parseConnectTarget:
No local build verified (no local Android SDK); CI on push is the
gate (android-ci.yml: debug APK + AAR).
Scope: only 3 files touched — MasterDnsVpnService.kt (+33/-3),
GlobalSettingsStore.kt (+7/-6), new test file (+41).