From: Inemesit Affia <inemesitaffia@gmail.com>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>,
starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran
Date: Thu, 15 Jan 2026 11:32:25 +0100 [thread overview]
Message-ID: <6a7e0aee-970f-44ad-8182-2091fbe6488f@gmail.com> (raw)
In-Reply-To: <5c0a93c4-21b2-4297-b4bb-befce0963a93@auckland.ac.nz>
Something more about d2c and other things.
In 4G the network can limit services to say SMS only. Or calls only. But once you give the phone access to IP, the phone is responsible for limiting itself. Hence satellite enabled apps. Without this we've seen people do speed tests on the DTC network.
More spectrum in use means more power or sometimes more equipment to do jamming. Only GPS and the Ku uplink seem to be jammed.
Expertise for RF work doesn't have to be local. Huawei is a world leader. And I'm sure you're familiar with expats.
As for underserved areas, Starlink may be advertised as a rural service, but in poorer countries, most users aren't just suburban but actually Urban
Jan 15, 2026 10:51:32 AM Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>:
> I guess you would have all been following the reporting on Iran & how Starlink is being used a communication backroute out of the country, but also how it's being jammed by the Iranian government. Today, I received a petition request from an NGO asking me to sign a petition to get Elon to turn on D2C (direct-to-cell) over Iran, and it's phrasing it in such a way that it'd "turn the lights on".
>
> My 5 cents worth:
>
> Jamming: Over every location in Iran, there are several dozen Starlink satellites visible at any one time that Dishys on the ground can in principle communicate with (read: 25 deg plus above the horizon and clear of the geostationary arc). There are purportedly tens of thousands of Dishys in the country. Each of those Dishys (when working) communicates with one of the satellites, and does so by pointing a beam at the satellite - which points a beam back. Even two Dishys in close vicinity of each other generally talk to different satellites.
>
> To jam communication between a Dishy and a satellite you have to insert the jammer into the transmission path - either by pointing it at the satellite's receiver, or by pointing it at the Dishy. In either case, you want to do so ideally from the direction of the respective transmitter that the receiver is listening to, because there isn't all that much sensitivity if you're jamming off beam. Basically, because signal power drops of with the square of the distance, you need to be fairly close to a Dishy in order to out-shout the transmitter at the far end of the beam if you're trying to jam from outside the beam.
>
> Jamming the main traffic channels to Dishy is an uphill task - for a total blackout, you'd have to cover a good part of the 2 GHz total in Ku with sufficient power in terms of spectral density to cause mischief. Not easy.
>
> Likewise, pointing your jammer at the satellite(s) is mission impossible because there's every chance that the satellites will be listening to Dishys that are in a different direction from you.
>
> There would I guess be some opportunity in terms of jamming management channels (e.g., access grant channel) but even this is complex with that number of satellites around.
>
> Plus those babies move, so you need jammers that can track. And 15 seconds after you're worked out what you need to point where, Starlink changes the game on you.
>
> The Independent quotes "a specialist in digital repression and associate director of the Technology Threats and Opportunities Program at Witness" https://www.independent.co.uk/news/world/middle-east/iran-internet-blackout-protest-starlink-musk-b2900101.html saying that they think it's GPS jamming. For all I know Starlink doesn't need GPS - while Dishys have GPS receivers, Starlink's got its own positioning system, too. Also, GPS jamming is fairly common globally and it's not known to be impairing Starlink all that much.
>
> D2C: Maybe someone should have asked the NZ Commerce Commission for advice first. They figured out a long time ago that D2C isn't quite there yet (and may never get fully there). It's only capable of supporting a comparatively small number of devices per unit area on the ground, and apart from a small number of premium phones, with text and perhaps RCS/MMS only. And that's with a telco on the ground that's actually cooperating and making frequencies available. One NZ, the New Zealand telco who partners with SpaceX on the D2C here, had its marketing department shouting the virtues from the rooftops until the Commerce Commission filed criminal charges. They're still in the game but when I bought a new mobile phone the other day, it took me several minutes to find the page that listed compatible phones. The service is now a little less prominent on their home page - you have to scroll a little to find it. Also, word doesn't seem to have gotten around that your mobile phone - even if satellite-capable - will connect to terrestrial networks with priority. So Iranians would have to go pretty far out into the desert just to TXT. Oh, and cellphones are a lot easier to jam than Dishys...
>
> Of course, that's not the only consideration here. Using Starlink is illegal in Iran, and I guess getting caught with a Dishy is a bit risky there at the moment. But RF direction finding 50k+ Dishys that change transmit frequency a couple of times a minute isn't trivial: It requires specialised equipment and skill, both of which are likely to be in short supply at the moment. So I suppose visual identification of Dishys (from the air or high rise buildings) might be a more promising tactic. But of course they can be camouflaged to an extent as well as moved.
>
> Also, Starlink tends to be more of a technology for underserved rural areas rather than cities in countries with high Internet penetration rates - which Iran is one of. So it's likely that many of the tens of thousands of Dishys are in rural locations where there haven't been any large protests.
>
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
next prev parent reply other threads:[~2026-01-15 10:32 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 9:51 [Starlink] Starlink and Iran Ulrich Speidel
2026-01-15 10:06 ` [Starlink] " Inemesit Affia
2026-01-15 10:30 ` Ulrich Speidel
2026-01-15 10:44 ` Inemesit Affia
2026-01-15 11:16 ` Ulrich Speidel
2026-01-15 10:32 ` Inemesit Affia [this message]
2026-01-15 10:51 ` Ulrich Speidel
2026-01-15 11:17 ` David Lang
2026-01-15 11:59 ` Sauli Kiviranta
2026-01-15 14:08 ` David Lang
2026-01-15 15:29 ` Sauli Kiviranta
[not found] ` <3af2ac06-e098-4c79-869d-9c389959ca07@gmail.com>
[not found] ` <q9304244-661o-3qsr-o6rp-9q1nqq09r419@ynat.uz>
[not found] ` <4ba64a41-bbbf-4fb5-adb0-c77c15e4ca0f@gmail.com>
2026-01-15 16:20 ` Inemesit Affia
2026-01-15 20:12 ` Ulrich Speidel
2026-01-15 17:10 ` J Pan
2026-01-15 20:07 ` Ulrich Speidel
2026-01-15 21:47 ` Oleg Kutkov
2026-01-16 4:18 ` Ulrich Speidel
2026-01-16 8:12 ` Frantisek Borsik
2026-01-16 8:24 ` Inemesit Affia
-- strict thread matches above, loose matches on Subject: below --
2026-01-15 14:50 David Fernández
2026-01-15 16:11 ` Oleg Kutkov
2026-01-15 17:13 ` J Pan
[not found] <176849731431.1249.14387618908540773471@gauss>
2026-01-15 17:42 ` Colin_Higbie
2026-01-15 18:56 ` Jim Forster
2026-01-15 20:15 ` Ulrich Speidel
2026-01-15 20:27 ` Ulrich Speidel
2026-01-15 20:30 ` Hayden Simon
2026-01-15 21:06 ` Ulrich Speidel
2026-01-15 21:09 ` Hayden Simon
2026-01-15 21:20 ` Ulrich Speidel
2026-01-15 21:23 ` Hayden Simon
[not found] <176851123059.1249.8585659892308012167@gauss>
2026-01-15 21:49 ` Colin_Higbie
2026-01-15 23:15 ` Frantisek Borsik
2026-01-16 0:13 ` Ulrich Speidel
2026-01-16 1:29 ` David Lang
2026-01-16 22:55 ` Frantisek Borsik
2026-01-16 23:06 ` J Pan
[not found] ` <13187.1768590201@obiwan.sandelman.ca>
2026-01-16 23:30 ` Ulrich Speidel
2026-01-17 0:07 ` David Lang
2026-01-17 21:56 ` Ulrich Speidel
2026-01-19 20:39 ` David Lang
2026-01-28 3:09 ` Ulrich Speidel
2026-01-28 3:30 ` David Lang
2026-01-28 4:02 ` Mike Puchol
2026-01-28 9:05 ` Ulrich Speidel
2026-01-28 9:53 ` David Lang
2026-01-28 20:43 ` Ulrich Speidel
2026-01-28 20:55 ` David Lang
2026-01-17 18:32 ` Michael Richardson
2026-01-17 18:38 ` Inemesit Affia
2026-01-17 19:25 ` Michael Richardson
2026-01-17 22:12 ` Ulrich Speidel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a7e0aee-970f-44ad-8182-2091fbe6488f@gmail.com \
--to=inemesitaffia@gmail.com \
--cc=starlink@lists.bufferbloat.net \
--cc=u.speidel@auckland.ac.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox