[ssl-3]

Unless your phone is rooted, TTL mangling happens on the hotspot-using client devices.

Specific details depend on what that client device uses for an operating system, and this makes it impossible to neatly summarize.

But it can be done fairly easily with things like OpenWRT or Mikrotik's RouterOS, or a regular stand-alone Linux box, and IIRC it's a simple one-liner on a Windows machine.

Because it can't be easily summarized, Google is your friend here. Generally, you want the TTL of all packets leaving the client (router, tablet, laptop, or whatever) to be set to 65 -- which is one more than the Android default of 64.

That's all the information you need to know to Google up instructions that work with your particular devices.

(I may or may not keep a Mikrotik-based hotspot-abuser in my work truck as a problem solver.)

[jowea]

Ok that does seems more viable than mangling it on the average Android phone. Unless of course you're tethering another smartphone by sharing the wifi hotspot, which in my personal experience is a common use case.

[ssl-3]

Yeah, rootless smartphone-to-smartphone (or tablet) is a harder problem to solve without an intermediary device.

But! That intermediary device could be something like a Raspberry Pi Zero.

It isn't "low power" by the strictest definitions, but it is also not particularly expensive power-wise -- it can be powered with USB OTG from a smartphone from the past decade or so. And it is very small, which also counts.

It can obviously run a real Linux distro (or just parts of one), but can also run OpenWRT -- which by nature tends to tolerate intermittent power very well.

It's theoretical, but (again in theory): A Zero W running OpenWRT might be a relatively simple path for a portable hotspot abuser.

First, dump OpenWRT onto an SD card, plug it in an and get in there with a browser -- however that is done.

Second: Create an interface or two for getting hotspot data into it: Maybe one of them via wifi, and another via USB tethering from the connected phone.

Third: Test. At least the Pi itself should have Internet connectivity by this point.

Fourth: Set it up as a wifi access point (I think that chipset can do both at once in OpenWRT), and get NAT going.

Fifth: Utter the well-documented incantations for mangling TTL on all of the hotspot interfaces.

Sixth: Wrap it in nice 3M Super 33+ electrical tape for posterity and a minimum of protection for those tiny SMD parts.

Seventh: ???

Eighth: Profit!!! Or, better: Push the resulting SD card image to the usual places, with correct attribution and license compliance, so that others can benefit more-easily.

Seems doable. To use, just power it on/plug it in, and turn tethering/hotspot on with the donor phone. And then connect other phones to the WiFi AP provided by the Pi.

It'll eat phone batteries pretty quick, but it might last long enough to get someone else out of a jam. (It'll also work well on a portable power bank, and those are also cheap.)