[Ovmsdev] Problems with AP + Client mode
dexter at expeedo.de
Sat Mar 17 22:02:23 HKT 2018
Thanks for testing, I haven't had time to experiment with it yet.
Maybe we should tag the AP+Client mode as "experimental" for the release?
Regarding the "job queue overflow" warnings: those occur when the network manager task is busy. I think I'll change them to debug level or avoid repeating them.
All mongoose socket processing is done in the network manager task, as mongoose is single threaded. So if one connection is busy, all other connections are blocked.
Am 16.03.2018 um 23:47 schrieb Greg D.:
> Hi folks,
> Are any of you having trouble with AP+Client mode? A couple of
> AP mode, by itself, works great. AP+Client, however, seems to depend on
> whether the client side gets connected or not. If it does, I can also
> connect to the AP, and when connected, navigate the webserver. If the
> client side doesn't get connected (the specified SSID isn't available),
> my phone can connect to the AP, but accessing the webserver never works
> (times out).
> This is with the simcom modem unconnected (antenna removed). I also
> have the DNS server address fixed to '126.96.36.199 188.8.131.52', to remove that
> from being an issue.
> If I go into the webserver (when it's working) and configure the client
> SSID to connect to any available, neither the client nor the AP come up
> after a module reset. This is apparently due to an error during the
> Auto execution, where the 'wifi mode apclient' command is failing due to
> not having the client ssid specified (it's coded as required, should be
> As I noted earlier, if the module comes up and the client SSID isn't
> immediately available, the ability for it to connect later is limited.
> Mark suggested this is because the wifi client isn't scanning channels
> other than the one the AP mode is on, so it's a matter of luck if the
> client AP happens to come up on the right one. (Here, that never seems
> to occur :( ).
> If the AP+Client does come up (client SSID is available), and later the
> modem gets connected, connection to the v2 server hangs. Seems like the
> internal routing of traffic is getting confused, or rather, the module
> is getting a new IP address, but the server's connection is not
> bounced. (Enhancement request: Have the network status command to note
> which interface is considered active.) IMHO, we really shouldn't even
> try to run the modem if the server is connected via the wifi client,
> because, besides messing up the network configuration, it's also causing
> a slow drain on the modem's data plan (I'm seeing the Rx/Tx counters
> increment) for no benefit.
> Sometimes I get a spew of 'job queue overflow' errors (see below). Not
> sure of all the conditions, but tapping the Status tab seems the most
> often cause, though it can be tapped without causing the error too.
> Under conditions where the AP+Client had the client connected and the AP
> able to associate, but not able to access the webserver, I was able to
> get to the webserver if I joined the same network as the client and
> surfed to the module's address there.
> Lots of test cases here. I really need a test matrix to be sure I can
> reproduce the issues and successes later... Part of the puzzle is that
> the retries built into the software often recover things, so it's hard
> to know what's a fatal failure, and what is recoverable in time, and so
> may be less serious for the end user.
> Finally, I have seen circumstances where the simcom model gets into a
> state where it comes up and starts connecting, but after a few frames
> (less than 10) gets stuck with an increasing number of framing errors,
> but no progress on receive. Eventually it will reset and try again, and
> after some number of these, sometimes finally connect (and mess up the
> wifi that was running happily all along).
> I (473446) simcom: Power Cycle
> I (479406) simcom: State: Enter PoweredOn state
> I (498456) simcom: State: Enter MuxStart state
> I (498456) gsm-mux: Start MUX
> I (498466) gsm-mux: Channel #0 is open
> I (498466) gsm-mux: Channel #1 is open
> I (498476) gsm-mux: Channel #2 is open
> I (498476) gsm-mux: Channel #3 is open
> I (498486) gsm-mux: Channel #4 is open
> I (499446) simcom: State: Enter NetWait state
> I (503836) webserver: HTTP POST /api/execute
> I (503836) webcommand: HttpCommandStream[0x3fff96c0]: 20240 bytes free,
> executing: simcom status
> I (509506) simcom: CREG Network Registration: RegisteredRoaming
> I (510446) simcom: State: Enter NetStart state
> I (511596) simcom: PPP Connection is ready to start
> I (512446) simcom: State: Enter NetMode state
> I (512446) gsm-ppp: Initialising...
> I (512456) webserver: HTTP GET /home
> I (515616) gsm-ppp: StatusCallBack: None
> I (515616) gsm-ppp: status_cb: Connected
> I (515616) gsm-ppp: our_ipaddr = 10.170.146.142
> I (515616) gsm-ppp: his_ipaddr = 10.64.64.64
> I (515616) gsm-ppp: netmask = 255.255.255.255
> I (515616) gsm-ppp: our6_ipaddr = ::
> I (515616) netmanager: Set DNS#0 184.108.40.206
> I (515616) netmanager: Set DNS#1 220.127.116.11
> I (515616) time: Starting SNTP client
> I (517746) webserver: HTTP GET /home
> I (520476) webserver: HTTP GET /status
> W (526166) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> W (526416) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> W (526446) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> W (526666) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> W (526916) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> W (527166) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> W (527416) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> W (527446) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
More information about the OvmsDev