[Ovmsdev] Problems with AP + Client mode

[Greg D.]

Interestingly, when I'm in the state where I can connect to the AP, but
the browser doesn't get any response from the webserver, I can still
ping the module from the phone (module at 192.168.4.1 from the phone on
192.168.4.2). 

There have also been times today where I have my phone on the same wifi
tether as the module, and I can ping the module from the phone, and the
phone as access to the internet via the tether, but the module isn't
able to connect to the V2 server.

{shrug}

Greg


Greg D. wrote:
> 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
>
>
>
>