Agreed, but I think this will force the average user to upgrade* their phones after losing access to sensitive apps (bank, gov) before getting compromised.
Good news for reusing old phones and taking control.
Considering that it's rare to get kernel (or any) updates on non-flagship phones, it seems likely.
Backporting an old kernel should be possible, but the only indicator is the system update changelog that explicitly mentions it, I rarely see CVEs mentioned in changelogs on any smartphone. A tool to test the vulnerability is the only way.
Any compromised app on the Play store or external can get root access instantly, but we can still rely on trust and audits when installing apps which should always be the rule.
I suspect that this will be added to all Google Play integrity levels, limiting many apps from being installed on unpatched phones in the future.
That's not the case with browsers with random sites and ads which is hardly avoidable, having any sandbox escape is now more severe considering that it bypasses the app container. It's similar to JailbreakMe on iOS [0]
Not to mention its practically beyond Google to fix, the majority of Android phones are affected. Not as big of an issue with servers/desktops.
It's rare to get kernel (or any) updates on non-flagship phones, backporting an old kernel should be possible, but the only indication that it's fixed is the system update changelog that explicitly mentions it, I rarely see CVEs in changelogs on Androids. A tool to test the vulnerability is the only way.
Any compromised app on the Play store or external can get root access instantly, but we can still rely on trust and audits when installing apps which should always be the rule.
I suspect that this will be added to Google Play integrity levels, limiting many sensitive apps from being installed in the future.
That's not the case with browsers with random sites and ads which is hardly avoidable, having any sandbox escape is now more severe considering that it bypasses the app container. It's similar to JailbreakMe on iOS [0]
Tip: Install a Chromium flavor browser (Chromite) separate from the main browser.
Disable Javascript and hardware accelerated video decoder (commonly exploited) from the flags page and enable reader mode to fix broken JS-dependent websites when browsing blogs and random sites on your personal devices, else dedicate a tablet.
It's not just a gaming and performance distro, it includes QoL fixes on modern hardware.
On my Lenovo laptop, fixes that would take over a day to enable and patch on most distros:
- Wake from sleep
- Nvidia GSP firmware workarounds and correct version OOTB (proprietary)
- Mouse lag/jitter
- External display hotplug
- DDC/CI over type-c
- Embedded controller power profiles from taskbar with correct TDP limits for CPU/GPU
- Battery charge limiter support right from KDE settings
- Working `switcherooctl` in hybrid graphics mode on AMD
- Firefox with video decode acceleration (YouTube) on almost all GPU models
Another gaming feature that is otherwise useful in workstations is the external scheduler support.
Currently using BPFland which makes multitasking as responsive as idle while compiling Yocto/Chromium in the background.
Windows, Mac (mini M1), and kernel built-in scheduler Linux jank and become almost unusable (Ryzen 5800H).
> Fast roaming has not, does not, and never will require APs be on the same channel. Only the SSID and password needs to match.
There were no mentions of requirements for 802.11r in the comment. You removed "much faster than K/V." from the quote. "only" was referring to 802.11r exclusively. You can have the same results with different channels with K/V, provided that the clients support it as the rest of the comment mentions.
802.11r-only on different channels is ineffective for devices without K/V, since the reductions are insignificant.
You will be shaving 100ms from a 700ms delay on scan and association, compared to no-scan association which is around 20ms, hence the 75ms note.
And even then, FT is only needed for short buffer streaming like VoIP and VoWiFi. It's more important for WPA3, since handshake roundtrips are even longer (~300ms) which can degrade video/voice internet calls with a lengthy time to recover and complete silence for second or two on VoIP, it's not really needed for the average user back when WPA2 was standard.
Android and iOS will first scan on the same frequency, then rotate through the channels, which is now even longer on 6Ghz capable devices with the total number of channels.
The transition time is significantly faster with equal channels on most hardware, this is where 802.11k helps with different channels, especially in iOS. Without it, they cache scan results provided that the farthest AP is detected, this rarely happens since the scan time is so short.
Scanning different channels while connected causes large amount of jitter on station optimized WiFi SoCs, affecting VoIP on mediocre connections while the user is moving and actively losing signal, so its done as quick as possible, often missing many beacons. They can scan longer on the same channel without degradation. [0]
Without K/V, iOS/Android goes to the extent of doing frequent rescans on low network activity on body movement, you can install a Wi-Fi diagnostic profile to view the current activity on iOS, logcat on "fused" for Android.
The suggestion doesn't bash on 802.11k/v, it's just a compatibility alternative, considering that very few clients support it, let alone off the shelf consumer AP support.
> Setting them to the same channel will cause the APs to interfere (when they can't "hear" each other) or block each other from transmitting, or both. You set APs near each other so they are on non-overlapping bands. Always.
> This is basic WiFi networking 101
This is only true under large air time traffic and in large scale indoor setups. Not satellite APs that are far. Qualcomm, Mediatek and many systems implement their own spatial reuse technology.
WiFi 6+ introduces BSS coloring for channel width overlaps to further improve speeds on mixed traffic, not to mention the generally low penetration / TX power of 5Ghz+ on SNR.
>> Samsung is known to push protocol support early: 802.11r in 2013
> 802.11r was released in 2008 and rolled into 802.11-2012.
> Also, the iPhone 5S (2013) has 802.11r support.
The Samsung line in the comment was referring to Androids, many Android didn't support these until 2020, some non-flagship still don't (disabled), Samsung was notable to include it early, there are three paragraphs underneath referring to old phones and smart TVs, both Androids.
It is not enabled by default on many off the shelf APs for these reasons.
The elevators are probably causing rapid blind spots (shadows) while the user is moving around, 802.11k is indeed useful in this case for cutting down scan time, since iOS will still scan with filtered channels.
It's an interesting setup, looking forward to an update.
You can stick to 802.11r only by lowering the transmission power and have all the APs on the same channel, in my tests it ended up switching much faster than K/V. (~75ms)
On iOS, equal channel with correct ESS will switch liberally. On Android 14+ with Broadcom chip it will start conservative, then switch liberally after the first poor signal switch-over event, up until disconnection.
Android (Pixel/Moto) will never switch (even with K/V) on large network activity, only VoIP/video call. It depends on vendor implementation. [0]
I use "dp.logcatapp" log reader while roaming, "com.android.location.fused" can be used to show score and current load.
Samsung is known to push protocol support early: 802.11r in 2013, 802.11w 2015, some models do not use Android's default connectivity manager.
To add, WPA3 with 802.11r is known to have issues on Apple hardware before 2021 on all iOS versions, many Android devices, especially smart TVs don't support it, will not connect or are unreliable (protected beacon frame), can be searched in buried report results at OpenWrt forum mega threads and Ubiquity. WPA2+FT and forced MFP with a long password is a safe alternative. 802.11r use PMK push on WPA3 compared to WPA2, which was known to be problematic on older hardware.
802.11K/V is more suitable for campus and load balancing, tuning it based on RSSI and station metrics is very difficult, enterprise hardware rely on network traffic and air time.
For reference, Octopart is useful to track prices from many distributors, linked below [0] is a commonly used memory (1G) for Rockchip, Amlogic, Allwinner on many Radxa and Orange Pis.
You can now run Docker images in Termux with Udocker/proot[0], the disk IO can be a bottleneck for large databases when using proot.
Tailscale works with "--tun=userspace-networking" [1].
I had it running on an old phone as a Frigate server with a solar powerbank in remote area, using the 4G as a failover. The uptime is almost a week without solar.
Attiny hooked to the power button and a photodiode on the phone flash [2] (blink per minute) used as a watchdog for shutdowns/hangs to hardware reset. The button cap is removed without disassembling the phone.
Old phones are still more efficient than most off the shelf SBCs, especially under load.
~3W compared to 12W with a Pi5 in the same performance ballpark.
Non-generic adapters are fixed in custom ROMs/LOS, on stock Android 16 my ZTE modem is still reporting as usb0 due to MAC address local bit, while Huawei dongle works just fine.
Android phone to android tablet USB tethering is also local MAC and non-functional.
Still using a very old Tab S 10.5 from 2014 running a bit slow with LOS 21 - Android 14.
Started with Android 4 KitKat, stuck with Linux kernel 3.4 :)
5.4mm thickness, 3GB RAM (enough for 32-bit), 2TB SD card works, watching movies/shows with the AMOLED look as good as a recent OLED TV. Truly ahead of their time.
SDR content with mDNIe dynamic enabled comes surprisingly close to HDR content on an HDR display, colors can be a bit too staturated though.
After a decade, the battery lasts a week for daily hour e-book with black background. 3 hours of video playback.
However, it restarts at 30% battery when running at full brightness with a white background.
Disabling Wi-Fi significantly extends standby time compared to modern hardware.
Caveats: Slow web browsing and no H.265 hardware decoder.
1440p H.264 60Mbit is the max (Display is 1600p).
Most content providers and streaming services are slowly moving away from AVC, so it's stuck at 720p H.265 on CPU.
Back in 2014, I couldn't have imagined using hardware that was over a decade old.