BUG location on windows

[SiNaPsEr0x]

WiFi location fails when device is on Ethernet — No location endpoint available

Prey version: 1.13.33
Node.js version: v22.22.0
OS: Windows 11 x64 — build 10.0.26200 (26H2)
winsvc version: 2.0.33

---

Description

WiFi-based location consistently fails when the device is connected to the internet
via Ethernet and the WiFi adapter is active but not associated to any network.

The WiFi adapter correctly scans 13 nearby access points with valid BSSIDs
(confirmed via netsh wlan show networks mode=bssid, signal strength up to 90%).
Despite this, every location request ends with Error: Unable to get location.

---

Steps to Reproduce

1. Connect device to internet via Ethernet cable
2. WiFi adapter enabled, scanning passively — not connected to any WiFi network
3. Install Prey v1.13.33, link to account
4. Request location from control panel (or let Aware Tracking trigger it)
5. → Error: Unable to get location every time

---

Expected Behavior

WiFi triangulation should work using any visible access points (by BSSID/signal strength),
regardless of whether the device is actively connected to one of them.
This is standard WiFi positioning behavior — you only need to see networks, not be
associated to one. The device has a working internet connection via Ethernet.

---

Actual Behavior

Location always fails. Debug log reveals the exact error chain:

debug [geo] [WIN32-INDEX] Windows detected. Delegating to win32LocationFetch orchestrator.
debug [geo] [WIN32-CACHE] Cache expired or not set (first fetch). Starting new fetch...
debug [geo] [WIN32-HISTORY] Retrieved no record
debug [geo] [WIN32-START] History empty → routing to BOOTSTRAP
debug [geo] [WIN32-BOOTSTRAP] Starting bootstrap (first location, empty history)
info  [geo] [WIN32-BOOTSTRAP] No anchor baseline — fetching fresh WiFi
info  [geo] Getting location via wifi strategy
debug [providers] Fetching access_points_list
debug [geo] Sending AP data to location service
debug [geo] [WIN32-BOOTSTRAP] ERROR: Wifi fetch failed during bootstrap
debug [geo] [WIN32-CONCURRENCY] Fetch complete. ERROR: No location endpoint available
error Error: Unable to get location

Key line: active_access_point: undefined — no active WiFi association.

AP data is collected and sent (Sending AP data to location service), but the pipeline
then returns No location endpoint available. The IP-based fallback introduced in
v1.13.33 does not trigger.

---

Diagnostics (external causes ruled out)

• netsh wlan show networks mode=bssid → 13 networks, all BSSIDs populated ✅
• sc query lfsvc → STATE: 4 RUNNING ✅
• Test-NetConnection www.googleapis.com -Port 443 → TcpTestSucceeded: True ✅
• Direct POST to www.googleapis.com/geolocation/v1/geolocate via Prey's own node.exe
  → HTTP 400 keyInvalid (server responds, TLS/TCP works) ✅
• prey config settings list → all permissions true, disabled_methods: [] ✅

The issue is not DNS, firewall, antivirus, Windows Location Services, or missing
WiFi networks. All external checks pass.

---

Config (verified correct)

control-panel.permissions.wifi_location:  'true'
control-panel.permissions.native_location: 'true'
control-panel.location_aware:              true
control-panel.location.disabled_methods:   []

---

Additional Notes

• The No location endpoint available error occurs even though Sending AP data to location service is logged immediately before — suggesting the endpoint lookup
  fails after the data is ready, not before.
• IP-based fallback (v1.13.33 feature) never activates despite WiFi strategy failing.
• The device has never successfully reported a location (WIN32-HISTORY: Retrieved no record on every attempt — no baseline is ever established).

---

Suggested Fix

The WIN32-BOOTSTRAP pipeline should use the scanned access points list
(access_points_list) to perform WiFi triangulation independently of whether
active_access_point is defined.

Currently the pipeline appears to require an active WiFi association before it
considers a location endpoint available. This check should be relaxed: if
access_points_list contains at least one entry with a valid BSSID, the
geolocation request should proceed regardless of active_access_point being
undefined.

In other words: decouple WiFi scanning from WiFi association in the location
pipeline. A device connected via Ethernet with a passive WiFi scan returning
valid BSSIDs has everything needed for triangulation.

[SoraKenji]

Hey @SiNaPsEr0x, thank you for the incredibly detailed report — the diagnostics and log breakdown are genuinely useful.
After reviewing your findings, we can confirm the issue isn't in the WiFi scanning or association logic you investigated — the client-side behavior is actually working as expected. The failure is happening at a different layer, and it's something we're already looking into on our end.
We'll update this thread once we have more to share. Thanks again for the effort you put into this.

[SiNaPsEr0x]

Thank you very much for the comment, I thought that a software of this type also needed this requirement, many do not pay attention to it but the reason for security on fixed devices is as important as that of laptops