Joachim Wiberg f78f161dbe modem: migrate from infix-modem to ietf-hardware/ietf-interfaces
The initial modem import used a standalone infix-modem YANG module with
an integer-indexed list under /infix-modem:modems carrying a bearer
config mixed in with hardware config.  Infix has adopted the ietf-hardware
model to allow for a clearer separation of concerns, this commit aims to
improve on that situation by refactoring the modem model to use the same
architectural pattern already used for WiFi radios, GPS receivers, and
USB ports:

Hardware:
    /ietf-hardware:hardware/component[class=infix-hardware:modem]
    /ietf-hardware:hardware/component[class=infix-hardware:sim]
Interface:
    /ietf-interfaces:interfaces/interface[type=infix-if-type:modem]

Configuration split:
  modem component — admin-state (enable/disable), radio access mode,
                    frequency bands, location services, probe-timeout
  sim component   — PIN, PUK, carrier profile
  wwan interface  — APN, IP type, roaming, route-preference, auth

This also enables the modem to appear in 'show hardware' alongside
other hardware components, and to be managed over NETCONF/RESTCONF
using the same ietf-hardware RPCs used for USB and WiFi.

YANG changes:
  - infix-modem.yang removed (1089 lines, standalone module)
  - infix-hardware.yang: new modem and sim containers, modem-state and
    sim-state operational state, typedefs for bands/modes/location,
    notification status-update; actions restart/reset/send-sms are
    augmented directly on the component list entry (not inside container
    modem) to work around sysrepo NP-container parent validation — when
    checking a nested action's parent, sysrepo restricts its operational
    data fetch to the container path, excluding the sibling 'class' leaf
    needed to evaluate the container's 'when' condition, so the container
    is never instantiated and the parent check fails
  - infix-if-modem.yang: new submodule (same pattern as wifi/wireguard)
    adds the wwan bearer container to ietf-interfaces
  - infix-if-type.yang: new modem identity for wwan interface type
  - confd version bumped to 1.9

confd:
  - if-modem.c: new file replaces the stub modem_gen() in modem.c;
    generates dagger init scripts with probe-timeout wait loop and
    unconditional dummy wwan creation so downstream IP config succeeds
    when a USB modem is slow to enumerate at boot
  - hardware.c: start/stop/enable/disable modemd (and modem-manager)
    in response to admin-state changes on the modem hardware component;
    use finit_enable/disable consistently
  - hardware_cand_infer_class(): auto-set class for modemN/simN names
  - modem.c: stripped to RPC/notification forwarding only; the old
    genconf() / enable() / disable() logic is gone — hardware.c owns
    the lifecycle now
  - interfaces.c: remove wwan from wait-interface timeout (the modem
    interface appearance is managed by modemd, not confd's init scripts)
  - migrate/1.9: script fully migrates /infix-modem:modems to the new
    split model; each modem[N] becomes a modemN hardware component and
    simN sim component; each bearer becomes a wwanN interface (bearers
    numbered globally across modems); APN, IP type, roaming, preferred-
    mode, bands, location, PIN/PUK/carrier are all carried over; plain-
    text bearer credentials are moved to a named keystore symmetric-key
    (base64-encoded) referenced from bearer/authentication/password;
    apn-type, firewall-enabled, dns-enabled and default-route are
    dropped (no equivalent in the new model)

modemd:
  - load_config() replaces the infix-modem sysrepocfg call; reads from
    ietf-hardware (modem/sim config), ietf-interfaces (bearer config),
    and ietf-keystore (credentials) — three standard modules instead of
    one proprietary one; modems absent from sysrepo config but present
    in system.json are still started (physical detection wins)
  - Default route written to /etc/net.d/<iface>.conf (picked up by
    netd/staticd/zebra) instead of a direct 'ip route add'; routes are
    now visible to FRR for redistribution and metric-based failover
  - Addresses tagged with proto wwan (rt_addrprotos entry 7) for
    precise flush on disconnect without touching other address sources
  - _derive_gateway() handles point-to-point bearers where modem
    reports gateway as "--"; derives peer from link-scope subnet route
  - SimThread exits cleanly on platforms without /dev/simctrl
  - sim-setup, modem-info, modem-udev, modem-rpc, modem-sms all ported
    to the ietf-hardware/ietf-interfaces namespace

statd:
  - infix_modem.py now emits modem-state and sim-state into ietf-hardware
    component entries (modem0, sim0, ...) instead of a separate tree;
    sim-state reports physical slot, lock state, and SIM operator name
  - ietf_hardware.py: hardware component names deduplicated by rename
    (cpu → cpu, cpu1, ...) to prevent LY_EVALID when hwmon and thermal
    sysfs both normalise to the same sensor name
  - show hardware: Cellular Modems and SIM Cards tables added; sensor
    table width now adapts to the widest section in the output
  - 00-probe: USB modem detection writes to system.json["modem"], same
    source as wifi-radios, feeding gen-hardware which emits the
    ietf-hardware component entries at factory config generation time

CLI:
  - 'show modem [ref]': without ref shows Cellular Modems and SIM Cards
    tables (same data subset as 'show hardware'); with ref shows a full
    per-modem dump (hardware info, status, cellular, SIM, bearers, GPS)
  - 'modem restart <ref>': disconnect and reconnect all bearers without
    a full hardware reset
  - 'modem reset <ref>': factory-reset the modem firmware
  - 'modem sms <ref> <number> <message>': send an SMS via the modem
    (uses the signalling plane; no active data bearer required)
  - MODEMS PTYPE provides tab-completion reading modem names from
    /run/system.json

doc:
  - Add initial User Guide for modems
  - Update ChangeLog with modem news
  - Use absolute URLs in ChangeLog.  Relative links only work for in-tree
    references, not in release notes

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
2026-06-07 20:50:58 +02:00
2022-12-05 21:09:05 +01:00

License Badge Release Badge GitHub Status Coverity Status Discord

Infix — Immutable.Friendly.Secure

Turn any ARM or x86 device into a powerful, manageable network appliance in minutes. From $35 Raspberry Pi boards to enterprise switches — deploy routers, IoT gateways, edge devices, or custom network solutions that just work.

Our Values

🔒 Immutable
Your system never breaks. Read-only filesystem with atomic upgrades means no configuration drift, no corrupted updates, and instant rollback if something goes wrong. Deploy once, trust forever.

🤝 Friendly
Actually easy to use. Auto-generated CLI from standard YANG models comes with built-in help for every command — just hit ? or TAB for context-aware assistance.

Familiar NETCONF & RESTCONF APIs and comprehensive documentation mean you're never stuck. Whether you're learning networking or managing enterprise infrastructure.

🛡️ Secure
Built with security as a foundation, not an afterthought. Minimal attack surface, separation between system and data, and container isolation. Sleep better knowing your infrastructure is protected.

Why Choose Infix

Hardware Flexibility: Start with a $35 Raspberry Pi, scale to enterprise switching hardware. Same OS, same tools, same reliability.

Standards-Based: Built around YANG models and IETF standards. Learn once, use everywhere - no vendor lock-in.

Container Ready: Run your applications alongside networking functions. GPIO access, dedicated Ethernet ports, custom protocols — your device, your rules.

Use Cases

  1. Home Labs & Hobbyists:
    Transform a Raspberry Pi into a full-featured router with WiFi
  2. IoT & Edge Computing:
    Bridge devices to the cloud with reliable, updatable gateways
  3. Small Business Networks:
    Enterprise-grade features without the complexity or cost
  4. Developers & Makers:
    Test networking concepts, prototype IoT solutions, or build custom appliances
  5. Network Professionals:
    Consistent tooling from development to production deployment.
    How about a digital twin using raw Qemu or GNS3!

Quick Example

Configure an interface in seconds - the CLI guides you with built-in help:

admin@infix-12-34-56:/> configure
admin@infix-12-34-56:/config/> edit interface eth0
admin@infix-12-34-56:/config/interface/eth0/> set ipv4 TAB
      address     autoconf      bind-ni-name     dhcp 
      enabled     forwarding    mtu              neighbor
admin@infix-12-34-56:/config/interface/eth0/> set ipv4 address 192.168.2.200 prefix-length 24
admin@infix-12-34-56:/config/interface/eth0/> show
type ethernet;
ipv4 {
  address 192.168.2.200 {
    prefix-length 24;
  }
}
admin@infix-12-34-56:/config/interface/eth0/> diff
interfaces {
  interface eth0 {
+    ipv4 {
+      address 192.168.2.200 {
+        prefix-length 24;
+      }
+    }
  }
}
admin@infix-12-34-56:/config/interface/eth0/> leave
admin@infix-12-34-56:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA                                  
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
eth0            ethernet   UP          52:54:00:12:34:56
                ipv4                   192.168.2.200/24 (static)
                ipv6                   fe80::5054:ff:fe12:3456/64 (link-layer)
admin@infix-12-34-56:/> copy running startup

Notice how TAB completion shows available options, show displays current config, and diff shows exactly what changed before you commit your changes with the leave command.

For more information, see CLI documentation.

Get Started

Get pre-built images for your hardware. Use the CLI, web interface, or standard NETCONF/RESTCONF tools, e.g., curl. Add containers for any custom functionality you need.

Supported Platforms

  • Raspberry Pi 2B/3B/4B/CM4 - Perfect for home labs, learning, and prototyping
  • Banana Pi-R3 - Your next home router and gateway
  • NanoPi R2S - Compact dual-port router in a tiny package
  • x86_64 - Run in VMs or on mini PCs for development and testing
  • Marvell CN9130 CRB, EspressoBIN - High-performance ARM64 platforms
  • Microchip SparX-5i - Enterprise switching capabilities
  • Microchip SAMA7G54-EK - ARM Cortex-A7
  • NXP i.MX8MP EVK - Highly capable ARM64 SoC
  • StarFive VisionFive2 - RISC-V architecture support

Why start with Raspberry Pi? It's affordable, widely available, has built-in WiFi + Ethernet, and runs the exact same Infix OS you'd deploy in production. Perfect for learning, prototyping, or even small-scale deployments.

📖 Complete documentation💬 Join our Discord

Technical Details

bitSign - Code Signing

Built on proven open-source foundations: Linux, Buildroot, and sysrepo — for reliability you can trust:

  • Immutable OS: Read-only filesystem, atomic updates, instant rollback
  • YANG Configuration: Industry-standard models with auto-generated tooling
  • Hardware Acceleration: Linux switchdev support for wire-speed packet processing
  • Container Integration: Docker support with flexible network and hardware access
  • Memory Efficient: Runs comfortably on devices with as little as 256 MB RAM
  • Code Signing: Releases are cryptographically signed for integrity verification

Perfect for everything from resource-constrained edge devices to high-throughput network appliances.

With the entire system modeled in YANG, scalability is no longer an issue, be it in development, testing, or end users deploying and monitoring their devices. All knobs and dials are accessible from the CLI (console/SSH), or remotely using the native NETCONF or RESTCONF APIs.

Check the Latest Build for bleeding-edge features.



Infix development is sponsored by Wires

Alt

Languages
Python 36.9%
C 16.3%
Go 16.1%
HTML 13.5%
Shell 8.2%
Other 8.9%