Comment by stuckindoors
18 hours ago
When reading the article I think he appears to be talking about car play/android auto connection not audio only connections. I think Bluetooth in AA and Carplay is used to configure a local network between the phone and the car to transmit the images to the cars screen. I would assume that that data capability can also be used for the car to communicate with the Internet.
It does produce a local Wi-Fi network but there's no evidence that it supports internet communication. That would be considered a hotspot, which not all carriers even support.
I've never understood how this can be limited in practice: surely as far as the carrier is concerned, all traffic from the mobile device is the same (unless there are identifiers on the traffic coming from hotspotted devices via the mobile device). Here in Australia we've never had any form of hotspot detection/segmentation - if you have a data plan, all data features work (across all carriers). I do recall lots of online chatter from the US though, especially years back when mobile data was more of a precious resource.
Your phone voluntarily tags the hotspot data with specific TTL values which carriers use to segment the data. Not all carriers work the same though.
6 replies →
> surely as far as the carrier is concerned, all traffic from the mobile device is the same
Going on a bit of a tangent, but deep packet inspection can identify packets routed using NAT, so if the phone is operating as a typical hotspot it would be identifiable by your carrier. Carriers in the USA used to block / denylist / charge extra for tethering using this exact approach.
4 replies →
I recently switched to a carrier (Fido/Rogers in Canada). My plan limits hotspot by disabling the hotspot settings on ios. However, I was able to enable it again by changing the access point name.
On android, there is an OS-level feature that checks the cell tower to verify if you're allowed to create a hotspot. It runs whenever you try to enable the hotspot feature. On rooted systems, you can disable this check. There are also apps that let you run a hotspot without using the OS feature, bypassing the check.
I believe there’s some stuff like that for commercial things. One project I worked on used an ‘IoT portal’ for cloud based telemetry (at the customer’s request) and we had to get a special SIM card for it (although I don’t know if this is still needed.)
Plus it seems unlikely that the telematics module is even really related to the display screen stuff, let alone being configured to use alternate network connections to transmit data.
How does the carrier know that the traffic is being proxied for another device, and not e.g. requested from the phone's web browser or another app?
Does the phone add a proxy header? Can it be configured to not add the header?
There might be multiple methods and heuristics, but one way that I have encountered was based on packet TTL.
Android and Linux use 64 by default - the block could be circumvented by setting the laptop to use 65 TTL.
Mostly by looking at packets TTL. It gets decreased by 1 by the hotspot’s NAT so if the value is something like 63 or 127 (instead of 64 or 128 which are the defaults for most platforms) then it’s almost certain the packet originated from a device behind the phone and not from the phone itself.
Does anyone have a flow log or pcap or something from the phone showing this tho?