upvote

points

by stuckindoors15 hours ago |
comments
upvoteby ezfe15 hours ago|
next
[-]
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.
reply
upvoteby zakisaad14 hours ago|
parent|
next
[-]
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.
reply
upvoteby ezfe13 hours ago|
parent|
next
[-]
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.
reply
upvoteby singron11 hours ago|
parent|
next
[-]
Specifically it decrements the TTL of routed packets, so hotspot traffic will tend to have a TTL of 63 instead of 64. You could theoretically disable this at the risk of creating infinite routing loops, although android probably makes it inaccessible if the kernel has a setting for it at all, so you might have to rewrite packets in user space.
reply
upvoteby josh37362 hours ago|
parent|
[-]
It has been a long time since I've done this, but:

If your Android is rooted, it's pretty easy to get tethering working. There's magisk modules that can fix the TTL problem and/or disable the hidden carrier-installed software that Android will ask for permission before enabling tethering.

reply
upvoteby rkagerer12 hours ago|
parent|
prev|
next
[-]
Different applications on a single device can't apply different TTL's? I thought TTL was a pretty basic knob exposed to applications. e.g. A sensor that transmits fresh data every 20 seconds doesn't need stale packets bounding around clogging up the pipes, while a file transfer over an intermittently delayed link might benefit from a higher TTL.
reply
upvoteby eptcyka12 hours ago|
parent|
prev|
next
[-]
Voluntarily tags specific TTL values much like your home router does. Some providers assign a different IP to hotspot users.
reply
upvoteby taneq11 hours ago|
parent|
prev|
next
[-]
> voluntarily tags

Aah, you mean ‘snitches’. :P

reply
upvoteby jamiek8812 hours ago|
parent|
prev|
[-]
Super easy to spoof too.
reply
upvoteby drtz13 hours ago|
parent|
prev|
next
[-]
> 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.

reply
upvoteby HDBaseT13 hours ago|
parent|
[-]
Deep Packet Inspection presumably requires a certificate to be installed on my device to allow my connection to be MiTM'd.
reply
upvoteby codebje13 hours ago|
parent|
next
[-]
DPI can refer to inspecting beyond just the headers, but since it's more of a marketing term than a technical one, you could also say you're "deeply inspecting" the IP headers of a packet and no-one would show up to arrest you for bad terminology.

Anyway, one way to detect NAT is to observe different TTLs originating from one device. Is that deep inspection? Probably depends on who you ask. The fact that you have to track information across multiple packets counts for something, though.

Off the top of my head I wouldn't really expect there to be much value in a MITM inspection of the contents of HTTP traffic for the purposes of NAT detection. You could probably come up with some scenarios in which it might be possible, but I'd content those scenarios aren't very practical. Easier to compare TTLs between packets, say, or track connections to known OS "phone home" destinations. While these just use information from the IP layer, they're stateful observations requiring comparisons across multiple packets, and that might count for something.

One way to detect a shitty carrier service, though, is that they're inspecting your traffic for "good" or "bad" uses of their service, because that is a good indicator that they're not just a carrier. I call it Dickish Practices Identification, or DPI.

reply
upvoteby akerl_13 hours ago|
parent|
prev|
next
[-]
DPI is distinct from TLS MITM (though many enterprise devices offer both).

The delineation here is between "shallow" packet inspection (which basically nobody refers to because it's just a normal part of networking), where network devices look at just the bits of the packets they need to route / NAT / etc them appropriately.

DPI can tell a ton of things without needing to MITM encrypted layer 7 traffic.

A boring example is that you can tell TLS from OpenSSH traffic just by seeing the initial handshake. sslh ( https://github.com/yrutschle/sslh ) takes advantage of this on the server side to let you run both on the same port.

A less boring example is identifying OpenVPN, Wireguard, etc traffic regardless of what port they're run on, to enable blocking VPN traffic on a network.

reply
upvoteby ninjaoxygen12 hours ago|
parent|
prev|
[-]
At one point it was definitely not so deep... carriers were literally looking at the IP TTL and seeing whether it was a recognised value from the phone or a few hops less than one of the common defaults, in which case it was considered tethering traffic.

You could spoof it by finding out your mobile's TTL, overriding the TTL in the connecting device to be one higher than the mobile.

reply
upvoteby HnUser1212 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby Centigonal12 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby taneq12 hours ago|
parent|
prev|
[-]
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.)
reply
upvoteby rconti15 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby dotancohen14 hours ago|
parent|
prev|
[-]
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?

reply
upvoteby svens_13 hours ago|
parent|
next
[-]
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.

reply
upvoteby ywain14 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby happyPersonR14 hours ago|
prev|
[-]
Does anyone have a flow log or pcap or something from the phone showing this tho?
reply