Closed kevdagoat closed 4 years ago
It would be best to rule them all once and forever.
We should be capable of working around this model-specificity with some more general approach. Usually we have some differences in default dropbear settings layout that will require different uci set
commands. It should be possible to define a new dropbear instance called 'afg' which we create from scratch in addition to whatever other existing sections. That's what I would like to add into that section I left blank for now.
Then we should be capable of embedding this inside AFG, and indirect root guide itself to avoid any temp ssh server on port 6666.
The previous revision had just some dropbear.lan.xxx=yyy which is not always the case as we could have to deal with allowed ips, different interface names, different auth method to enable or reset.
Like we need it to have model specific root guide.
Yeah I know
Sent from my iPhone
On 16 Jul 2019, at 8:37 am, nutterthanos notifications@github.com wrote:
Like we need it to have model specific root guide.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Universal root settings for permanent access are served (https://github.com/kevdagoat/hack-technicolor/commit/48e14da263747e712b8659a926e349fbfad9ae06). We should either upgrade AFG to always use them or never to simplify guide flows.
Model-specific (actually firmware-specific) root guides are simply unmaintainable and prone to be outdated, redundant and not compatible with new procedures and recommendations. There are dozens of firmwares across different models, I think we have not enough resources to make such an effort with good results. IMHO, local community threads perform much better against model-specificity.
As of current state in master, there are no modules of the whole rooting guide that needs to be differentiated across different firmwares. You can think to some optional post-root ISP-specific optimizations, or mods collections to handle frequent community requests. Let's say we have a bucket of modular mini-guides organized per topic (VoIP, WiFi, DSL, ...), then the ISP-specific collections would maintain a list of links to those modules. Note that "per-ISP", differently from "per-firmware/model", has a scalable order of magnitude in size.
on the tg-799vac, firmware specific optimizaitons would be a good idea! while I tend to favour 16.3, the current 'Hardening Gained Access' works without a flaw on 17.2 while on 16.3 gives out several errors - due to those deamons not being there.
How about creating 3 profiles:
may need to think which cards should be made available to above profiles.
The bank plan you described is not a good idea. The Hardening section contains commands to disable whatever may break root access and takes into account every possible known feature we need to disable. Assume you are a noob user rooting a new firmware: you have to run them all to be safe, even if some commands give errors because of that feature is missing in its firmware version. Apart from root hardening, you can collect ISP-specific tweaks in a new wiki page and explain each single tweak in existing ones. Try following my previous post guidelines and see if you get something that works for the purpose you described. You can suggest different Testra-specific tweak sets if you want. Make sure the tweaks you suggest work for every known model and firmware from the same ISP.
We had somehow six different "new" guide layouts since this issue was opened, Each different root strategy is properly classified along the single unified guide path.
As @LuKePicci commented on his latest commit (https://github.com/kevdagoat/hack-technicolor/commit/fab493bed1df850d8b94d7e1adc1a80ba7c39bd8):
Maybe the guide needs to become more model specific with like a choose your own path style?