From: Sauli Kiviranta <smksauli@gmail.com>
To: David Lang <david@lang.hm>
Cc: Ulrich Speidel <u.speidel@auckland.ac.nz>,
"starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Re: Starlink and Iran
Date: Thu, 15 Jan 2026 17:29:50 +0200 [thread overview]
Message-ID: <CAJbqEYDY+QArTAmr9mau7DFyuosPbzG2JARvLSK4rAyvNO9qSg@mail.gmail.com> (raw)
In-Reply-To: <0or232r4-op62-2700-p842-3rp7s82n6413@ynat.uz>
X posts by Grok:
”Various sources report widely differing levels of packet loss affecting
Starlink connections in Iran during the January 2026 internet blackouts and
protests. Reported figures range from roughly 20% to more than 80%,
depending on location, timing, and source. This variability is most
plausibly explained by localized jamming and interference efforts, which
appear to impact specific neighborhoods or regions more severely than
others rather than producing uniform nationwide disruption. The claims
below are grouped by reported packet-loss ranges and are drawn from media
reports, technical analyses, and social media posts that explicitly
reference packet loss measurements or estimates, often based on user
reports, NetBlocks monitoring, or expert commentary.
Claims of 20–22% packet loss
Research cited by bne IntelliNews reports sustained packet loss of
approximately 20–22% over five-minute sampling windows in tested areas,
compared with Starlink’s typical baseline of under 1%. These losses were
attributed primarily to GPS spoofing attacks.
Claims of approximately 30% packet loss
Several outlets and analysts report packet loss around 30% in affected
areas. TechRadar describes degraded Starlink performance reaching roughly
this level due to jamming. Multiple X posts, including those by
@Intelligencer41 and @NuclearID68, cite figures near 30%, often attributing
the data to digital rights researcher Amir Rashidi or the Miaan Group.
These reports generally describe averages or moderate interference rather
than worst-case conditions.
Claims of 30–40% packet loss
Euronews reports packet loss of up to 40% in parts of Tehran, likely caused
by mobile jamming equipment deployed in urban areas.
Claims of 30–80% packet loss
A number of sources describe much wider ranges, with packet loss varying
between 30% and 80% depending on time and place. France 24 and Ars Technica
both report losses within this range, attributing them to state-sponsored
jamming technologies. Similar figures appear in user discussions on Reddit
and in reporting by Techflowpost, which notes averages around 30% on the
first day of the blackout but spikes up to 80% in some locations. Multiple
X posts echo this pattern, emphasizing strong geographic variability and
particularly severe impacts in dense urban neighborhoods.
Claims of 80% or higher packet loss
The highest figures appear in reports describing intensive or
military-grade jamming. Forbes, cited via social media, reports disruptions
affecting roughly 80–90% of Starlink traffic in some contexts. Other
claims, based largely on anonymous user reports or social media posts, also
suggest packet loss exceeding 80% during peak interference periods.
Broader context
NetBlocks, referenced across several reports and posts, confirms elevated
packet loss and unstable Starlink connectivity during the blackout period,
though it does not always provide precise percentages. Other cybersecurity
reporting notes sharp increases in packet loss linked to GPS and RF jamming
without quantifying exact levels. Several sources attribute the
interference technology to Russian- or Chinese-supplied systems, while
emphasizing that effectiveness varies substantially by region.
Overall, lower reported figures in the 20–30% range generally reflect
averages or less-affected areas, whereas higher figures, reaching 80–90%,
appear to correspond to localized hotspots, particularly in parts of
Tehran. The estimates rely on user-submitted measurements, network
monitoring tools such as Cloudflare Radar, and expert analysis.”
20% is not that bad, but 80% starts to be a bit 😅
- Sauli
On Thursday, January 15, 2026, David Lang <david@lang.hm> wrote:
> Sauli Kiviranta wrote:
>
> "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."
>>
>> Do we have any technical characteristics about the jamming how it is
>> visible to the application layer? I saw some X posts talk about 20% packet
>> loss, some said 80%.
>>
>> Anyone from SpaceX can comment on what is the challenge "requirements" for
>> contributions?
>>
>
> I would not expect this information to be made public. Finding out what
> SpaceX is trying (and even finding out how SpaceX categorizes the attacks
> as hard/easy to deal with) would be valuable information for those trying
> to block the signal.
>
> David Lang
>
next prev parent reply other threads:[~2026-01-15 15:29 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
2026-01-15 11:59 ` Sauli Kiviranta
2026-01-15 14:08 ` David Lang
2026-01-15 15:29 ` Sauli Kiviranta [this message]
[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=CAJbqEYDY+QArTAmr9mau7DFyuosPbzG2JARvLSK4rAyvNO9qSg@mail.gmail.com \
--to=smksauli@gmail.com \
--cc=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