No longer sending SSID/BSSID

[CiaranG]

• App build number: 2.5.3
• Android version: 14
• Device: Samsung Galaxy S23
• Installation source: Google Play

The app no longer sends SSID and BSSID for the connected wifi access point. This was working ok in previous versions - I'm not sure exactly when it stopped.

[jpmens]

I'm still seeing them in 2.5.3 (Galaxy S8)

If you're using our Recorder: have you verified that the data isn't in a _type: location record?

[CiaranG]

I'm using my own HTTP endpoint. This is what I see posted:

{'_type': 'location', '_id': '82486537', 'acc': 12, 'alt': 80, 'batt': 71, 'bs': 1, 'cog': 0, 'conn': 'w', 'created_at': 1729344894, 'lat': 0, 'lon': 0, 'm': 2, 'tid': '01', 'topic': 'owntracks/owntracks1/galaxys23', 'tst': 1729344893, 'vac': 3, 'vel': 0}

So conn is w for WiFi, and previously that would have been accompanied by SSID and BSSID in the same message, right?

[jpmens]

(I have redacted lat/lon out of your message for your privacy.)

Could you please explicitly publish a message (up-arrow on top right of map)? That should add a "t":"u" element to the JSON. Do SSID/BSSID show then?

[jpmens]

Are you also quite sure your endpoint is not removing values? What you posted above is not the JSON string received from the device ...

[CiaranG]

Thanks - I decided the lat/lon didn't really matter as I wasn't at the secret batcave, but it's best not to set a bad example!

Here's what was received as a result of pressing the up-arrow, still no SSID/BSSID...

{'_type': 'location', '_id': '6fd8a7fd', 'acc': 7, 'alt': 80, 'batt': 91, 'bs': 1, 'cog': 108, 'conn': 'w', 'created_at': 172 9491498, 'lat': 0, 'lon': 0, 'm': 2, 't': 'u', 'tid': '01', 'topic': 'owntracks/owntracks1/galaxys23', 'tst': 1729491497, 'vac': 3, 'vel': 5}

The output I posted was just directly parsed from the JSON, nothing removed. To be sure, I logged the raw string prior to parsing, here's an example:

{"_type":"location","_id":"ea0bc971","acc":10,"alt":80,"batt":90,"bs":1,"cog":0,"conn":"w","created_at":1729491883,"lat":0,"lon":0,"m":2,"tid":"01","topic":"owntracks/owntracks1/galaxys23","tst":1729491883,"vac":2,"vel":0}

[jpmens]

There's a setting called "extra data" or similar (can't check now). Is that on in the Android OwnTracks app?

[CiaranG]

"Extended data" - it's on, yes. I'm getting the battery status and the connection type, for example.

[wir3z]

Not seeing any issues on the Play Store version of 2.5.3 on Android 14 (extended data on).

[CiaranG]

I had a sudden idea about this overnight, which I've just tested and it turned out to be right... I have the tailscale app on this phone, and it has interfered with things before. The test I've just done is a) disabled the talscale connection, and watched reports coming into the HTTP server with SSID/BSSID included in them, and then b) re-enabled the tailscale connection, and watched as the reports no longer contained those two entries. I repeated a few times to be sure.

So I don't know why that's causing it, but it definitely is.

[jpmens]

Thanks for reporting back. Closing now as not our bug.

[growse]

I'm interested in why the API that we query for SSID returns nothing when tailscale is active.

At a guess, the API returns properties of the currently active connection, which may or may not be a WiFi connection (could be VPN or Ethernet).

@jpmens the question is then what the behaviour should be. Should those values in the message show the SSID of a connected WiFi, even if that isn't the current primary data connection? What if there's multiple radios associated with multiple APs?

FWIW, I don't think the current behaviour is undesirable, but it might be worth flagging in the docs/spec, as it'll likely affect anyone on a VPN.

[jpmens]

@growse I don't think we should invest any time on this; IMO the behavior is fine as it is. I have added an appropriate note to the Booklet (pointing back to this issue).