Michael
Balzer wrote:
Am 16.04.2018 um 22:16 schrieb Michael Balzer:
I have seen the queue overflow problem once on the current build, so it isn't solved. But it wasn't related to any action, it happened while
the module was idle.
To clarify, it's no problem if it resolves after some seconds, that may be due to a temporary mongoose lock / overload. If we can trigger that
reliably by some action, that would help to track this down.
Short update: I could trigger it again now multiple times on the OTA page. It seems to be happening due to the update check running over the
modem line, it does not happen with modem disabled. I need to check in Wifi client mode.
Regards,
Michael
Hi Michael,
Interesting... I was going to write back and say that
the 3.003 to 3.004 update went very smoothly, with no
queue overflows being reported, and that all was well.
I don't recall if the modem was connected at the time,
however.
A side note for anyone having trouble connecting to AP
mode with their cell phone... I've always had a lot of
trouble with timeouts and such, and finally tracked it
down to a similar issue as above. If the phone has both
an LTE and AP connection, the http request to
192.168.4.1 often goes out over the LTE path, and is
therefore doomed. Disabling LTE "fixes" that, but of
course, also disables your phone.(or at least the data
part). I haven't found a good way to beat some
(routing) sense into the phone otherwise.
This was with my new Google Pixel2, so it's not a matter
of an old buggy device. (Ok, so it's a new buggy
device...)
Also, the first time you connect to the AP, the phone
blocks all communications with it until
you answer the annoying notification (usually hidden in
the background) that says "Hey, we can't get to the
Internet with that AP. Are you sure you want to stay
connected to it?", or words to that effect. Me thinks
they have taken this always connected Internet meme a
bit too far.
Greg