Call for testing finalized WebREPL setup (before 1.8 release)

[pfalcon]

Thanks for testing.

1. In order to have the cursor in the right place (this is after "New password:") I first had to click into the window. You can't simply start typing. Here's a screenshot to explain ...

Yes, that's how GUI (Graphical User Interfaces) work - among all widgets in a particular windows, there's "focused" one which accepts keyboard input. Usually, another widgets is focused on a webpage, like address entry, or connect button, like on your screenshot, so you need to click on terminal widget to make it accept keyboard input. Well, I guess it would make sense to switch focus automatically after "Connect" is clicked, need to look into that.

[pfalcon]

Ok, auto-focus on connect is added, also added textual tip, as a user still can click away from a terminal widget and then wonder why they can't type. Even enabled browser auto-complete support for URL entry - people usually wonder how to disable it, who'd know there're some hops to go thru to enable it .

[wendlers]

Hi,

tried it on one of my boards, and it seams to work as described. Are there plans to store the password somehow crypted in future (since now it is cleartext in "port_config.py")?

Regards,
Stefan

[mad474]

Cursor and URL entry behaviour is perfect now, thanks!

Two other remarks (maybe just to be mentioned in release notes?) after torture testing this morning:

• 1. Different browsers acting differently (surprise!) after pressing Disconnect button.
  
  • In Firefox/Iceweasel 46.0a2

    Code: Select all

    term.write('\x1b[31mDisconnected\x1b[m\r\n')

    happens instantly and also Connect button is shown promptly, which also means I may immediately reconnect by pressing Connect.
    
    Chromium 50.0.2661.75 takes a pause of about 45 secs after pressing Disconnect until text "Disconnected" appears and Connect button shows off.
  2. Surely a bit off topic over here, nevertheless maybe mentionable: LmacRxBlk:1 (buffer overflow) shows after repeatedly pressing Connect and Disconnect - usually after about 5 times (10 button clicks).
  

  Code: Select all

  MicroPython v1.7-241-g83e99f8 on 2016-05-01; ESP module with ESP8266
  Type "help()" for more information.
  >>> 
  >>> import webrepl
  >>> webrepl.start()
  WebREPL daemon started on ws://192.168.4.1:8266
  Started webrepl in normal mode
  >>> 
  WebREPL connection from: ('192.168.4.2', 36071)
  dupterm: EOF received, deactivating
  
  WebREPL connection from: ('192.168.4.2', 36072)
  dupterm: EOF received, deactivating
  
  WebREPL connection from: ('192.168.4.2', 36073)
  dupterm: EOF received, deactivating
  
  WebREPL connection from: ('192.168.4.2', 36074)
  dupterm: EOF received, deactivating
  
  WebREPL connection from: ('192.168.4.2', 36076)
  LmacRxBlk:1
  LmacRxBlk:1
  LmacRxBlk:1
  

  Sidenote: Wondering if missing listener socket ... 36075 is symptomatic.

Hope I'm not considered a smellfungus
Tests ran on one of my cheap ESP-01 1MB boards together with my Debian 8.4 machine. Huzzah is waiting in the test queue

[pfalcon]

tried it on one of my boards, and it seams to work as described. Are there plans to store the password somehow crypted in future (since now it is cleartext in "port_config.py")?

I'd say no, what's the point? esp8266 is not a multi-user mainframe where someone can peek at something and then reuse it to gain more access. Anyone who gets access to REPL on MicroPython or especially physical access to the module can do anything to it anyway. And playing any "multi-user mainframe" games on esp8266 will only lead to taking away its already rather modest resources from useful user applications.

[pfalcon]

In Firefox/Iceweasel 46.0a2

Code: Select all

term.write('\x1b[31mDisconnected\x1b[m\r\n')

happens instantly and also Connect button is shown promptly, which also means I may immediately reconnect by pressing Connect.

Chromium 50.0.2661.75 takes a pause of about 45 secs after pressing Disconnect until text "Disconnected" appears and Connect button shows off.

So, Firefox used to have just the same delay, and specifically went to fix it. Well, need to see why Chome is still not happy with websocket close handshaking. In the meantime, known workaround is to reload the page .

2. Surely a bit off topic over here, nevertheless maybe mentionable: LmacRxBlk:1 (buffer overflow) shows after repeatedly pressing Connect and Disconnect - usually after about 5 times (10 button clicks).

That's a known issue, discussed at the early release 3/4 thread mentioned above. Yes, it definitely will be mentioned in the release notes, and one of the highest priority to fix. But fixing it properly (and not by a chance) requires good insight into internal working of networking stack and currently there's not enough insight (because it's closed-source blob). Working on toolset to achieve such insight will require quite a lot time, and such toolset is of no interest to users. So, with some things having known issues, there're many more which work really well, but need polishing and documentation, and that's what we're working on these last days before the release.

Hope I'm not considered a smellfungus
Tests ran on one of my cheap ESP-01 1MB boards together with my Debian 8.4 machine. Huzzah is waiting in the test queue

Your (and everyone's) help is much appreciated, and we want to be plain with our community about known issues. We've crushed quite a bunch of hard, nobody-did-it-before things, but 2 months is quite a short term for a project, so some issues are still up. We want to get from "the port is not yet ready for the end users" to "everyone is welcome to use it!" with the upcoming release, and then concentrate on hard things and stretch goals.

[jwissing]

Hi, the setup procedure works as expected, but the board has to be in station mode as my dev machine does not have wifi.
My board (ESP12E, doit) has no serial connection, but is just connected via wifi.
As soon as i enter a wrong password the board starts to misbehave.
I'm seeing hangups that i can only solve with a hard reset.
It also might reset itself after some time.
Also cut and paste of longer files seem to hang the webREPL.

Update:
When i set AP-Mode inactive and start webREPL i can not always login with correct password.
The webREPL is just disconnected without response.
Output on serial REPL:

Code: Select all

#4 ets_task(401002d8, 3, 3fff5180, 4)
MicroPython v1.7-250-g4fb9452-dirty on 2016-05-01; ESP module with ESP8266
Type "help()" for more information.
>>>
connected with OMEGA, channel 6
dhcp client start...
ip:192.168.178.34,mask:255.255.255.0,gw:192.168.178.1
pm open,type:2 0

>>> webrepl.start()
WebREPL daemon started on ws://192.168.178.34:8266
Started webrepl in normal mode
>>>
WebREPL connection from: ('192.168.178.26', 60528)
dupterm: EOF received, deactivating

WebREPL connection from: ('192.168.178.26', 60538)
dupterm: EOF received, deactivating

[wendlers]

When setting password to empty on first setup (means just pressing enter 2x), the board seams to crash. Every time now with the empty password when issuing "webrepl.start()", I get the following:

Code: Select all

>>> webrepl.start()
Fatal exception 3(LoadStoreErrorCause):
epc1=0x4000c068, epc2=0x00000000, epc3=0x00000000, excvaddr=0x4026aa29, depc=0x00000000

 ets Jan  8 2013,rst cause:2, boot mode:(1,6)

As soo, as I set "port_config.WEBREPL_PASS" to something != '', no more crashes.

[mad474]

When setting password to empty on first setup (means just pressing enter 2x), the board seams to crash. Every time now with the empty password when issuing "webrepl.start()", I get the following:

Code: Select all

>>> webrepl.start()
Fatal exception 3(LoadStoreErrorCause):
epc1=0x4000c068, epc2=0x00000000, epc3=0x00000000, excvaddr=0x4026aa29, depc=0x00000000

 ets Jan  8 2013,rst cause:2, boot mode:(1,6)

As soo, as I set "port_config.WEBREPL_PASS" to something != '', no more crashes.

Tested that as well but can't confirm. Setting empty password led to repetition of procedure which seemed plausible to me.

[pfalcon]

Rejoice folks, empty passwords are no longer allowed .