Hi Michael,

Thanks for the reference to the new parameters; I'd missed that.  Unfortunately, no joy, either as an apclient or a regular client.

OVMS# wifi mode client <ssid> <bssid>    using the ssid that's been in use since before the change, and the bssid copy/pasted from the results of a wifi scan.  The network is definitely seen by the module, but the module just sits there with all zeros, including the bssid, when I ask for wifi status. 

I created a temporary "guest" SSID on the home wifi router, without a hidden ssid, and it connects to that just fine.  But switching back and forth between the guest SSID and the hidden one seems to take two tries to go from hidden (and not connected) to guest.  Something's getting stuck...   4-way handshake, perhaps?  I'm looking at the router's log, and am seeing a lot of back-to-back associate / disassociate events.  I'm not 100% sure where in my testing these correlate to, but they seem to be when I was trying to connect to the hidden SSID, as they end, after a short gap, with a DHCP offer and a connect, and that was to the guest network.
Sep  1 13:15:54 syslog: WLCEVENTD wlceventd_proc_event(481): wl0.2: Disassoc 30:AE:A4:43:92:88, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  1 13:15:58 syslog: WLCEVENTD wlceventd_proc_event(500): wl0.2: Auth 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:15:58 syslog: WLCEVENTD wlceventd_proc_event(529): wl0.2: Assoc 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:16:06 syslog: WLCEVENTD wlceventd_proc_event(466): wl0.2: Deauth_ind 30:AE:A4:43:92:88, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  1 13:16:16 syslog: WLCEVENTD wlceventd_proc_event(500): wl0.2: Auth 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:16:16 syslog: WLCEVENTD wlceventd_proc_event(529): wl0.2: Assoc 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:16:24 syslog: WLCEVENTD wlceventd_proc_event(466): wl0.2: Deauth_ind 30:AE:A4:43:92:88, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  1 13:16:36 syslog: WLCEVENTD wlceventd_proc_event(500): wl0.2: Auth 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:16:36 syslog: WLCEVENTD wlceventd_proc_event(529): wl0.2: Assoc 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:16:44 syslog: WLCEVENTD wlceventd_proc_event(466): wl0.2: Deauth_ind 30:AE:A4:43:92:88, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  1 13:16:56 syslog: WLCEVENTD wlceventd_proc_event(500): wl0.2: Auth 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:16:56 syslog: WLCEVENTD wlceventd_proc_event(529): wl0.2: Assoc 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:17:05 syslog: WLCEVENTD wlceventd_proc_event(466): wl0.2: Deauth_ind 30:AE:A4:43:92:88, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  1 13:17:16 syslog: WLCEVENTD wlceventd_proc_event(500): wl0.2: Auth 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:17:16 syslog: WLCEVENTD wlceventd_proc_event(529): wl0.2: Assoc 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:17:24 syslog: WLCEVENTD wlceventd_proc_event(466): wl0.2: Deauth_ind 30:AE:A4:43:92:88, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  1 13:17:36 syslog: WLCEVENTD wlceventd_proc_event(500): wl0.2: Auth 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:17:36 syslog: WLCEVENTD wlceventd_proc_event(529): wl0.2: Assoc 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:17:44 syslog: WLCEVENTD wlceventd_proc_event(466): wl0.2: Deauth_ind 30:AE:A4:43:92:88, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  1 13:17:54 syslog: WLCEVENTD wlceventd_proc_event(500): wl0.2: Auth 30:AE:A4:43:92:88, status: Successful (0)
Sep  1 13:17:54 syslog: WLCEVENTD wlceventd_proc_event(529): wl0.2: Assoc 30:AE:A4:43:92:88, status: Successful (0)
Log from Putty, attached (sorry about all the escape codes...).   Logging was started with the module already connected to the guest network, ending with a final re-connect to guest. 

Greg


Michael Balzer wrote:
Greg,

to connect to a hidden SSID, you need to specify the BSSID (MAC)
additionally to the SSID.

There was and is no config for that, so you need to use the commands,
e.g. by scripts:

OVMS# wifi mode client ?
Usage: wifi mode client [<ssid>] [<bssid>]
Omit <ssid> or pass empty string to activate scanning mode.
Set <bssid> to a MAC address to bind to a specific access point.

As you can see in the change history, I added the BSSID option to the
apclient mode command as well:

OVMS# wifi mode apclient ?
Usage: wifi mode apclient <apssid> [<stassid>] [<stabssid>]
Omit <stassid> or pass empty string to activate scanning mode.
Set <stabssid> to a MAC address to bind to a specific access point.

Scanning mode isn't supported with hidden SSIDs.

Regards,
Michael


Am 01.09.20 um 05:23 schrieb Greg D.:

Looks like AP+Client mode is broken too.  Only Client mode to a
non-hidden AP seems to be working, and that only after a
manually-initiated scan.  I haven't (can't) test the automatic switching
between Cellular and WiFi, as the car is currently being worked on
(infamous PEM Fan connector).

I'm on the 3.2.014 EAP build from 4-August 2020.

Greg


Greg D. wrote:

Hi folks,

Looks like one of the updates broke the ability of OVMS to connect to a
WiFi AP that isn't broadcasting its SSID.  Was this a known side effect
of the WiFi refactoring?  Is there a parameter that I need to set on the
module to allow the connection?

Working around the issue by broadcasting my home SSID is NOT what I want
to do.

Greg



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev