Database Develop

Getting proper su at very early init via one of .rc files?

Hello dear Chainfire and community!
I have a rather obscure issue: I want to run a root script at very early init.
The script (predictably) runs afoul of Selinux policy (who'd have thought) and since it's a chinese phone no sources are available.
Good things:
I can unpack/repack boot.img without issue, and can add/start services from .rc
Phone is rootable and after proper boot, SuperSu works fine (and so does setenforce 0)
Bad things:
This is lolipop 5.0 so install-recovery.sh and anything else of that general kind is not available
Source (and thus opportunity to change sepolicy) not available
SuperSu daemon's normal start is waaaaay too late for what I'm trying to do.
Question:
Given that I can add my own service and run it as I please, is there a way to "kickstart" su functionality early-on (so I can set Selinux to permissive and run my stuff), without breaking functioning of supersu after boot completes?

[AOSP] sepolicy patch for Marshmallow ROMs

After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a

Stickied.

sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?

WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.

Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.

Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:

BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.

@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?

Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above

Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.

the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...

Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?

BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk

danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing

I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks

Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688

Thank you for your work!

Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.

I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.

It reminds me of Korean dramas ,

[Module][10.14.2018][Discontinued] Magisk SELinux Manager

This project has been discontinued. The final state of the module can be found at the GitHub Repo https://github.com/Jman420/magisk_selinux_manager.
Magisk SELinux Manager
A Magisk Module dedicated to the manipulation and analysis of SELinux.
Features
* Select SELinux mode to set at startup
Usage
The SELinux mode to set at startup must be specified during module installation. The SELinux mode can be selected either by specifying the mode (permissive or enforcing) in the install zip's filename (ie. magisk_selinux_manager_v1.0_permissive.zip) or using your phone's volume keys when prompted.
Disclaimer & Recommendations regarding Permissive Mode
This module should be used to enable SELinux Permissive Mode only as a last resort only if appropriate SELinux Permissions can not be generated and injected into the SELinux Policy using selinux-inject, supolicy or magiskpolicy. Putting your device into Permissive Mode will essentially disable all of the operating system level security built into Android and allow any app in any context to do whatever it wants. Actions requiring root access will still trigger your SU Manager App, but all apps have elevated privileges due to permissive mode and may be able to take malicious actions on your device without needing root access. If you find that this module fixes issues you are experiencing with an app I recommend contacting the app developer and trying to work with them to isolate the necessary SELinux Permissions and have them injected into the SELinux Policy at startup.
Here is a discussion of some of concerns to consider when running your device in Permissive Mode : https://forum.xda-developers.com/gen...risks-t3607295
GitHub Repo : https://github.com/Jman420/magisk_selinux_manager
Requirements
* SELinux enabled kernel
* Magisk v15.3+
Change Log
* v1.0.5 - Update Unity Installer Files to v1.5.4
* v1.0.4 - Update Unity Installer Files to v1.5.3
* v1.0.3 - Update Unity Installer Files to v1.5.2
* v1.0.2 - Update Unity Installer Files to v1.4.1
* v1.0.1 - Update Unity Installer Files to v1.4
* v1.0.0 - Initial Release
Special thanks!
* topjohnwu - For providing Magisk and the interesting insights that its source code gave into SELinux
* ahrion & zackptg5 - For providing the Unity Installer and Vol Key Input code
* Everyone who supported the old magisk_permissive_script module and giving me a bit of motivation to keep working on SELinux stuff
Release Distribution Plans
All Releases are available on the Magisk Module Repo. Releases will not be distributed here.

Jman420 said:
Magisk SELinux Manager
A Magisk Module dedicated to the manipulation and analysis of SELinux.
Features
* Select SELinux mode to set at startup
Usage
The SELinux mode to set at startup must be specified during module installation. The SELinux mode can be selected either by specifying the mode (permissive or enforcing) in the install zip's filename (ie. magisk_selinux_manager_v1.0_permissive.zip) or using your phone's volume keys when prompted.
Disclaimer & Recommendations regarding Permissive Mode
This module should be used to enable SELinux Permissive Mode only as a last resort only if appropriate SELinux Permissions can not be generated and injected into the SELinux Policy using selinux-inject, supolicy or magiskpolicy. Putting your device into Permissive Mode will essentially disable all of the operating system level security built into Android and allow any app in any context to do whatever it wants. Actions requiring root access will still trigger your SU Manager App, but all apps have elevated privileges due to permissive mode and may be able to take malicious actions on your device without needing root access. If you find that this module fixes issues you are experiencing with an app I recommend contacting the app developer and trying to work with them to isolate the necessary SELinux Permissions and have them injected into the SELinux Policy at startup.
Here is a discussion of some of concerns to consider when running your device in Permissive Mode : https://forum.xda-developers.com/gen...risks-t3607295
GitHub Repo : https://github.com/Jman420/magisk_selinux_manager
Requirements
* SELinux enabled kernel
* Magisk v15.3+
Change Log
* v1.0 - Initial Release
Special thanks!
* topjohnwu - For providing Magisk and the interesting insights that its source code gave into SELinux
* ahrion & zackptg5 - For providing the Unity Installer and Vol Key Input code
* Everyone who supported the old magisk_permissive_script module and giving me a bit of motivation to keep working on SELinux stuff
Release Distribution Plans
I have submitted a request to include this module in the Magisk Repo List. Once that request has been accepted the Magisk Repo List will be the ONLY source for up to date releases of the module. Until that time I will provide download links through this posting.
Click to expand...
Click to collapse
What are the differences with this zip and the old one?

dredq said:
What are the differences with this zip and the old one?
Click to expand...
Click to collapse
When installing the module you can choose if SELinux should be set to enforcing or permissive (it's written right there in the OP).

Didgeridoohan said:
When installing the module you can choose if SELinux should be set to enforcing or permissive (it's written right there in the OP).
Click to expand...
Click to collapse
Sorry. I saw that. I was wondering if there where any other differences.

dredq said:
Sorry. I saw that. I was wondering if there where any other differences.
Click to expand...
Click to collapse
Nope, if there were I'd have mentioned them.

I installed the module and set it to permissive, but when I restarted my phone now it is stuck in the boot animation. I tried uninstalling using the magisk uninstaller, but still the problem remains. Is there a way to undo the changes from Recovery? Thank you! Running lineage 14.

samplebird said:
I installed the module and set it to permissive, but when I restarted my phone now it is stuck in the boot animation. I tried uninstalling using the magisk uninstaller, but still the problem remains. Is there a way to undo the changes from Recovery? Thank you! Running lineage 14.
Click to expand...
Click to collapse
You can flash the zip again to uninstall, thanks to Unity Installer... but I don't expect that to do anything different than the Magisk Uninstall. You may need to debug your Magisk installation with Magisk Manager for Recovery (https://forum.xda-developers.com/apps/magisk/module-tool-magisk-manager-recovery-mode-t3693165).

samplebird said:
I installed the module and set it to permissive, but when I restarted my phone now it is stuck in the boot animation. I tried uninstalling using the magisk uninstaller, but still the problem remains. Is there a way to undo the changes from Recovery? Thank you! Running lineage 14.
Click to expand...
Click to collapse
Did you try installing the module again and choosing enforcing instead of permissive?

Update v1.0.1 has been released on Magisk Repo. No real functionality updates, just updated Unity Installer to latest (v1.4). See change logs for Unity Installer here : https://forum.xda-developers.com/android/software/module-audio-modification-library-t3579612
I've also migrated to using Semantic Versioning for this project (although it's probably not needed). See details here : https://semver.org/

The module doesn't seem to be part of the magisk repo yet. But v1.0.0 us working fine on my side anyway. :good:

PixelChris95 said:
The module doesn't seem to be part of the magisk repo yet. But v1.0.0 us working fine on my side anyway. :good:
Click to expand...
Click to collapse
Clear the repo cache (Manager settings) and reload the Downloads list (pull down).

Didgeridoohan said:
Clear the repo cache (Manager settings) and reload the Downloads list (pull down).
Click to expand...
Click to collapse
That did the trick. Thx!

Not working on Oreo b390 Huawei P10. SeLinunx remains on enforce:
watch this issue:
https://forum.xda-developers.com/p10/help/magisk-16-0-p10-orea-t3765921

mxn2000 said:
Not working on Oreo b390 Huawei P10. SeLinunx remains on enforce:
watch this issue:
https://forum.xda-developers.com/p10/help/magisk-16-0-p10-orea-t3765921
Click to expand...
Click to collapse
"Preserve Forced Encryption" doesn't have anything to do with SELinux. That's /data encryption...
Try running:
Code:
setenforce permissive
And if that still doesn't work, run this and use whatever options are available, or return with the result:
Code:
setenforce --help

Every time I setenforce 1 it always says Permissive after .. Even after reboot or in the Twrp terminal .. Anytime I type grtenforce it always says Permissive. What do I type in terminal emulator to access this mod? Am I missing something here?? Lol sorry - still learning.

Intelli69 said:
Every time I setenforce 1 it always says Permissive after .. Even after reboot or in the Twrp terminal .. Anytime I type grtenforce it always says Permissive. What do I type in terminal emulator to access this mod? Am I missing something here?? Lol sorry - still learning.
Click to expand...
Click to collapse
You don't have to do anything after installing the module. At installation your choose enforcing or permissive, and then that's what the module will set at each boot.

OK I thought that was it! Thanks!

so should use this one or old version?
or it is still the same function?

does this work on samsung?

lawong said:
does this work on samsung?
Click to expand...
Click to collapse
Yup, as long as you have magisk.

Magisk boot script help for pixel 2 xl

Hi guys,
I'm trying to make a script to enable the android 11 notification shade blur in my pixel 2 xl,, so far I have managed to successfully enable it with ADB with this command:
adb shell
taimen:/ $ su
taimen:/ # setprop ro.surface_flinger.supports_background_blur 1
taimen:/ # stop
taimen:/ # start
It does work fine but as soon as the phone reboots it is lost
I made a magisk module and also managed to make a setprop mod with magiskhide that does indeed successfully add ro.surface_flinger.supports_background_blur 1 in build.prop, but the mod does not work unless I adb and input the command
adb shell
taimen:/ $ su
taimen:/ # stop
taimen:/ # start
I believe this is to restart system UI.
Is there any way to do this in magisk automatically at boot?
When I input in termux
su
# stop
The phone seems to try to restart the UI but it gets stuck in google logo, unlike when I do it via adb the screen goes blank and comes back alive when I input via adb
# start
I'm a complete noob in this stuff, I would really like to make a magisk script or module that let me do this, it would be useful to try first via termux to avoid a magisk boot loop in case something goes wrong with this script. The notification blur is actually the only reason I unlocked the bootloader an rooted the phone...
Thanks in advance.

You should use Magisk's resetprop tool.
All you should need in your boot script is this:
Code:
resetprop ro.surface_flinger.supports_background_blur 1
Try using service.d first, but if that doesn't work move the script to post-fs-data.d.
Or, if you're using a module, use a system.prop file.

Does "magiskhide props config 5.3.6" uses resetprop?
I did try that in service.d and post-fs-data.d
As I said, the property does seem to be changed with the setprop, since after a restart of the phone all I need to do is
Adb shell
Su
Stop
Start
And I get the blurred notification shade...

Yes, MagiskHide Props Config uses resetprop (but there you generally don't need to change to late_start service or post-fs-data, the default should be fine most of the time).
With resetprop you shouldn't need to run stop/start. That's the difference.

I did not try the delay option. I really don't know what else I could try though...
Maybe there's a delayed script I could run with the stop/start command?
Edit: sorry if I understand what you're saying, should I delete the magiskhide props config key and instead do it manually? That way I should no need the stop/start command.

I thought you had been doing it manually all along... To quote your first post: "I'm trying to make a script", "I made a magisk module and also managed to make a setprop mod".
If the stop/start commands need to be included for this to work, making your own boot script with the resetprop command and stop/start commands is the way to go.

Yeah yeah sorry, I did manage to make the module, the setprop mod I was referring to was via magiskhide...
My problem is when I try to run this stop/start script in termux
#!/system/bin/sh
su
cd
cd data/adb
stop
start
The phone goes to google logo and is stuck there, I'm afraid if I do that with magisk I could get a non booting phone...

Does this script sounds good to you?
#!/system/bin/sh
resetprop to.surface_flinger.supports_background_blur 1
stop
start
BTW I really appreciate your help!
Edit: just ran this script from termux and stuck at google logo...
Edit 2: if anyone is wondering or maybe it helps someone I ended up making this simple script in service.d
resetprop to.surface_flinger.supports_background_blur 1
Then I discovered all I needed was the terminal command
# killall surfaceflinger
And Systemui does successfully restart with the blurred background, so I created a home screen shorcut with this terminal command and all I need to do is hit the shorcut shortly after booting and it works, it's not automatic but it gets the job done...
Thanks @Didgeridoohan for your help... XDA rocks!

Hello!
I don't know if you're still looking for this but decided to share anyway.
Attached to this post is a Magisk module that enables Background Blur that survives reboots....
It's weird that a simple Magisk module with a system.prop doesn't work but ok... had to create this version which uses a service.sh script to do the job.
You'll need Magisk, obviously.
Enjoy!
Cheers!

Thank you for making this. The double restart is kinda annoying tho

Typhus_ said:
Hello!
I don't know if you're still looking for this but decided to share anyway.
Attached to this post is a Magisk module that enables Background Blur that survives reboots....
It's weird that a simple Magisk module with a system.prop doesn't work but ok... had to create this version which uses a service.sh script to do the job.
You'll need Magisk, obviously.
Enjoy!
Cheers!
Click to expand...
Click to collapse
Is this module device specific or will it work on other devices running Android 11?

rodken said:
Is this module device specific or will it work on other devices running Android 11?
Click to expand...
Click to collapse
It should work on any device running Android 11.

Typhus_ said:
It should work on any device running Android 11.
Click to expand...
Click to collapse
Perfect - functions as expected on OnePlus 8 OOS 11.

How about android 13?

Troubleshooting wifi problems on S2 exynos5433 tablet ONLY discussion for users running any version of Android 10

The S2 wifi blobs have now been incorporated into the Aug 25 17.1 builds.
Please take 10 minutes to read all of post #1 and #2. lpedia and I have spent 5 days troubleshooting this together and want to present our wifi findings. DO NOT USE this thread to report any other problems, it's only for exynos5433 S2 tablet wifi. If this is unreasonable, then stop reading. Thank you.
If your device's wifi is not connecting after a restart and/or wake from sleep, and/or dropping out at random, this could be because the 17.1 code is using Samsung Galaxy S6 wifi blobs instead of its stock S2 wifi blobs. This commit was made in 17.1 at
gts2: Import Galaxy S6 BCM4358 firmware · universal5433/[email protected]
@lpedia has confirmed that LineageOS 17.1 on his T710 has the wifi problems when using S6 blobs, but not after the S6 blobs have been replaced with stock S2 blobs. This appears to fix both non-connection at boot and not reconnecting on wake from sleep. Random dropouts are less common and were not seen during the limited testing, so it's not certain that they're gone.
FAQ
Q1. Will changing from S6 wifi blobs solve all my wifi no reconnect or disconnect problems?
A1. This has only been tested on the T710, and there's no guarantee it will help the other devices. If you want to try, follow the instructions below. Before you try, make sure to back up all your data. The following should write the stock S2 blobs to the /system partition only, but if you make a mistake you could lose your data! Back up first.
It's an easy test to see if the stock S2 blobs will help or not. If your current rom does not connect to wifi after a restart, try our proposed solution. Before you do, reboot your current rom 5 times in a row. After each reboot, see if your wifi connects. After you install stock S2 blobs, reboot your device again 5 times in a row and see if wifi connects. This will easily tell you if the S2 stock blobs have solved this one particular problem or not.
As for wifi not connecting after long/deep sleep, you should notice over 2 or 3 days if wifi connects or not after deep sleep.
Q2. Will this work on SM-T710, SM-T810, etc?
A2. Same answer as A1. It should work on any S2 tablet exynos5433 device that uses the S6 wifi blobs that are the default in 17.1 or Android 10. These instructions are only for exynos5433 devices.
As the thread grows bigger, you can see who is responding back with either positive or negative feedback and what model they have.
Q3. Will this work on RR, Havoc or LineageOS (Android 10 or 17.1)?
A3. The instructions below replace the S6 blobs with the original stock S2 blobs. The instructions provided should work regardless if it's Havoc, RR or LineageOS. All these variant OSes share the same repo (i.e. code and blobs) on github.
Q4. Is this post relevant to Android 9 or LineageOS 16.0?
A4. NO. The github repos show that Android 9 or LineageOS 16.0 used the stock S2 wifi blobs. This was changed to S6 wifi blobs in Android 10 or LineageOS 17.1. I don't know why it was changed to S6 blobs as I'm not involved with that change.
Q5. Why do I need my model and code name?
A5. In order to follow the instructions below, you need to know your model number and it's code name. The model number or device name is settings, about tablet.
You can find the code name at (scroll almost all the way down to the bottom)
Samsung
This is the Team Win website and the official home of TWRP! Here you will find the list of officially supported devices and instructions for installing TWRP on those devices.
twrp.me
For example, SM-T710 is gts28wifi.
Q6. Does it matter if my wifi is 2.4Ghz or 5Ghz or a mix of both?
A6. When reporting back to us, please state whether your network is 2.4Ghz only, 5Ghz only, or a mix of 2.4Ghz and 5Ghz. In addition, if its a mix, please let us know if it's one wifi network (same ssid) or two separate wifi networks. That is, 2.4Ghz is one ssid and 5Ghz is another ssid.
Q7. If this works, how will this be fixed for the next release of code and the future?
A7. If enough people say it fixes their wifi problems, I can submit a git pull request to Anan to revert the S6 wifi blobs back to S2 wifi blobs.
Instructions
1. Make sure adb debugging is enabled in developer options. To enable developer options, tap settings, about tablet, build number 7 times until it says developer options unlocked. Go back to settings, system, advanced, developer options, enable android debugging and rooted debugging.
Note if you are running Magisk, see posts regarding Magisk if you cannot see rooted debugging.
2. You will need git. There are instructions and download links for installing git on Windows, MacOS, and Linux at Git Guides - install git | GitHub.
3. After you install git, follow the instructions exactly below.
Bash:
# make temporary vendor directory
mkdir temp
# cd to that directory
cd temp
# git the 16.0 stock drivers
git clone https://github.com/universal5433/proprietary_vendor_samsung -b lineage-16.0
# change directory to proprietary_vendor_samsung/<your device>/proprietary/system/vendor/etc
# or if Windows, to proprietary_vendor_samsung\<your device>\proprietary\system\vendor\etc
# where "<your device>" is your device's code, for example gts28wifi for the T710:
cd proprietary_vendor_samsung/gts28wifi/proprietary/system/vendor/etc
# start adb root
adb root
# remount /system as rw (it's read only by default)
adb remount
# start adb shell
adb shell
# delete S6 blobs from wifi directory
cd /system/vendor/etc/wifi
rm bcm*
rm nvr*
# There should be only .conf files left now
ls -al
exit
# you should be back at your desktop terminal prompt now
# now push all stock drivers to /system/vendor/etc/wifi
adb push wifi /system/vendor/etc
# check to make sure it got pushed okay
adb shell ls -al /system/vendor/etc/wifi
# now reboot Android
adb reboot
If the above does not work for you, or if it causes other problems, just reflash the last rom. That will overwrite the /system partition and everything will be restored.
If you do try this, please report back to this thread about whatever happened and include your device and what wifi network you are running.

Reserved.

Thanks for the instructions!
I had to boot my T810 (gts210wifi) into TWRP and mount /system from there before adb root and adb remount was possible. Everything else worked as described.
Observations after 5 reboots: WiFi available after reboot each time! Much better than before!
I will observe it now for a while regarding wifi-off after sleep or sporadical wifi-off.
Btw. for the random reboots of the unmodified linageos17.1 (ripee) I'm pinging my DNS-server all 2mins using Tasker. Fixed reboots since 2 month at least on my system.

Yogi555 said:
I had to boot my T810 (gts210wifi) into TWRP and mount /system from there before adb root and adb remount was possible.
Click to expand...
Click to collapse
The above might be due to you not having adb root enabled in developer options. I will update the instructions to make sure that's enabled.

Strangely the setting seems not there in my system. But I remember that in some system its available. Can the installed Magisk be the reason?

Yogi555 said:
Strangely the setting seems not there in my system.
Click to expand...
Click to collapse
It's there.

Short update: The S2 wifi blobs are a huge improvement. With S6 blobs I had reliable dropoffs at medium router-signal combined with heavy wifi-load (no dropoffs with full router signal). With the S2 blobs no single dropoff even at weak router-signal and heavy wifi-load for several hours now.

Again, to enable developer options, tap settings, about tablet, build number 7 times until it says developer options unlocked. Go back to settings, system, advanced, developer options, enable android debugging and rooted debugging.

As I said earlier, the routed debugging option is missing in my developer-options (with installed Magisk). Everything else is looking identical to the attachement of post 6. But maybe we should not cover this thread with the different ways to adb root. The really important thing is that the proposed fix works really great! At least for me and hopefully for everybody else who is willing to try it

Yogi555 said:
As I said earlier, the routed debugging option is missing in my developer-options (with installed Magisk). Everything else is looking identical to the attachement of post 6. But maybe we should not cover this thread with the different ways to adb root. The really important thing is that the proposed fix works really great! At least for me and hopefully for everybody else who is willing to try it
Click to expand...
Click to collapse
Thanks, @Yogi555! It's great to know that replacing the blobs works on one of the other S2 models! We could only test it on gts28wifi (T710).

@Yogi555, about the Rooted debugging option: my T710 doesn't show that option, either, and I think it's because I have Magisk installed (@retiredtab doesn't).
If the device is not rooted, "adb root" temporarily restarts the adbd daemon on the device as root (there's a timeout period after which it will remove root access again).
I'm guessing that if the device is rooted, that isn't necessary - because adbd is probably already running as root . The Rooted debugging option is therefore unnecessary, and isn't shown.
In either case, when you do "adb root" on the PC, there should be a prompt on the device asking you if you want to allow access. Did you see the prompt? If you don't explicitly allow it, root access won't be given.
Also, "adb root" works on Windows (for an account that's in the Administrators group) without needing to be Run As Administrator, but I think Linux requires the command to be run as root (eg, sudo adb root).

Update2: after the night the T810 with S2 blobs was immediately connected to wifi this morning. Great!
Regarding "adb root" with Magisk: I'm running it from Win10 PC. Independent if normal commandline or commandline as administrator - after "adb root" there is no output at all, but a sound like connecting or disconnecting a device. After "adb remount" next, an error is displayed:
Not running as root. Try "adb root" first.
remount failed
Maybe my adb is too old (version 1.0.40)
However "adb reboot recovery" works and "adb root" then in TWRP as well. So strange, but no problem

Yogi555 said:
Update2: after the night the T810 with S2 blobs was immediately connected to wifi this morning. Great!
Regarding "adb root" with Magisk: I'm running it from Win10 PC. Independent if normal commandline or commandline as administrator - after "adb root" there is no output at all, but a sound like connecting or disconnecting a device.
Click to expand...
Click to collapse
Did you check the device to see if it's prompting you to allow this access? The prompt times out fairly quickly, so you might not see it if you don't check straight away. It does give a notification sound.

The prompting came yesterday at the very beginning of the activity and I allowed it (including the always checkbox). "adb device" shows the device id.

I don't understand why you'd see anything different from what I see. I use a Windows PC, I have Magisk (version 23.0) installed on the T710, and have previously allowed adb root access "always".
What I see is this:
Code:
> adb version
Android Debug Bridge version 1.0.41
Version 31.0.2-7242960
> adb root
adbd is already running as root
> adb remount
remount succeeded
> adb root
gts28wifi:/ #
I think there could be something wrong with your Magisk configuration. What version is it?

Downloaded adb version 1.0.41. Now I get "ADB Root access is disabled by system setting - enable in Settings -> System -> Developer options"
Updated Magisk from 20.4 to 22.1. and App to 23.0 => No difference :-(
In Magisk App adb is not listed in Superuser-tab. Can I add it somehow?

Yogi555 said:
Downloaded adb version 1.0.41. Now I get "ADB Root access is disabled by system setting - enable in Settings -> System -> Developer options"
Updated Magisk from 20.4 to 22.1. and App to 23.0 => No difference :-(
In Magisk App adb is not listed in Superuser-tab. Can I add it somehow?
Click to expand...
Click to collapse
I think I know what's going on now.
I've just uninstalled Magisk, and (after the enforced reboot) I can now see the "Rooted debugging" setting in Settings > System > Developer Options > Debugging.
Mine was ON, but had been hidden by Magisk's presence, as I suspected.
If you uninstall Magisk, I think you will find that your "Rooted debugging" is OFF. If so, turn it on, then try "adb root" etc. You don't need to root the device in order to use adb root functions. If you want the device to be rooted, by all means re-install Magisk - but with that setting still ON.
I'll be very interested to hear what happens.

The simplest way to check that adb root has actually given you root access is to "adb shell". The prompt will end in a "#" if the shell's running as root. As mentioned in an earlier post.

Want to also quickly confirm in here that the S2 Blobs are working real fine for me as well.

lpedia said:
I think I know what's going on now.
I've just uninstalled Magisk, and (after the enforced reboot) I can now see the "Rooted debugging" setting in Settings > System > Developer Options > Debugging.
Mine was ON, but had been hidden by Magisk's presence, as I suspected.
Click to expand...
Click to collapse
I've just re-installed Magisk and proved to myself that Magisk 23 is hiding the setting. I found that Magisk 22 didn't hide it - I re-installed using a version 22 zip that I had on hand, checked the "Rooted debugging" setting, which was still visible, then updated to Magisk 23 via the app. After the reboot, the setting had disappeared again.