Forgot to mention that I found this article on hidden SSIDs that provides some technical details on how some clients do/don’t handle them: https://lifehacker.com/5636856/is-hiding-your-wireless-ssid-really-more-secu... <https://lifehacker.com/5636856/is-hiding-your-wireless-ssid-really-more-secure> I’ve always felt this it was a bit of this: and never used them myself. Regards, Mark.

On 4 Dec 2017, at 10:13 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Attached message from 9th November gives more detail on the way the promiscuous mode wifi client currently works.

That scan approach won’t work for hidden SSIDs, but it will handle other SSIDs elegantly and won’t connect to any SSIDs not explicitly configured.

I’m really not sure how phones do it, or how that can be applied to the Espressif ESP-32 wifi libraries. I don’t think they round-robin connect to all configured SSIDs, one after the other - imagine you have dozens of SSIDs (I do); the power consumption would be horrendous. As you mention, maybe an active probe, but I can’t find that in the Espressif API:

http://esp-idf.readthedocs.io/en/v2.1.1/api-reference/wifi/esp_wifi.html <http://esp-idf.readthedocs.io/en/v2.1.1/api-reference/wifi/esp_wifi.html>

I don’t see anything in that API other than the (expensive) connect-to-an-AP in station mode.

I’m not overly worried about this at the moment, as it is relatively simple to switch to a specific SSID in a one-line script triggered by geolocation. Most likely users will be controlling wifi by geolocation / car state anyway. But, if you have time to look into any better way of doing it, please have a go.

Regards, Mark.

<[Ovmsdev] A promiscous wifi client.eml>

...

On 3 Dec 2017, at 1:10 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

Hi Mark,

Yes, specifying the AP works fine (ignoring the crash I got when changing APs on the fly). I certainly don't expect a scan to pick up a hidden AP, but I do think that connecting to a hidden one which has been configured should work the same as a configured one that is in full peacock mode with its beacons. Both phones and laptops can; that's what probe frames are for.

Conversely (haven't checked this), we should not be connecting promiscuously to an AP that has not been configured. Way too likely to hit a Hotspot that requires a login / EULA Acceptance button, and thus breaking a perfectly good, if slow, LTE connection in favor of a hot WiFi connection that goes no where. Not to mention the security angle.

Is the promiscuous connect loop driven from the results of the scan, or by walking / probing the list of configured SSIDs? It should be the later.

Greg

Mark Webb-Johnson wrote:

...

Connecting to a hidden AP should be just specify the AP ssid:

WiFi mode client <ssid>

You won’t be able to see it in the scan, and won’t be able to promiscuously connect to it, but you should be able to directly specify it.

So long as you are running latest firmware and diff sdkconfig and sdkconfig.defaults is not too far off (pay attention to Bluetooth), it should work.

Regards, Mark

On 3 Dec 2017, at 12:11 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

...

Ah, the proverbial "heap of trouble"... {ahem} Sorry. Perhaps something to tune later, or do we need to adjust things now?

So, the original issue - automatically connecting to a hidden AP- is not related. It's not a showstopper for me since I have the dongle, but could be important for some (e.g. WiFi at home hidden, work is open). It appears that the wifi scan code is somewhere in the ELF library set. Is it worth trying to dig into it?

Greg

Stephen Casner wrote:

...

Greg,

The crash was in the "new" operation because you ran out of heap space.

-- Steve

On Sat, 2 Dec 2017, Greg D. wrote:

...

Hi all,

Is there an easy way to enable the wifi code to connect to an SSID that's known (configured) but hidden, without directly telling it to? i.e., using 'wifi mode client' by itself (no SSID specified)?

Some of the places I want to connect to are visible (seen in a scan), but the home network is hidden. If it helps, running a scan within earshot of the home network only burps up an error 'wifi: incorrect scan type: 1073583304'.

Greg

p.s. Possibly related, I have the module in my Roadster, connected to the V2 server via WiFi through a SyncUp Drive OBDII dongle that's being driven by the OBD2ECU engine. The SyncUp's WiFi hotspot is visible, and I have a startup script that gets everything going, and the OVMS module auto connects through it. I just tried forcing the connection over to the home network (wifi mode client gregnet) and after switching networks and reconnecting to the V2 server, crashed and rebooted (whereupon it reconnected through the dongle's network). Any ideas?

OVMS > wifi mode client gregnet Starting WIFI as a client to gregnet... I (1519905) wifi: ap_loss I (1519905) wifi: state: run -> init (0) I (1519905) wifi: pm stop, total sleep time: 0/1415162800

I (1519905) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (1519915) ovms-server-v2: Disconnected from OVMS Server V2 I (1520415) webserver: Stopping Web Server I (1520415) telnet: Stopping Telnet Server I (1520415) ssh: Stopping SSH Server I (1523025) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1 I (1523685) wifi: state: init -> auth (b0) I (1523685) wifi: state: auth -> assoc (0) I (1523685) wifi: state: assoc -> run (10) I (1523715) wifi: connected with gregnet, channel 6 OVMS > I (1524725) event: ip: 10.30.1.102, mask: 255.255.255.0, gw: 10.30.1.1 I (1524725) ovms-mdns: Launching MDNS service WiFi UP with SSID: gregnet, IP: 10.30.1.102, mask: 255.255.255.0, gw: 10.30.1.1 I (1524735) webserver: Launching Web Server I (1524745) telnet: Launching Telnet Server I (1524755) ssh: Launching SSH Server I (1529915) ovms-server-v2: Connection is tmc.openvehicles.com:6867 <http://tmc.openvehicles.com:6867/> ROADSTER_834/Gdbkt2017server I (1530115) ovms-server-v2: Connected to OVMS Server V2 at tmc.openvehicles.com <http://tmc.openvehicles.com/> I (1530115) ovms-server-v2: Sending server login: MP-C 0 1zyHGC+OXD1EofY2dlH19v sy8L79oHSah2+yDqliMKTA== ROADSTER_834 I (1530305) ovms-server-v2: Received welcome response MP-S 0 N9H5zlASBHMxtzteFD9WpG ZoNMc8491dJNxl/x6XSIxg== I (1530305) ovms-server-v2: Got server response: MP-S 0 N9H5zlASBHMxtzteFD9WpG ZoNMc8491dJNxl/x6XSIxg== I (1530315) ovms-server-v2: Server token is N9H5zlASBHMxtzteFD9WpG and digest is ZoNMc8491dJNxl/x6XSIxg== I (1530315) ovms-server-v2: Server authentication is successful. Prime the crypto... I (1530315) ovms-server-v2: Shared secret key is N9H5zlASBHMxtzteFD9WpG1zyHGC+OXD1EofY2dlH19v (44 bytes) I (1530315) ovms-server-v2: OVMS V2 login successful, and crypto channel establishedbort() was called at PC 0x40121ad6 on core 1 0x40121ad6: _Znwj at /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc:54 <http://new_op.cc:54/>

Backtrace: 0x400886e0:0x3fff8140 0x400887df:0x3fff8160 0x40121ad6:0x3fff8180 0x40121ab5:0x3fff81a0 0x40120200:0x3fff81c0 0x400f998e:0x3fff81f0 0x400f3d3e:0x3fff8290 0x400886e0: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519

0x400887df: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519

0x40121ad6: _Znwj at /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc:54 <http://new_op.cc:54/>

0x40121ab5: _Znaj at /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_opv.cc:32 <http://new_opv.cc:32/>

0x40120200: _ZN10OvmsBuffer10PollSocketEil at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- System-3/vehicle/OVMS.V3/main/./ovms_buffer.cpp:145

0x400f998e: _ZN12OvmsServerV210ServerTaskEv at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:247

0x400f3d3e: _ZL15OvmsServer_taskPv at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- System-3/vehicle/OVMS.V3/components/ovms_server/./ovms_server.cpp:55

Rebooting...

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Greg, I just tested this, and found a bug in metrics (that wasn’t calling the listeners). Now fixed, so with latest code, something like this: OVMS > event trace on Event tracing is now on OVMS > level info Logging level for * set to info OVMS > location set whitehouse 38.897985 -77.036508 1000 Location defined I (265925) events: Signal(config.changed) OVMS > metrics set v.p.latitude 38.897985 Metric set I (281595) events: Signal(location.leave.work) OVMS > metrics set v.p.longitude -77.036508 Metric set I (289365) events: Signal(location.enter.whitehouse) OVMS > location status Currently at 38.897984,-77.036507 (with good GPS lock) Active locations: whitehouse So, assuming you live at the whitehouse, your script would be: /store/events/location.enter.whitehouse wifi mode client gregnet Regards, Mark. P.S. To find all current events, look for ‘MyEvents.SignalEvent’ in the code. Here is what I show: power.<device>,<state> location.enter.<location> location.leave.<location> notify.<type> app.connected app.disconnected config.changed config.mounted config.unmounted gps.lock.los gps.lock.on network.down network.mgr.init network.mgr.stop network.modem.down network.modem.up network.up network.wifi.down network.wifi.up sd.insert sd.mounted sd.remove sd.unmounted system.modem.down system.modem.gotip system.modem.stop system.start system.wifi.down ticker.1 ticker.10 ticker.300 ticker.3600 ticker.60 ticker.600 vehicle.alarm.off vehicle.alarm.on vehicle.charge.finish vehicle.charge.mode vehicle.charge.pilot.off vehicle.charge.pilot.on vehicle.charge.prepare vehicle.charge.start vehicle.charge.state vehicle.charge.stop vehicle.headlights.off vehicle.headlights.on vehicle.locked vehicle.off vehicle.on vehicle.unlocked vehicle.valet.off vehicle.valet.on

On 4 Dec 2017, at 1:11 PM, Greg D. <gregd2350@gmail.com> wrote:

Hi Mark,

Yes, all understood (I spent 14 years in wireless network R&D before retiring last year). Hidden networks have their advantages, disadvantages, and costs, and some find them useful for avoiding casual observers from seeing too much. Not everyone is an expert in InSSIDer and Wireshark, and those that are don't care a lot about whether the SSID is hidden or not, unless there's another network that isn't hidden nearby (since it's an easier target). That my laptop leaks "gregnet" while I'm sitting at the airport 50+ miles away from home isn't really a problem.

Regardless, hidden networks are a fact of life; my question was whether they could be supported in a manner such as phones and laptops do. If the Expressif APIs don't allow such without a big drain on resources, or a significant re-coding effort, then I guess that answers my question. I looked at the docs you referenced (thanks!), and I don't see a way to cause a probe either. Bummer.

As I said, it's not a showstopper for me, but I think it will be an annoyance for some. Could you explain a bit more how one would implement a geo-triggered script? I can't find the list of triggers, other than the "Icing" ones you added on 11/8.

Thanks,

Greg

Mark Webb-Johnson wrote:

...

Forgot to mention that I found this article on hidden SSIDs that provides some technical details on how some clients do/don’t handle them:

https://lifehacker.com/5636856/is-hiding-your-wireless-ssid-really-more-secu... <https://lifehacker.com/5636856/is-hiding-your-wireless-ssid-really-more-secure>

I’ve always felt this it was a bit of this:

and never used them myself.

Regards, Mark.

...

On 4 Dec 2017, at 10:13 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

Attached message from 9th November gives more detail on the way the promiscuous mode wifi client currently works.

That scan approach won’t work for hidden SSIDs, but it will handle other SSIDs elegantly and won’t connect to any SSIDs not explicitly configured.

I’m really not sure how phones do it, or how that can be applied to the Espressif ESP-32 wifi libraries. I don’t think they round-robin connect to all configured SSIDs, one after the other - imagine you have dozens of SSIDs (I do); the power consumption would be horrendous. As you mention, maybe an active probe, but I can’t find that in the Espressif API:

http://esp-idf.readthedocs.io/en/v2.1.1/api-reference/wifi/esp_wifi.html <http://esp-idf.readthedocs.io/en/v2.1.1/api-reference/wifi/esp_wifi.html>

I don’t see anything in that API other than the (expensive) connect-to-an-AP in station mode.

I’m not overly worried about this at the moment, as it is relatively simple to switch to a specific SSID in a one-line script triggered by geolocation. Most likely users will be controlling wifi by geolocation / car state anyway. But, if you have time to look into any better way of doing it, please have a go.

Regards, Mark.

<[Ovmsdev] A promiscous wifi client.eml>

...

On 3 Dec 2017, at 1:10 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

Hi Mark,

Yes, specifying the AP works fine (ignoring the crash I got when changing APs on the fly). I certainly don't expect a scan to pick up a hidden AP, but I do think that connecting to a hidden one which has been configured should work the same as a configured one that is in full peacock mode with its beacons. Both phones and laptops can; that's what probe frames are for.

Conversely (haven't checked this), we should not be connecting promiscuously to an AP that has not been configured. Way too likely to hit a Hotspot that requires a login / EULA Acceptance button, and thus breaking a perfectly good, if slow, LTE connection in favor of a hot WiFi connection that goes no where. Not to mention the security angle.

Is the promiscuous connect loop driven from the results of the scan, or by walking / probing the list of configured SSIDs? It should be the later.

Greg

Mark Webb-Johnson wrote:

...

Connecting to a hidden AP should be just specify the AP ssid:

WiFi mode client <ssid>

You won’t be able to see it in the scan, and won’t be able to promiscuously connect to it, but you should be able to directly specify it.

So long as you are running latest firmware and diff sdkconfig and sdkconfig.defaults is not too far off (pay attention to Bluetooth), it should work.

Regards, Mark

On 3 Dec 2017, at 12:11 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

...

Ah, the proverbial "heap of trouble"... {ahem} Sorry. Perhaps something to tune later, or do we need to adjust things now?

So, the original issue - automatically connecting to a hidden AP- is not related. It's not a showstopper for me since I have the dongle, but could be important for some (e.g. WiFi at home hidden, work is open). It appears that the wifi scan code is somewhere in the ELF library set. Is it worth trying to dig into it?

Greg

Stephen Casner wrote: > Greg, > > The crash was in the "new" operation because you ran out of heap > space. > > -- Steve > > On Sat, 2 Dec 2017, Greg D. wrote: > >> Hi all, >> >> Is there an easy way to enable the wifi code to connect to an SSID that's known >> (configured) but hidden, without directly telling it to? i.e., using 'wifi mode >> client' by itself (no SSID specified)? >> >> Some of the places I want to connect to are visible (seen in a scan), but the home >> network is hidden. If it helps, running a scan within earshot of the home network >> only burps up an error 'wifi: incorrect scan type: 1073583304'. >> >> Greg >> >> p.s. Possibly related, I have the module in my Roadster, connected to the V2 server >> via WiFi through a SyncUp Drive OBDII dongle that's being driven by the OBD2ECU >> engine. The SyncUp's WiFi hotspot is visible, and I have a startup script that gets >> everything going, and the OVMS module auto connects through it. I just tried forcing >> the connection over to the home network (wifi mode client gregnet) and after switching >> networks and reconnecting to the V2 server, crashed and rebooted (whereupon it >> reconnected through the dongle's network). Any ideas? >> >> OVMS > wifi mode client gregnet >> Starting WIFI as a client to gregnet... >> I (1519905) wifi: ap_loss >> I (1519905) wifi: state: run -> init (0) >> I (1519905) wifi: pm stop, total sleep time: 0/1415162800 >> >> I (1519905) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 >> I (1519915) ovms-server-v2: Disconnected from OVMS Server V2 >> I (1520415) webserver: Stopping Web Server >> I (1520415) telnet: Stopping Telnet Server >> I (1520415) ssh: Stopping SSH Server >> I (1523025) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1 >> I (1523685) wifi: state: init -> auth (b0) >> I (1523685) wifi: state: auth -> assoc (0) >> I (1523685) wifi: state: assoc -> run (10) >> I (1523715) wifi: connected with gregnet, channel 6 >> OVMS > I (1524725) event: ip: 10.30.1.102, mask: 255.255.255.0, gw: 10.30.1.1 >> I (1524725) ovms-mdns: Launching MDNS service >> WiFi UP with SSID: gregnet, IP: 10.30.1.102, mask: 255.255.255.0, gw: 10.30.1.1 >> I (1524735) webserver: Launching Web Server >> I (1524745) telnet: Launching Telnet Server >> I (1524755) ssh: Launching SSH Server >> I (1529915) ovms-server-v2: Connection is tmc.openvehicles.com:6867 <http://tmc.openvehicles.com:6867/> >> ROADSTER_834/Gdbkt2017server >> I (1530115) ovms-server-v2: Connected to OVMS Server V2 at tmc.openvehicles.com <http://tmc.openvehicles.com/> >> I (1530115) ovms-server-v2: Sending server login: MP-C 0 1zyHGC+OXD1EofY2dlH19v >> sy8L79oHSah2+yDqliMKTA== ROADSTER_834 >> I (1530305) ovms-server-v2: Received welcome response MP-S 0 N9H5zlASBHMxtzteFD9WpG >> ZoNMc8491dJNxl/x6XSIxg== >> I (1530305) ovms-server-v2: Got server response: MP-S 0 N9H5zlASBHMxtzteFD9WpG >> ZoNMc8491dJNxl/x6XSIxg== >> I (1530315) ovms-server-v2: Server token is N9H5zlASBHMxtzteFD9WpG and digest is >> ZoNMc8491dJNxl/x6XSIxg== >> I (1530315) ovms-server-v2: Server authentication is successful. Prime the crypto... >> I (1530315) ovms-server-v2: Shared secret key is >> N9H5zlASBHMxtzteFD9WpG1zyHGC+OXD1EofY2dlH19v (44 bytes) >> I (1530315) ovms-server-v2: OVMS V2 login successful, and crypto channel >> establishedbort() was called at PC 0x40121ad6 on core 1 >> 0x40121ad6: _Znwj at >> /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc:54 <http://new_op.cc:54/> >> >> >> Backtrace: 0x400886e0:0x3fff8140 0x400887df:0x3fff8160 0x40121ad6:0x3fff8180 >> 0x40121ab5:0x3fff81a0 0x40120200:0x3fff81c0 0x400f998e:0x3fff81f0 >> 0x400f3d3e:0x3fff8290 >> 0x400886e0: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519 >> >> 0x400887df: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519 >> >> 0x40121ad6: _Znwj at >> /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc:54 <http://new_op.cc:54/> >> >> 0x40121ab5: _Znaj at >> /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_opv.cc:32 <http://new_opv.cc:32/> >> >> 0x40120200: _ZN10OvmsBuffer10PollSocketEil at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- >> System-3/vehicle/OVMS.V3/main/./ovms_buffer.cpp:145 >> >> 0x400f998e: _ZN12OvmsServerV210ServerTaskEv at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- >> System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:247 >> >> 0x400f3d3e: _ZL15OvmsServer_taskPv at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- >> System-3/vehicle/OVMS.V3/components/ovms_server/./ovms_server.cpp:55 >> >> >> Rebooting... >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Is it possible to register/name the cars current location? Like if I’m parked at work, I can just use location set work?

Yes. I’m not quite sure how I forgot to handle this case. I’ve now made the ‘location set <name>’ command default latitude and longitude to the current position.

And will this work via SMS? If I can park the car and send the OVMS an SMS with the text location set xxx, that would be really great.

ALL commands will work via SMS (when that bit is implemented). Also via remote consoles like the Android App has (and iOS will too). Regards, Mark.

On 16 Dec 2017, at 12:25 AM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:

This is really nice, Mark! Is it possible to register/name the cars current location? Like if I’m parked at work, I can just use location set work?

And will this work via SMS? If I can park the car and send the OVMS an SMS with the text location set xxx, that would be really great.

Geir

...

4. des. 2017 kl. 07:13 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:

Greg,

I just tested this, and found a bug in metrics (that wasn’t calling the listeners). Now fixed, so with latest code, something like this:

OVMS > event trace on Event tracing is now on

OVMS > level info Logging level for * set to info

OVMS > location set whitehouse 38.897985 -77.036508 1000 Location defined

I (265925) events: Signal(config.changed) OVMS > metrics set v.p.latitude 38.897985 Metric set

I (281595) events: Signal(location.leave.work) OVMS > metrics set v.p.longitude -77.036508 Metric set I (289365) events: Signal(location.enter.whitehouse)

OVMS > location status Currently at 38.897984,-77.036507 (with good GPS lock) Active locations: whitehouse

So, assuming you live at the whitehouse, your script would be:

/store/events/location.enter.whitehouse wifi mode client gregnet

Regards, Mark.

P.S. To find all current events, look for ‘MyEvents.SignalEvent’ in the code. Here is what I show:

power.<device>,<state> location.enter.<location> location.leave.<location> notify.<type>

app.connected app.disconnected config.changed config.mounted config.unmounted gps.lock.los gps.lock.on network.down network.mgr.init network.mgr.stop network.modem.down network.modem.up network.up network.wifi.down network.wifi.up sd.insert sd.mounted sd.remove sd.unmounted system.modem.down system.modem.gotip system.modem.stop system.start system.wifi.down ticker.1 ticker.10 ticker.300 ticker.3600 ticker.60 ticker.600 vehicle.alarm.off vehicle.alarm.on vehicle.charge.finish vehicle.charge.mode vehicle.charge.pilot.off vehicle.charge.pilot.on vehicle.charge.prepare vehicle.charge.start vehicle.charge.state vehicle.charge.stop vehicle.headlights.off vehicle.headlights.on vehicle.locked vehicle.off vehicle.on vehicle.unlocked vehicle.valet.off vehicle.valet.on

...

On 4 Dec 2017, at 1:11 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

Hi Mark,

Yes, all understood (I spent 14 years in wireless network R&D before retiring last year). Hidden networks have their advantages, disadvantages, and costs, and some find them useful for avoiding casual observers from seeing too much. Not everyone is an expert in InSSIDer and Wireshark, and those that are don't care a lot about whether the SSID is hidden or not, unless there's another network that isn't hidden nearby (since it's an easier target). That my laptop leaks "gregnet" while I'm sitting at the airport 50+ miles away from home isn't really a problem.

Regardless, hidden networks are a fact of life; my question was whether they could be supported in a manner such as phones and laptops do. If the Expressif APIs don't allow such without a big drain on resources, or a significant re-coding effort, then I guess that answers my question. I looked at the docs you referenced (thanks!), and I don't see a way to cause a probe either. Bummer.

As I said, it's not a showstopper for me, but I think it will be an annoyance for some. Could you explain a bit more how one would implement a geo-triggered script? I can't find the list of triggers, other than the "Icing" ones you added on 11/8.

Thanks,

Greg

Mark Webb-Johnson wrote:

...

Forgot to mention that I found this article on hidden SSIDs that provides some technical details on how some clients do/don’t handle them:

https://lifehacker.com/5636856/is-hiding-your-wireless-ssid-really-more-secu... <https://lifehacker.com/5636856/is-hiding-your-wireless-ssid-really-more-secure>

I’ve always felt this it was a bit of this:

and never used them myself.

Regards, Mark.

...

On 4 Dec 2017, at 10:13 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

Attached message from 9th November gives more detail on the way the promiscuous mode wifi client currently works.

That scan approach won’t work for hidden SSIDs, but it will handle other SSIDs elegantly and won’t connect to any SSIDs not explicitly configured.

I’m really not sure how phones do it, or how that can be applied to the Espressif ESP-32 wifi libraries. I don’t think they round-robin connect to all configured SSIDs, one after the other - imagine you have dozens of SSIDs (I do); the power consumption would be horrendous. As you mention, maybe an active probe, but I can’t find that in the Espressif API:

http://esp-idf.readthedocs.io/en/v2.1.1/api-reference/wifi/esp_wifi.html <http://esp-idf.readthedocs.io/en/v2.1.1/api-reference/wifi/esp_wifi.html>

I don’t see anything in that API other than the (expensive) connect-to-an-AP in station mode.

I’m not overly worried about this at the moment, as it is relatively simple to switch to a specific SSID in a one-line script triggered by geolocation. Most likely users will be controlling wifi by geolocation / car state anyway. But, if you have time to look into any better way of doing it, please have a go.

Regards, Mark.

<[Ovmsdev] A promiscous wifi client.eml>

...

On 3 Dec 2017, at 1:10 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

Hi Mark,

Yes, specifying the AP works fine (ignoring the crash I got when changing APs on the fly). I certainly don't expect a scan to pick up a hidden AP, but I do think that connecting to a hidden one which has been configured should work the same as a configured one that is in full peacock mode with its beacons. Both phones and laptops can; that's what probe frames are for.

Conversely (haven't checked this), we should not be connecting promiscuously to an AP that has not been configured. Way too likely to hit a Hotspot that requires a login / EULA Acceptance button, and thus breaking a perfectly good, if slow, LTE connection in favor of a hot WiFi connection that goes no where. Not to mention the security angle.

Is the promiscuous connect loop driven from the results of the scan, or by walking / probing the list of configured SSIDs? It should be the later.

Greg

Mark Webb-Johnson wrote: > Connecting to a hidden AP should be just specify the AP ssid: > > WiFi mode client <ssid> > > You won’t be able to see it in the scan, and won’t be able to promiscuously connect to it, but you should be able to directly specify it. > > So long as you are running latest firmware and diff sdkconfig and sdkconfig.defaults is not too far off (pay attention to Bluetooth), it should work. > > Regards, Mark > > On 3 Dec 2017, at 12:11 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote: >> Ah, the proverbial "heap of trouble"... {ahem} Sorry. Perhaps something to tune later, or do we need to adjust things now? >> >> So, the original issue - automatically connecting to a hidden AP- is not related. It's not a showstopper for me since I have the dongle, but could be important for some (e.g. WiFi at home hidden, work is open). It appears that the wifi scan code is somewhere in the ELF library set. Is it worth trying to dig into it? >> >> Greg >> >> >> >> Stephen Casner wrote: >>> Greg, >>> >>> The crash was in the "new" operation because you ran out of heap >>> space. >>> >>> -- Steve >>> >>> On Sat, 2 Dec 2017, Greg D. wrote: >>> >>>> Hi all, >>>> >>>> Is there an easy way to enable the wifi code to connect to an SSID that's known >>>> (configured) but hidden, without directly telling it to? i.e., using 'wifi mode >>>> client' by itself (no SSID specified)? >>>> >>>> Some of the places I want to connect to are visible (seen in a scan), but the home >>>> network is hidden. If it helps, running a scan within earshot of the home network >>>> only burps up an error 'wifi: incorrect scan type: 1073583304'. >>>> >>>> Greg >>>> >>>> p.s. Possibly related, I have the module in my Roadster, connected to the V2 server >>>> via WiFi through a SyncUp Drive OBDII dongle that's being driven by the OBD2ECU >>>> engine. The SyncUp's WiFi hotspot is visible, and I have a startup script that gets >>>> everything going, and the OVMS module auto connects through it. I just tried forcing >>>> the connection over to the home network (wifi mode client gregnet) and after switching >>>> networks and reconnecting to the V2 server, crashed and rebooted (whereupon it >>>> reconnected through the dongle's network). Any ideas? >>>> >>>> OVMS > wifi mode client gregnet >>>> Starting WIFI as a client to gregnet... >>>> I (1519905) wifi: ap_loss >>>> I (1519905) wifi: state: run -> init (0) >>>> I (1519905) wifi: pm stop, total sleep time: 0/1415162800 >>>> >>>> I (1519905) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 >>>> I (1519915) ovms-server-v2: Disconnected from OVMS Server V2 >>>> I (1520415) webserver: Stopping Web Server >>>> I (1520415) telnet: Stopping Telnet Server >>>> I (1520415) ssh: Stopping SSH Server >>>> I (1523025) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1 >>>> I (1523685) wifi: state: init -> auth (b0) >>>> I (1523685) wifi: state: auth -> assoc (0) >>>> I (1523685) wifi: state: assoc -> run (10) >>>> I (1523715) wifi: connected with gregnet, channel 6 >>>> OVMS > I (1524725) event: ip: 10.30.1.102, mask: 255.255.255.0, gw: 10.30.1.1 >>>> I (1524725) ovms-mdns: Launching MDNS service >>>> WiFi UP with SSID: gregnet, IP: 10.30.1.102, mask: 255.255.255.0, gw: 10.30.1.1 >>>> I (1524735) webserver: Launching Web Server >>>> I (1524745) telnet: Launching Telnet Server >>>> I (1524755) ssh: Launching SSH Server >>>> I (1529915) ovms-server-v2: Connection is tmc.openvehicles.com:6867 <http://tmc.openvehicles.com:6867/> >>>> ROADSTER_834/Gdbkt2017server >>>> I (1530115) ovms-server-v2: Connected to OVMS Server V2 at tmc.openvehicles.com <http://tmc.openvehicles.com/> >>>> I (1530115) ovms-server-v2: Sending server login: MP-C 0 1zyHGC+OXD1EofY2dlH19v >>>> sy8L79oHSah2+yDqliMKTA== ROADSTER_834 >>>> I (1530305) ovms-server-v2: Received welcome response MP-S 0 N9H5zlASBHMxtzteFD9WpG >>>> ZoNMc8491dJNxl/x6XSIxg== >>>> I (1530305) ovms-server-v2: Got server response: MP-S 0 N9H5zlASBHMxtzteFD9WpG >>>> ZoNMc8491dJNxl/x6XSIxg== >>>> I (1530315) ovms-server-v2: Server token is N9H5zlASBHMxtzteFD9WpG and digest is >>>> ZoNMc8491dJNxl/x6XSIxg== >>>> I (1530315) ovms-server-v2: Server authentication is successful. Prime the crypto... >>>> I (1530315) ovms-server-v2: Shared secret key is >>>> N9H5zlASBHMxtzteFD9WpG1zyHGC+OXD1EofY2dlH19v (44 bytes) >>>> I (1530315) ovms-server-v2: OVMS V2 login successful, and crypto channel >>>> establishedbort() was called at PC 0x40121ad6 on core 1 >>>> 0x40121ad6: _Znwj at >>>> /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc:54 <http://new_op.cc:54/> >>>> >>>> >>>> Backtrace: 0x400886e0:0x3fff8140 0x400887df:0x3fff8160 0x40121ad6:0x3fff8180 >>>> 0x40121ab5:0x3fff81a0 0x40120200:0x3fff81c0 0x400f998e:0x3fff81f0 >>>> 0x400f3d3e:0x3fff8290 >>>> 0x400886e0: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519 >>>> >>>> 0x400887df: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519 >>>> >>>> 0x40121ad6: _Znwj at >>>> /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc:54 <http://new_op.cc:54/> >>>> >>>> 0x40121ab5: _Znaj at >>>> /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_opv.cc:32 <http://new_opv.cc:32/> >>>> >>>> 0x40120200: _ZN10OvmsBuffer10PollSocketEil at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- >>>> System-3/vehicle/OVMS.V3/main/./ovms_buffer.cpp:145 >>>> >>>> 0x400f998e: _ZN12OvmsServerV210ServerTaskEv at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- >>>> System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:247 >>>> >>>> 0x400f3d3e: _ZL15OvmsServer_taskPv at/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring- >>>> System-3/vehicle/OVMS.V3/components/ovms_server/./ovms_server.cpp:55 >>>> >>>> >>>> Rebooting... >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev> > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev