-
Notifications
You must be signed in to change notification settings - Fork 6
Target stops responding after variable time when using Firefox on Windows 10 #3
Comments
Hi @revell1 Thanks for the detailed investigation.
As you've already tested found out, there must be something weird with the combination of Try to use different browsers, such as If the issue happens only when using Firefox, you can post the issue on Firefox Forum as the issue is possibly so complex that I don't have interests (and never use Firefox) as well as know where or how to start. I'm closing the issue anyway, and won't reopen until the bug of this library is proven. Good Luck with your investigation, |
I have been repeating tests using Microsoft Edge, and the Async_AdvancedWebServer.ino example code, with: I have encountered similar issues as before. Below is the serial/USB log output of the heartbeat output, while EDGE was left with single TAB opened on target address 192.168.1.105 Page was updating for about 37 minutes before finally stalling and being unrecoverable. What was seen on browser was the full webpage with the UPTIME (37:02 was the final time) and random data SVG graphs. But at times when the page was updating, the GRAPH was replaced with a SMALL ICON, this appeared to line up with the error output in the serial log where the setCloseError() is displayed. A text comment in the code (in check_status() function) suggests that the "." logging is updated every 60 seconds, but I think that is an error and should be 10seconds, in which case each dot in the log below is a 10 second interval. From the log, it does not look like a regular error/event/fault, but is quite frequent. I am guessing that this effect is what I was seeing with Firefox, but with Firefox it appeared to be fatal, and once the error occured, Firefox was unable to recover or even reconnect. I am not sure where the "[ATCP] setCloseError()" output is comming from, but did find a similar log report from one of your other projects in the "readme" file for: github.com/khoih-prog/AsyncMQTT_Generic#debug-terminal-output-samples I am still unclear where the issue is, but appears that both Firefox and Edge are being affected in different ways. Suggesting that the problem is either WiFi driver or program code, or some Wireless router issue that has been observed by other users with other libraries. The Serial (USB) Log OutputLocal IP Address: 192.168.1.105 |
HI @revell1 There can be some problem with your board, network, etc. as I have been running the same example more than 4 and 1/2 hours and still running. My browser is latest Chrome running on Ubuntu 20.04 LTS 7++ hrs and still running |
Thanks for your further testing. I have been trying to do further testing, but still get the frequent/random failures with no clue why. As an further experiment, I took a side step to the example in: The Sketch code looks similar to yours, just using the NON Async server, so I was assuming that much of the underlying network driver code would be the same. This also is having the same stability issues. Also tried various other test code with not real conclusions. I have a number of Pi Zero-W and PI 3B's running Volumio, all connecting to 2.4GHz network, and have been fine for several years, can always connect to them from Laptop or Android on 5GHz, with router providing the link between 2.4 and 5GHz networks, but they use different hardware etc, so not really a useful comparison. So I am still at a loss on how to track down what is causing the random issues. Powercycle of the Pico always clears the block, but still does not help to track the source. ===== As a side note, I read that the use of the META - REFRESH method of periodic updates is considered bad web design, due to taking control from the user. I guess you do not have any test code examples of such "GET" post requests from a script perspective? |
Saw your post at Pi PICO-W WifiServer example code failure #860 Check this issue PICO W and tp-link wifi harware issues in RPi Forum to see anything useful to you. Also test and see if the shared 2.4GHz WiFi is so crowded there in UK, creating channel competing situation, periodic (37 minutes) interference, etc. Try also to use other routers (such as Cisco, Linksys, Netgear, etc., not the notorious TP-Link) and see if better. I bought a TP-Link to test quite some time ago, got very bad experience and never buy / use TP-Link again. |
HI @revell1 I don't know if this will work for you in UK, but try to modify as follows to test
AsyncWebServer_RP2040W/examples/Async_AdvancedWebServer/Async_AdvancedWebServer.ino Line 47 in 6b4f24e
this line
AsyncWebServer_RP2040W/examples/Async_AdvancedWebServer/Async_AdvancedWebServer.ino Line 185 in 6b4f24e
this line
For example
If working OK for you, I'll make some PR for the List of countries you can use is in cyw43_country.h of
|
I also add new example Async_AdvancedWebServer_Country for you to try. Just modify to the correct code here AsyncWebServer_RP2040W/examples/Async_AdvancedWebServer_Country/Async_AdvancedWebServer_Country.ino Line 193 in a647b54
|
Sorry don't use it yet. Still hanging, not working. |
The correct place to modify is picow_init.cpp of RP2040W To be changed to
from
You have to modify manually now, until we can find a way to auto-change in |
// See the list of country codes in // https://github.com/earlephilhower/cyw43-driver/blob/02533c10a018c6550e9f66f7699e21356f5e4609/src/cyw43_country.h#L59-L111 // To modify https://github.com/earlephilhower/arduino-pico/blob/master/variants/rpipicow/picow_init.cpp // Check #3 (comment)
Test the new Async_AdvancedWebServer_Country example, which displays the country code. Just be sure to modify picow_init.cpp as above #3 (comment)
|
// See the list of country codes in // https://github.com/earlephilhower/cyw43-driver/blob/02533c10a018c6550e9f66f7699e21356f5e4609/src/cyw43_country.h#L59-L111 // To modify https://github.com/earlephilhower/arduino-pico/blob/master/variants/rpipicow/picow_init.cpp // Check #3 (comment)
Try the new AsyncWebServer_RP2040W v1.0.3 with Release v1.0.3
|
Hi, @khoih-prog (and @earlephilhower). Thanks for a fast response. Here is a log of my testing with your new code. I am still trying to work out the results, as you will see from my notes. See 5], 6] and 7], can't prove it yet, but I think having a device not set to GB has ability to knock out other device regardless of their country code. I do not know what could be occuring, but what if bad country code causes the network to switch to a different channel, will the board's Wifi hardware shift to the new channel or stay blindly on the original channel? What happens if I change my MICROPYTHON code to select the wrong countrycode, will this break the code in same way I am seeing for CPP code? [Another test to add to my investigation]. I certainly think that the lack of country code selection in the 2.5.4 code is something that needs fixing, also I would suggest that if a @earlephilhower does a fix, it possibly should FORCE the user to specify a country code, so that a default is not used, that atleast makes the program author make a decision, and hopefully provide support of user configuration, for example what appers to be a common practice of using a secrets.h or secrets.py file to hold SSID and PASSWORD that could also have country code (and anything else that may be user critical), then you do not hide things in code files. =-==== 1]: 2]: 3]: 4]: 5]: [DID I ACTUALLY NEED TO DO THAT OR DOES THE NEXT CHANGE DO THE WORK?] Modified picow_init.cpp Frustratingly, both targets eventually stop responding again. 6]: 7]: 8]: As I write this, I had both MICROPYTHON and Async_AdvancedWebServer_Country running, (About 25 minutes) and Async_AdvancedWebServer_Country has just died, but MICROPYTHON is still running. Further testing needed, as still unclear what is actually happening, or why MICROPYTHON is not having an issue. |
You don't need to do this. Did you check the country-code is correct ?
and (9+ hrs and still running) If correct, try to
It's possible |
Hi, Yes the displayed Web page was showing GB. The Micropython code I created generates a web page split into a number of gets, HTML, CSS, SCRIPT and a clone of the SVG image file. The Meta 5 second refresh version, it does a get of the root HTML document, that then gets all the other docs, as tried to prevent any CACHE of files. The last death of the CPP code, left the serial com port heartbeat ticking away, so the code was still running. Also I could still PING the board and get a reply (15 - 100ms delay reported), but trying to browse to the IP address, browser gets timeout, Wireshark showed web request go out, but LED on PICO-W stayed OFF, so code did not appear to receive the GET request, otherwise should have got a blink. Android table (again Firefox) could not get to the stalled board, but fine with other. Will try installing some different browsers on Android. Again thanks for you help, just wish the cause of the difference between the two boards would show itself so a fix could be worked out. |
FWIW, I am very doubtful the country setting has anything to do here. All the country setting should do is a) adjust the allowed bands and possibly b) adjust the transmit power. I've never seen an AP which changes bands dynamically, so if you can see and connect to the AP then the country bands and setting aren't an issue. |
Good to know. I'm out now and nothing I can do here. You're on your own now to isolate the issue, if possible and necessary. |
OK, thanks for your help. All my evidence so far is still pointing to differences between either the CYW43 driver specific files in the Micropython and RP2040 github collections, or code running on top of the CYW43. So far there appear to be many changes between the two file sets. Lots of added documentation/comments, but also functional changes. Yes I think that there is some environmental effect occuring with my router, but as Micropython happily runs without fault, either a bug was fixed some time in the past on the Micropython library forked code, or changes in the RP2040 branch have introduced an issue that causes the driver to die in such a way that pings still get responses but requests are not making their way into the application code, but may be getting into the CYW43439 chip and it's firmware but then blocking at the SPI interface. Are their any code hooks that could be added to the USB serial port to either periodically report inner status of the CYW43 driver, or be used as some form of console/terminal debug menu? The search for inspiration continues. |
For curiosity, I install Firefox, and have been running continuously all Chrome, Vivaldi and Firefox without issue in 19+ hours The system is Ubuntu 20.04LTS ( using kernel Is it possible you're running on Windows machine, with some kind of |
Wow, just got one issue now, coming from the notorious Firefox, which destroys the operation of all 3 browsers. It seems that very bad behaviour of Firefox, sometimes surfaces to wreak havoc to the network / system. Unrecoverable situation after this. I suggest you, if interested, create a bug report to Firefox, EGDE, etc., or avoid Firefox. EGDE, until they find out and destroy the bug. It seems that the RP2040W is now crashed, no more heartbeat. Weird. |
Hi, I guess you did not try pinging the PICO after the failure, just to see if it was still on the network. As I have found when web server is no longer responding, it generally can still be pinged, which I think would suggest that the Wifi chip and it's firmware is still doing something, but the link over SPI to the PICO processor code and drivers has stalled. Though you did say that the heartbeat had also stopped, which suggests the loop() code had also stalled or crashed out in some way, so not sure if ping would still respond, probably should unless stalled application code can also halt the Wifi chip code. |
We at least can isolate now that something bad in I've never |
No more Seems you're in better shape there !!! |
OK, I think I found out what's wrong with Firefox, Edge, etc., and have tried to adjust both the
Running all 3 browsers (Chrome, Vivaldi and Firefox) w/o issue so far, continuously for 3+ hrs now. It seems Firefox is much slower in response than other browsers, such as Chrome, Vivaldi, etc., and I have to tweak some time_outs to cope with it. Hopefully final here. Will leave them running for one more day to be sure. |
HI @revell1 Just released the AsyncWebServer_RP2040W v1.1.0. Be sure to use with the latest AsyncTCP_RP2040W v1.1.0+. Your contribution is again noted in Contributions and Thanks I've been testing using Firefox (in Ubuntu,not Windows 10) for many hours and still OK. Please test there to see if there still more issues. Release v1.1.0
|
### Releases v1.3.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3)
### Releases v1.3.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3)
### Releases v1.5.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3) 2. Add functions and example `Async_AdvancedWebServer_favicon` to support `favicon.ico`
### Releases v1.5.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3) 2. Add functions and example `Async_AdvancedWebServer_favicon` to support `favicon.ico`
### Releases v1.5.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3) 2. Add functions and example `Async_AdvancedWebServer_favicon` to support `favicon.ico`
### Releases v1.5.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3) 2. Add functions and example `Async_AdvancedWebServer_favicon` to support `favicon.ico`
### Releases v1.5.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3) 2. Add functions and example `Async_AdvancedWebServer_favicon` to support `favicon.ico`
### Releases v1.5.0 1. Fix issue with slow browsers or network. Check [Target stops responding after variable time when using Firefox on Windows 10 #3](khoih-prog/AsyncWebServer_RP2040W#3) 2. Add functions and example `Async_AdvancedWebServer_favicon` to support `favicon.ico`
HI @revell1 Please check the new AsyncWebServer_RP2040W v1.2.0 to see if better for you in Windows Firefox, by using the new and efficient Async_AdvancedWebServer_MemoryIssues_Send_CString example |
HI @revell1 You can try the new and very promising Use the new version (in master) of Async_AdvancedWebServer to display heap data More info can be found in Earle's PR Rewrite PicoW LWIP interface, major stability increase #916
|
FWIW, this is with the built-in webserver and a
|
Describe the bug
While testing the Async_AdvancedWebServer.ino example,
it has been seen that while accessing the target using Firefox 104.0.2 (64-bit) from a Windows 10 laptop, that the program responds every 5 seconds with an update.
But after some random time, the last request fails to get a reply.
The SERIAL debug output shows that the heartbeat DOTS are still occuring.
But trying to refresh the browser or connect to the target using a different browser (EGDE), or trying to attach using Firefox from an Android device all fail to connect.
If first connect to target using EDGE rather than Firefox, then have not yet seen target stop responding.
Have also had THREE connections (Firefox + Edge on PC, and Firefox on Android) at same time, for over 20 minutes, without issue.
Problem only appears to occur when using Firefox as first/only connection from power up.
Unclear if this is a Firefox induced issue, a target program issue, or a network/router issue.
Steps to Reproduce
As above, connect to the target address (just the IP, no HTTP:// or HTTPS://) using Firefox, and watch the regular updates, wait till the browser reports
"
The connection has timed out
The server at 192.168.1.xxx is taking too long to respond.
"
Expected behavior
Would expect the target device to continue returning replies without issue.
Actual behavior
After random time, target stops responding, but heartbeat debug output shows still alive.
Debug and AT-command log (if applicable)
N/a
Screenshots
N/a
Information
The text was updated successfully, but these errors were encountered: