V preteklem nadaljevanju smo se najprej lotili uvoza Arduino aplikacij v MPLAB X razvojno okolje, nato pa prebojnega testiranja Arduino IoT aplikacij. Na koncu smo izdelali še ojačevalnik Wi-Fi signala, ki pride prav predvsem v strnjenih naseljih, v katerih je si dostopne točke pogosto konkurirajo.
Avtor: dr. Simon Vavpotič
V Arduino IoT ugnezdeni programski opremi smo odkrili šibke točke in ranljivosti, ki napadalcu lahko omogočijo dekodiranje varnostnega gesla in spremljanje vsebine Wi-Fi kontrolnih in podatkovnih paketov pa tudi onemogočanje storitev. Zanimalo nas bo, kako to preprečimo, obenem pa tudi, kako zagotovimo drugi in tretji nivo zaščite podatkov. Ranljivosti so tudi v programskih knjižnicah proizvajalcev razvojnih plošč, ki so osnova za gradnjo ugnezdene programske opreme. K sreči te pogosto lažje nadomestimo z novimi različicami, kot popravimo svojo programsko kodo.
Za začetek se lotimo leta 2019 odkritih ranljivosti priljubljenih ESP8266 in ESP32 modulov, ki so nevarne predvsem v okoljih, v katerih uporabljamo načeloma varnejšo EAP (Extensible Authentication Protocol) avtentikacijo namesto enostavnejše PSK (Protected Access Pre-Shared Key (WPA-PSK), ki jo večinoma uporablja v domačih projektih.
Ta vsebina je samo za naročnike
Ranljivosti Espressif Systems ESP modulov
V knjižnicah za gradnjo ugnezdene programske opreme priljubljenih ESP8266 in ESP32 modulov mrgoli hroščev, vendar večina njih vpliva zgolj na stabilnost delovanja modulov, ne pa tudi na varnost podatkovnih komunikacij. Obenem večino zaobidemo s prilagoditvijo svoje ugnezdene programske opreme.
Kljub temu so leta 2019 hekerji na področju Wi-Fi komunikacij odkril tri ključne ranljivosti: namestitev glavnega šifrirnega ključa z vrednostjo 0 (Zero PMK Installaton, uradna oznaka CVE-2019-12587) v Enterprise odjemalce, sesutje odjemalca WPA2 Enterprise, ki uporablja EAP protokol (EAP Client Crash, uradna oznaka CVE-2019-12586), in sesutje ESP8266 z napačno oblikovanimi kontrolnimi paketi za iskanje dostopnih točk (Beacon Frame Crash, uradna oznaka CVE-2019-12588).
Zaradi Zero PMK Installation so omrežni protokoli WPA, WPA2 in WPA3 pri ESP8266 in ESP32 v kombinaciji z EAP-PEAP, EAP-TTLS in EAP-TLS (namesto z običajnim PSK) precej neuporabni, saj lahko heker z injekcijo paketa povsem zaobide varnostni mehanizem in povzroči namestitev ničelnega šifrirnega ključa, s čemer lahko vstopi v omrežje in dekodira vse pakete, ne da bi poznal geslo.
Ranljivosti je Espressif Systems za ESP32 module zakrpal v ESP-IDF SDK-jih od različic 3.1.5, 3.3 in 4.0 naprej, medtem ko so popravki za ESP8266 od SDK 2.2.1 in SDK 3.0.2 naprej. Zakaj toliko različic? Razvoj SDK za ESP32 in ESP8266 module je zaradi njihove pestre uporabe precej razvejan in mnogi programerji ne morejo takoj priti na novejši tip SDK (npr. iz različice 2.x.x. na različico 3.x.x), saj je delovanje nekaterih funkcij spremenjeno in je potrebno prilagoditi tudi vgrajeno programsko opremo, kar zahteva veliko testiranja. Vsekakor pa so varnostni popravki nujni za vse različice.
So ogrožene tudi Arduino ESP IoT aplikacije?
Seveda! Podpora za ESP32 in ESP8266 temelji na Espressif Systems SDK knjižnicah. Različica razvojnega okolja Arduino, v tem primeru ni tako pomembna, saj uporabljamo predvsem njen grafični vmesnik, medtem ko so programske knjižnice del vtičnikov za razvoj Arduino aplikacij za ESP8266, ESP32 in ESP32C. Za razvoj ugnezdene programske opreme za ESP32 moramo namestiti vsaj različico 1.0.3 vtičnika za razvoj programske opreme za ESP32 module, oziroma tako, ki temelji na dovolj novem ESP-IDF SDK. Če imate vtičnik že nameščen, ga lahko enostavno posodobite na zadnjo različico prek interneta. Podobno velja tudi za vtičnik za razvoj ESP8266 Arduino aplikacij.
Po drugi strani, je pri razvojnih ploščah na osnovi AVR mikrokontrolerjev zelo pomembna tudi različica Arduina, saj je bil ta v osnovi razvit zanje in zato ne potrebujejo vtičnikov. Je pa tudi res, da so bile omenjene ranljivosti odkrite le pri ESP modulih. Kakorkoli, v času nastajanja tega članka je bila zadnja stabilna različica Arduino razvojnega okolja 1.8.19, na uradno izdajo pa je še vedno čakala različica 2.0.
AMESIA:33 – skupek ranljivosti več kot milijona IoT modulov
Hekerji pri napadih na v Wi-Fi omrežja uporabljajo tudi druge načine. AMNESIA:33 je nabor 33 ranljivosti IoT sistemov, ki temeljijo na odprtokodnih skladih TCP/IP: uIP, FNET, picoTCP in Nut/Net, ki jih uporablja velika večina IoT naprav. Večinoma gre za kombinacije nepravilnega upravljanja pomnilnika in nepravilno sestavljenih podatkovnih kontrol ali paketov, kar ima za posledico poškodovanje podatkov v pomnilniku, kar lahko omogoči tudi izvajanje zlonamerne programske kode vdiralca.
Na virtualni konferenci BlackHat Europe 2020 je bil pred dvema letoma na to temo predstavljen tudi zanimiv prispevek How Embedded TCP/IP Stacks Breed Critical Vulnerabilities (Kako ugnezdeni TCP/IP skladi porodijo kritične ranljivosti), ki podrobneje opisuje ranljivosti, njihove sprožilce in posledice pri IoT napravah, ki jih uporabljamo v vsakdanjem življenju. Po izsledkih raziskave so potencialno ogrožene IoT naprave 158 različnih proizvajalcev, ki uporabljajo omenjene TCP/IP sklade. Najhujše ranljivosti so odkrili v odprtokodnih skladih CVE-2020-24336 v uIP, CVE-2020-24338 v picoTCP in CVE-2020-25111 v Nut/Net. uIP sklad pri procesiranju DNS naslovov prek NAT64 protokola ne preverja dolžine polja z odgovorom, kar pomen nevarnost poškodovanja podatkov in programov v pomnilniku, posledično pa lahko heker v nekaterih primerih vnese in zažene zlonamerno strojno kodo. picoTCP sklad prav tako ne preverja dolžine DNS imen, zato so naprave, katerih vgrajena programska oprema temelji na tem skladu, enako ogrožene. Nut/Net med analizo imena DNS ne preverja razpoložljivosti pomnilniške kopice (heap), kar omogoča napadalcu zapisovanje poljubnega števila bajtov v pomnilnik naprave, s čemer prav tako dobi možnost vnosa in zagona zlonamerne programske kode.
Med velikimi proizvajalci naprav in programskih razvojnih okolij za gradnjo IoT naprav so se med prvimi odzvali pri Microchipu, ki je glede odkritih ranljivosti izdal belo listino (white paper) s priporočili graditeljem strojne opreme, v kateri najdemo tudi povezavo na pomemben dokument: AMNESIA:33 Identify and Mitigate the Risk From Vulnerabilities Lurking in Millions of IoT, OT and IT Devices s priporočili za proizvajalce strojne opreme. Posebej velja izpostaviti 4 kritične ranljivosti, ki lahko napadalcu omogočijo popoln nadzor nad IoT naprave. Ocenjujejo tudi, da je ogroženih okoli milijon različnih naprav.
Microchip je pri popularnih Wi-Fi modulih WINC1500 in WINC3400 odkril kar 5 ranljivosti, ki jih lahko odpravimo s posodobitvijo vgrajenih programskih oprem na ATWINC3400 Firmware v1.4.1 oziroma ATWINC1500 Firmware v19.7.3, od leta 2021 pa smo že lahko kupimo tudi module s tovarniško vgrajenimi različicami programskih oprem s popravki.
Nadalje, so v razvojem okolju Harmony 3.x odkrili dve ranljivosti (CVE-2020-17439 in CVE-2020-17441), ki sta odpravljeni v Harmony 3.7 in novejših različicah. Medtem, ko se ranljivost CVE-2020-17470 (FSCT-2020-0025) nanaša na programsko kodo, ki jo ustvari MPLAB Code Cinfigurator. Odpravljana je bila šele februarja 2021 z različico 2.2.14 tega priljubljenega orodja.
V programskem okviru s programskimi knjižnicami Microsoft Libraries for Applications (MLA) so odkrili ranljivosti, do katerih pride pri njihovi uporabi z WINC1500 ali WINC3400 modulom in jih odpravimo z namestitvijo že omenjenih posodobljenih vgrajenih programskih oprem. Dobra novica pa je, da pri rešitvah z moduli WILC1000 in WILC3000 ranljivosti niso odkrili.
AMNESIA:33 – Ranljivosti Arduino razvojnih plošč
Veliko Arduino ChipKIT IoT razvojnih plošč za Wi-Fi komunikacije uporablja module WINC1510 in WINC3400, zato so izpostavljene zgoraj omenjenim ranljivostim. Edina rešitev je posodobitev tovarniško nameščene ugnezdene programske opreme modulov, v kolikor to razvojne plošče omogočajo.
Vendar to ne pomeni, da so na AMNESIA:33 občutljive le razvojne plošče z Microchipovimi mikrokontrolerji, prej da je Microchip eden izmed redkih proizvajalcev strojne opreme, ki je ponudil konkretne rešitve za odkrite varnostne luknje v skladih odprtokodnih programskih knjižnic.
ESP32 Wi-Fi Penetration Tool
Vsekakor odkritje in zakrpanje ranljivosti v ESP-IDF SDK hekerjev ni odvrnilo od uporabe ESP32 modula za napade na Wi-Fi omrežja, po drugi strani so tudi varnostni inženirji iskali način, kako preveriti varnost in zanesljivost delovanja ESP in drugih razvojnih modulov z Wi-Fi povezljivostjo. Tako je nastalo orodje ESP32 Wi-Fi Penetration Tool, ki smo ga površno opisali v preteklem nadaljevanju.
Orodje omogoča ne samo izvajanje napadov, ampak tudi zajemanje EAPOL paketov s hash kodami, ki jih lahko nato dokaj enostavno prenesemo v osebni računalnik in se z orodjem, kot je hashcat lotimo ugibanja gesla. Pakete zajema v datoteke capture.pcap in capture.hccapx, kar omogoča analizo podatkov tudi v programskih orodjih, kot je priljubljeni zastonjski WireShark, ki je na voljo za skoraj vse platforme in operacijske sisteme. Če boste WireShark namestili v Microsoftov Windows, morate za neposredno zajemanje podatkov iz omrežnih kartic (tudi Wi-Fi) namestiti še aplikacijo Ncap.
Tokrat pa ga bomo uporabili za preverjanje varnosti Arduino IoT in drugih Wi-Fi aplikacij. Še posebej ogrožene so aplikacije, ki uporabljajo storitve javnih računalniških oblakov, kot so: Google Cloud in Amazon AWS in Microsoft Azure, ki uporabljajo protokol MQTT. Slednji mora biti dodatno zaščiten z uporabo ustreznega kriptografskega algoritma (npr. TLS), kar pa obenem močno obremeni procesor v razvojnih modulih in lahko upočasni njihovo delovanja.
Kako odkrijemo in odpravimo ranljivosti svoje IoT aplikacije?
Mnogi ob branju o številnih ranljivostih IoT strojne in programske oprem zamahnejo z roko misleč, da se jih hekerji pač ne bodo lotili. Vsekakor je malo verjetno, da bi se naključni heker med pitjem kavice v sosednjem lokalu zavzeto lotil prav vaših domačih računalnikov, če za to ne bo imel posebnega razloga. Po drugi strani, hekerji uporabljajo tudi avtomatizirana programska orodja, ki naključno iščejo nove tarče predvsem za to, da bi ugrabili nove računalniške zmogljivosti za napad na večje tarče, pri katerih lahko računajo tudi na finančne koristi. Če želimo doma narejeno strojno opremo vsakodnevno uporabljati, moramo vsekakor zakrpati vsaj najbolj kritične ranljivosti.
Slednje lahko razdelimo na tiste, ki se nanašajo na nevarnost hekerskega vdora prek Wi-Fi omrežja, kot tudi tiste, ki prežijo na aplikacije, ki uporabljajo odstop do interneta in storitve prej omenjenih javnih računalniških oblakov. Prve se nanašajo na redke varnostne luknje v protokolih WPA, WPA2 in WPA3, ki so jih proizvajalci IoT razvojnih modulov večinoma že zakrpali, medtem ko so druge večinoma zajete v že omenjenem skupku ranljivosti AMNESIA:33.
V prvem koraku se moramo vprašati, ali smo naredili dovolj za zavarovanje dostopa do Wi-Fi omrežja. Pomembna je tako uporabljena različica protokola za varnostno kodiranje podatkov (WEP, WPA, WPA2 ali WPA3), kot tudi način, na katerega postaja (npr. prenosni računalnik, pametni telefon, … ) vzpostavi povezavo z dostopno točko (npr. kabelski modem z Wi-Fi povezljivostjo). Doma pretežno uporabljamo PSK protokol, medtem ko naj bil v podjetjih protokol EAP nudil večjo stopnjo varnosti. Kot ste lahko prebrali, vsaj med samograditelji pri priljubljenih ESP modulih ni bilo vedno tako. Druga težava je protokol WPS (Wi-Fi protected setup), ki mora biti izklopljen, saj lahko heker v največ 11.000 korakih ugane pin in prebere celotno konfiguracijo dostopne točke, vključno s pristopnim geslom, zato je tveganje pri njegovi morebitni uporabi navadno preveliko.
Pomembno vlogo igra tudi izbira pristopnega gesla, saj imajo hekerji pri vseh WPA protokolih možnost na tak ali drugačen način zajeti koda hash s šifrirnimi ključi. Iz slednjih lahko hekerji uganejo pristopno geslo, če imajo dovolj časa in dovolj zmogljivo strojno opremo. Potrebne zmogljivosti lahko najamejo tudi v javnih računalniških oblakih…
V naslednjem koraku se lotimo odrivanja Wi-Fi ranljivosti s programskimi orodji. Za to moramo v enega od domačih računalnikov namestiti programsko opremo in po potrebi tudi strojno opremo za prebojno testiranje. Kot slednja zadošča Wi-Fi vmesnik z možnostjo oglednega načina delovanja (angl. monitor mode), v katerem spremlja in po potrebi shranjuje vse kontrolne in podatkovne pakete, ki si jih izmenjujejo postaje in dostopne točke različnih Wi-Fi omrežij, ne da bi moral se moral za to v njih prijaviti. Od programske opreme smo že omenili WireShark in hashcat, a povsem dovolj je, da v svoj računalnik namestimo Kali Linux, ki vsebuje omenjeni in še vrsto drugih orodij, ki jih uporabljajo tako varnostni inženirji kot hekerji. Vendar je za začetnika pogosto prezapleteno, da bi znal uporabiti prav vsa orodja iz ukazne vrstice, zato je v Kali Linuxu na voljo tudi več programov v Pythonu, ki združujejo več osnovnih orodij in samodejno izvajajo osnovne prebojne teste, denimo Wifite. Omenimo še, da lahko Kali Linux namestimo tudi v Rasberry Pi, kar vsekakor ni slaba ideja, saj ta nima težav niti z oglednim načinom delovanja Wi-Fi vmesnika, kakor tudi z injiciranjem podatkovnih ali kontrolnih paketov. Druga možnost je uporaba PIC32 Wi-Fi Penetration Toola, ki ga lahko izdelamo sami, pri čemer moramo zajete EAPOL pakete prenesti v zmogljivejši računalnik z orodji za njihovo analizo.
Večino nevarnosti prek Wi-Fi lahko odpravimo z uporabo novejših različic programskih knjižnic za razvoj ugnezdene programske opreme. Napake v odprtokodnih knjižnicah seveda lahko odpravljamo tudi sami, vendar je to zaradi količine programske kode in omejenih možnosti razhroščevanja pogosto neprimerno težje.
Kako odvrniti ali vsaj omiliti nevarnosti prek spleta?
Čeprav se zdi skupek ranljivosti AMNESIA:33 za programerje skorajda nerešljiv problem, saj so ranljivosti iz njega prisotne skoraj v vseh odprtokodnih skladih programskih knjižnic, je v osnovi dovolj da se izognemo le tistim, ki podpirajo delovanje funkcionalnosti naše aplikacije. Če aplikacija prek Wi-Fi ne dostopa do interneta, odsotnost kontrole dolžine DNS imen ni tako pomembna, saj DNS funkcionalnosti morda ne bomo potrebovali. Tudi, če jo bomo uporabili, bo ta znotraj zaprtega omrežja računalnikov, za katere lahko verjamemo, da ne bodo okuženi z zlonamerno kodo.
IoT naprave lahko zaščitimo tudi tako, da vzpostavimo varni usmerjevalnik, namenjen samo Wi-Fi komunikaciji računalnikov v lokalnem omrežju z IoT napravami. Pri tem lahko dovolimo le določene načine komunikacije, ki se ne nanašajo na omenjeni skupek ranljivosti. Kaj pa aplikacije, ki uporabljajo storitve velikih javnih računalniških oblakov, denimo tiste za razpoznavanje predmetov na sliki s kamere? Ker se najhujše ranljivosti nanašajo na pretvorbo DNS ime v IP naslove, si tu lahko pomagamo tudi tako, da namesto DNS imen v aplikacijo vgradimo kar IP naslove, a je to pogosto nepraktično. Namesto tega je mogoče tudi preverjanje dolžine naslovov v aplikaciji, preden te posredujemo programskim knjižnicam DNS sklada. Skratka, dvojno preverjanje.
Kaj pa funkcionalnosti, ki v ozadju kličejo funkcije DNS? Tu skoraj ne moremo uvesti dodatne kontrole v osnovi programski kode, ker pa imamo na voljo izvorne kode programskih knjižnic, lahko te enostavno vključimo v svoj projekt in dopolnimo njihove kode – torej sami odpravimo težave. Pri iskanju mesta napake v programskih knjižnicah si lahko pomagamo z zastonjskimi orodji, kot je Sublime Text, ki omogočajo preiskovanje velikega števila datotek z izvorno programsko kod z enim samim ukazom, hkrati pa lahko s pomočjo logičnih izrazov tudi zelo natančno opredelimo, kaj iščemo. Slabi lastnosti take rešitve sta predvsem dve: zahteva poglobljeno programersko znanje ter predelane programske knjižnice ne bomo mogli preprosto nadomestiti z novo različico, ko bo ta na voljo, saj moramo v slednjo iz stare prenesti tudi svoje morebitne spremembe in popravke.
Pes čuvaj in varovanje pomnilnika
Sodobni mikrokontrolerji se po zmogljivosti vse bolj spogledujejo s PCji, zato zmogljivejši že dobivajo možnosti za strojno zaščito pomnilnika, kar pomeni, da se ob prekoračitvi obsega programske kopice ali programskega sklada samodejno sproži past, oziroma sistemska prekinitev. Če nam sklad sistemskih programskih knjižnic to omogoča, lahko sistemsko prekinitev vežemo na lastno funkcijo za njeno obravnavo, ki podrobneje ugotovi vzrok, prepreči kontaminacijo delovnega pomnilnika, s tem pa tudi morebiten vnos zlonamerne programske kode. Obenem moramo v aplikaciji implementirati tudi povratno vstopno točko, prek katere lahko ta normalno nadaljuje z delovanjem.
Ena izmed pomembnih aplikacijskih varovalk je lahko tudi strojno podprta funkcionalnost psa čuvaja (watch dog), ki preprečuje neskončne zanke zaradi nepredvidenih napak, ki bi sicer zaustavile delovanje aplikacije. Ker poznamo trajanje določene funkcije, lahko pred izvajanjem le te določimo najdaljši čas njenega izvajanja. V primeru prekoračitve trajanja, oziroma, če aplikacija v vnaprej določenem času ne ponastavi psa čuvaja, se ta sproži in aplikacijo vrne v vnaprej določeno stanje, ki omogoča nadaljnje delovanje kljub težavi. Pri tem opozorimo, da preprosti programski ponovni zagon mikrokontrolerja pogosto ni najboljša rešitev, posebej če pri tem izgubimo pomembne podatke, denimo trenutni čas in datum, ali pa se sesujejo vse Wi-Fi povezave s trenutno povezanimi postajami, ki se morajo po restartu ponovno povezati.
Dobro je, če programsko kodo koncipiramo tako, da ob sistemskih napakah odpravi vzrok, denimo odklopi postajo, ki je povzročila napako, nato pa čim bolj nemoteno deluje naprej z drugimi postajami. Priznam, da se je za slednje potrebni precej potruditi.
Praktični primer
Kako ohranjati povezavo med postajo in dostopno točko?
Heker pri poskusih odkrivanja pristopnega gesla ali onemogočanju delovanja spletnih storitev, pogosto uporabi napad z deavtentifikacijskimi paketi, s katerimi nemalokrat uspe prekiniti že vzpostavljeno povezavo med našima Wi-Fi postajo in Wi-Fi dostopno točko. Kadar podatki nimajo posebnega pomena za hekerja, je pomembno predvsem, da zna postaja povezavo ponovno samodejno vzpostaviti. Denimo, Wi-Fi dostopna točka je le merilnik za zunanjo temperaturo, ki jo periodično bere vremenska postaja, ki deluje tudi kot Wi-Fi postaja, ki periodično odčitava izmerjeno temperaturo.
Predpostavili bomo, da za transport podatkov prek Wi-Fi povezave uporabljamo telnet, saj ne gre za strogo varovane podatke. Četudi bi heker odkril pristopno geslo, bi lahko zgolj izvedel zunanjo temperaturo, ki jo lahko kadarkoli izmeri tudi s svojo napravo. Zato je vseeno, če se postaja takoj po izgubi povezave poskuša ponovno povezati s dostopno točko, ne da bi prej izvedla kakšne preventivne ukrepe.
Toda kako to učinkovito storiti v Arduino programski kodi (C/C++)? Dejansko imamo dve povezavi, Wi-Fi povezavo med postajo in dostopno točko na fizičnem nivoju in logično TCP/IP telnet povezavo na logičnem nivoju. Ob zrušitvi Wi-Fi povezave, moramo istočasno ugotoviti tudi zrušitev TCP/IP telnet povezave. Mogoče je tudi, da se iz kateregakoli vzroka TCP/IP telnet povezava ne vzpostavi ali pa da se ta prekine kljub obstoječi Wi-Fi povezavi. Vzrok je lahko tudi na strani dostopne točke, v kateri zataji TCP/IP telnet strežnik. Zato moramo tako v postajo kot v dostopno točko vgraditi detekcijo tovrstni stanj, za večjo zanesljivost delovanja pa morebiti tudi poseben kanal, prek katerega lahko postaja dostopno točko obvesti, da telenet strežnik ni sprejel njene zahteve.
Zanimivo, da med Arduino primeri izvornih kod ugnezdenih programskih oprem na GitHub ali iz drugih spletne strani skoraj ne najdemo primera, ki bo vključeval samodejno ponovno vzpostavitev Wi-Fi povezave. Velika večina priložnostnih programerjev se tako uvršča med prave zanesenjake, manj veščim nadobudnimi domačim programerjem pa tako ob porušitvi povezave ne preostane drugega kot ponovni zagon naprav.
Kakorkoli, najlaže bomo do rešitve za ohranjanje Wi-Fi povezave prišli, če se odločimo, da bo največje število hkrati povezanih postaj z dostopno točko omejimo na 1, kar omogoča bistveno poenostavitev programske kode, saj nam MAC naslovov postaj ni potrebno povezovati s TCP/IP naslov, ki so jim dodeljeni ob povezavi z telnet strežnikom. Če se poruši Wi-Fi povezava, lahko smatramo, da je padla tudi TCP/IP povezava, zato se v tem primeru lahko postopek povezovanja postaje in dostopne točke začne znova, ne da bi morali karkoli ugotavljati. Če se poruši samo telnet povezava, pač ponovno vzpostavimo le to.
Če pa lahko dostopna točka hkrati sprejme več postaj, moramo enako funkcionalnost podpreti tudi pri telenet strežniku. Vsaka postaja mora dobiti svoj IP naslov, prek katerega se pogovarja s telnet strežnikov, prav tako pa moramo ob zaznani prekinitvi njene Wi-Fi povezava na fizičnem nivoji, prekiniti tudi njeno logično povezavo s telnet strežnikom. No, vsaj to je ena izmed možnosti. Lahko iz sveta PCjev vemo, da je mogoča tudi zahtevnejša implementacija, ko povezavo TCP/IP obdržimo pri življenju kljub zrušitvi in ponovni vzpostavitvi Wi-Fi povezave. Pogoj za to je, da porušitev in ponovna vzpostavitev ne trajata dlje od časovne omejitve nedejavnosti TCP/IP povezave. Posebno programsko logiko potrebuje tudi telnet strežnik, saj mora omogočati ponovno sinhronizacijo s postajo.
Kako zgraditi Wi-Fi kontrolno logiko?
Že takoj povejmo, da osnovne Arduino funkcije niso dovolj. Povezovalno tabelo med MAC in IP naslov moramo vzpostaviti z porabo funkcij ESP-IDF SDK, oziroma drugega SDK, ki podpira delovanje vmesnika Wi-Fi na razvojni plošči in na katerem hkrati temeljijo enostavne Arduino funkcije. Poglejmo program 1.
program 1
void WiFiEvent(WiFiEvent_t event){
EventStr=«[WiFi-event] event: »+String(event,DEC)+String(»n«);
switch (event) {
case SYSTEM_EVENT_AP_STACONNECTED:
err=esp_wifi_ap_get_sta_list(&sta_list);
break;
…
Ko vidimo, smo v povratno klicano funkcijo WiFiEvent, katere delovanje vzpostavimo na v zagonski funkciji Setup ob vzpostavitvi delovana dostopne točke s klicem funkcije WiFi.onEvent(WiFiEvent), vstavili ukaz esp_wifi_ap_get_sta_list, ki tabelo sta_list napolni s podatki trenutno povezanih postaj, vključno s podatki na novo povezane. Ključen je seveda MAC naslov, ki ga pri določitvi IP naslova v TCP/IP strežniku (v našem primeru telnet strežniku) povežemo z MAC naslovom, kot sledi program 2.
program 2
ip4_addr_set_u32(&client_ip[i],serverClients[i].remoteIP()); // add a new client
for(m=0;m<sta_tcpip_list.num;m++){ // get MAC for client
sta_tcpip=sta_tcpip_list.sta[i];
if(ip4_addr_cmp(&client_ip[i],&sta_tcpip.ip))client_mac[i]=macToString(sta_tcpip.mac);}
Kot vidimo, ob povezavi nove postaje s TCP/IP strežnikom njen IP naslov povežemo z njenim MAC naslovom, kar omogoča, da ob njenem odklopu, odklopimo tudi njeno logično povezavo s TCP/IP strežnikom in sprostimo njen IP naslov.
Nova nadaljevanka
Microchip v je v zadnjem času predstavil kopico novih tehnologij, pa tudi novih mikrokontrolerjev s številnimi novimi funkcionalnostmi, s katerimi lahko pohitrimo razvoj zahtevnih aplikacij.
V novi nadaljevanki nas bo zanimalo, kako izbrati ustrezen mikrokontroler in razvojno orodje, s katerima bomo najhitreje prišli želene aplikacijske rešitve.
Spletna stran:
https://sites.google.com/site/pcusbprojects
