Can't login to telnet due to wrong password, can't factory reset

[10-p]

Device

blitzwolf bwshpx compatible

Version

espurna-1.15.0-dev.gitb409dc27+github230330-espurna-minimal-arduino-ota-1m.bin

Question

I wanted to update the firmware from 1.14.1 to the latest development build. However I had to do the two step upgrade due to memory issues with espurna-1.15.0-dev.gitb409dc27+github230330-espurna-minimal-arduino-ota-1m.bin

After doing this the device connects to my AP normally and uses the expected IP.

I can connect with telnet but I can't use any password that the device would have. I've made a backup before I did the upgrade and no string in the json works for telnet.
Disabling my AP forces the device to create its own which I can connect and attempt telnet with it, but still fails.

This wouldn't be an issue if it wasn't that I can't factory reset it either. I've tried keeping the button pressed for x seconds or the unplugging and plugging back in several times to no avail. There is no web server running either.

Definitely don't want to open the device as it is extremely tightly sealed.

• Am I missing something when connecting via telnet? I did it before with 1.14.1 and I don't recall having changed anything.
• Am I doing the factory reset wrong?

[mcspr]

#2563 (comment) ?

Anything related to 'telnet' in client sw should be off, connection expects just plain socket data. Meaning, something like nc / ncat / netcat should work out-of-the-box. Otherwise, it would try to insert extra binary data on top of the text you are writing, making it something else entirely on the device's end.

Note that there should be no password for AP connections
After (factory) reset telnetSTA opt might be reset back to default, which does reject connections coming from local network

[10-p]

Managed to get it working before I saw this comment. Yes, Putty didn't work either, probably due to that comment you linked. Ironically enough what saved it was using Windows crummy telnet client.
New lines didn't print at all so it was hard to follow but I could send stuff just fine, including the password and the ota command.

I couldn't trigger a factory reset though. Where are the instructions to do so?

[mcspr]

factory.reset should do it.
minimal .bin does not handle buttons, so only .bin that knows about the device would do anything on very-long-click

also note there is a 2nd minimal .bin with a minimal webserver, so both browser and curl ota methods work

[10-p]

Ok, so the only way to factory reset is with button support? That's unfortunate for minimal builds but now I know.

I was under the impression that n failed boots would be able to trigger a factory reset.

I'll close this as it is answered.

[mcspr]

Ok, so the only way to factory reset is with button support? That's unfortunate for minimal builds but now I know.

I was under the impression that n failed boots would be able to trigger a factory reset.

I'll close this as it is answered.

Right, but for local builds it is still possible to restore button handling by changing code/espurna/config/hardware.h for minimal build and copying button config from the real device
(or storing button 0, button 1, etc. output for settings like btnGpio0, btnMode0, etc.)

Just to note, I think there was a misunderstanding about the password? You were typing the correct one, the issue is with the way telnet client sends it. fa7c187 attempts to restore the minimal telnet handling present in 1.14.x, so at least auth works.

Ugly lines usually solved in putty by changing defaults from CRLF (aka \r\n) to just LF (aka \n). Not possible with telnet.exe, though

[10-p]

Ok, so the only way to factory reset is with button support? That's unfortunate for minimal builds but now I know.
I was under the impression that n failed boots would be able to trigger a factory reset.
I'll close this as it is answered.

Right, but for local builds it is still possible to restore button handling by changing code/espurna/config/hardware.h for minimal build and copying button config from the real device (or storing button 0, button 1, etc. output for settings like btnGpio0, btnMode0, etc.)

Is the configuration stored anywhere in the flash like with Tasmota? A solution could be to only read GPIOs that are defined as switches.

Just to note, I think there was a misunderstanding about the password? You were typing the correct one, the issue is with the way telnet client sends it. fa7c187 attempts to restore the minimal telnet handling present in 1.14.x, so at least auth works.

I was certain because I exported the configuration JSON from the previous version before flashing the minimal file, and I copied and pasted any field that could be used for a password in case I got it wrong for some reason.
My attempt with telnet.exe worked with the password I expected which is the value from adminPass
So I also assume the issue was with how telnet was sending it as you guys said.

Ugly lines usually solved in putty by changing defaults from CRLF (aka \r\n) to just LF (aka \n). Not possible with telnet.exe, though

This is kind of interesting. Because it was telnet.exe which saved the day. I didn't touch telnet.exe configuration so, maybe it used \r\n already?

[mcspr]

Is the configuration stored anywhere in the flash like with Tasmota? A solution could be to only read GPIOs that are defined as switches.

https://github.com/xoseperez/espurna/wiki/Buttons-and-switches#settings

These persist between OTA updates. While you are running blitzwolf .bin, switch to WebUI DEBUG tab or open a telnet connection again and check out output of button and button 0. Everything from .json config gets saved, so if there happens to be btn* key=>value - any .bin with buttons support would use them. By default, values come from build flags e.g. btnGpio0 default value would be from BUTTON1_PIN defined somewhere in .h files.

This is kind of interesting. Because it was telnet.exe which saved the day. I didn't touch telnet.exe configuration so, maybe it used \r\n already?

Just comparing putty and telnet.exe - nothing get sent immediately after typing something. ESPurna incorrectly assumed putty binary data was the password, hence the issue described above. telnet sends just the text, which allows auth and more commands

edit: but, received data is interpreted as-if it was with \r\n, so telnet.exe prints lines all over the place since it assumes a real telnet server and there does not seem to be any options to change that unlike putty