hack-gpon/hack-gpon.github.io

use web-serial-polyfill to run web root on some device don't support webserial

Closed this issue · 18 comments

some device (such as Android) don't support webserial but webusb. use https://github.com/google/web-serial-polyfill to implement a wevserial api over webusb. so that able to root a stick with only a phone

demo of it: https://androidserialport.web.app

I don't understand the reason for this, why would one use Android to root an SFP GPON stick?

The solution to this is to simply use a PC with chromium based browsers, I'm totally against making things more complicated for Android.

Firefox and Safari don't even support webusb so there is no interest in using polyfill to add support for these desktop browsers

because that's the only "computer" i have. and also because that's possible and can increase some compatibility to the device which have webusb only.

Firefox and Safari not support webserial either. that should not become a reason to against webusb. because it have wider support than webserial

I am absolutely against supporting devices without webserial as far as I'm concerned, if you want you can do a PR but it shouldn't bring too much new code to maintain and above all it should be just a fallback in case webserial isn't supported and not replace webserial

another way is write a manual way to do the v3 root procedure rather than hide it in some js/html. so that user can use their favorite terminal on any device to root the stick.

the "one key" way looks like simplified the process. but actually limited it to a specific rang (computer chrome user). and blocking others using it

i can contribute the v3 manual way if anyone need it.

What do you mean you only have an android computer? But have you already used the serial in this android computer?
But does it by chance also work in chromebooks or computers with unusual operating systems?

In any case, I agree with @ErnyTech, if you think this functionality is useful and easy to do (no new dialogues, no new code, just a <script src>, remember that this site is currently being developed without the use of npm, so it must be self-updating).

There is no hidden code all the code is always visible in the source code, and in any case there is the v2 version if the device supports failback mode and a mixture of v2 and v1 if the device does not support it, which is currently quite up to date, there would be editing. A v3 manual could be made based on python scratch

I am absolutely against supporting devices without webserial as far as I'm concerned, if you want you can do a PR but it shouldn't bring too much new code to maintain and above all it should be just a fallback in case webserial isn't supported and not replace webserial

yes. i agree with "it should become a fallback rather than replace the webserial". but unfortunately im not pretty familiar with front end. so the only things i can contribute is writing some document about how to do v3 root manually

how to do v3 root manually

Just use Python script (https://hack-gpon.github.io/ont-huawei-ma5671a-root/#root-procedure-for-huawei-ma5671a-v2---python), the result is the same

What do you mean you only have an android computer? But have you already used the serial in this android computer? But does it by chance also work in chromebooks or computers with unusual operating systems?

sorry for my misleading sentence. i means "Android phone" is just a regular linux computer. if there is a more generic/manual tutorial, android user can use the normal linux way (such as picocom)

In any case, I agree with @ErnyTech, if you think this functionality is useful and easy to do (no new dialogues, no new code, just a <script src>, remember that this site is currently being developed without the use of npm, so it must be self-updating).

i said im not familiar with front end. but maybe i can have a try

There is no hidden code all the code is always visible in the source code, and in any case there is the v2 version if the device supports failback mode and a mixture of v2 and v1 if the device does not support it, which is currently quite up to date, there would be editing. A v3 manual could be made based on python scratch

sorry for the misleading sentence again. the "hide" is actually means they are in the js code. to the end user which don't familiar with js, they may unable to find it. that's what "hide" means

i didn't check the steps what v2 did is same as v3 or not. but the page said "Do not use the V2 and V1 versions under any circumstances" without explaining why. that make me think v3 have some change on procedure, and v2 / v1 not up to date

sorry for my misleading sentence. i means "Android phone" is just a regular linux computer. if there is a more generic/manual tutorial, android user can use the normal linux way (such as picocom)

both me and @ErnyTech are also linux users (he much more than me, and the procedure has been tested on numerous linux distros), now apart from android which distros have problems? I don't even understand what picocom has to do with it...

i said im not familiar with front end. but maybe i can have a try

good luck, I don't really understand what needs to be done and I have more doubts than questions about the code you linked....

sorry for the misleading sentence again. the "hide" is actually means they are in the js code. to the end user which don't familiar with js, they may unable to find it. that's what "hide" means

Ok...

i didn't check the steps what v2 did is same as v3 or not. but the page said "Do not use the V2 and V1 versions under any circumstances" without explaining why. that make me think v3 have some change on procedure, and v2 / v1 not up to date

the reason is simple at present most of the Italian people who are in the telegram group despite the warnings still use it as soon as the web procedure gives an error without even asking or anything else, at present V2 and V1 have been kept up-to-date and congruent with V3 (as far as possible, I remember that they are currently mainly used for consultation), but in the future this might change.

i means "Android phone" is just a regular linux computer.

Absolutely not, Android is not a normal linux computer. A linux computer generally means a computer with a GNU/Linux distribution installed, Android has just the kernel and some programs in common.
In fact in a GNU/Linux distribution it is sufficient to install chromium to use webserial and there is no problem, all tests of the root procedure with web serial have been developed in a Linux environment and I can guarantee that there is no problem.

i means "Android phone" is just a regular linux computer.

Absolutely not, Android is not a normal linux computer. A linux computer generally means a computer with a GNU/Linux distribution installed.

i means termux (or other terminal emulator) and chroot to a arm based linux rootfs

i means "Android phone" is just a regular linux computer.

Absolutely not, Android is not a normal linux computer. A linux computer generally means a computer with a GNU/Linux distribution installed.

i means termux (or other terminal emulator) and chroot to a arm based linux rootfs

It's such an unusual usage that it's not useful to modify our tool to cover such a small number of users, if you can use the serial from termux you should be able to use the root python script V2.

sorry for my misleading sentence. i means "Android phone" is just a regular linux computer. if there is a more generic/manual tutorial, android user can use the normal linux way (such as picocom)

both me and @ErnyTech are also linux users (he much more than me, and the procedure has been tested on numerous linux distros), now apart from android which distros have problems? I don't even understand what picocom has to do with it...

then you should know it would be better to explain how to solve the problem to others (like v1), rather than embedded everything to a script and tell others to run it (v2/v3). that what i means here. i want to use picocom to access the stick and run command by myself. rather than run some script fron internet.

v2/v3 is using sfp ttl adapter. v1 is not. "write a manual version of v3" i mentioned before is means i want a v1 style manual way but using sfp ttl adapter just like v2/v3

i didn't check the steps what v2 did is same as v3 or not. but the page said "Do not use the V2 and V1 versions under any circumstances" without explaining why. that make me think v3 have some change on procedure, and v2 / v1 not up to date

the reason is simple at present most of the Italian people who are in the telegram group despite the warnings still use it as soon as the web procedure gives an error without even asking or anything else, at present V2 and V1 have been kept up-to-date and congruent with V3 (as far as possible, I remember that they are currently mainly used for consultation), but in the future this might change.

ok. but please also add a comment on v1/v2 to tell that it's still up to date. so that user can still read the step in v1/v2 as a reference.

i also noticed that the gpio config in v2 is same as v3. but different than v1. is that because v2/v3 using a sfp tll adapter and v1 using some jump wire to access ttl directly?

then you should know it would be better to explain how to solve the problem to others (like v1), rather than embedded everything to a script and tell others to run it (v2/v3). that what i means here. i want to use picocom to access the stick and run command by myself. rather than run some script fron internet.

Yes this is true, it is not documented what to do if it gives an error.
This could be PR.
In general:

  • if it gives the error step 2 is to use the flash procedure with ymodem
  • if it gives the error step 1 you have to change TTL adapter or MA5671A

@ErnyTech correct me if I'm wrong

v2/v3 is using sfp ttl adapter. v1 is not. "write a manual version of v3" i mentioned before is means i want a v1 style manual way but using sfp ttl adapter just like v2/v3

yes it too, the only thing it requires extra is tweezers to short-circuit the eeprom.

ok. but please also add a comment on v1/v2 to tell that it's still up to date. so that user can still read the step in v1/v2 as a reference.

No, because there is no point in saying that this procedure is up-to-date if it is not, it is easy to tell if it is by the date it was last modified on github.

In the sense that if I write today that it is up to date and if I edit v3 but not v2/v1 it is no longer up to date but there is a note that it is up to date.

i also noticed that the gpio config in v2 is same as v3. but different than v1. is that because v2/v3 using a sfp tll adapter and v1 using some jump wire to access ttl directly?

is the same between v1/v2/v3, only we realised that some batches of MA5671A have some unconnected pins.

i means "Android phone" is just a regular linux computer.

Absolutely not, Android is not a normal linux computer. A linux computer generally means a computer with a GNU/Linux distribution installed.

i means termux (or other terminal emulator) and chroot to a arm based linux rootfs

It's such an unusual usage that it's not useful to modify our tool to cover such a small number of users, if you can use the serial from termux you should be able to use the root python script V2.

yes. you're right. but you mixed my 2 opinions. which are:

  1. a webusb compatible version for chrome on android. (which im working on)
  2. a manual version (v1 like) procedure but using sfp tll adapter just like v2/v3

im not trying to run chrome in chroot on a android phone and use v3 procedure in it. that's so dumb xd

2. a manual version (v1 like) procedure but using sfp tll adapter just like v2/v3

A manual version of V2/V3 is not recommended as you need perfect timing to stop uboot and then there is no serial output until you complete the unlock, it is not easy to do manually.

For this reason a manual version has never been made and we made V2 with python scripts and V3 with webserial.

A manual version of V2/V3 is not recommended as you need perfect timing to stop uboot and then there is no serial output until you complete the unlock, it is not easy to do manually.

I would add that a manual version of v2 could seriously damage the ma5671a by causing it to lose its optical calibration.

any news? if the OP does not want to do a PR this issue will be closed