Page does not load when accessing via external address - be it IP of DNS, either from on network browser or an internet browser. #74
Comments
|
Could be related to this: esp8266/Arduino#867 |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Thanks Xose, sorry I made a mess of the other thread. Harry, what high ports are you specifically concerned about in your trace? Client connection (high port) to service (low port) is correct right? Later Ferdie |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Could also be that it is being looked at .. I have no clue yet how the version work of the libraries that get listed in platformio but it seems like this might be a fix or an attempt to fix. Later Ferdie |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): Ferdie, on your trace your marked entry goes to port 54483..source--destination..i have the same entries with randomizes ports...i think there shouldn't be high ports involved , neither the browser nor the device should use any other than 80 to communicate...therefore , i think, this is most likely some other communication that gets in the way.. |
|
Hi I was a bit puzzled by the commit @F-Fish referenced a few messages above in ESPAsyncTCP. It actually looks like it's addressing the issue here. There is a lengthy conversation about it here: me-no-dev/ESPAsyncTCP#20 You might find some data there familiar. The fix was released in November. I think we are all using PlatformIO to manage the libraries and the platformio.ini file was loading ESPAsyncTCP and ESPAsyncWebServer by their library names which means fetching the latest version. Partially true. Actually it means fetching the latest "cached" version of the library. When does PlatformIO cache the libraries? Upon version change: monitoring the library.json file. As it turns out @me-no-dev has not updated the library.json file since October, so all those changes in November (and others in December) are not in the PlatformIO version of the library!! I have changed the platformio.ini file to use the GIT repository as source for those two libraries. At the moment the change is only in the dev branch. Can any of you test it with your set up? You will have to delete those two libraries folders from the .piolibdeps folder before trying to build it and flash it. |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Indeed .. that was it. Did the rm, a pull, see the changes in the platformio.ini, normal build and load. Setup the external DMZ route. Hit the external DDNS and IP and - slow but it worked. Going to do a quick wireshark trace just to close the loop on this one. Later Ferdie |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Did a capture of both internal ip and external ip, normal reload so that timing is not affected by my slow fingers. Internal trace looks OK. External trace show the fix in play, the extra payload that did not fit into the packet gets chunked up and a smaller bit is send (not sure this is the most efficient way, but hey it works ;-) So recap - MSS of 1460 packet length would be 1514, but with the routers MTU being lower the device says hey my MSS is 1452 so the max packet length one can send is 1506. As in line 21 with the ack in 22 and then the remainder is send in 23 with an ack back 24. But why so slow .... well we now going from PC to router and then router to esp and all the way back again. Call that 90ms round trip - in reality I have 5 devices in the data path so I am ok with the 90ms for now, but that is not the entire story. The esp has to work a bit harder and send more data via the router. What is the difference on my network.
Looking at the difference in packet count / sizes etc ... 82 vs 117 Later Ferdie |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): Hey, i can confirm that 1.6.4b is working from inside and from outside ! maybe not releated, but i was not able to flash OTA..the log didn't show any errors, but it didn't update...also, everytime i flash, i change the 'title' in the index.html to make sure that i am really on the latest version..and i got 2 different titles..e.g. on the internal access i got 'ESpurna 0.0.1' and when using external access i got 'ESpurna 0.0.2' ?!? any ideas how this could happen ? ..no, it was not a cache problem on chrome ;-) regards, |
|
The title in the index.html gets overwritten when the client receives the data using the APP_NAME + APP_VERSION. Does the data in the interface make sense? Can you switch on/off, the board name, the IP, wifi configuration... is everything else OK? Can you check the data you are receiving through the websocket? Using chrome open the developer tools (F12) and hit the device. In the network tab you should see a /ws request, click on it and expand the data frame. |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): i know that i get's overwritten..but for a sec or so you see the old title :-) never mind..probably my PIO setup... and there is a YES on everything you've asked. but IP, Config, board name, /ws request , toggle on/off..everything seems to work ! Heap is currently 23056. |
|
There is a setting that forces WIFI reconnect after X unsuccessful MQTT connections. It's in the general.h file under MQTT_MAX_TRIES. Setting it to 0 disables this option. |
|
Since this is working now I will close the ticket once it will released in master branch. |
|
Original comment by f-fish (Bitbucket: f-fish, GitHub: Unknown): Agree the heap does seem to hold steady even when you are hitting the page now on the internet IP. I suspect that previously the retries kept data at the ready for sending while the device was waiting for the ACK to get back to it. Later Ferdie |
|
Original comment by J.D. (Bitbucket: Harry_Reutter, GitHub: Unknown): ok, thanks for the efford !!!!! :-) |
|
Thank you guys, I wouldn't have found this without you... amazing work you have done! |
|
Released with 1.6.4 |
This comes from issue #24. Opening it here to track it. Captures and explanation by user @F-Fish.
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 ;-)
The text was updated successfully, but these errors were encountered: