[Ovmsdev] Problems with AP + Client mode

[Greg D.]

Hi Michael,

As in my last note, I think something broke the webserver for me.  I
can't seem to connect to it, from either phone/tablet or brower
(chrome/firefox).  I can't think of anything I did in the configuration,
either, and even tried paring things back to a much simpler config with
just wifi mode ap.  No joy.

With Mark's latest changes, the network activation seems a lot better
than it was before, and if I just look at the ability to ping the
module, I think it's in pretty good shape.  But why would I be
consistently getting a connection refused from the browser?  And, why
(sometimes) would either the modem or wifi interface seem to be up
(network status shows an ip address, and default interface pointing to
it), but the module wouldn't connect through it to the v2 server?

The overflow warnings may be related to the above, in that they would
persist until there was a timeout from the browser, or if I tapped on,
say, the home link.  That would send the new command across, and both
stop the warnings, and execute the new command.  But today's work was
focused on just getting to the home page, not Status, so Mongoose is
getting stuck before even that.  No indication of a command, for
example, on the console.  Is the issue in the network socket layer?

Still poking at it...

Greg


Michael Balzer wrote:
> 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.
>
> Regards,
> Michael
>
>
> 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
>> observations....
>>
>> 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 '9.9.9.9 8.8.8.8', 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
>> optional).
>>
>> 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).
>>
>> Greg
>>
>>
>> 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 9.9.9.9
>> I (515616) netmanager: Set DNS#1 8.8.8.8
>> 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
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev