CLIENT_BASE – rollen

Hva er CLIENT_BASE?

CLIENT_BASE er en nodefunksjon i Meshtastic beregnet på faste, godt plasserte noder, typisk på et tak eller en høy vegg. Den fungerer som en personlig basestasjon for dine egne noder og sørger for at meldinger fra svakere eller bakkeplasserte enheter faktisk når ut i nettverket.

Denne artikkelen beskriver atferden i firmware 2.7.15, som er den versjonen Ryfylkenett bruker. Enkelte detaljer er endret i senere firmware, og dette er omtalt der det er relevant.

Forutsetning: favoritter

CLIENT_BASE-atferden aktiveres ikke automatisk. Den avhenger av at du setter opp favoritter på taknoden. En favoritt er en annen node du eksplisitt har merket som “din”. For all annen trafikk oppfører CLIENT_BASE seg som en helt vanlig CLIENT.

Konkret betyr dette at taknoden (CLIENT_BASE) må ha de portable nodene dine lagt inn som favoritter. Det er denne listen som styrer hvilke meldinger taknoden prioriterer. Det holder ikke at den portable noden har taknoden som favoritt, det er taknoden som må kjenne den portable noden.

Et enkelt eksempel

Tenk deg tre enheter:

• Portabel node, med deg i lommen inne i huset.
• Taknode (CLIENT_BASE), montert på taket med god antenne, og med din portable node lagt inn som favoritt.
• Backbone-router, plassert på en høyde i nærheten, del av det lokale nettverket.

Uten CLIENT_BASE konkurrerer meldingen din fra lommen med alle andre noder om å bli videresendt. En svak nabo-node kan plukke den opp og sende den videre med dårlig rekkevidde. Meldingen når kanskje aldri backbone-routeren.

Med CLIENT_BASE på taket, med din portable node som favoritt, skjer dette i stedet:

1. Du sender fra lommen.
2. Taknoden gjenkjenner deg som favoritt og videresender meldingen med garantert prioritet, uansett om andre noder allerede har videresendt den.
3. Meldingen når backbone-routeren med god signalstyrke fra taket.
4. Backbone-routeren sender den videre i nettverket.

Det samme skjer andre veien: meldinger på vei til deg prioriteres av taknoden og leveres til den portable enheten din. Uten favoritter satt på taknoden vil ingenting av dette skje, og noden oppfører seg som en vanlig CLIENT.

---

Teknisk beskrivelse (firmware 2.7.15)

Rebroadcast i Meshtastic

Meshtastic bruker ikke tradisjonell ruting, men managed flooding. Når en node hører en pakke, venter den et kort, SNR-vektet tidsrom før den eventuelt videresender. Noder som hører pakken svakt (langt unna) sender tidlig, slik at meldingen rekker lengst mulig. Hører en node at noen andre allerede har videresendt, kansellerer den vanligvis sin egen videresending for å spare luftetid.

CLIENT_BASE endrer to ting for favoritt-pakker. Begge er verifisert i kildekoden til firmware 2.7.15.

1. Kansellerer aldri videresending av favoritt-pakker

I FloodingRouter::roleAllowsCancelingDupe() returnerer CLIENT_BASE at den ikke skal kansellere når pakken er fra eller til en favoritt:

if (config.device.role == ...Role_CLIENT_BASE) {
    // CLIENT_BASE: hvis pakken er fra eller til en favoritt,
    // skal vi opptre som en ROUTER og aldri kansellere en
    // rebroadcast, selv om vi har hørt en annen stasjon
    // videresende den allerede.
    return !nodeDB->isFromOrToFavoritedNode(*p);
}

Det betyr at taknoden garantert videresender favoritt-pakker, selv om en annen node rakk den først.

2. Sender tidlig (Early-vinduet) for favoritt-pakker

I RadioInterface::shouldRebroadcastEarlyLikeRouter() sender CLIENT_BASE favoritt-pakker tidlig, på linje med ROUTER:

if (config.device.role == ...Role_CLIENT_BASE) {
    return nodeDB->isFromOrToFavoritedNode(*p);
}

Den korte forsinkelsen gir taknoden forrang foran vanlige klienter, slik at den godt plasserte taknoden er den som faktisk når frem.

Merknad om senere firmware: Fra firmware 2.7.18 (via PR #8567) er denne timingen endret slik at CLIENT_BASE i stedet sender i det sene (ROUTER_LATE) vinduet for favoritt-pakker. Det beskrevne her med Early-vinduet gjelder 2.7.15.

Hop-limit og zero-cost hops

Meshtastic begrenser pakkers rekkevidde med et hop-limit, standard 3. Hvert videresendt ledd trekker fra én telling. Zero-cost hops er en mekanisme der infrastrukturnoder kan videresende uten å redusere telleren, slik at pakker rekker lenger.

Logikken ligger i Router::shouldDecrementHopLimit(). En node lar være å redusere hop-telleren dersom alle disse er oppfylt:

1. Nodens egen rolle er ROUTER, ROUTER_LATE eller CLIENT_BASE.
2. Det er ikke pakkens første hopp.
3. Forrige videresender er i nodens favorittliste og har en godkjent rolle.

Betingelse 3 er det avgjørende punktet, og den er strengere i 2.7.15 enn folk ofte tror. Verifisert i kildekoden (tag v2.7.15.567b8ea, Router.cpp linje 116):

// Firmware 2.7.15: forrige relay må være ROUTER eller ROUTER_LATE
if (!IS_ONE_OF(node->user.role,
               ROUTER,
               ROUTER_LATE)) {
    continue;
}

I 2.7.15 er ikke CLIENT_BASE med i betingelse 3. Det betyr at en CLIENT_BASE-node ikke kvalifiserer som “forrige videresender” i en zero-cost-kjede.

Konsekvens for zero-cost i 2.7.15

Retning	Hvem vurderer hoppet	Resultat i 2.7.15
ROUTER → CLIENT_BASE	CLIENT_BASE	Zero-cost (CLIENT_BASE må ha ROUTER som favoritt)
CLIENT_BASE → ROUTER	ROUTER	Ordinært hopp (–1), CLIENT_BASE godtas ikke som forrige relay
CLIENT_BASE → Portabel	Portabel	Ordinært hopp (–1), portabelen er ikke infrastruktur

Den som vurderer om hoppet skal koste, er alltid noden som mottar pakken og skal videresende den. I 2.7.15 gir dette en asymmetri: trafikk inn til taknoden fra en favoritt-ROUTER er zero-cost, men trafikk ut fra taknoden til backbone straffes med en telling, fordi backbone-routeren ikke godtar en CLIENT_BASE som zero-cost-forgjenger.

Merknad om senere firmware: I commit 25bdefec (PR #9168, 4. januar 2026), tilgjengelig fra firmware 2.7.18, ble CLIENT_BASE lagt til i betingelse 3. Fra 2.7.18 blir også CLIENT_BASE → ROUTER zero-cost, forutsatt at backbone-routeren har taknoden som favoritt. På 2.7.15 gjelder dette ikke.

Verktøy for konfigurasjon og fjernstyring

Favoritter settes enklest fra Meshtastic-appen (Android eller iOS) mens du er koblet til noden via Bluetooth. For taknoder som ikke er fysisk tilgjengelige kan du bruke Meshtastic Python CLI, et kommandolinjeverktøy for Windows, Linux og Mac. Det kan kobles til noden via USB, via TCP/IP (Wi-Fi) eller via nettets admin-kanal dersom admin-nøkler er satt opp på forhånd. For Windows finnes det også som selvstendig meshtastic.exe uten installasjon.

Et viktig poeng: admin-nøkler må konfigureres på taknoden via fysisk Bluetooth-tilgang før noden monteres, ellers er fjernstyring ikke mulig etterpå. Med fjernstyring på plass kan favoritter, roller og øvrig konfigurasjon endres over nettet, og traceroute kan brukes til å verifisere at zero-cost-hoppene faktisk virker.

---

Oppsummering

• CLIENT_BASE er for godt plasserte taknoder som skal betjene dine egne nærliggende noder.
• Favoritter må settes på taknoden for at noe skal skje. Uten favoritter er den en vanlig CLIENT.
• I 2.7.15 sender CLIENT_BASE favoritt-pakker tidlig og garantert (Early-vinduet).
• I 2.7.15 er zero-cost asymmetrisk: inn til taknoden er gratis, ut fra taknoden koster en telling.
• Symmetrisk zero-cost mellom taknode og backbone kommer først med firmware 2.7.18.

---

Referanser

• Meshtastic-dokumentasjon, Device Configuration: meshtastic.org/docs/configuration/radio/device/
• Offisiell blogg, rolleguide: Choosing the Right Device Role
• Offisiell blogg, zero-cost hops: Zero-Cost Hops for Favorite Routers
• Kildekode Router.cpp, tag v2.7.15: Router.cpp linje 81, v2.7.15
• Kildekode FloodingRouter.cpp og RadioInterface.cpp, tag v2.7.15: src/mesh, v2.7.15
• PR #8567, CLIENT_BASE ROUTER_LATE-timing (fra 2.7.18): github.com/meshtastic/firmware/pull/8567
• Commit 25bdefec, PR #9168, zero-cost utvidet til CLIENT_BASE (fra 2.7.18): github.com/meshtastic/firmware/commit/25bdefec
• Meshtastic Python CLI: github.com/meshtastic/python