Konfigurera och testa Sophos Firewall Wireless Mesh i en befintlig APX-installation

Wireless Mesh på Sophos Firewall ansluter en eller flera APX Access Points trådlöst till en kabelansluten root-AP. Det kan täcka en lucka där Ethernet saknas. Mesh-backhaul är inte det synliga wifi-SSID:t: SFOS skapar ett dolt WPA2-Personal-nät med slumpmässig passphrase. Klienterna använder ett separat konfigurerat Wireless Network.

⚠️ Viktigt: Guiden gäller befintliga APX-installationer som hanteras direkt av SFOS. APX kan bara bilda mesh med APX. AP6, inbyggt LocalWiFi, SD-RED Wi-Fi-moduler och blandade Sophos AP-serier ingår inte. Mesh ersätter inte kabelredundans: minst en AP förblir LAN-ansluten och SFOS byter inte automatiskt root om root-AP:n fallerar.

Omfattning: befintlig drift, inte en ny wifi-plattform

Följande steg beskriver äldre brandväggshanterat mesh för en befintlig APX-installation, inte uppbyggnaden av en ny APX- eller UTM-plattform. Innan något ändras måste stödet för den aktuella AP-modellen, dess hårdvarurevision och den SFOS-build som faktiskt används vara bekräftat. Wireless-hjälpen för SFOS 22 och SFOS 23 innehåller äldre mesh-arbetsgångar; att en hjälpsida finns är inte ett bevis på hårdvarustöd. Det får framför allt inte tolkas som stöd för att uppgradera APX till SFOS 23. Om stödet inte är bekräftat ska den befintliga konfigurationen behållas tills modell-/build-kompatibilitet och migrering har klarlagts.

AP6-mesh hanteras på ett annat sätt: En centralt hanterad AP6-installation konfigureras i Sophos Fusion, tidigare Sophos Central, inte under Wireless > Mesh networks på brandväggen. En Sophos Firewall kan fortfarande fungera som router och säkerhetsgräns i datavägen, men blir inte en AP6-controller. APX och AP6 får inte ingå i samma mesh-nät. Registrering och nätverkskrav för denna separata hanteringsväg beskrivs i Krav för Sophos Central Wireless; konkret planering, mesh-konfiguration och verifiering finns i Planera och konfigurera AP6-mesh. APX-rollerna, SSID-tilldelningarna och stegen för avveckling som visas här ska inte tillämpas på AP6.

Utomhusmodellen APX 320X ingår inte i den här brandväggshanterade arbetsgången. Hänvisningar till den äldre Sophos AP-serien och manuella roller i äldre guider förklarar historiska installationer, inte en nyinstallation som stöds i dag. Inte heller inbyggt LocalWiFi eller SD-RED Wi-Fi-moduler kan ersätta de två externa APX-enheterna i exemplet; deras wifi- och modellkrav måste kontrolleras separat. UTM-guider vidareutvecklas inte här och rekommenderas inte heller som en väg för nyinstallation.

Kort arbetsgång:

1. Anslut först båda APX via LAN, godkänn dem under Wireless > Access points och kontrollera firmware, Country och radioplan.
2. Ange samma fasta kanal på alla deltagande AP för mesh-bandet och stäng av Dyn chan.
3. Konfigurera Mesh-ID, Frequency band och APX under Wireless > Mesh networks > Add.
4. Tilldela det synliga klient-SSID:t separat till båda APX.
5. Spara, koppla bort LAN-kabeln från mesh-AP, starta om APX och vänta upp till fem minuter.
6. Kontrollera AP-status, klient, DHCP, Rule ID, internet och bortfall av root-vägen.

När APX-mesh passar

Mesh passar när en fjärr-AP saknar Ethernet och radiolänken till root-AP är stabil. Exempel är ett litet lager, mötesrum eller tillfälligt område som senare ska kabelanslutas.

Ethernet är fortfarande bättre för varaktig kapacitet, stabil latency och förutsägbar failover. Mesh-backhaul delar radiotid med annan trafik. Mät därför verklig prestanda med avsedda klienter och applikationer.

Produktgränsen är också viktig: APX är End-of-Sale och når End-of-Life 31 december 2027. Ta med APX-livscykeln och AP6 som efterföljare i planeringen. AP6 hanteras inte via SFOS.

Förstå mesh-backhaul, klient-SSID och roller

• Mesh network: dold radiobackhaul mellan APX. Mesh-ID identifierar gruppen och SFOS hanterar WPA2-passphrase.
• Root-AP: APX med Ethernet till brandväggen. För APX följer rollen automatiskt av kabeln.
• Mesh-AP: APX utan Ethernet-uplink som når root-AP via radio.
• Wireless Network: synligt klient-SSID med Security mode, Client traffic, DHCP och regler. Se Konfigurera wifi direkt på Sophos Firewall.

På äldre Sophos AP-serier tilldelas root- och meshroller uttryckligen. Artikeln använder bara APX och tar därför inte över den äldre rollvyn.

Repeater eller wireless bridge

Som repeater sänder mesh-AP det tilldelade klient-SSID:t på fjärrplatsen. Klienterna ansluter via wifi och trafiken går över backhaul till root-AP.

Med wireless bridge ansluts även ett Ethernetsegment till mesh-AP. Det utökar Layer 2 och kan skapa loopar om en andra kabelväg finns. Använd underhållsfönster och dokumenterad återställning. STP måste passa hela switch-/bridgedesignen och stängs inte av enbart för att en väg blockeras.

Repeater är tydligare för små utökningar. Bridge används bara när Ethernetsegmentet behövs och broadcast-, VLAN- och loopbeteendet förstås.

Kontrollera gränserna

• Alla AP tillhör APX-serien.
• Endast ett mesh-nät per AP.
• Minst en APX förblir LAN-ansluten.
• Alla mesh-AP använder samma kanal.
• Dynamic Channel Selection eller Dyn chan måste vara av, annars kan kanaler skilja sig efter omstart.
• Båda APX-radioenheterna får inte samtidigt använda 5 GHz med mesh.
• AP med VLAN kan bara mesha om VLAN inte använder Client traffic Bridge to VLAN.
• Ett andra mesh på samma AP fungerar inte.
• En annan mesh-AP tar inte automatiskt och avbrottsfritt över root-fel.

Sophos anger 2.4 GHz för backhaul och 5 GHz för klient-SSID som en möjlig start, inte universell best practice. Avstånd, väggar, störning, kanaler, Country och kapacitetskrav styr.

Så ska dokumentationskonflikten tolkas: Den äldre installationsguiden anger 5 GHz på root-AP och 2.4 GHz på mesh-AP; guiden för att lägga till mesh skiljer däremot mellan 5 GHz för klient-SSID och 2.4 GHz för mesh-backhaul. Dessa formuleringar får inte leda till att root-AP och mesh-AP använder olika backhaul-band. För den arbetsgång för befintliga installationer som dokumenteras här måste båda AP använda samma valda mesh-band och samma fasta kanal. Exemplet 2.4 GHz är inte ett krav; innan ett annat band väljs måste modell-/build-stödet och radiolänken kontrolleras. APX-begränsningen för två radioenheter som samtidigt är konfigurerade för 5 GHz gäller fortfarande.

Planera exempeltopologin

• Firewall: fw01
• kabelansluten APX: ap-office-root
• trådlös APX: ap-warehouse-mesh
• Mesh-ID: OfficeMesh
• synligt Wireless Network: Company WiFi
• Mesh-band: 2.4 GHz
• Mesh-kanal: en fast, lokalt testad kanal

OfficeMesh ersätts med ett kort unikt lokalt namn. Mesh-ID är inte det synliga SSID:t. Company WiFi har redan rätt Client traffic, DHCP, regler och NAT.

Förbered aktuell backup, kabelansluten hantering och rollback. Båda APX får PoE och testas inom räckhåll för slutplatserna. Root-AP måste kunna nås via Ethernet.

Förbered AP och radiokanal

Provisionera först båda APX via LAN

1. Anslut ap-office-root och ap-warehouse-mesh till hanteringsnätet.
2. Kontrollera Wireless Protection och Allowed zone under Wireless > Wireless settings.
3. Godkänn båda pending APX med Accept under Wireless > Access points.
4. Ange rätt Country. Spara och starta om kontrollerat efter ändring för att uppdatera kanaler.
5. Kontrollera aktiv status och mottagen konfiguration.

Den första kabelanslutningen är obligatorisk. En APX utan mesh-konfiguration kan inte anslutas enbart via radio senare.

Planera även firmware via Sophos Firewall Pattern Updates. Kombinera inte firmwareuppdatering och mesh-övergång okontrollerat.

Ange en gemensam fast kanal

1. Öppna första APX under Wireless > Access points.
2. Ange en fast, lokalt testad kanal i rätt fält, Channel 2.4 GHz eller Channel 5 GHz, under Advanced settings.
3. Stäng av Dyn chan.
4. Gör samma på den andra APX.
5. Placera närliggande AP utanför mesh på annan störningsfri kanal om möjligt.

Välj kanal efter lokal scan, Country och grannkanaler, inte exemplet. Båda mesh-AP måste visa samma värde efter ändringar.

Skapa Wireless Mesh i SFOS

Skapa mesh-nätet

För mesh-backhaul skapas ett nytt, separat mesh-nät eller ett nytt mesh-SSID; det befintliga synliga klient-SSID:t Company WiFi omvandlas inte till ett mesh-nät. Hjälpen använder både Mesh-ID och mesh-enabled SSID för detta. Om det befintliga gränssnittet bara erbjuder Enable mesh mode när ett nytt SSID skapas ska denna dokumenterade äldre arbetsgång endast användas på en modell och build där stödet har bekräftats, och klient-SSID:t ska hållas separat. Endast ett mesh-nät per AP är avsett att användas. Alla deltagande AP måste tilldelas samma Mesh-ID; de delar den WPA2-Personal-passphrase som SFOS genererar slumpmässigt. Det är inte klient-wifits passphrase.

1. Öppna Wireless > Mesh networks.
2. Välj Add.
3. Ange OfficeMesh som Mesh-ID.
4. Välj gemensamt band under Frequency band, här 2.4 GHz.
5. Lägg till ap-office-root och ap-warehouse-mesh.
6. Spara.

På APX tilldelas ingen roll manuellt. Med båda kabelanslutna får de konfigurationen. När ap-warehouse-mesh kopplas bort förblir ap-office-root root tack vare Ethernet.

Tilldela synligt klient-SSID

Mesh-nätet är osynligt för klienter. Tilldela därför också Company WiFi till båda APX under Wireless > Access points eller via en Access Point Group.

SSID:t behåller Security mode och Client traffic. Vid Separate zone måste Wireless interface, DHCP, regel, NAT och Device Access fungera. Mesh rättar inte en saknad regel eller fel DHCP-väg.

Flytta mesh-AP till målplatsen

1. Kontrollera konfiguration och SSID på båda APX.
2. Ta bara bort Ethernet från ap-warehouse-mesh.
3. Lämna ap-office-root kabelansluten.
4. Placera och starta mesh-AP på målplatsen; den startar då utan Ethernet.
5. Starta om root-AP kontrollerat. Om mesh-AP inte blev strömlös när den flyttades startar du även om den nu.
6. Vänta upp till fem minuter.

Normalt förblir bara en APX LAN-ansluten. Om den andra ansluts till samma Layer 2, kontrollera loopar och STP.

Validera Wireless Mesh kontrollerat

1. Under Wireless > Access points är båda aktiva; root har kabel och mesh nås utan Ethernet.
2. Kontrollera mesh-tilldelning och samma kanal.
3. Anslut en klient nära ap-warehouse-mesh till Company WiFi.
4. Visa testklienten efter AP eller SSID under Wireless > Wireless client list och kontrollera att den är ansluten till förväntad mesh-AP och till Company WiFi. Notera signalstyrka och frekvens och kontrollera dem igen under liknande förhållanden vid jämförelsen med root-AP; en visad klientfrekvens bevisar inte i sig vilket band backhaul använder.
5. Jämför klientens IP-adress, gateway och DNS med det planerade Wireless Network.
6. Testa ett tillåtet och ett blockerat mål.
7. Filtrera på testklientens IP-adress i Log Viewer och kontrollera att Firewall Rule ID och NAT Rule ID motsvarar de förväntade reglerna.
8. Jämför realistisk throughput och latency med root-AP.

Grön status bevisar inte hela vägen. Klienten måste använda rätt AP, adress och regler med tillräcklig prestanda. Se Testa brandväggsregler korrekt.

Testa felgränsen medvetet

Root-AP är ett beroende. Koppla kort bort uplink i underhållsfönster och dokumentera avbrottet. SFOS lovar inget automatiskt rootbyte. Mesh-AP kan behöva startas om och kabelanslutas.

Stäng inte av produktions-root oplanerat. Använd kabeluplink eller annan arkitektur för kritiska områden.

Bedöm mesh-objektet i XML API på ett säkert sätt

XML-referenserna för SFOS 22 och 23 beskriver Add Mesh Networks och Update Mesh Networks för objektet WirelessMeshNetworks. Detta är en dokumenterad objektstruktur, inte ett godkännande av ytterligare hårdvara: omfattningen för befintliga APX-enheter, modell-/build-kontrollen och den separata hanteringsvägen för AP6 ovan förblir oförändrade. Åtkomstskydd, explicita operationer, XML-svar och säkra återförsök förklaras i Säkra åtkomsten till Sophos Firewall XML API.

Håll isär MeshID, band och AP-roll

När en automatisering förbereds måste följande fält särskiljas:

• MeshID är en obligatorisk skalär sträng med högst tio tecken. OfficeMesh passar som ett kort exempelnamn; det är fortfarande backhaul-förbindelsens ID, inte det synliga klient-SSID:t. Tolka inte den ytterligare referensmarkören APINTERFACENAME som en självförklarande teckenregel eller som en AP-identitet; bekräfta det tillåtna formatet i den installerade builden.
• FrequencyBand är obligatoriskt och tillåter exakt 5GHz eller 2.4GHz. Tabellen anger 5 GHz som dokumenterat standardvärde, inte som en rekommendation för varje radiolänk. Den kombinerade formen 5GHz/2.4GHz i referensexemplet finns inte i listan över tillåtna värden och används inte som ett enskilt fältvärde. Alla berörda AP:er behöver fortfarande samma bekräftade backhaul-band och samma fasta kanal; Dyn chan förblir avstängt på detta band.
• Description är en valfri skalär sträng. Ett tomt element i exemplet bevisar inte hur en uppdatering hanterar en befintlig beskrivning.
• AccessPoints innehåller MeshNetwork i XML-exemplet; där står AccessPoint och Role tillsammans. Parametertabellen beskriver båda fälten som valfria arrayer med flera värden och påpekar att dubbletter inte ignoreras. Dra inte slutsatsen att detta innebär två listor som kan sorteras godtyckligt och oberoende av varandra eller automatisk deduplicering. Kontrollera AP-identiteten och dess tillhörande roll tillsammans mot den befintliga konfigurationen och buildens API help.
• För Role är exakt MeshAccessPoint och RootAccessPoint dokumenterade; tabellen anger Root Access Point som standardvärde. Dessa XML-värden kommer från API-referensen, inte från GUI-begreppen Root, Mesh eller Repeater. Den automatiska tilldelningen av APX-roller via Ethernet bevisar i synnerhet inte om Role måste anges, utelämnas eller hanteras på annat sätt i den specifika APX-payloaden. Skicka ingen skrivbegäran om kopplingen till modell/build är oklar.

Följande begränsade XML-strukturutdrag är inte en körbar begäran och inte en APX-rolltilldelning. Det visar endast den dokumenterade nästlingen med ett referensvärde för Role; AP_IDENTITAET_AUS_API_HELP är en platshållare som inte får skickas. AP30-identiteten i tillverkarens exempel används inte som ett APX-exempel:

<WirelessMeshNetworks>
  <MeshID>OfficeMesh</MeshID>
  <FrequencyBand>2.4GHz</FrequencyBand>
  <Description />
  <AccessPoints>
    <MeshNetwork>
      <AccessPoint>AP_IDENTITAET_AUS_API_HELP</AccessPoint>
      <Role>RootAccessPoint</Role>
    </MeshNetwork>
  </AccessPoints>
</WirelessMeshNetworks>

Läs före en ändring tillbaka den faktiskt sparade mesh-konfigurationen med mesh-ID, AP-identiteter, tilldelningar och radioparametrar, säkerhetskopiera den och jämför den med det planerade måltillståndet. Utdraget innehåller varken inloggning eller någon operation och ersätter inte en bekräftad fullständig payload. XML-strukturen innebär varken ett säkert återförsök eller en fungerande radioförbindelse; separat verifiering och godkännande av AP-status, klient-SSID, DHCP och nyttodataväg krävs fortfarande.

Skilj mellan svar utifrån operation, kod och symbol

Referenserna kopplar följande XML-statuskoder och ordagranna Message.*-nycklar till de båda operationerna. Nycklarna har inte lösts upp: de är inte bekräftade meddelanden vid körning och översätts inte till förmodade felmeddelandetexter. Den objektspecifika kopplingen måste stämmas av mot API help i den installerade builden; tolka i synnerhet inte 521 och 522 här enbart utifrån den allmänna statustabellen i den centrala API-artikeln.

Add Mesh Networks:

• 200: Message.WLANAPAddSuccessful.
• 500: Message.WLANAPAddFailed.
• 501: Message.WLANAPIPAlreadyInUsed.
• 504: Message.WLANAPIntBaseVHExist.
• 521: Message.WLANAPAddRunConfigFailed.
• 522: Message.WLANAccessPointUnbound.

Update Mesh Networks:

• 200: Message.WLANAPEditSuccessful.
• 500: Message.WLANAPEditFailed.
• 501: Message.WLANAPIPAlreadyInUsed.
• 504: Message.WLANAPIntBaseVHExist.
• 511: Message.WLANAPFailedWhileUnbinding.
• 512: Message.WLANAPFailedWhileDeleteDHCPServer.
• 513: Message.WLANAPFailedWhileDeleteDHCPRelay.
• 516: Message.WLANAPFailedToUnbindInterface.
• 520: Message.WLANAPFailedToUnbindIfaceRCg.
• 521: Message.WLANAPEditRunConfigFailed.
• 523: Message.WLANAPWLAN1UnboundEditFaild.
• 524: Message.WLANAPOtherUnboundEditFaild.

Även stavningen Faild bevaras exakt. Dra inte slutsatser från symbolnamnen om en verifierad orsak, fullständig återställning av en ändring eller ett DHCP-/gränssnittsberoende som redan har tagits bort. Efter ett oklart eller misslyckat svar ska först det faktiskt sparade mesh- och AP-tillståndet samt beroende trådlösa konfigurationer, gränssnittskonfigurationer och DHCP-konfigurationer jämföras med det säkerhetskopierade utgångsläget; spara det sanerade svaret och loggarna för utredningen. Besluta om en ytterligare ändring först efter att frågan har klarlagts för den specifika builden, och upprepa inte automatiskt samma Add eller Update. Inte heller 200 ersätter vare sig återläsning av målobjektet eller verifieringen och godkännandet av radio och klienter ovan.

Felsök efter symptom

Mesh-AP syns inte eller är offline

Vänta fem minuter. Kontrollera att AP:n var aktiv vid LAN-provisionering och fick mesh-konfiguration. Kontrollera sedan APX-serie, tilldelning, band, kanal, Dyn chan, Country och ström.

Root-AP förblir kabelansluten. Om båda är trådlösa eller fel AP kopplats bort saknas vägen till brandväggen. Korrigera, starta om och vänta.

Om alternativet Enable mesh mode saknas för ett befintligt SSID i ett äldre arbetsflöde skapar du ett nytt SSID i stället för att ändra användningen av det synliga klient-SSID:t. Om orsaken fortfarande är oklar kan du isolera vägen i ett underhållsfönster: sänd endast mesh-nätet på root-AP och endast det synliga klient-SSID:t på repeatern. Om klient-SSID:t visas på repeatern tyder det i första hand på att klientkonfigurationen sänds ut, men det är ännu inte ett fullständigt bevis på fungerande backhaul eller internetåtkomst. Kontrollera dessutom att repeatern verkligen kan nås utan LAN-uplink, att testklienten visas på denna AP i klientlistan och att den förväntade DHCP-vägen och den tillåtna datavägen fungerar. Återställ därefter de normala tilldelningarna. Om mesh-nätet fortfarande inte kan användas kontrollerar du om STP blockerar mesh-konfigurationen. Stäng inte av STP utan vidare: protokollet förhindrar loopar i bridgetopologier.

Klient-SSID syns inte

Mesh-ID sänds inte som klient-SSID. Tilldela ett synligt Wireless Network under Wireless > Access points. Enbart OfficeMesh syns inte.

Kontrollera Frequency band, schema, Security mode och tilldelning. Ett andra mesh hjälper inte eftersom bara ett stöds.

Klient ansluter utan IP-adress

I det här läget fungerar radioförbindelsen mellan klienten och AP:n redan delvis. Kontrollera därefter inställningen Client traffic, Wireless interface, DHCP-server eller DHCP-relay och möjliga vägar genom VLAN. Vid Bridge to VLAN måste du även ta hänsyn till produktbegränsningen: AP-enheter som är tilldelade VLAN kan bara bilda mesh om dessa VLAN inte använder detta läge för Client traffic.

Att starta om den trådlösa tjänsten (wireless service) är inte ett standardsteg i felsökningen. Fastställ först vilken AP klienten faktiskt är ansluten till och kontrollera om DHCP-förfrågningarna når fram längs den förväntade vägen.

Klient har IP men inget Internet

Filtrera på testklientens IP-adress i Log Viewer och sök först efter förväntade Firewall Rule ID och NAT Rule ID. Om båda saknas ligger problemet troligare i zonen, nätverksobjektet, regelordningen eller datavägen än i själva mesh-nätet. Om identifierarna motsvarar de förväntade reglerna kontrollerar du därefter DNS, gateway och vägen till WAN.

Använd inte en bred Any-regel för att diagnostisera mesh. Utför samma klienttest en gång vid root-AP och en gång vid mesh-AP. Om testet bara lyckas vid root-AP undersöker du backhaul vidare. Om testet misslyckas vid båda AP-enheterna ligger felet sannolikt i den gemensamma WLAN- eller brandväggskonfigurationen.

Anslutningen är instabil eller långsam

Kontrollera samma kanal, avstängd Dyn chan, signal, störning, avstånd och väggar. AP utanför mesh bör inte belasta kanalen i onödan. Kapacitet måste finnas för backhaul och klienter.

Jämför samma applikation och klient under liknande förhållanden på root och mesh för att skilja från WAN-, DNS- eller klientfel.

Controller- eller klientstatus är oklar

Sophos Firewall-serviceloggar hjälper vid lokal felsökning på den aktuella noden. Följande kontroller i Advanced Shell läser endast loggarna:

tail -n 200 /log/awed.log
tail -n 200 /log/wc_remote.log

awed.log visar kommunikationen mellan controller och APX; wc_remote.log hjälper vid felsökning av trådlösa klienter. En enskild loggrad bevisar inte att vägen för användartrafik fungerar. Jämför tidsstämplar, AP-status, klientlistan och brandväggsloggarna med ett reproducerbart trafiktest. LED- och blinkkoder för Sophos AP hjälper dessutom till att tolka enhetens start-, uppdaterings- och mesh-status.

Rulla tillbaka mesh säkert

Skilj mellan mesh-SSID och klient-SSID vid avveckling: Den äldre hjälpen beskriver hur mesh stängs av genom att mesh-SSID:t tas bort. Det avser det tillhörande mesh-konfigurationsobjektet, inte generellt det synliga klient-SSID:t Company WiFi. Kontrollera Mesh-ID, AP-tilldelningar och beroenden före borttagning, säkerhetskopiera den aktuella konfigurationen och se till att AP-enheterna kan nås via den avsedda kabelvägen. När backhaul tas bort bryts anslutningen till trådlöst anslutna AP; om ett klient-SSID som fortfarande behövs tas bort kopplas även dess wifi-användare från. Beroende på det äldre gränssnittet sker avvecklingen via mesh-nätet eller dess mesh-SSID. Om kopplingen inte är entydig ska inget tas bort på chans; klarlägg först den konkreta modell-/build-konfigurationen.

1. Dokumentera root och mesh APX.
2. Återanslut mesh-AP via LAN och invänta aktiv status.
3. Flytta vid behov SSID till en kabelansluten AP.
4. Ta bort mesh från APX eller under Wireless > Mesh networks.
5. Återställ kanal och Dyn chan medvetet.
6. Starta om båda kontrollerat.
7. Testa IP, DNS, regler och Internet igen.

Fabriksåterställning är först relevant om APX trots korrekt kabel, ström och controller inte tar konfiguration. Den ersätter inte rollback.

Driftchecklista

• Alla enheter är kompatibla APX och provisionerades först via LAN.
• Exakt ett mesh är tilldelat per AP.
• En APX förblir kabelansluten root.
• Mesh-band och kanal är identiska.
• Dyn chan är avstängd.
• Synligt klient-SSID är separat tilldelat.
• DHCP, Firewall Rule ID, NAT Rule ID och blockerat mål har testats.
• Prestanda och stabilitet har jämförts.
• Root-fel, utebliven automatisk takeover och rollback är dokumenterade.
• APX End-of-Life och framtida plattformsbyte är planerade.

FAQ