Forem: Musa Nayyer

Signal QR Stuck on Spinner — University Firewall Was the Culprit

Musa Nayyer — Sun, 24 May 2026 06:43:16 +0000

Problem: I tried linking my iPhone as a secondary Signal device. The QR code just spun forever — a loading spinner inside a white box. No error. Just nothing.

My setup: Primary device — Redmi 13C (PTA), Signal registered and working. Secondary device — iPhone (non-PTA). University Wi-Fi. I wasn't doing a full registration or transfer. Just: Settings → Linked Devices → Link New Device on iPhone. Dead silence from Signal.

What I Tried

First assumption: it's the non-PTA iPhone. Maybe Signal's blocking it? Nope — PTA status is a cellular registration thing. It has zero effect on Wi-Fi app behavior.

Second assumption: maybe I need to select "transfer from Android"? Nope — I didn't want a transfer. Just a secondary link. The flow is: iPhone shows QR → Redmi scans it.

I got the flow backwards at first too. Thought Redmi generates QR, iPhone scans. Wrong. iPhone (secondary) generates the QR. Redmi (primary) scans it.

The QR never loaded on iPhone. That's when it clicked — it's not the phone, it's the network.

What Actually Happened

Signal's QR code generation isn't local. The iPhone hits Signal's provisioning API (api.signal.org, storage.signal.org) to create a time-sensitive token before displaying the code. My university network was blocking those endpoints.

Why did Redmi register fine earlier? Probably a different time, different access point, or Android and iOS clients have different TLS fingerprints — and the firewall's application-layer inspection treats them differently. University-grade firewalls (Fortinet, Palo Alto) do this.

The Fix

Proton VPN on both devices, same server location.

Installed Proton VPN (free tier) on both iPhone and Redmi
Connected both to the same server (Netherlands)
On iPhone → Signal → Linked Devices → Link New Device
QR code appeared instantly
Redmi scanned it — linked successfully

6. Redmi got logged out immediately after. That's not a bug — Signal logs out existing sessions when a new device links, by design. Re-registered with the phone number and everything was fine. Message history is local anyway; it doesn't sync across linked devices.

Key Insights

The QR code requires a live API call. If Signal's servers are unreachable, the spinner loops forever with no error message. Signal could honestly show a better error here.
iOS and Android Signal clients behave differently at the network level. A firewall can block one and pass the other.
University networks block more than you think. VoIP, messaging APIs, certain CDN routes — it's not just torrents.
Free VPN is enough for this. Proton VPN free tier worked fine. No speed requirements for a one-time provisioning handshake.

- Both devices need to be on the same network exit. The provisioning token is bound to the originating network context. If iPhone generated it over VPN and Redmi scanned from plain university Wi-Fi, it failed with "QR code not valid."

TIL

Signal's device linking QR is a remote token, not a local code — and if your network blocks Signal's API endpoints, you'll get an endless spinner with zero explanation.

Firefox Profiles Frozen and Corrupted on CachyOS — What Broke and How psd Was the Culprit

Musa Nayyer — Fri, 22 May 2026 12:35:15 +0000

The Problem

Opened Firefox one morning and the profile picker showed up. Clicked my main profile — nothing happened. Hover worked, tooltips appeared, but clicks registered nowhere. Profile 1 was already dead the day before. Only the third profile (sss) responded. Main profile had six accounts in it.

What I Tried

Keyboard navigation — nothing. Tab and Enter didn't work either.

Checked the Firefox profile directory and found this:

lrwxrwxrwx  lbjm2hpz.Profile 2 -> /run/user/1000/psd/user-firefox-lbjm2hpz.Profile 2
lrwxrwxrwx  xcpk3xfu.default   -> /run/user/1000/psd/user-firefox-xcpk3xfu.default

Symlinks. Not real directories. psd (profile-sync-daemon) moves Firefox profiles to RAM and replaces them with symlinks. The RAM targets were either empty or broken.

Ran psd preview — confirmed psd was managing both profiles. xcpk3xfu.default showed profile size 0. That profile was already gone.

Tried psd resync — ran without errors but didn't fix the picker clicks.

Tried launching directly from terminal:

firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"
firefox -P "default-release" --no-remote
MOZ_ENABLE_WAYLAND=0 firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"

All three kept opening the sss profile instead. The --no-remote attempts threw repeated channel errors because Firefox was already running.

Checked about:profiles — confirmed the current window was actually running default-release (the main profile), but it was completely empty. No accounts, no history, nothing. The 49M of data was somewhere but Firefox wasn't seeing it.

Stopped psd, deleted the broken profile directory, tried restoring from the -backup folder — backup had disappeared when psd stopped (psd overwrites it on shutdown with whatever is in RAM). Only a crashrecovery folder from earlier that morning survived with 49M of actual data.

Restored from crashrecovery, started psd again — psd immediately created a new symlink pointing to RAM and the profile went missing again. psd was overwriting the restore on every start.

The GUI click issue turned out to be a separate Wayland input problem with the Firefox profile picker — unrelated to psd but compounding the mess.

Root Cause

psd syncs browser profiles to RAM for speed. On unclean shutdowns or crashes, the sync back to disk fails. The -backup folder gets overwritten on the next psd start with whatever empty state is in RAM. Over time this had been happening repeatedly — the profile directory had 64 crash recovery folders going back months, all showing the same pattern.

xcpk3xfu.default was already fully gone. lbjm2hpz.Profile 2 survived only because a crashrecovery snapshot existed from earlier that same day.

The Fix

Disabled Firefox in psd by adding this to ~/.config/psd/psd.conf:

BROWSERS=(google-chrome)

Restarted psd. Firefox now reads directly from disk. No more symlinks, no more RAM sync, no more silent corruption on shutdown.

Also ran psd clean to delete the accumulated crash recovery folders and reclaim disk space.

TIL

psd is a silent data risk on systems that crash or suspend frequently — it will eat your browser profiles and leave behind only empty backup folders.

How I got out of dependency hell with Docker (SpiderFoot OSINT lab)

Musa Nayyer — Mon, 20 Apr 2026 20:47:23 +0000

I wanted to try SpiderFoot – an OSINT tool. Thought it would be a simple pip install.

Nope.

It crashed on lxml. Something about headers and versions. Classic dependency hell on Arch.

I didn't want to mess up my main system. So I gave up on virtual environments and used Docker instead.

Here's what worked.
Set this up so you don't need sudo for every command.

1. Docker permissions

sudo usermod -aG docker $USER
newgrp docker
sudo systemctl restart docker

2. Clone and build

Grab the source and build the image locally.

git clone https://github.com/smicallef/spiderfoot.git
cd spiderfoot
docker build -t spiderfoot .

3. Run it (the easy way)

I used the VS Code Docker extension. Built the image, then ran the container from the UI. The extension shows all running containers on my system, so I could start/stop it with one click.

If you prefer the command line, this works too:

docker run -d -p 5001:5001 --name spiderfoot-app spiderfoot
Either way, open http://localhost:5001 and SpiderFoot is there.

Why I'm doing this
I'm a beginner in cybersecurity. I don't want to install random tools directly on my laptop. With Docker, I can try anything and delete it later without breaking stuff.

This worked for me. Might work for you too.