From: David Lang <david@lang.hm>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Re: Starlink and Iran
Date: Thu, 15 Jan 2026 04:17:35 -0700 (MST) [thread overview]
Message-ID: <q459rp19-7ppq-2o1p-5128-n4088op69o0n@ynat.uz> (raw)
In-Reply-To: <5c0a93c4-21b2-4297-b4bb-befce0963a93@auckland.ac.nz>
Authorized or not, starlink service has been turned on in Iran, I would assume
that D2C is enabled as well.
D2C is not going to be good for livestreaming video, it will support text and
voice communications
Jamming the D2C signal is far easier than jamming the dishys, all you need is
to have the towers running with a stronger signal. (the phones will connect to
the tower with the strongest signal). It's also easier to jam the D2C satellites
(wider beamwidth and fewer that need to be jammed)
I don't think they would need to get new sims, esims, etc in place, they just
need to instruct the satellites to accept any sim rather than only authorized
sims.
creative use of aluminum foil should be able to shield your phone from the
ground based towers, leaving them nothing other than the satellites for the
phone to connect to (this will also block bluetooth, but wired connections to
the phones will work)
In terms of tracking/jamming the dishys normal signal, I think it would be
easier to track/jam their wifi signal, those default to SSID STARLINK and will
be in a known MAC range. disabling wifi and only working with a wired connection
is going to be much safer (admittedly, less convienient, but when they are
threatening to kill you if you use a dishy, you should batch upload via a wired
connection, not try to livestream the protests, at least, not unless you are
truely mobile)
At the beginning of the invasion of Ukraine, Elon said that people needed to be
careful, have a hill or other obstruction between the dishy and the bad guys,
don't leave it running all the time, etc (basic signal security)
I have seen reports that SpaceX is in all-hands-on-deck mode to work to defeat
the jammers. I expect that this will include things like pointing the beams at
different dishy cells than they normally would use, etc.
I could see GPS jamming being a problem, if the dishy thinks it's somewhere
other than where it really is, how successful will it be in connecting to the
right satellites?? there are ways to work around this, and that may also be what
starlink is working on.
David Lang
Ulrich Speidel wrote:
> 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.
>
>
>
next prev parent reply other threads:[~2026-01-15 11:17 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
2026-01-15 10:51 ` Ulrich Speidel
2026-01-15 11:17 ` David Lang [this message]
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=q459rp19-7ppq-2o1p-5128-n4088op69o0n@ynat.uz \
--to=david@lang.hm \
--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