search

xoseperez / espurna

Home automation firmware for ESP8266-based devices
http://tinkerman.cat
GNU General Public License v3.0
2.99k stars 637 forks source link

Sonoff Switch: Web server not available #24

Closed xoseperez closed 6 years ago

xoseperez commented 7 years ago

Originally reported by: Pavel Eremin (Bitbucket: paveleremin, GitHub: paveleremin)

Steps to reproduce:

  1. download espurna

  2. change "platform" from "espressif8266" to "espressif8266_stage" in platformio.ini

  3. upload and uploadfs with "pio run"

  4. connect to wifi network SONOFF_XXXXXX make setup

  5. try to enter to the web interface in the router's wifi, but it's fail, seems something wrong with web server:

Resource interpreted as Document but transferred with MIME type application/octet-stream: "http://192.168.0.104/".

also it propose to download some "download" file in browser

xoseperez commented 7 years ago

Pending issues in thei ticket have been released with 1.6.4

xoseperez commented 7 years ago

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.

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

@xoseperez thats what i wrote earlier..i think most of the things are fixed/follow up error.

Nr.5 not releated to DNS, happens with IP also

Nr.6 still an issue (sometimes) right now it's stable at 22k

@ ferdie i have the same entries....but look at the port !? these seem to be random windows high ports..i agree that they are more or less dropped when coming from outside, but i am not sure that this is the cause of the problem..If so, where do the high port numbers from ?

Regards, Harry

xoseperez commented 7 years ago

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.

badpacket.JPG

wireshark trace above - esp and router can not agree on MSS

badpacket1.JPG

the first segment the esp sends what the router can handle based on MSS 1452

badpacket2.JPG

we get an ACK for 41 so esp sends the next stream but at the wrong MSS 1460

badpacket3.JPG

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)

badpacket-working.JPG

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

xoseperez commented 7 years ago

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

xoseperez commented 7 years ago

Guys. I think we should do some clean-up here. This is going way too far from the original issue. I'd like to know if @paveleremin has tested the current dev branch to see if we have done some steps in the right direction here.

Some many different (?) things in this ticket.

  1. Browser trying to download the page as a file. => I'm almost certain this is due to low free heap. Some improvements have been done here.
  2. Partial download (html but no css or js). => This should not happen since everything is in one file now.
  3. Connects to network only when connected to the board via serial => power issue?
  4. AP mode not stable. => This should also be fixed with the latest commits to dev
  5. Page not working when using external DNS service (whatever the cause might be)
  6. Free heap going down when using named requests (not using IP). => I could not reproduce this.

I'd like to open a different issue for the DNS problem. Is anyone still facing any of the other issues?

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

For completeness .. this is espeasy R120 - via device IP 

#!arduino

23:36:29.269882 IP (tos 0x0, ttl 64, id 1097, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.24.53382 > 192.168.1.61.http: Flags [S], cksum 0x4416 (correct), seq 2276470477, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:36:29.361208 IP (tos 0x0, ttl 128, id 14, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.61.http > 192.168.1.24.53382: Flags [S.], cksum 0x5cd6 (correct), seq 6517, ack 2276470478, win 5840, options [mss 1460], length 0
23:36:29.361467 IP (tos 0x0, ttl 64, id 1101, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.24.53382 > 192.168.1.61.http: Flags [.], cksum 0x9072 (correct), seq 1, ack 1, win 64240, length 0
23:36:29.361771 IP (tos 0x0, ttl 64, id 1102, offset 0, flags [DF], proto TCP (6), length 421)
    192.168.1.24.53382 > 192.168.1.61.http: Flags [P.], cksum 0x2304 (correct), seq 1:382, ack 1, win 64240, length 381: HTTP, length: 381
        GET / HTTP/1.1
        Host: 192.168.1.61
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1
        User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
        Accept-Encoding: gzip, deflate, sdch
        Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

23:36:29.372699 IP (tos 0x0, ttl 128, id 15, offset 0, flags [none], proto TCP (6), length 157)
    192.168.1.61.http > 192.168.1.24.53382: Flags [P.], cksum 0x0dff (correct), seq 1:118, ack 382, win 5459, length 117: HTTP, length: 117
        HTTP/1.1 200 OK
        Content-Type: text/html
        Content-Length: 1742
        Connection: close
        Access-Control-Allow-Origin: *

23:36:29.403336 IP (tos 0x0, ttl 64, id 1103, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.24.53382 > 192.168.1.61.http: Flags [.], cksum 0x8ef5 (correct), seq 382, ack 118, win 64123, length 0
23:36:29.409980 IP (tos 0x0, ttl 128, id 16, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.61.http > 192.168.1.24.53382: Flags [P.], cksum 0x5bc5 (correct), seq 118:1578, ack 382, win 5459, length 1460: HTTP
23:36:29.441412 IP (tos 0x0, ttl 64, id 1105, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.24.53382 > 192.168.1.61.http: Flags [.], cksum 0x88cc (correct), seq 382, ack 1578, win 64240, length 0
23:36:29.446278 IP (tos 0x0, ttl 128, id 17, offset 0, flags [none], proto TCP (6), length 322)
    192.168.1.61.http > 192.168.1.24.53382: Flags [P.], cksum 0x329c (correct), seq 1578:1860, ack 382, win 5459, length 282: HTTP
23:36:29.446611 IP (tos 0x0, ttl 64, id 1106, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.24.53382 > 192.168.1.61.http: Flags [F.], cksum 0x88cb (correct), seq 382, ack 1860, win 63958, length 0
23:36:29.449021 IP (tos 0x0, ttl 128, id 18, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.61.http > 192.168.1.24.53382: Flags [R.], cksum 0x6bce (correct), seq 1860, ack 383, win 5840, length 0

vs external DDNS - both work for espeasy - but the payload is so much smaller. 

#!arduino

23:40:50.377881 IP (tos 0x0, ttl 51, id 6362, offset 0, flags [DF], proto TCP (6), length 52)
    DDNSIPADDr.53519 > 192.168.1.61.http: Flags [S], cksum 0x2cb0 (correct), seq 3833006701, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
23:40:50.380256 IP (tos 0x0, ttl 128, id 24, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.61.http > DDNSIPADDr.53519: Flags [S.], cksum 0x455f (correct), seq 6526, ack 3833006702, win 5840, options [mss 1460], length 0
23:40:50.468565 IP (tos 0x0, ttl 51, id 6363, offset 0, flags [DF], proto TCP (6), length 40)
    DDNSIPADDr.53519 > 192.168.1.61.http: Flags [.], cksum 0x74af (correct), seq 1, ack 1, win 65340, length 0
23:40:50.482551 IP (tos 0x0, ttl 51, id 6364, offset 0, flags [DF], proto TCP (6), length 429)
    DDNSIPADDr.53519 > 192.168.1.61.http: Flags [P.], cksum 0xf9e7 (correct), seq 1:390, ack 1, win 65340, length 389: HTTP, length: 389
        GET / HTTP/1.1
        Host: DDNSIPADDr
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1
        User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
        Accept-Encoding: gzip, deflate, sdch
        Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

23:40:50.590960 IP (tos 0x0, ttl 128, id 25, offset 0, flags [none], proto TCP (6), length 157)
    192.168.1.61.http > DDNSIPADDr.53519: Flags [P.], cksum 0xf686 (correct), seq 1:118, ack 390, win 5451, length 117: HTTP, length: 117
        HTTP/1.1 200 OK
        Content-Type: text/html
        Content-Length: 1743
        Connection: close
        Access-Control-Allow-Origin: *

23:40:50.729339 IP (tos 0x0, ttl 51, id 6365, offset 0, flags [DF], proto TCP (6), length 40)
    DDNSIPADDr.53519 > 192.168.1.61.http: Flags [.], cksum 0x732a (correct), seq 390, ack 118, win 65223, length 0
23:40:50.790758 IP (tos 0x0, ttl 128, id 26, offset 0, flags [none], proto TCP (6), length 1492)
    192.168.1.61.http > DDNSIPADDr.53519: Flags [.], cksum 0xd549 (correct), seq 118:1570, ack 390, win 5451, length 1452: HTTP
23:40:50.950883 IP (tos 0x0, ttl 51, id 6366, offset 0, flags [DF], proto TCP (6), length 40)
    DDNSIPADDr.53519 > 192.168.1.61.http: Flags [.], cksum 0x6d09 (correct), seq 390, ack 1570, win 65340, length 0
23:40:50.997627 IP (tos 0x0, ttl 128, id 27, offset 0, flags [none], proto TCP (6), length 48)
    192.168.1.61.http > DDNSIPADDr.53519: Flags [P.], cksum 0x149f (correct), seq 1570:1578, ack 390, win 5451, length 8: HTTP
23:40:51.132668 IP (tos 0x0, ttl 51, id 6367, offset 0, flags [DF], proto TCP (6), length 40)
    DDNSIPADDr.53519 > 192.168.1.61.http: Flags [.], cksum 0x6d09 (correct), seq 390, ack 1578, win 65332, length 0
23:40:51.199939 IP (tos 0x0, ttl 128, id 28, offset 0, flags [none], proto TCP (6), length 323)
    192.168.1.61.http > DDNSIPADDr.53519: Flags [P.], cksum 0x8f95 (correct), seq 1578:1861, ack 390, win 5451, length 283: HTTP
23:40:51.309953 IP (tos 0x0, ttl 51, id 6368, offset 0, flags [DF], proto TCP (6), length 40)
    DDNSIPADDr.53519 > 192.168.1.61.http: Flags [F.], cksum 0x6d08 (correct), seq 390, ack 1861, win 65049, length 0
23:40:51.404774 IP (tos 0x0, ttl 128, id 29, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.61.http > DDNSIPADDr.53519: Flags [R.], cksum 0x544e (correct), seq 1861, ack 391, win 5840, length 0

Later Ferdie

xoseperez commented 7 years ago

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 ;-) we are going the wrong direction..

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 ?!?

xoseperez commented 7 years ago

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

xoseperez commented 7 years ago

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. 

#!arduino

22:58:36.585428 IP (tos 0x0, ttl 64, id 15913, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.22.35048 > 192.168.1.29.http: Flags [S], cksum 0x6f65 (correct), seq 419379479, win 29200, options [mss 1460,sackOK,TS val 7997246 ecr 0,nop,wscale 7], length 0
22:58:36.587146 IP (tos 0x0, ttl 128, id 12, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.29.http > 192.168.1.22.35048: Flags [S.], cksum 0x0902 (correct), seq 6513, ack 419379480, win 5840, options [mss 1460], length 0
22:58:36.587495 IP (tos 0x0, ttl 64, id 15914, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.22.35048 > 192.168.1.29.http: Flags [.], cksum 0xc57e (correct), seq 1, ack 1, win 29200, length 0
22:58:36.587862 IP (tos 0x0, ttl 64, id 15915, offset 0, flags [DF], proto TCP (6), length 360)
    192.168.1.22.35048 > 192.168.1.29.http: Flags [P.], cksum 0x1373 (correct), seq 1:321, ack 1, win 29200, length 320: HTTP, length: 320
        GET / HTTP/1.1
        Host: sodemo.local
        User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
        Accept-Language: en-US,en;q=0.5
        Accept-Encoding: gzip, deflate
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1

22:58:36.607553 IP (tos 0x0, ttl 128, id 13, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.22.35048: Flags [.], cksum 0x3242 (correct), seq 1:1461, ack 321, win 5520, length 1460: HTTP, length: 1460
        HTTP/1.1 200 OK
        Content-Length: 50971
        Content-Type: text/html
        Content-Encoding: gzip
        Content-Disposition: inline; filename="index.html"
        Last-Modified: Feb 18 2017 07:39:00 GMT
        Connection: close
        Accept-Ranges: none

22:58:36.607770 IP (tos 0x0, ttl 128, id 14, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.22.35048: Flags [P.], cksum 0x2b7b (correct), seq 1461:2921, ack 321, win 5520, length 1460: HTTP
22:58:36.608351 IP (tos 0x0, ttl 64, id 15916, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.22.35048 > 192.168.1.29.http: Flags [.], cksum 0xb322 (correct), seq 321, ack 1461, win 32120, length 0
22:58:36.608979 IP (tos 0x0, ttl 64, id 15917, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.22.35048 > 192.168.1.29.http: Flags [.], cksum 0xa206 (correct), seq 321, ack 2921, win 35040, length 0
22:58:36.612532 IP (tos 0x0, ttl 128, id 15, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.22.35048: Flags [P.], cksum 0xfa2b (correct), seq 2921:4381, ack 321, win 5520, length 1460: HTTP

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

xoseperez commented 7 years ago

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

xoseperez commented 7 years ago

@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?

xoseperez commented 7 years ago

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 ! it's not like we are transfering Gbit of date...this is never the issue..least not ever since 15 years ago :-) ...if this is REALLY some kind of an issue, a problem with the TCP/IP stack is much more likely !

xoseperez commented 7 years ago

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. 

#!arduino

        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
        Accept-Encoding: gzip, deflate, sdch
        Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

22:34:44.843221 IP (tos 0x0, ttl 128, id 19, offset 0, flags [none], proto TCP (6), length 1370)

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

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

MTU size is so 80's :-) don't get hook up on these things...that's hardly ever the problem.

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 ? or is to too far away from the original issue ?

xoseperez commented 7 years ago

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 ?

xoseperez commented 7 years ago

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. ?

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Seeing some corruption.

Working from local PC to internal device IP. 

#!arduino

22:05:19.857331 IP (tos 0x0, ttl 64, id 17730, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.24.52260 > 192.168.1.29.http: Flags [S], cksum 0x78c3 (correct), seq 699817116, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
22:05:19.859123 IP (tos 0x0, ttl 128, id 18, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.29.http > 192.168.1.24.52260: Flags [S.], cksum 0x9187 (correct), seq 6513, ack 699817117, win 5840, options [mss 1460], length 0
22:05:19.859362 IP (tos 0x0, ttl 64, id 17731, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.24.52260 > 192.168.1.29.http: Flags [.], cksum 0xc523 (correct), seq 1, ack 1, win 64240, length 0
22:05:19.859725 IP (tos 0x0, ttl 64, id 17732, offset 0, flags [DF], proto TCP (6), length 421)
    192.168.1.24.52260 > 192.168.1.29.http: Flags [P.], cksum 0x5bad (correct), seq 1:382, ack 1, win 64240, length 381: HTTP, length: 381
        GET / HTTP/1.1
        Host: 192.168.1.29
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1
        User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
        Accept-Encoding: gzip, deflate, sdch
        Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

22:05:19.881500 IP (tos 0x0, ttl 128, id 19, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.24.52260: Flags [.], cksum 0xbac7 (correct), seq 1:1461, ack 382, win 5459, length 1460: HTTP, length: 1460
        HTTP/1.1 200 OK
        Content-Length: 50971
        Content-Type: text/html
        Content-Encoding: gzip
        Content-Disposition: inline; filename="index.html"
        Last-Modified: Feb 18 2017 07:39:00 GMT
        Connection: close
        Accept-Ranges: none

22:05:19.881829 IP (tos 0x0, ttl 128, id 20, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.24.52260: Flags [P.], cksum 0xb400 (correct), seq 1461:2921, ack 382, win 5459, length 1460: HTTP
22:05:19.882768 IP (tos 0x0, ttl 64, id 17733, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.24.52260 > 192.168.1.29.http: Flags [.], cksum 0xb83e (correct), seq 382, ack 2921, win 64240, length 0
22:05:19.886734 IP (tos 0x0, ttl 128, id 21, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.24.52260: Flags [.], cksum 0x82b9 (correct), seq 2921:4381, ack 382, win 5459, length 1460: HTTP
22:05:19.888016 IP (tos 0x0, ttl 128, id 22, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.24.52260: Flags [P.], cksum 0x04e8 (correct), seq 4381:5841, ack 382, win 5459, length 1460: HTTP
22:05:19.888523 IP (tos 0x0, ttl 64, id 17734, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.24.52260 > 192.168.1.29.http: Flags [.], cksum 0xacd6 (correct), seq 382, ack 5841, win 64240, length 0
22:05:19.892255 IP (tos 0x0, ttl 128, id 23, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.24.52260: Flags [.], cksum 0xb19f (correct), seq 5841:7301, ack 382, win 5459, length 1460: HTTP
22:05:19.893589 IP (tos 0x0, ttl 128, id 24, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.1.29.http > 192.168.1.24.52260: Flags [P.], cksum 0x9fd3 (correct), seq 7301:8761, ack 382, win 5459, length 1460: HT

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. 

#!arduino

22:02:01.080890 IP (tos 0x0, ttl 51, id 6217, offset 0, flags [DF], proto TCP (6), length 52)
    DDNSIPADDr.52258 > 192.168.1.29.http: Flags [S], cksum 0x4de4 (correct), seq 3341093784, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
22:02:01.203060 IP (tos 0x0, ttl 128, id 13, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.29.http > DDNSIPADDr.52258: Flags [S.], cksum 0x66a0 (correct), seq 6513, ack 3341093785, win 5840, options [mss 1460], length 0
22:02:01.246597 IP (tos 0x0, ttl 51, id 6218, offset 0, flags [DF], proto TCP (6), length 52)
    DDNSIPADDr.52259 > 192.168.1.29.http: Flags [S], cksum 0x2a03 (correct), seq 1151775223, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
22:02:01.251168 IP (tos 0x0, ttl 128, id 14, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.29.http > DDNSIPADDr.52259: Flags [S.], cksum 0x42be (correct), seq 6514, ack 1151775224, win 5840, options [mss 1460], length 0
22:02:01.350564 IP (tos 0x0, ttl 51, id 6219, offset 0, flags [DF], proto TCP (6), length 40)
    DDNSIPADDr.52258 > 192.168.1.29.http: Flags [.], cksum 0x95f0 (correct), seq 1, ack 1, win 65340, length 0
22:02:01.365187 IP (tos 0x0, ttl 51, id 6220, offset 0, flags [DF], proto TCP (6), length 429)
    DDNSIPADDr.52258 > 192.168.1.29.http: Flags [P.], cksum 0x1b29 (correct), seq 1:390, ack 1, win 65340, length 389: HTTP, length: 389
        GET / HTTP/1.1
        Host: DDNSIPADDr
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1
        User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
        Accept-Encoding: gzip, deflate, sdch
        Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

22:02:01.418562 IP (tos 0x0, ttl 128, id 15, offset 0, flags [none], proto TCP (6), length 1492)
    192.168.1.29.http > DDNSIPADDr.52258: Flags [.], cksum 0xa3d8 (correct), seq 1:1453, ack 390, win 5451, length 1452: HTTP, length: 1452
        HTTP/1.1 200 OK
        Content-Length: 50971
        Content-Type: text/html
        Content-Encoding: gzip
        Content-Disposition: inline; filename="index.html"
        Last-Modified: Feb 18 2017 07:39:00 GMT
        Connection: close
        Accept-Ranges: none

22:02:01.418785 IP (tos 0x0, ttl 128, id 16, offset 0, flags [none], proto TCP (6), length 1492)
    192.168.1.29.http > DDNSIPADDr.52258: Flags [.], cksum 0x9875 (correct), seq 1453:2905, ack 390, win 5451, length 1452: HTTP
22:02:01.620647 IP (tos 0x0, ttl 51, id 6221, offset 0, flags [DF], proto TCP (6), length 40)
    DDNSIPADDr.52258 > 192.168.1.29.http: Flags [.], cksum 0x8913 (correct), seq 390, ack 2905, win 65340, length 0
22:02:01.714781 IP truncated-ip - 1460 bytes missing! (tos 0x0, ttl 128, id 17, offset 0, flags [none], proto TCP (6), length 2960)
    192.168.1.29.http > DDNSIPADDr.52258: Flags [P.], seq 2905:5825, ack 390, win 5451, length 2920: HTTP
22:02:02.180563 IP (tos 0x0, ttl 128, id 18, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.29.http > DDNSIPADDr.52259: Flags [S.], cksum 0x42be (correct), seq 6514, ack 1151775224, win 5840, options [mss 1460], length 0
22:02:02.352807 IP (tos 0x0, ttl 51, id 6222, offset 0, flags [DF], proto TCP (6), length 40)

Payload never gets to the browser.

Still looking

Later Ferdie

xoseperez commented 7 years ago

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.

xoseperez commented 7 years ago

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. 

#!arduino

[NTP] Error: NTP server not reachable
[NTP] Time: 20:23:46 18/02/2017
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /index.html
[BEAT] Free heap: 7728
[NTP] Time: 20:28:41 18/02/2017
xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

had the same idea this morning, i did wireshark the traffice already :) i noticed some high ports being forwarded to source-destination IP (56000 and higher..) but they seem to be random ports that most probably come from Windows...maybe you see them also..

the browser is loading the index.html file... and then just stops...maybe it can't load the favicon.ico ????

xoseperez commented 7 years ago

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. On the router configure DMZ ip address to point to the device's internal IP address. Check can ping the DDNS name. Plug un-plug the device yep ICMP is going to the device. Hit the DDNS name with the web browser - never get data back. - Harry think this is what you are seeing aaah not seeing. Now to go build an AP that I can snoop the network traffic with.

Later Ferdie

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

hmmm overall wait of 5 seconds seems to give good /ws hit rates, 100 for a 100 so all got to /ws - heap took a knock but seems able to recover. 

#!arduino

658-[RELAY] Number of relays: 1
686-[BUTTON] Number of buttons: 1
716-[LED] Number of leds: 1
740-[LED] Led auto indicator is ON
771:[BEAT] Free heap: 26800
795-[NTP] Time: Time not set
820-[WIFI] Scanning
836-[WIFI]     AP1 SEC:YES RSSI:-81 CH:7
875-[WIFI] --> Ap2 SEC:YES RSSI:-37 CH:12
--
7137-[WEBSOCKET] #39 disconnected
7166-[WEBSERVER] Request: GET /index.html
7203-[WEBSERVER] Request: GET /auth
7234-[WEBSOCKET] #40 connected, ip: 192.168.1.24, url: /ws
7288:[BEAT] Free heap: 20952
7312-[NTP] Time: 16:25:01 18/02/2017
7344-[WEBSOCKET] #40 disconnected
7373-[WEBSERVER] Request: GET /index.html
7410-[WEBSERVER] Request: GET /auth
--
15678-[WEBSERVER] Request: GET /index.html
15715-[WEBSERVER] Request: GET /auth
15746-[WEBSOCKET] #96 connected, ip: 192.168.1.24, url: /ws
15800-[WEBSOCKET] #96 disconnected
15829:[BEAT] Free heap: 21528
15853-[NTP] Time: 16:30:01 18/02/2017
15885-[WEBSERVER] Request: GET /index.html
15922-[WEBSERVER] Request: GET /auth
15953-[WEBSOCKET] #97 connected, ip: 192.168.1.24, url: /ws

once the browser has already been auth'ed once simple iMacros 

#!arduino
VERSION BUILD=9030808 RECORDER=FX
TAB T=1
URL GOTO=about:home
WAIT SECONDS=2
URL GOTO=http://192.168.1.61/?!
WAIT SECONDS=3

Later Ferdie

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Less of an issue with a 2 second delay .. but with 310 attempts only 153 got to /ws wonder if the heap is not related to a tcp keep open or something when Harry's GET index parks and waits for an ack? 

#!arduino

658-[RELAY] Number of relays: 1
686-[BUTTON] Number of buttons: 1
716-[LED] Number of leds: 1
740-[LED] Led auto indicator is ON
771:[BEAT] Free heap: 26800
795-[NTP] Time: Time not set
820-[WIFI] Scanning
836-[WIFI]     AP1 SEC:YES RSSI:-86 CH:7
875-[WIFI] --> Ap2 SEC:YES RSSI:-27 CH:12
--
4932-[WEBSERVER] Request: GET /index.html
4969-[WEBSERVER] Request: GET /auth
5000-[WEBSERVER] Request: GET /index.html
5037-[WEBSERVER] Request: GET /auth
5068:[BEAT] Free heap: 25952
5092-[NTP] Time: 15:59:24 18/02/2017
5124-[WEBSERVER] Request: GET /index.html
5161-[WEBSERVER] Request: GET /auth
5192-[WEBSOCKET] #18 connected, ip: 192.168.1.24, url: /ws
--
19660-[WEBSERVER] Request: GET /index.html
19697-[WEBSERVER] Request: GET /auth
19728-[WEBSOCKET] #87 connected, ip: 192.168.1.24, url: /ws
19782-[WEBSOCKET] #87 disconnected
19811:[BEAT] Free heap: 25928
19835-[NTP] Time: 16:04:24 18/02/2017
19867-[WEBSERVER] Request: GET /index.html
19904-[WEBSERVER] Request: GET /auth
19935-[WEBSERVER] Request: GET /index.html
--
34055-[WEBSOCKET] #152 connected, ip: 192.168.1.24, url: /ws
34110-[WEBSOCKET] #152 disconnected
34140-[WEBSERVER] Request: GET /index.html
34177-[WEBSERVER] Request: GET /auth
34208:[BEAT] Free heap: 25928
34232-[NTP] Time: 16:09:24 18/02/2017
34264-[WEBSERVER] Request: GET /index.html
34301-[WEBSERVER] Request: GET /auth
34332-[WEBSERVER] Request: GET /index.html

Later Ferdie

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Did a quick iMacro .. over a thousand connections with aut .. etc. heap dropped a small amount. 

#!arduino

[BEAT] Free heap: 25032
[WEBSOCKET] Validation check failed
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /auth
[WEBSOCKET] #1032 connected, ip: 192.168.1.24, url: /ws
[WEBSOCKET] Validation check failed
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /auth
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /auth
[WEBSERVER] Request: GET /index.html
[WEBSERVER] Request: GET /auth
[WEBSOCKET] #1033 connected, ip: 192.168.1.24, url: /ws
[BEAT] Free heap: 24456

I might have to put a delay in so that the device can respond before I fire the next request ;-)

xoseperez commented 7 years ago

Crossed messages :)

Ok, one point for the gateway theory. But what is it transferring? 2.8KB is way more than some headers...

xoseperez commented 7 years ago

Yes, md5 of the first request should be the same and should be the one you got (this changes from version to version, of course).

The /auth request only returns a header with an HTTP code 204 (No content).

@Harry_Reutter The key here is to know where it fails, why it does not trigger the /auth request.

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

ok,lot to answer :-) first Ferdie: i'm not a programmer, i'm coming from the network side of things..so, yes, i am hitting my device..no, i don't need forwarding when i am on the same networksegmet..although the DDNS Name points to the Official IP of my router,since my router is the gateway, he knows i'm on the same segment so the traffic is not being routed out of my router -- back into my router..that's why NAT'ing on the same network segment dosn't work...anyways, as Xose said, i'm hitting the right device :-)

@xose about the heap....i'm just letting it sit there and do nothing actually...except for connecting to device thru Chrome....

Gateway vs java/auth problem : that's because you are a programmer and i am an network guy :-) ...but i gotta admit that my theory is unprobable since my MQTT broker is hosted on the Internet and is able to communicate with my device, the Gateway must be correct ..so it would be a Gateway problem that's related to the protocol (in that case HTTP) which is very unlikely indeed...

here a 2 screenshots with the chrome dev network tab open when i access the web page...first one is using the IP and the second is using the name..

log4.jpg log5.jpg

when i press ctrl-u nothing happens when using name, when using IP i get the source of the page..

as Ferdie said in his last msg, when the device is receiving a request and doesn't know where to send it back to, it get's stuck.. --> Gateway issue :-)

Regards, Harry

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

With the GET /index.html not being time stamped it is hard to say, but yes. Could still be an external routing issue the device gets the request i.e. the GET /index.html but the reply never reaches the requesting browser ( this is the assumption that we need to get clarity on ) so data at setp 2 goes to dev null?

Later Ferdie

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Xose, am I correct in saying that for that curl we should all have the same checksum for that payload? Assuming this is the same version etc ..

#!arduino

curl --compressed http://sodemo.local | md5sum
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 50971  100 50971    0     0   129k      0 --:--:-- --:--:-- --:--:--  128k
970f34f1f9b038f5082052606484ec53  -

curl --compressed http://192.168.1.61 | md5sum  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 50971  100 50971    0     0   455k      0 --:--:-- --:--:-- --:--:--  456k
970f34f1f9b038f5082052606484ec53  -

Irrelevant if DNS or IP since this is now all pre-auth and no device info in that payload as yet.

Later Ferdie

xoseperez commented 7 years ago

Morning everybody @f-fish But he is hitting the ESP device, otherwise those GET /index.html wouldn't be there... If the page downloads correctly to the browser it should execute the /auth request right away. ut it isn't. Options?

  1. The javascript is corrupted => there should be an error in the chrome console
  2. jQuery does not execute the init() => can't see why not
  3. The auth request goes somewhere else => in the chrome network tab you should be able to see the full request and it should go to the same server the page is hitting

The communication flow is as follows:

  1. the browser requests the main page, there is no authentication here
  2. once downloaded and rendered (contents are not visible yet) there is an AJAX request to the /auth URL using the same domain/ip as before. The /auth does not return anything, it only trigger the authentication and store a key in the server (the ESP) to validate websocket requests from this client
  3. there is a websocket connection (client is validated) and the server returns the configuration values in a JSON string

Screenshot-1.jpg

xoseperez commented 7 years ago

@Harry_Reutter: You say it's 99% a gateway issue and I'm almost sure it's a javascript/authentication issue :) We are looking opposite directions. Can you check if you actually get the contents of the page (Ctrl+U on Chrome). If you have experience with linux commands you could use cURL:

curl --compressed http://hostname.local

I'm worried about that low free heap. How long does it take to go that low and what were you doing?

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Morning Harry ... wait a second. Let me see if I understand what you are seeing / trying to do.

So you have an internal IP - either it is static or dynamic, but I assume it is something like 192.168.1.xxx. Then your machine is sitting on 192.168.1.114 - PC I assume, and when you use the PC you can connect to 192.168.1.xxx.. - and you can do that for ever and a day and it always works until you try something else. Then you want to be able to access the device from the internet - mobile network etc. So you have setup a ddns service for your external IP address. That way you can get to your ADSL / Network router when you are on your mobile network ( not home wifi right).

I suspect the following is happening, your device is actually just configure for the internal IP address and you have no port forwarding, masquerading etc on your router that can get the traffic to your device.

To check this one could try the following tests. You have 3 possible things you need to check from each network ( i.e internet / mobile network and your home network - PC) What can you ping when the sonoff is on and what changes when it is off (as in the entire device and not just the relays) for each network.

#!arduino

read WIFI
get ip0

on the serial trace.

if while the device is off as in now power to it you can still ping b and c then you are probably pinging your router and that would imply trying it's web page?

Not sure if my thinking makes sense.

Remember MQTT is a subscription service - your device is connecting to the MQTT server - be it in the cloud from your local IP internal IP is via your router. So it can broadcast events - but is also receives events from your MQTT server on that connection that it already established, so being able to restart the device via MQTT actually just shows that yes you can talk out onto the cloud on MQTT.

As an example if I enable mqtt to my MQTT server I see on the current serial trace the other devices that are talking to the MQTT server even if my monitored device is not talking to those devices sending the MQTT information from other sensors in my network. 

#!arduino

[MQTT] Connected!
[MQTT] Sending /test/switch/sodemo/ip => 192.168.1.61
[MQTT] Sending /test/switch/sodemo/version => 1.6.3
[MQTT] Subscribing to /test/switch/sodemo/action
[WEBSOCKET] Broadcasting '{"mqttStatus": true}'
[MQTT] Sending /test/switch/sodemo/relay/0 => 0

[MQTT] Subscribing to /test/switch/sodemo/relay/+
[MQTT] Subscribing to domoticz/out
[MQTT] Subscribing to /test/switch/sodemo/led/+
[MQTT] Received /test/switch/sodemo/relay/0 => 0 - SKIPPED
[MQTT] Received domoticz/out => {
   "Battery" : 255,
   "RSSI" : 12,
   "description" : "",
   "dtype" : "Temp + Humidity",
   "id" : "82012",
   "idx" : 13,
   "name" : "DHT11 - Fish Room",
   "nvalue" : 0,
   "stype" : "THGN122/123, THGN132, THGR122/228/238/268",
   "svalue1" : "25",
   "svalue2" : "24",
   "svalue3" : "1",
   "unit" : 1
}

Hope this helps .. does no address your goal, but I suspect your page that is not loading is because you are not hitting your esp device. With dDNS or the IP address that dDNS resolves to.

Have a look and see if you can confirm this.

Later Ferdie

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

Good Morning,

i flashed the DEV code , and here are the results. it behaves slightly different..i agree with Ferdie that the page loads much faster..so thats a good thing :+1:

here is the log : log3.jpg

the connects was from using the IP (tried it 2 times)..after the connection i closed the browser and tried DNS..this where the GET/index.html come from, and there it gets stuck...so, not working! also, as you can see, the heap is much lower than it used to be...

and, yes..i can ping the device using either IP or DNS...

although, i am not so sure if it is a DNS problem anymore :-) i can also not connect when i use the IP my DDNS name is resolving to..so, it seems you can only connect to the webserver when you are on the same network segment..this is 99% an Gateway issue...could you check if there a several different gateways defined somewhere ? ..since MQTT is working from the outside (using a cloudbased MQTT Broker) ..the IP Gateway in general seems to be correct...

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

I needed to clean the windows shared PC - was getting a bit much so did a quick mint vm in virtualbox. Used this testing to get it done. - Actually doing platformio on linux is such a pleasure. - As you say anyway ;-), followed your dev instructions above on the new mint box. Everything deployed as expected with only the single index.html.gz in data. Took a new fiddler from the windows PC.

espdif04.JPG

Probably my imagination, but I think the page loads way faster now.

Thanks for all the effort Xose getting epsurna in such a good shape.

Later Ferdie

xoseperez commented 7 years ago

@f-fish Thanks for all the debugging work. It's good to know that the support for mDNS under Windows is not so straight forward. At least it looks like you need to add support for it and open your firewall (https://commaster.net/content/how-resolve-multicast-dns-windows).

Anyway I think @Harry_Reutter is not using mDNS but a third party solution. Can you ping the machine? In the meanwhile I've been doing some more work on the authentication side. The #dev branch has some recent commits that fix some memory issues, merge images inside the HTML file (now there is only one file, no images in the filesystem) and is defers the authentication: it is not longer required to download static content like the page itself, only prior to request configuration info via websockets. If you want to test it you will have to (from the repo root folder):

git checkout dev
git pull
cd code
npm install
pio run -t upload -e sonoff-debug
pio run -t uploadfs -e sonoff-debug
pio device monitor -b 115200
xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Can also confirm that it works with mDNS .. booted a RPi ... could connect to the mDNS address no issues.

espdif03.JPG

Think mDNS not working is a windows thing, not network or esp/sonoff/espurna.

Later Ferdie

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

mDNS is not working on my network .. never used it no clue if what etc ..

Did set the hosts entry for .61 device 

#!arduino

192.168.1.61        demo

Did the fiddler and all worked fine, could log in etc ..

espdif02.JPG

All seems to work no issue with local hosts file entry.

Later Ferdie

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Harry - can you run a fiddler ? If I hit a 1.6.3 sonoff-debug-ota image with an incognito chrome tab, authenticate I can see the following, this is direct IP not mDNS - need to figure that out and see what it shows in a trace. espfid01.JPG

This clearly shows that a single index file is downloaded to the browser in a compressed format, I would expect this for dns also, but need to play.

Later Ferdie

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

what i don't understand is that you can't reproduce the problem ?! for me this is 100% reproducable...so, if i have that problem and you don't have it..maybe it's an environment/inftrastructure problem and not a code problem ?

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

just an empty screen..no errors on the browser console ..if i reload the site i get an ERR_EMPTY_RESPONSE ...

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

A tool you can use to track exactly what is happening in the web world is http://www.telerik.com/fiddler.

Let me see if I can get that working on my pc .. not that I am having the issue with the web interface going MIA.

Later Ferdie

xoseperez commented 7 years ago

That low heap is no good. When you say the "interface still crashed" you mean it doesn't show anything? Are there any errors in the browser console?

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

...and heap is now at 11376...

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

ok, authentication was triggered,pop up came up...but web interface still crashed.. log2.jpg...

to make things a bit more complicated (interesting :-) ) i am not using the 'internal' dns name but an Dyndns name...from an network point of view , this does not make a difference since i am in the same ip segment as the device is...just for your information :-)

xoseperez commented 7 years ago

Hi The ESP8266 has two different MACs for AP and STA modes. So that's normal. Actually the mDNS was a late-addon. I don't use it myself but I though it could be a nice feature for a non tech person. I'd like to know what's going wrong so I would probably spend sometime on this. @Harry_Reutter in the screenshot it looks like there is no auth request which should always happen since it's in the init method. It could be that the basic authentication is failing (the log reports a requests to / but never actually sends the data if failed authentication):

void _onHome(AsyncWebServerRequest *request) {
    webLogRequest(request);
    if (!_authenticate(request)) return request->requestAuthentication();
    request->send(SPIFFS, "/index.html");
}

To force it reauthenticate type http://admin@yourhostname.local/ (issuing the user should trigger the authentication dialog again under Chrome). We just want the browser to delete the cached authentication. Now type again http://yourhostname.local/ (without the admin@). It should ask you again the credentials and then, hopefully, show you the content...

Easier: you can also open an incognito window and do the request there using the hostname.

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

Never mind - seems like that is the way AP mode works .. being fake and all. I see the same 5E-5C on my working basic

Later Ferdie

xoseperez commented 7 years ago

Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown):

How did the mac address change from AP to STA mode? [WIFI] MAC 5E:CF:7F:E7:06:A9 to [WIFI] MAC 5C:CF:7F:E7:06:A9

Maybe this is "normal" but I need to test with mine first.

this will cause all sorts of fun with ARP if you have dodge mac - but I might be barking up the wrong tree - will see if mine does the same.

Later Ferdie

xoseperez commented 7 years ago

Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown):

ok, from an network point of view..wouldn't it make sense to de-activate the local DNS alltogether ? i mean, everybody is using the ip address anyways (right ???????) ..maybe this would solve the problem ? a short update on the heap front, after an ALEXA turn on/off , it went to 18672......right now it is at 19040..so i guess we are good the the memory leak front ...

xoseperez commented 7 years ago

Yes, definitely it looks like a problem with the mDNS (it's a multicast DNS, no central DNS server). 20k was orientative. It can go below that under heavy duty, but it should not keep on falling, which might mean there is a memory leak somewhere.