Sonoff Switch: Web server not available #24
Comments
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin): it's the "best result", that I got from web server: |
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin):
Can't figure out where is the problem |
|
You mean you can see the web interface correctly only when connected to the AP the device creates, but not when it connects to your home wifi network? |
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin): @xoseperez correct |
|
That's somewhat weird. In the screenshot it looks like only the HTML got loaded, no style, no data (so no websocket connection either),... I would gather some more info:
One question: does it happen when using the IP of the device and/or the local name (like http://hostname.local)? |
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin): @xoseperez http://{id}.local not work for me, so I'm use IP. This how it's look like in the Edge browser: That's all what I see in COM port Here is content of "download" file when I try to load url http://192.168.0.101/styles.css |
|
I thinking this might be due to the same problem reported here: me-no-dev/ESPAsyncWebServer#115. |
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin): Same issue with Sonoff POW :( |
|
I'm working on this issue right now but I still cannot reproduce it with confidence, i.e. it happens randomly after the device has been working right for some hours (at least to me). When it happens only the request to SPIFFS files fail (the browser tries to download a binary file, no known format). But the requests to dynamically generated content work just fine (API calls, for instance). The device works as expected otherwise (MQTT, relays, led,...). So my guess right now is still on the SPIFFS handling. |
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin): Today I got interesting behaviour:
@xoseperez is it correct behaviour? What do you think? |
|
Original comment by Tim K (Bitbucket: clueo8, GitHub: clueo8): I too am experiencing this issue. The web page works on a fresh restart, but after some time it becomes unavailable. API calls (i.e. Alexa) still work (response is slow sometimes), but the web server is inaccessible. Is there any workarounds for this? Possibly host the web server external to the device and just have it use the API to control the relays? |
|
This one is really hard to catch... I've been running a Sonoff TH for days without any issue :( If anyone has a step-to-reproduce I will very much thank you. |
|
@paveleremin Why do you turn off your router to enter the Sonoff web interface? |
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin): @xoseperez because when Sonoff work as AP I can't enter to the web interface, because of this issue. But when it create own wifi network - all is ok. |
|
OK, I'm 90% sure it's a memory leak that empties free heap and prevent the ESPAsyncWebServer library from serving big files. I'm doing tests right now but I suspect it's the Alexa integration. Are you using it? |
|
Original comment by Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin): Nope. First device (Sonoff Switch) seems even didn't had this option, and at second one (Sonoff POW) I turn it off in web interface at first time setup. |
|
This is a dump from the debug log of one device I have running: As you can see after the Alexa device (a Amazon Dot in my case) did a discovery (it does it from time to time) the free heap is 2.5K less... I'm opening an issue in the fauxmoESP library repo (https://bitbucket.org/xoseperez/fauxmoesp/issues/5/memory-leak). Won't close this one thou. |
|
The Amazon Dot (I uess the Echo as well) run the discovery process from time to time on their own. No need for you to trigger it. There is a huge memory leak on the fauxmoESP library and after 10 discoveries the free heap is below 5k and the web page becomes irresponsible. |
|
@clueo8 Since version 1.6.0 you can reset the board remotely using MQTT (send a message to your root topic + /action with payload "reset") or using RPC (http://yourip/rpc?apikey=XXXXX&action=reset). @clueo8 That will only work if you have internet connection in you PC and that is not true if you are connected to the device in AP mode to configure it the first time... |
|
Original comment by matantal (Bitbucket: matantal, GitHub: matantal): @xoseperez |
|
@matantal Have you flashed the filesystem image? |
|
Original comment by matantal (Bitbucket: matantal, GitHub: matantal): @xoseperez |
|
Not the firmware, the filesystem. You have to flash two different images on the device: |
|
@matantal Can you connect your USB2UART board to the device and see the debug output when it boots and when you do a request? |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): Hi, I could never reproduce this on my notebook using chrome,firefox,edge,IE....... i hope this was of any help, Cheers, |
|
Original comment by Xavier Smith (Bitbucket: xavier, GitHub: Unknown): After firmware and filesystem update (1.6.0 release) with these commands this is my output from PlatformIO serial monitor: After looonnnggg time, i get the same web interface of Pavel Eremin "best result". No one button functional, if I press, no reply. Best result with old 1.4.0 firmware: good web interface at power on, unreachable after some time. |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Ok good news ... I can duplicate the problem. Setup DDNS for router external IP address. Check can not ping the dns name. Later Ferdie |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): had the same idea this morning, i did wireshark the traffice already :) the browser is loading the index.html file... and then just stops...maybe it can't load the favicon.ico ???? |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Ok have a bridge AP working on a RPi 3 ... Can also confirm the heap issues is with the GET's from the DDNS IP - fresh reset and then try. |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): So when you hit the DDNS enough times you get the heap drops and then you need to reset the device to get is to clear memory to allow normal internal IP to connect. Busy looking at the tcpdumps .. need to confirm a few things. |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Seeing some corruption. Working from local PC to internal device IP. The above goes on till the entire payload is delivered then it moves to the next step .. auth all works. Not working local PC to DDNS address. Payload never gets to the browser. Still looking Later Ferdie |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Maybe a correlation between MTU size of 1492 - set on the router vs - 1500 on the MTU of Ethernet. ? |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): it seems like the IP 192.168.1.29 is hiting on port 52259...... what OS/browser are are you running ? could you install wireshare to monitor traffic ? |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): MTU size is so 80's :-) i tihink we are going the wrong direction...basically i think we are missing something really fundamental..i admitt that i am really stuck on the network thing..but maybe that is not even close to the problem ..i am not even sure that we are still talking about the original issue...what about the guy who originally reported this problem ? can they confirm the things we found out so far ? |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): So changing the MTU on the router changes the length of the data ... for the DDNS requested page. 1370 is the lowest that my router will go on MTU. Could it be as simple as the tcp-stack on the esp only wants to play on sizes of 1500 ? maybe that is why the failed load has the 22:02:01.714781 IP truncated-ip - 1460 bytes missing! the TCP stack could not reduce the payload to 1460? Later Ferdie |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): thrust me, if we need to fidle with the MTU size, something fundamentaly is wrong ! |
|
@Harry_Reutter In the dev branch everything is embedded in one single file. Even images and the favicon are included encoded in base64, so there is no other static content to download. @F-Fish amazing investigation. I'm sorry I cannot keep up with it right now. Family weekend. Last week, while trying to catch a memory leak in the MQTT module, I used ab (apache benchmark) to benchmark the server and the numbers I got are consistent with yours: 4s average response time and struggling to handle more than 3 concurrent connections. Anyway I'm not worried about the concurrency or the response time (not the goal of the app) as much as a possible memory leak. Can you confirm this behaviour only happens when using mDNS or an externa DNS service and not when using the IP? |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Quick google - seems like loads of issues with MTU sizes - to big to small with the ESP. From the SDK limiting you to 1500 and guys debating buffers with large chunks of data. Harry I think your problem is so unique in the way that the data first goes back into your router from your PC and then to the device - that it is probably an MTU issue. Later Ferdie |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Yeah I hear you Harry, could well be in the stack. Looks like the issue is only when you do the external DDNS - so the request has to run out to the router so that the router can pass it back to the internal device. Did as quick test from mDNS on mint - no issues. and since local hosts files also worked .. it does seem to point to the router dictating MTU. I have no way of upping it past 1492 on the router so can not test the theory further unfortunately. Later Ferdie |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Side note ... just checked this on a basic sonoff with espeasy R120 ... set the DMZ to point to that IP address .. no issue, can use the DDNS name via the router. Need to do some flashing to put that behind the AP bridge, to run real traces. But this is for another day. Later Ferdie |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): ok..i don't know how to say this...MTU size is OSI layer stuff...this is NOT an issue with TCP/IP HTTP connections..the TCP protocol should be able to handle this...otherwise we wouldn't be able to Download ripped Porn over Web ;-) i have over 20 webcams setup to access from outside...this is not a unique setup. again, the packet size is not an issue...even if it is, it's an server issue, not an client/router issue.. i still strongly believe that it is a routing issue..(or authentification/Java :-) ) OR the web interface is using an other port than 80 for some reason ?!? |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): For completeness .. this is espeasy R120 - via device IP vs external DDNS - both work for espeasy - but the payload is so much smaller. Later Ferdie |
|
Guys. I think we should do some clean-up here. This is going way too far from the original issue. Some many different (?) things in this ticket.
I'd like to open a different issue for the DNS problem. Is anyone still facing any of the other issues? |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): On 1.6.4b retested .... same same (not that I expected a magic fix ;-) AFAIK only point 5 still an issue for this thread. 5 and 6 I see as related since the device does not seem to recover that easily. I would describe point 5 slightly differently: Page does not load when accessing via external address - be it IP of DNS, either from on network browser or an internet browser. Sorry Harry - see I missed you wireshark dump request - having some issues on the AP bridge with install fluff - will see if I can get it installed on that. Later Ferdie |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Since we do not have a new thread yet... here goes - and one can "clearly" see the issue. wireshark trace above - esp and router can not agree on MSS the first segment the esp sends what the router can handle based on MSS 1452 we get an ACK for 41 so esp sends the next stream but at the wrong MSS 1460 we never get an ACK back from the router - I am assuming because of segment length. So we never get to send the next bit of data. When I look at the working internal ip address (mDNS or direct internal IP) both are happy with a MSS of 1460 and data flows. One could probably "fix" it by reducing the max MSS on the esp ... that sounds like coding to me ;-) Later Ferdie |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): @xoseperez Nr.5 not releated to DNS, happens with IP also Nr.6 still an issue (sometimes) right now it's stable at 22k @ ferdie Regards, |
|
Opened issue #74 to track the problem accessing the device from outside the network. Please report there further info. About the heap issue: I have been doing tests hitting just the index.html or the /auth resource alone (using curl and ab doing up to ten requests in a row) or both (using a browser). The free heap goes back to the previous value after the requests have been responded, both using IP or DNS (just in case). When using the browser the websocket client object uses some memory but it gets correctly freed after the browser closes. |
|
Pending issues in thei ticket have been released with 1.6.4 |
use an #ifdef to check if we should include the custom.h file Approved-by: Xose Pérez <xose.perez@gmail.com>
Originally reported by: Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin)
Steps to reproduce:
download espurna
change "platform" from "espressif8266" to "espressif8266_stage" in platformio.ini
upload and uploadfs with "pio run"
connect to wifi network SONOFF_XXXXXX make setup
try to enter to the web interface in the router's wifi, but it's fail, seems something wrong with web server:
also it propose to download some "download" file in browser
The text was updated successfully, but these errors were encountered: