SouveraineOS/saf/device/mms.md

# PAF · MMS (picture messaging)

## STATUS (2026-07-15): MMS SEND WORKS end-to-end. Two loose ends remain.

**A real picture message sent successfully today** — image to +12897767709,
508 KB, POSTed through Fido's MMS proxy and cleared from the queue. The core
problem (reaching Fido's MMS servers with the right APN) is SOLVED. See
"THE WORKING RECIPE" below.

Two things still not fully nailed:
1. **No auto-start / lifecycle for the daemon.** `mmsd-tng` has no D-Bus
   auto-spawn or systemd service — it only runs when launched by hand. When it
   isn't running, sends silently pile up in the queue (that's how 4 messages
   got stuck). Needs a proper service unit.
2. **Chatty says "MMSC is not configured."** The daemon's *internal* config is
   correct and it sends fine, but it does NOT expose the
   `org.ofono.mms.ModemManager` D-Bus interface (only `org.ofono.mms.Service`),
   which is what Chatty's settings menu reads. So Chatty can't see the MMSC even
   though sending works. Setting values in Chatty's own menu did NOT bring that
   interface up. Daemon-side interface-registration issue, not a wrong-value
   issue — the file `~/.mms/modemmanager/mms` already reads
   `MMS_APN=netsvcs`, `CarrierMMSC=http://mms.fido.ca`,
   `CarrierMMSProxy=205.151.11.13:80` (all correct).

---

## THE WORKING RECIPE (proven live 2026-07-15)

1. **APN = `netsvcs`** (NOT `mms.fido.ca`). Patched into the carrier database at
   `rootfs-overlay/usr/share/mobile-broadband-provider-info/serviceproviders.xml`
   (Fido entry, `<apn value="netsvcs">`, mmsc `http://mms.fido.ca`, proxy
   `205.151.11.13:80`). `mmsd-tng` re-reads that DB and writes the right values
   into `~/.mms/modemmanager/mms` — BUT only re-looks-up when its current MMSC is
   the placeholder `http://mms.invalid`, so to force a refresh you must
   `rm ~/.mms/modemmanager/mms` before restarting the daemon.
2. **The `netsvcs` bearer must be connected AND have its IPv4 applied to the
   netdev.** ModemManager reports the IP but nothing installs it — apply
   manually (see cheat-sheet). Once the IP is on `qmapmux0.X`, the proxy becomes
   reachable and `mmsd-tng`'s `SO_BINDTODEVICE` binds sends to it correctly.
3. With both in place, `mmsd-tng` POSTs queued messages through the proxy and
   they send. `AutoProcessOnConnection=true` means it auto-flushes the queue
   when a usable bearer appears.

**To reproduce a send right now:** ensure the `netsvcs` bearer is up with its IP
applied, `rm ~/.mms/modemmanager/mms`, then
`mmsdtng --debug` — it re-looks-up `netsvcs` from the DB and flushes the queue.

---

Texting (SMS) already works. This doc is about **MMS** — the picture/group
messages. They still don't send/receive on their own yet, but today we found
*why*, and proved the hard part (reaching Fido's MMS servers) actually works.

---

## ELI5 — what MMS even is, and why it's fussy

A plain text (SMS) is tiny, so it rides along on the same signaling channel the
phone uses to talk to the tower — no internet needed. A picture message (MMS) is
too big for that. So MMS actually works like this:

1. The tower sends you a tiny SMS that secretly means *"there's a picture waiting
   for you."*
2. Your phone then has to **open a special little internet connection** and go
   **download the picture from the carrier's own server** (the "MMSC").
3. To send a picture, your phone uploads it to that same server the same way.

The catch: that "special little internet connection" is **not** your normal data
or WiFi. Carriers put their MMS server on a **private, members-only road** that
only exists inside their own cellular network. You can't get to it from WiFi, and
you can't get to it from the normal data connection either. You have to dial a
**second, separate connection** specifically for MMS.

Every piece of confusion we hit came from that one fact: **MMS needs its own
special door, and we kept knocking on the wrong ones.**

---

## The pieces (and the plain-English name for each)

| Thing | What it really is | Value for this SIM |
|---|---|---|
| **APN** | The *name of the door* you dial for a given service | `netsvcs` (NOT `mms.fido.ca`) |
| **MMSC** | The *server* that actually holds the pictures | `http://mms.fido.ca` → `209.4.229.111` |
| **MMS proxy** | A *doorman* you must go through to reach the MMSC | `205.151.11.13:80` |
| **The daemon** | `mmsd-tng`, the background program that does all this for you | already installed |
| **The phone book** | `serviceproviders.xml`, a big list of carrier settings the daemon trusts | had the WRONG APN |

---

## What we got wrong (and how we found the right answer)

### Wrong door #1: `mms.fido.ca`
Every website, and the settings file already on the phone, said Fido's MMS APN is
`mms.fido.ca`. We dialed it. The network slammed the door:
`ServiceOptionNotSubscribed` — *"you're not signed up for that."*

That error sounds like an account/billing problem, but it wasn't. It just means
**that door name doesn't exist on this SIM.** The public instructions are for
manually typing settings into an Android phone; they don't necessarily match what
the SIM is actually *provisioned* for underneath.

**How we found the truth:** we asked the modem to list the doors it *actually*
knows about (`mmcli -m 0 --3gpp-profile-manager-list`). It answered with a real
list, and there it was:

```
profile 4:  apn: netsvcs   apn type: mms
```

The real MMS door on this SIM is called **`netsvcs`**, not `mms.fido.ca`. Dialed
`netsvcs` → it **connected immediately.** (Confirmed the same name shows up in the
raw Android radio logs from this same SIM, so it's genuinely the carrier's name
for it, not a fluke.)

> **Gotcha:** `ltemobile.apn` is the *generic Rogers-family* internet door
> (Rogers/Fido/Chatr all share it). Some guides say "just use that for MMS too."
> It's a red herring here — it's not Fido-specific, and it came up **IPv6-only**,
> which can't even reach the IPv4 MMS server. `netsvcs` is the right door.

### Wrong door #2: trying to reach the server the normal way
Once `netsvcs` connected, we tried to reach the MMS proxy (`205.151.11.13`) — and
it hung, dead silence.

Two reasons, both now understood:

1. **The connection was "connected" but had no address actually plugged in.**
   The modem dialed the door and the carrier handed us an address
   (`10.145.x.x`) — but *nothing put that address onto the network card.* It's
   like being handed the keys to a car that nobody parked in your driveway. On the
   normal data connection, a program called NetworkManager does this parking step
   automatically. For our hand-dialed MMS connection, **nobody did it.** The
   interface had no IPv4 address at all.

   The moment we manually "parked the car" (`ip addr add 10.145.146.168/28` onto
   the interface, plus routes to the proxy through the carrier gateway) — **the
   proxy answered.** Reliably, every time. That was the real unlock.

2. **The proxy only speaks "MMS language."** After it started answering, a plain
   web request (`curl`) to it still got silence. That's expected: Fido's proxy is
   a **WAP proxy** — it only understands the special MMS protocol (WSP), and
   ignores normal web traffic. So a normal browser test will *always* look like a
   failure even when the path is perfectly open. Only `mmsd-tng` speaks the right
   language to it.

---

## Where it actually stands right now

**PROVEN working:**
- The correct APN is `netsvcs`, and it connects.
- Once its IP is applied to the interface, **Fido's MMS proxy is reachable** (TCP
  handshake succeeds every time, from the bearer's own address).

**Still missing (the automation):**
- Nothing yet automatically does the "park the car" step — dial the `netsvcs`
  MMS connection, apply its IP + routes to the interface, and hand it to
  `mmsd-tng` — at the moment a picture needs to go out, then tear it down after.
- `mmsd-tng`'s own config keeps regenerating from the carrier phone book
  (`serviceproviders.xml`) with the wrong `mms.fido.ca` APN, so editing its
  local config by hand gets overwritten. Fixing the phone book entry is the
  durable path (started: patched to `netsvcs` in `rootfs-overlay/usr/share/
  mobile-broadband-provider-info/serviceproviders.xml`), **but** `mmsd-tng`'s
  lookup only matches an entry when the *active* bearer's APN equals the entry's
  `value=`, so the exact match behavior still needs verifying against the real
  code path before calling it solved.

**Next step:** re-test `mmsd-tng` end-to-end now that the network road is
manually open (send one real MMS), to confirm the daemon itself works, *before*
building the automation that opens the road on its own.

---

## Cheat-sheet: manually open the MMS road (for testing)

```sh
# 1. dial the real MMS door, IPv4
mmcli -m 0 --create-bearer="apn=netsvcs,apn-type=mms,ip-type=ipv4"
mmcli -m 0 -b <N> --connect          # note the interface (qmapmux0.X) + address

# 2. "park the car": put the handed-out IP onto the interface
sudo ip addr add <address>/<prefix> dev qmapmux0.X

# 3. lay down the private road to the proxy + MMSC via the carrier gateway
sudo ip route add 205.151.11.13/32 via <gateway> dev qmapmux0.X   # proxy
sudo ip route add 209.4.229.111/32 via <gateway> dev qmapmux0.X   # MMSC

# 4. proof the road is open (TCP handshake to the proxy should succeed):
python3 -c "import socket;s=socket.socket();s.bind(('<address>',0));s.connect(('205.151.11.13',80));print('proxy OPEN')"
```

(A plain `curl` through the proxy will still hang — that's normal, it only
speaks MMS, not web. Real proof is `mmsd-tng` sending a message.)