Configuration notes

Last updated 2026-06-28

The settings I actually change on every rCell before it goes into service, plus the troubleshooting checklist I wish I'd had the first time one wouldn't stay online. Menu paths are approximate — they've shifted slightly between firmware releases.

Cellular failover (dual SIM & WAN)

Two related things get called "failover" on these boxes, so be clear which you mean:

SIM failover — the modem switches from SIM 1 to SIM 2 when the primary carrier can't attach or fails a connectivity check. Configured under Cellular → SIM Management.
WAN failover — upstream of the rCell, your firewall/router treats the cellular link as a backup path behind a wired primary. That's done on the firewall, not here.

For SIM failover I set an active connectivity check (ICMP to a stable host) so a silently-dead-but-still-attached carrier actually triggers a switch:

# conceptual settings (names vary by firmware)
sim.failover.enabled         = true
sim.primary                  = 1
sim.check.method             = icmp
sim.check.target             = 1.1.1.1
sim.check.interval_s         = 30
sim.check.fail_threshold     = 3          # 3 misses -> switch SIM
sim.revert.enabled           = true       # go back to SIM1 when it recovers
sim.revert.hold_min          = 15         # but not too eagerly (flap guard)

Flapping: without a revert hold time, a marginal primary will bounce you back and forth between SIMs and burn data on both. The 15-minute hold above stopped that on my remote unit.

Port forwarding (and the CGNAT reality)

Port forwarding lives under Firewall → NAT / Port Forwarding. A rule maps an external port on the WAN (cellular) side to an internal host:port on the LAN. Example: expose an internal web service on 8080 as external 443.

Field	Value
Name	`fwd-nvr`
Protocol	TCP
External port	`443`
Internal host	`192.168.2.50`
Internal port	`8080`

This only works with a public IP. On a normal carrier SIM you're behind CGNAT, so inbound forwards never reach you regardless of the rule. Options: a static/public-IP SIM (ask the carrier), or an outbound tunnel from a device on the LAN to a VPS you control (WireGuard/SSH reverse tunnel). I use the tunnel approach at the remote site — nothing to forward, and it survives IP changes.

Firewall basics

Default posture out of the box is sane: LAN → WAN allowed, WAN → LAN blocked except your explicit forwards, and management restricted to the LAN interface. Things I always verify:

Remote management from WAN is OFF. Never expose the admin UI or SSH to the cellular side. Manage over the LAN, or in-band through your tunnel.
Default-deny inbound on the WAN zone, with only the specific forwards you added.
Egress can be tightened at the remote site — the sensors only need DNS, NTP and one outbound TCP port, so I restrict LAN egress to that.

Enabling SSH

SSH is handy for scripting and for the AT console. Enable it under Administration → Access Configuration and, importantly, bind it to LAN only.

ssh.enabled            = true
ssh.port               = 22
ssh.interface          = lan          # NOT wan
ssh.password_auth      = false        # keys only, please
ssh.permit_root        = false

Then copy your key over and confirm before you disable password auth:

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@192.168.2.1
$ ssh admin@192.168.2.1
admin@rcell:~$ uptime
admin@rcell:~$ mlog tail          # vendor log helper on some builds

NTP / time

Accurate time matters for TLS, logs and scheduled reboots. Point it at a couple of pool servers (or your own LAN NTP if the remote site has one) under Administration → Date & Time:

ntp.enabled     = true
ntp.server[0]   = 0.pool.ntp.org
ntp.server[1]   = 1.pool.ntp.org
timezone        = UTC              # I keep everything in UTC

If the device can't reach NTP on boot (cellular still attaching), it'll correct once the link is up. If TLS to the UI acts weird right after a cold boot, it's usually clock skew — give it a minute.

Watchdog / auto-reboot

The feature that earns its keep on unattended units. A connection watchdog pings a target and, after N consecutive failures, restarts the cellular stack — and as a last resort reboots the whole device. I also schedule a weekly reboot in the small hours as a belt-and-braces measure.

watchdog.enabled          = true
watchdog.ping_target      = 1.1.1.1
watchdog.interval_s       = 60
watchdog.fail_count       = 5         # 5 misses -> restart cellular
watchdog.reboot_after     = 10        # still down after 10 -> full reboot

autoreboot.enabled        = true
autoreboot.schedule       = "0 4 * * 0"   # Sundays 04:00 UTC

Pick a ping target that won't rate-limit or go away. A carrier gateway or a big anycast resolver is fine; your own VPS is better because it also proves the tunnel path, not just raw internet.

Sample config snippet

A trimmed export from my remote unit, annotated. Yours won't match key-for-key across firmware versions, but the shape is representative:

# --- rcell-remote-01 : exported 2026-06-28 ---
[system]
hostname            = rcell-remote-01
timezone            = UTC

[lan]
address             = 192.168.2.1
netmask             = 255.255.255.0
dhcp.enabled        = true
dhcp.range          = 192.168.2.100-192.168.2.200

[cellular]
apn                 = iot.example.net
auth                = none
roaming             = false

[sim]
failover.enabled    = true
primary             = 1
check.target        = 1.1.1.1
revert.hold_min     = 15

[watchdog]
enabled             = true
ping_target         = 10.8.0.1        # my VPS over the tunnel
fail_count          = 5
reboot_after        = 10

[access]
ssh.enabled         = true
ssh.interface       = lan
wan_mgmt.enabled    = false           # never from cellular

Export a backup after every change: Administration → Save/Restore → Download configuration. Keep the last few, dated.

Troubleshooting

No signal / won't register

Check both antennas are on MAIN and AUX, finger-tight, vertical, away from metal.
Read the real number: AT+CSQ and AT+CESQ over SSH/serial. If RSSI is 99/unknown, it's not seeing the network at all — likely band or antenna, not APN.
Confirm the SIM is provisioned for data and not locked to a device/IMEI by the carrier.
Force/allow the right RAT and bands for your region if you've manually restricted them.

SIM not detected

Power off, re-seat the SIM (contacts up, notch first — see SIM insertion).
Clean the gold contacts if the card's been in a wallet; grime is a surprisingly common cause.
Check for a PIN lock — a SIM enabled with a PIN elsewhere will read as failed here until you disable the PIN or set it in the UI.
Test the SIM in a phone to rule out a dead card, then test a known-good SIM in the slot to isolate slot vs card.

Connection drops / won't stay up

Watch signal over time, not once — a spot that reads "2 bars" but swings wildly will drop. Fix antenna placement or add a better external antenna.
Make sure the watchdog is on so a wedged session self-heals instead of sitting dead.
Check the flap guard on SIM failover (revert hold) so it isn't ping-ponging between carriers.
Update firmware — a couple of my early-firmware drop issues went away after 5.3.x.
Rule out thermal: a unit in a sealed sun-baked box can throttle. Give it airflow or shade.

Still stuck? Pull the system log (Administration → Logs or mlog tail over SSH) around the time of a drop — the attach/detach and PDP messages usually name the cause.