# 3rdParty eSim - almost works on Ubuntu24 tachyon

**URL:** https://community.particle.io/t/3rdparty-esim-almost-works-on-ubuntu24-tachyon/72659
**Category:** Tachyon
**Created:** [September 24, 2026, 9:40am UTC](https://community.particle.io/t/3rdparty-esim-almost-works-on-ubuntu24-tachyon/72659 "2026-09-24T09:40:43Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![steel-glint](https://avatars.discourse-cdn.com/v4/letter/s/f0a364/32.png) [@steel-glint](https://community.particle.io/u/steel-glint)
#### Post date: [September 24, 2026, 9:40am UTC](https://community.particle.io/t/3rdparty-esim-almost-works-on-ubuntu24-tachyon/72659/1 "2026-09-24T09:40:43Z")

</div>

\*\*\*

**Ubuntu version 24.04 on Tachyon**

\*\*\*

I've spent the last couple of days checking out the Tachyon that has been sitting on a shelf since last time I tested it a year ago. I thought I'd write up the experience in case it proved useful for others here.

Ubuntu 24 headless seems ok for our app ([https://v-stream.camera](https://v-stream.camera)) - I still need to work on the gstreamer pipeline but otherwise I'm ok on the application front.

I spent most of my time on the eSim side - our cameras get through ~1Gb/hour when racing and travel the world, so we need to manage our own eSims (currently mostly from Airalo).

The built in esim download failed halfway through on an Airalo esim - so I built and installed lpac  
( [GitHub - estkme-group/lpac: C-based eUICC LPA · GitHub](https://github.com/estkme-group/lpac) ) and pointed it at the qmi\_qrtr - which worked !

`LPAC_APDU=qmi_qrtr bin/qmilpac profile download -a 'LPA...'`

Then the fun began. I could see that the modem connected with

`particle-tachyon-ril-ctl vitals`

But no interface showed up in `ifconfig`, so I switched to `ip a ` which showed a qmapmux interface that was not up or configured.

So I used a set of ip commands to set it up based on the info in vitals.

```auto
  sudo ip link set qmapmux1.0 up

  sudo ip addr add 10.75.202.208/24 dev qmapmux1.0

  sudo ip route add default via 10.75.202.208 dev qmapmux1.0 metric 200

  sudo resolvectl dns qmapmux1.0 194.151.228.2 194.151.228.34 

```

Which worked.  
For 4 minutes. Then the connection dropped.  
on inspection I found that my esim had been disabled.  
`LPAC_APDU=qmi_qrtr bin/qmilpac profile list`

So some process is actively deleting the connection ~4 mins after an IP route is established.

I tried disabling several of the likely systemd services - but nothing I saw fixed it.

So close - but not close enough to even test in a racecar.

I'm out of time on this experiment - so it is back to the VIM4+Quectel modem on PCie while we wait for usable Tachyon support of eSims.

My feeling is that the Particle tools get in the way, I'd like a ubuntu build without them - where we can just use open source and port our working app to this platform - but I guess that isn't the team's vision. I don't have the time to invest in a yocto build _before_ I discover if the hardware (specifically the antenna) is up to racecar life.

Hope this helps some folks out there!

Tim.

---

<div class="post-metadata">

### Author: ![erasmart35](https://avatars.discourse-cdn.com/v4/letter/e/cab0a1/32.png) [@erasmart35](https://community.particle.io/u/erasmart35)
#### Post date: [September 26, 2026, 10:45pm UTC](https://community.particle.io/t/3rdparty-esim-almost-works-on-ubuntu24-tachyon/72659/2 "2026-09-26T22:45:26Z")

</div>

If you revisit this, the useful distinction is whether the eSIM profile becomes disabled before or after the network interface disappears. The observations so far don't identify which process is responsible.

For a small diagnostic capture, note the time immediately before reproducing it, then run `sudo journalctl -b --since "YYYY-MM-DD HH:MM:SS" -o short-precise --no-pager` afterwards (replace the timestamp with that start time). Compare the entries around the drop with `particle-tachyon-ril-ctl vitals` and `LPAC_APDU=qmi_qrtr bin/qmilpac profile list` taken before and immediately after it. Also note exactly which services were stopped and whether the drop still occurred with them stopped.

That would give support a reproducible timeline rather than assuming the route change caused the profile disable. If you share excerpts, remove activation codes, subscriber identifiers, credentials and unrelated personal data; the full journal isn't needed.
