Repository navigation
Keeps the managed-mode gateway's MAC across starts, so clients don't see a new network every time - #8
Merged
Conversation
vaplan0 is a new veth on every start, so the gateway gets a new random MAC each time and clients treat the hotspot as a new network. -m <mac> sets a fixed MAC on vaplan0 before it comes up; empty, the default, keeps the random one. A MAC equal to ap0's is refused, since the bridge would keep the gateway's frames for itself. caps now reports the Wi-Fi's factory MAC (mac=, from Android's Wi-Fi settings store, the kernel or Samsung's efs) and status the gateway's live one (gw_mac=).
Advanced gets a Gateway MAC mode with a MAC box: Random every start (the default, read-only, shows the live MAC while running), Random once (picked once and kept, editable) and Static MAC (prefilled with the Wi-Fi's factory MAC, editable). An invalid MAC blocks Start through isValid().
Contributor
Author
|
I should add that i been using this and its working just fine |
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.
Problem
In managed mode the clients' gateway is
vaplan0, the container end of the veth pair thatconfig_network_bridged()creates on every start. A new veth gets a new random MAC from the kernel, so the gateway's MAC changes every time the hotspot or the container restarts.Clients that remember networks by their gateway's MAC see a brand new network each time. Windows is the obvious one: it creates a new profile (
wn17 2,wn17 3, ...) and puts it back in the Public category, so setting it to Private never sticks and discovery and file sharing get blocked again.Fix
The backend gets
-m <mac>, saved inap.confasGW_MAC, which sets the MAC onvaplan0after the rename and before the link comes up. Empty, the default, keeps the random one, and a MAC the kernel refuses is a warning, not a failed start. A MAC equal toap0's is refused too, becauseap0sits on the same bridge and the bridge would keep the gateway's frames for itself.capsnow reports the Wi-Fi's factory MAC asmac=, andstatusthe gateway's live one asgw_mac=. The factory MAC comes fromwifi_sta_factory_mac_addressin the Wi-Fi service'sWifiConfigStore.xml, which AOSP fills from the Wi-Fi HAL on Android 11 and up, so it doesn't depend on the vendor. The kernel's permanent address and Samsung's efs copy are the fallbacks.In the app, the Advanced card in managed mode gets a Gateway MAC mode and a MAC box, in place of the DNS field the container owns there:
An invalid MAC blocks Start through
APConfig.isValid(), so the Quick Settings tile follows it too. Routed mode is untouched: its gateway isap0, and that MAC belongs to the Wi-Fi driver.Tested on a Samsung Galaxy A15 4G (SM-A155F, MT6789) in managed mode with the OpenWrt container