How to flash LN882H with open source Tasmota/Esphome style firmware - backup procedure included

Very cool. I've been spying on your PR to see how it's going!

My PR is very chaotic because I don't even have compiler setup locally and I am doing other things in the background but I finally managed to get stuff displayed.

To simplify things, I have a "shared TMGN driver" which supports multiple similiar display controllers like TM1637, TM1638, GN6932, etc.

Added after 27 [minutes]:

Ok it's working I guess:

p.kaczmarek2 wrote:

>>21072408
Guys, do you have B9 gpio working on your LN882Hs? For me, it's in high state all the time and OBK can't control it.

That's probably, because B9 is Tx1 (so you will find your serial logs there on a physical port - at least this is where I get my logs from )

TX1 I/O UART_TX1 pin for log printing, corresponding to the GPIOB9 pin (pin 30) of the IC.

indeed, but why isn't it controllable? are RX/TX GPIOs always fixed high? The datasheet says FULLMUX, like other controllable GPIOs...

max4elektroda wrote:

[
That's probably, because B9 is Tx1 (so you will find your serial logs there on a physical port - at least this is where I get my logs from )

Wait, but my module has TX and RX on the other side... so there are two UART ports, like on Beken? Well, that makes sense...

Yes, there are two UARTS. On my WL2S module, the ports are on the back and labeled accordingly:

https://obrazki.elektroda.pl/7439873600_1708165255.jpg

So I think they are defined as UART somwhere, making any other setting useless.
At least, I didn't even see glitches in serial log, if I change B09 in UI ...

Well, my module is different, you can see that I have B9 on the back and I was suprised that this B9 was not working:

That's why I pointed out, that I had the advantage of my module having the UART ports labeled not as gpio pin but as Rx/Tx.
So I would call it: "works as designed"

And I can only tell, that I like this feature: If you connect a 3.3V com port, you will be able to see the log with the unusual settings "921600 8N1".
That's very useful e.g. to see if there are WiFi problems, which you obviously can't see in the JS apps Log section...

yes. very useful having B9 attached to an independent USB-TTL for watching logs while flashing on A2/A3 (also connected to on-board CH340)



B9=IO2 https://www.elektroda.com/rtvforum/topic4050274.html

Piorun2002 wrote:

>>21070551
I turned off some test MQTT options (hass / tele discovery) and it seems to work well
[...]
after enabling the options:

Code: text Expand Select all Copy to clipboard

Flag 27 - [HASS] Invoke HomeAssistant discovery on change to ip address, configuration
Flag 30 - [MQTT] Enable Tasmota TELE etc publishes (for ioBroker etc)

the problem started occurring again

@Piorun2002 : Could you please try if this issue also occurs, if you use this functions with a release image (without LFS)?

As far as I know the MQTT instability is a well-known issue that spreads accross many SDKs and it's related to the multithreading in LWIP.

@valeklubomir fixed it on BK7231N platform some time ago by updating LWIP:
https://github.com/openshwprojects/OpenBK7231N/pulls?q=is%3Apr+is%3Aclosed
https://github.com/openshwprojects/OpenBK7231N/pull/3
Some things like LWIP_ASSERT_CORE_LOCKED were added and it increased the stability.

There is also a smaller stability fix possible for LWIP MQTT:
https://github.com/openshwprojects/OpenBL602/commit/c73dcaab7e73ab68b29bd20a3b5d4c0992902c1d
... but from I can see, it's already applied to LN882H:
https://github.com/openshwprojects/OpenLN882H/commit/15fde0f403e408eab6ffa31d0e5711e97c37afe2

Of course, I am not saying that I am certain that this is the cause of the instability, but I know it was for BK7231N..

Hi! How do I reset password web ui? the original firmware does not reset the password web ui(

The OpenLN882H firmware usually has no password...
So, did you configure Web authentication here or do you mean how to reset a password in the original firmware?

I think he has set password for OBK web ui and now tries to remove it. Well, that could be problematic! Flashing original firmware may not overwrite the config partition. He may need a custom OBK build that will let him to remove the password or change it to something else...

Shouldn't it just be "remove the check in OBK GUI" and the password is no longer used??

Added after 19 [minutes]:

Or is the question: how to remove an unknown password?

I think he forgot his password and now he is trying to hack into his own device. That can be problematic.

I see. We might be able to provide a quick solution in changing this code to always ignore auth in safe mode

https://github.com/openshwprojects/OpenBK7231...lob/main/src/httpserver/http_basic_auth.c#L12

But this has the drawback, that the config is revealed.
A better idea would be, only to allow a "full reset" of all settings and password in one.

So what about something like it's done on Fritzbox: during the first x minutes, you can initiate a reset if password is wrong?

Of course, it could also be something like a special clear config image, which will erase "all" settings and then starts in safe mode to allow OTA for a regular image. This would mean that there is no change in "regular" releases

>>21083917
Yes!

This file is responsible for auth:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/httpserver/http_basic_auth.c
There is a define for that:

If you compile without ALLOW_WEB_PASSWORD defined, any connection will be accepted.
You can also just manually edit code to accept any password. Then flash via UART.

Here is a guide showing how you can compile OBK online, without any setup on your PC:
https://www.elektroda.pl/rtvforum/topic4033833.html#20946719

I tried to implement a "general" possibility to reset the configuration, if "http auth" fails more than x times during the first minutes after startup.
If you have a git account, you can download the "artifacts" there, containing an image for LN882H, too.
https://github.com/openshwprojects/OpenBK7231T_App/pull/1240

If you reset the device and give a wrong password more than 5 times, you will be asked if you like to reset the configuration of the device....

I'm new and I don't know how to build the firmware. Here, no matter who, can I build a firmware without a web password for ln882h

Added after 1 [hours] 45 [minutes]:

>>21084699
Thanks, I'll check this method.

If you dont have a git account, here the two images (OTA and UART) for LN882H

max4elektroda wrote:

If you reset the device and give a wrong password more than 5 times, you will be asked if you like to reset the configuration of the device....

I think that, for security reasons, there should be a flag to enable/disable this functionality in the configuration

vovatvset wrote:

I'm new and I don't know how to build the firmware. Here, no matter who, can I build a firmware without a web password for ln882h

This is why have guides for beginners here: https://www.elektroda.com/rtvforum/topic4033833.html#20946719

max4elektroda wrote:

https://github.com/openshwprojects/OpenBK7231T_App/pull/1240

|
While this looks good and sounds useful, it's still a potential security breach. Can you encapsulate your code into something like #ifdef ENABLE_OBK_AUTH_RECOVERY ? Then I will happily merge your changes.

This is discussable, one could argue, you usually don't know in advance, whether you will loose your password - just kidding.

I tried to make a proposal with a decent measure of a calculated risk:
You will need (kind of) physical access to the device to restart it: the mechanism will only work the first x seconds after a restart (in PR: 180 seconds) .
If this is implemented, the time should be a compromise:
- need for this procedure (lost password) will usually mean you have to repower it
- it might take some time from the device to your browser to configure it.

You can't reset the web password (and so expose the settings) but only do a full reset of all settings.

My idea behind this proposal: a person who has physical access to restart the device can usually do whatever he/she wants with the device.
So resetting it was not so much of an additional risk (I thought) ...

Added after 2 [minutes]:

p.kaczmarek2 wrote:

Can you encapsulate your code into something like #ifdef ENABLE_OBK_AUTH_RECOVERY ? Then I will happily merge your changes.

Sure, no problem.

Added after 4 [minutes]:

As an additional point: I first thought of "you need to press the button during the procedure".
But since we don't handle some fixed devices with known properties (a single module might even have none) I thought of this alternative.

>>21085618thanks a lot)

max4elektroda wrote:

As an additional point: I first thought of "you need to press the button during the procedure".

now is an option: "Enable web authentication"
so you can add the "Disable password reset" extension
when setting a password, you decide whether you want to disable this option
that would be very intuitive

Piorun2002 wrote:

so you can add the "Disable password reset" extension
when setting a password, you decide whether you want to disable this option
that would be very intuitive

Yes, indeed, very good point to decide here!
I'll try make this possible, another flag would probably the best for this.

I can agree for a flag, but would that flag be on or off by default?

I would vote for the reset be possible in default (so on/off depends on if it's "enable possible config reset" or "disable possible config reset").

But there are arguments for both:

If there haven't been too many questions about lost passwords, it doesn't seem a big issue
It's a possible security breach

As stated above: everyone with physical access can do more harm than resetting the configuration
It's only possible for a very short period of time
We are talking about web auth with plain HTTP, so everyone in the network can read the credentials (they are only encoded but not encrypted)

It should work as a simple way to overcome a possible lost password, so in my opinion, if disabled by default it won't be a help).
At least at the moment I think most users are willing to flash a precompiled image but not to compile one themselves. If that was the case I would vote for completely disable it and every user with a forgotten password could easily compile a recovery image.

I will accept all decisions and code it as you like

All in all it was not too much of work, so even if it doesn't at all make it's way to the image, it's not a big deal.