Test i shpejtësisë në të njëjtën kohë me disa modemë LTE

Në karantinë, më ofruan të merrja pjesë në zhvillimin e një pajisjeje për matjen e shpejtësisë së modemëve LTE për disa operatorë celularë.

Porositësi donte të vlerësonte shpejtësinë e të gjithë operatorëve të mundshëm të komunikimit në vende të ndryshme gjeografike, në mënyrë që të kuptonte se cili operator celular ishte më optimal për të instaluar pajisje që përdorin lidhjen LTE, për shembull, për transmetime video. Detyra duhej zgjidhur sa më thjesht dhe ekonomikisht, pa pajisje të shtrenjta.

E them direkt, që detyra s'ishte e lehtë dhe kërkonte shumë kërkime, do të flas për problemet që kam hasur dhe si i kam zgjidhur ato. Pra, le të fillojmë.

Shënim

Matja e shpejtësisë së lidhjes LTE është një gjë mjaft e komplikuar: është e nevojshme të zgjidhet saktë pajisja dhe metodologjia e matjes, gjithashtu të kuptohet mirë topologjia dhe funksionimi i rrjetit celular. Përveç kësaj, shpejtësinë mund ta ndikojnë disa faktorë: numri i abonentëve në qelë, kushtet atmosferike, madje nga qelia në qeli shpejtësia mund të ndryshojë ndjeshëm për shkak të topologjisë së rrjetit. Në përmbledhje, kjo është një detyrë me shumë të panjohura, dhe mund ta zgjidhë saktësisht vetëm operatori i komunikimeve.

Fillimisht, porositësi donte thjesht të dërgonte një kurier me telefonat e operatorëve, të kryente matjet direkt në telefon dhe pastaj të regjistronte rezultatet e matjes në një fletore. Zgjidhja ime për matjen e shpejtësisë së rrjeteve LTE, ndonëse jo perfekte, e zgjidh problemin e parashikuar.

Për shkak të mungesës së kohës, mora vendime jo në favor të rehatshme ose praktikës, por në favor të shpejtësisë së zhvillimit. Për shembull, për qasje të largët ngrihej një SSH i kundërt, në vend të një VPN më praktike, për të kursyer kohën në konfigurimin e serverit dhe të çdo klienti të veçantë.

Detyra teknike

Siç thotë artikulli Pa TЗ: pse klienti nuk dëshiron atë: Mos punoni pa TЗ! Asnjëherë, askund!

Detyra teknike ishte mjaft e thjeshtë, unë do ta zgjas pak për ta bërë më të kuptueshme për përdoruesin përfundimtar. Zgjedhja e zgjidhjeve teknike dhe pajisjeve ishte diktuar nga porositësi. Pra, vetë TЗ, pas të gjithë miratimeve:

Në bazë të një kompjuteri me një pllakë vim2 të bëja një tester shpejtësie për lidhjen LTE përmes modemëve Huawei e3372h — 153 për disa operatorë të komunikimeve (nga një deri në n). Gjithashtu është e nevojshme të merrni koordinatat nga një pranues GPS të lidhur përmes UART. Matjet e shpejtësisë duhet të kryhen duke përdorur shërbimin www.speedtest.net dhe t'i përmbledhin ato në një tabelë të tipit:

Tabela në format csv. Pas kësaj, të dërgohet tabela në e-mail çdo 6 orë. Në rast të gabimeve, të flakërohet një LED i lidhur në GPIO.

TЗ-un e kam përshkruar në mënyrë të shkurtër, pas shumë miratimesh. Por kuptimi i detyrës është tashmë i dukshëm. Kohëzgjatja për gjithçka ishte një javë. Por në realitet zgjati tri javë. Kjo duke pasur parasysh që e bëja këtë vetëm pas punës kryesore dhe në fundjavë.

Këtu dua të theksoj përsëri se porositësi kishte rënë dakord përpara në përdorimin e shërbimit të matjes së shpejtësisë dhe pajisjeve, që e kufizonte ndjeshëm mundësitë e mia. Buxheti gjithashtu ishte i kufizuar, kështu që nuk u blenë shumë gjëra shtesë. Pra, duhej të luaja sipas këtyre rregullave.

Arkitektura dhe zhvillimi

Skema është e thjeshtë dhe e qartë. Prandaj do ta lë atë pa komente të veçanta.

Të gjithë projektin vendosa ta realizoj në python, ndonëse nuk kisha aspak përvojë zhvillimi në këtë gjuhë. E zgjodha atë, pasi kishte shumë shembuj të gatshëm dhe zgjidhje që mund të përshpejtonin zhvillimin. Prandaj, ju lutem të gjithë programuesve profesionalë mos më kritikoni për këtë përvojë të parë zhvillimi në python, dhe gjithmonë me kënaqësi jam i hapur për kritika konstruktive për të përmirësuar aftësitë e mia.

Gjithashtu në proces, zbulova se python ka dy versione funksionale, 2 dhe 3, dhe përfundimisht u ndala në të tretën.

Njësitë harduerike

Pajisja me një pllakë vim2

Si makinë kryesore, më ishte dhënë një pajisje me një pllakë vim2

Një mediamak i shkëlqyer dhe i fuqishëm për shtëpinë inteligjente dhe SMART-TV, por jashtëzakonisht i papërshtatshëm për këtë detyrë, ose mund ta themi ashtu, pak i përshtatshëm. Për shembull, sistemi i tij operativ i kryesor është Android, ndërsa Linux është një sistem operativ ndihmës, dhe kështu askush nuk garanton funksionimin e duhur të të gjitha nyjave dhe shoferëve për Linux. Mendoj se një pjesë e problemeve ishte në lidhje me shoferët USB të kësaj platforme, dhe për këtë arsye modemët nuk punonin siç prisja në këtë plang. Po ashtu, dokumentacioni i tij është shumë i dobët dhe i shpërndarë, kështu që çdo operacion merrte shumë kohë për të kaluar nëpër dokumente. Edhe puna e zakonshme me GPIO më shkaktoi shumë probleme. Për shembull, për të konfiguruar punën me LED-in, më nevojitën disa orë. Por, për të qenë objektiv, në thelb nuk kishte rëndësi se çfarë lloj plangje ishte, sa rëndësi kishte që të funksiononte dhe të kishte porta USB.

Për fillim, më duhet të instaloj Linux në këtë plang. Që të mos kërkoj nëpër thellësitë e dokumentacionit, dhe gjithashtu për ata që do të merren me këtë plang, po shkruaj këtë kapitull.

Janë dy mundësi për të instaluar Linux: në një kartë të jashtme SD, ose në MMC të brendshme. Me kartën u përleshëm një natë, por nuk arrita të kuptoj se si ta bëj të funksionojë, dhe kështu vendosa ta instaloj në MMC, edhe pse pa dyshim kishte qenë më e lehtë të punoja me kartën e jashtme.

Për flasher ka informacion të pasaktë këtu. Po përkthj edhe nga një formë të çuditshme në rusisht. Për të flasher plangun, më duhet të lidh një UART harduerik. E lidha atë në këtë mënyrë.

• Tool Pin GND: Pin17 i GPIO-ve të VIM
• Tool Pin TXD: Pin18 i GPIO-ve të VIM (Linux_Rx)
• Tool Pin RXD: Pin19 i GPIO-ve të VIM (Linux_Tx)
• Tool Pin VCC: Pin20 i GPIO-ve të VIM

Pas kësaj, shkarkova firmuerin këtu. Versioni konkret i firmuerit VIM1_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20191231.

Për të ngarkuar këtë firmuer, më nevojiten utilitarë. Më shumë detaje për këtë janë dhënë këtu. Nuk kam provuar ta flashem nën Windows, por për flasherin nën Linux duhet të them pak fjalë. Për fillim do të instaloj utilitarët, sipas udhëzimeve.

git clone https://github.com/khadas/utils
cd /path/to/utils
sudo ./INSTALL

Iii… Asgjë nuk funksionon. Kam kaluar disa orë duke bërë rregullime në skenarët e instalimit, që gjithçka të instalohet siç duhet. Çfarë asaj bëra, nuk e mbaj mend, por gjithashtu ishte një sirkus i vogël. Prandaj, kini kujdes. Por pa këta utilitarë, nuk ka kuptim të vazhdoni me vim2. Më mirë të mos merremi fare me të!

Pas shtatë rrethshqipërimeve, rregullimit të skenarëve dhe instalimit, mora paketën e funksionueshme të utilitarëve. Lidh plangun përmes USB me kompjuterin tim Linux, dhe gjithashtu e lidha UART-në sipas skemës më sipër.
Configurim terminalin tim të preferuar minicom në shpejtësi 115200, pa kontroll të gabimeve harduerike dhe programore. Dhe vazhdojmë.

Gjatë ngarkesës së VIM2 në terminalin UART, shtyp ndonjë çelës, për shembull hapësirë, për ta ndaluar ngarkesën. Pas shfaqjes së rreshtit

kvim2# 

Shkruaj komandën:

kvim2# run update

Në hostin nga e cila ngarkohet, ekzekutoj:

burn-tool -v aml -b VIM2 -i  VIM2_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20191231.img

Të gjitha, uffff. E flashta, në plang ka Linux. Login/fjalëkalimi khadas:khadas.

Pas kësaj disa konfigurime fillestare. Për punë të mëtejshme çaktivizoj fjalëkalimin në sudo (po, nuk është i sigurt, por është i lehtë).

sudo visudo

Editoj rreshtin në formën dhe ruaj

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) NOPASSWD: ALL

Pas kësaj e ndryshoj lokalitetin aktual, që koha të jetë sipas Moskës, përndryshe do të jetë sipas Greenwichit.

sudo timedatectl set-timezone Europe/Moscow

apo

ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Nëse ju duket e komplikuar, atëherë mos përdorni këtë plang, preferoni Raspberry Pi. Sinqerisht.

Modemi Huawei e3372h — 153

Ky modem më shkaktoi shumë problem, dhe, në thelb, ai u bë pika më e dobët e të gjithë projektit. Në fakt, emri 'modem' për këto pajisje nuk reflekton asnjëherë natyrën e punës: është një kombinim i fuqishëm, ky pajisje ka një rrjet të përbërë, e cila pretendon të jetë CD-ROM për të instaluar shoferët dhe pastaj kalon në modin e kartës rrjet.

Arkitecturally, nga këndvështrimi i përdoruesit të Linux, pas të gjitha rregullimeve, duket kështu: pas lidhjes së modemëve, më shfaqet një ndërfaqe rrjeti eth*, e cila merr ip adresën 192.168.8.100 nga dhcp, dhe portalin e paracaktuar 192.168.8.1.

Dhe pika kryesore! Ky model modemi nuk e ka aftësinë të punojë në modin e modemëve që menaxhohet përmes komandave AT. Të gjitha do të ishin shumë më të lehta, të krijoja lidhje ppp për çdo modem dhe më pas të veproja me ta. Por në rastin tim, 'vetë' (më saktë, shoferët e Linux sipas rregullave udev), krijon ndërfaqen eth dhe i cakton asaj një ip adresë përmes dhcp.

Për të mos u ngatërruar, sugjeroj të harrojmë fjalën 'modem' dhe të flasim për kartën rrjet dhe portalin, pasi në thelb është si të lidhemi me një kartë rrjeti të re me portalin.
Kur ka një modem, nuk shkakton shumë probleme, por kur ka më shumë se një, e veçanërisht n, atëherë shfaqet kjo pamje e rrjetit.

Pra shpjegim nënkuptohet se kemi n kartela rrjeti, me një IP adresë, ku secili ka të njëjtin gateway të paracaktuar. Por në fakt, secili prej tyre është i lidhur me operatorin e vet.

Fillimisht, kisha një zgjidhje të thjeshtë: me komandën ifconfig ose ip ndalonim të gjitha ndërfaqet dhe thjesht aktivizonim njëra pas tjetrës për t'i testuar. Zgjidhja ishte e mirë në çdo aspekt, përveç faktit që gjatë ndërrimit nuk kisha mundësi të lidhesha me pajisjen. Dhe për shkak të ndërrimeve të shpeshta dhe të shpejta, në praktikë nuk kisha mundësi të lidhesha për asnjë moment.

Prandaj, zgjodha rrugën e ndryshimit të adresave IP të modemëve manualisht dhe më pas kalimin e trafikut nëpërmjet konfigurimeve të rrugëzimit.

Me këtë problemi me modemët nuk u mbyll: në rast probleme me energjinë, ata ndaleshin; kërkohej një furnizim i mirë dhe stabil për USB hub-in. Këtë problem e zgjidhja duke u lidhur drejtpërdrejt me hub-in. Një problem tjetër me të cilin u përballa dhe që e shkatërroi gjithë projektin: pas rinisjes ose nisjes së ftohtë të pajisjes, të gjithë modemët nuk identifikoheshin dhe jo gjithmonë, dhe nuk arrita të kuptoj pse ndodhte kjo dhe me cilin algoritëm. Po flas për të gjitha me radhë.

Për funksionimin e duhur të modemëve, kam instaluar paketën usb-modeswitch.

sudo apt update
sudo apt install -y usb-modeswitch

Pas kësaj, modemët do të identifikohen dhe konfigurohen saktë nga sistemi udev. E kontrolloj, thjesht duke lidhur modemët dhe siguruar që rrjeta u aktivizua.
Një tjetër problem që nuk e zgjidhja ishte se si të merrja emrin e operatorit që përdorim nga ky modem? Emri i operatorit ndodhet në ndërfaqen web të modemës në adresën 192.168.8.1. Kjo është një faqe web dinamike, e cila merr të dhënat përmes kërkesave ajax, kështu që thjesht wget-e faqen dhe shpjegimin e emrit nuk është e mundur. Prandaj fillova të shikoj si të punoj me atë faqe web, dhe kuptova se po merrem me diçka të kote. Në fund e braktisa këtë ide dhe fillova të merrja emrin e operatorit përmes API të Speedtest.

Shumë gjëra do të ishin më të thjeshta nëse modemi do të kishte qasje përmes komandave AT. Do të mund ta rindërtoja, të krijoja një lidhje ppp, të caktoja IP, të merrja operatorin e lidhjes etj. Por fatkeqësisht, punoj me atë që janë dhënë.

GPS

GPS-priçesori që më dhënë, kishte ndërfaqe UART dhe furnizim. Nuk ishte zgjidhja më e mirë, por megjithatë ishte funksionale dhe e thjeshtë. Priçesori dukej në këtë mënyrë.

Me sinqeritet, ishte hera e parë që punoja me një GPS-priçesor, por siç presupozohej, gjithçka ishte marrë parasysh. Prandaj, thjesht përdorim zgjidhjet e gatshme.

Për fillim aktivizoj uart_AO_B (UART_RX_AO_B, UART_TX_AO_B) për të lidhur GPS.

khadas@Khadas:~$ sudo fdtput -t s /dtb.img /serial@c81004e0 status okay

Pas kësaj kontrolloj për suksesin e operacionit.

khadas@Khadas:~$ fdtget /dtb.img /serial@c81004e0 status
okay

Kjo komandë, sipas dukjes, modifikon në fluks devtree-në, e cila është shumë e përshtatshme.

Pas suksesit të këtij operacioni, rinisemi dhe instalojmë gps-daemon.

khadas@Khadas:~$ sudo reboot

Instalimi i gps-daemon. Instaloj të gjitha dhe e çaktivizoj menjëherë për konfiguracionin e mëtejmë.

sudo apt install gpsd gpsd-clients -y
sudo killall gpsd

/* GPS daemon stop/disable */
sudo systemctl stop gpsd.socket
sudo systemctl disable gpsd.socket

Modifikoj skedarin e konfigurimit.

sudo vim /etc/default/gpsd

Caktoj UART-in, në të cilin do të lidhet GPS.

DEVICES="/dev/ttyS4"

Dhe më pas aktivizojmë gjithçka dhe startojmë.

/* GPS daemon enable/start */
sudo systemctl enable gpsd.socket
sudo systemctl start gpsd.socket

Pas kësaj, lidh GPS.

Në duar kam kabllon GPS, dhe nën gishta duken kabllot UART të debugarit.

Rinisem dhe kontrolloj funksionimin e GPS me programin gpsmon.

Në këtë screenshot nuk duken satelitët, por duket komunikimi me GPS-priçesorin, dhe kjo tregon se gjithçka është në rregull.

Kam provuar shumë variante pune me këtë daemon në python, por ndaluam te ai që punonte saktë me python 3.

Instaloj bibliotekën e nevojshme.

sudo -H pip3 install gps3 

Dhe krijoj kodin e punës.

from gps3.agps3threaded import AGPS3mechanism
...
def getPositionData(agps_thread):
	counter = 0;
	while True:
		longitude = agps_thread.data_stream.lon
		latitude = agps_thread.data_stream.lat
		if latitude != 'n/a' and longitude != 'n/a':
			return '{}' .format(longitude), '{}' .format(latitude)
		counter = counter + 1
		print ("Wait gps counter = %d" % counter)
		if counter == 10:
			ErrorMessage("Gabim në GPS-priçesor!!!")
			return "NA", "NA"
		time.sleep(1.0)
...
f __name__ == '__main__':
...
	#gps
	agps_thread = AGPS3mechanism()  # Instanco mekanizmat AGPS3
	agps_thread.stream_data()  # Nga localhost (), ose nga hoste të tjera, për shembull, (host='gps.ddns.net')
	agps_thread.run_thread()  # Kohë pauzë pas një kërkese bosh, parazgjedhja '()' 0.2 dy të dhjeta të një sekonde

Nëse kam nevojë të marrë koordinatat, atëherë bëhet me thirrjen e mëposhtme:

longitude, latitude = getPositionData(agps_thread)

Dhe brenda 1-10 sekondave do të marr ose koordinatën, ose jo. Po, kam pasur dhjetë përpjekje për të marrë koordinatat. Nuk është optimale, as e mirë, por funksionon. Vendosa ta bëj kështu, sepse GPS mund të kapë dobët dhe nuk merr gjithmonë të dhënat. Nëse prisni për të marrë të dhënat, kjo do ta ndalonte programin në këtë pikë kur punon në një ambient të errët. Prandaj, realizova këtë variant të papërsosur.

Në parim, po të kisha më shumë kohë, do të mund të merrja të dhëna nga GPS drejtpërdrejt përmes UART, t'i parseja ato në një thread të veçantë dhe të punoja me to. Por nuk kishte fare kohë, ndaj rezultati ishte një kod shumë i çrregullt. Dhe po, nuk kam turp.

Diodë LED

Me lidhjen e diodës LED, gjithçka ishte e thjeshtë dhe e komplikuar në të njëjtën kohë. Sfidën kryesore e përbënte fakti se numri i pin-it në sistem nuk përputhej me numrin e pin-it në pllakën e qarkut dhe sepse dokumentacioni ishte shkruar dobët. Për të bërë një përputhje të numrit të pin-it fizik dhe numrit të pin-it në OS, duhet të ekzekutoni komandën:

gpio readall

Do të shfaqet një tabelë përputhjeje midis pin-it në sistem dhe atij në pllakë. Pas kësaj, unë mund të operoj me pin-in në OS. Në rastin tim, dioda LED është e lidhur me GPIOH_5.

E kaloj pin-in GPIO në modin e daljeve.

gpio -g mode 421 out

Regjistroj zero.

gpio -g write 421 0

Regjistroj një.

gpio -g write 421 1

Të gjitha shkëlqejnë pas regjistrimit të "1".

#gpio subsistem
def gpio_init():
	os.system("gpio -g mode 421 out")
	os.system("gpio -g write 421 1")

def gpio_set(val):
	os.system("gpio -g write 421 %d" % val)
	
def error_blink():
	gpio_set(0)
	time.sleep(0.1)
	gpio_set(1)
	time.sleep(0.1)
	gpio_set(0)
	time.sleep(0.1)
	gpio_set(1)
	time.sleep(0.1)
	gpio_set(0)
	time.sleep(1.0)
	gpio_set(1)

def good_blink():
	gpio_set(1)

Tani, në rast gabimesh, thërras error_blink() dhe dioda LED na shqetëson me një ndriçim të bukur.

Njësitë programore

Speedtest API

Gëzim i madh që shërbimi speedtest.net ka API-në e vet për python, mund ta shihni në Github.

E bukur është se ka kodet burimore që gjithashtu mund të shihen. Si të punoni me këtë API (shembuj të thjeshtë) mund të shihni në seksionin përkatës.

Instaloj bibliotekën python me komandën e mëposhtme.

sudo -H pip3 install speedtest-cli

Për shembull, mund ta instaloni speedtester në Ubuntu direkt nga repos. Kjo është e njëjta aplikacion python, që më pas mund të iniciohet direkt nga konzola.

sudo apt install speedtest-cli -y

Dhe të realizoni matjet e shpejtësisë së internetit tuaj.

speedtest-cli
Po marrjen e konfigurimit të speedtest.net...
Testimi nga B***** (*.*.*.*)...
Po merr listën e serverëve speedtest.net...
Selecting best server based on ping...
E strehur nga MTS (Moskë) [0.12 km]: 11.8 ms
Testimi i shpejtësisë së shkarkimit................................................................................
Shkarkimi: 7.10 Mbit/s
Testimi i shpejtësisë së ngarkimit......................................................................................................
Ngarkimi: 3.86 Mbit/s

Siç e bëra unë. Më duhet të hyj në kodet burimore të këtij speedtesti për ta inkorporuar më plotësisht në projektin tim. Një nga detyrat më të rëndësishme është të marr emrin e operatorit të komunikimit për ta vendosur në tabelë.

import speedtest
from datetime import datetime
...
# Specifikoni një server të caktuar për testimin
#6053) MaximaTelecom (Moskë, Federata Ruse)
servers = ["6053"]
# Nëse dëshironi të përdorni një test me thread të vetëm
threads = None
s = speedtest.Speedtest()
# merrni emrin e operatorit të celularit
opos = '%(isp)s' % s.config['client']
s.get_servers(servers)
# merrni një varg tekstual me parametrat e serverit
testserver = '%(sponsor)s (%(name)s) [%(d)0.2f km]: %(latency)s ms' % s.results.server
# test i shkarkimit
s.download(threads=threads)
# test i ngarkimit
s.upload(threads=threads)
# merrni rezultatet
s.results.share()

# Më pas formohet një varg për regjistrimin në një skedar csv.
# merrni pozitën GPS
longitude, latitude = getPositionData(agps_thread)
# koha dhe data
curdata = datetime.now().strftime('%d.%m.%Y')
curtime = datetime.now().strftime('%H:%M:%S')
delimiter = ';'
result_string = opos + delimiter + str(curpos) + delimiter + 
	curdata + delimiter + curtime + delimiter + longitude + ', ' + latitude + delimiter + 
	str(s.results.download/1000.0/1000.0) + delimiter + str(s.results.upload / 1000.0 / 1000.0) + 
	delimiter + str(s.results.ping) + delimiter + testserver + "n"
# këtu bëhet regjistrimi në skedarin e logeve

Këtu gjithashtu nuk ishte aq e thjeshtë, ndonëse dukej e tillë. Fillimisht, parametri servers ishte i barabartë me [], thjesht zgjidh serverin më të mirë. Si rezultat, unë pata servera të rastësishëm dhe, siç është lehtë e kuptueshme, shpejtësi të paqëndrueshme. Kjo është një temë e komplikuar, përdorimi i një serveri të fiksuar, nëse po, atëherë statik ose dinamik, kërkon hulumtim. Por ja një shembull grafiku të matjeve të shpejtësisë të operatorit Beeline me zgjedhjen dinamike të serverit të testimit dhe një server të përzgjedhur statik.

Rezultati i matjes së shpejtësisë duke zgjedhur një server dinamik.

Rezultati i testimit të shpejtësisë, me një server të zgjedhur strikt.

„Lesh“ gjatë testimit është atje dhe atje, dhe duhet hequr me metoda matematikore. Por me një server të fiksuar është pak më pak dhe amplituda është më e stabilizuar.
Për të qenë të sinqertë, ky është një vend për hulumtime të mëdha. Unë do të realizoja matjet e shpejtësisë ndaj serverit tim, përmes utilitarit iperf. Por ne kemi për të respektuar specifikimet teknike.

Dërgimi i emailit dhe gabimet

Për dërgimin e emailit kam provuar disa dhjetëra variante të ndryshme, por përfundimisht u ndala në këtë. Regjistrova një adresë emaili në yandex dhe më pas mora këto shembuj dërgimi email-i. E verifikova dhe e inkorporova në program. Në këtë shembull shqyrtohen disa mundësi të ndryshme, përfshirë dërgimin me gmail etj. Nuk doja të merresha me ngritjen e serverit tim të emailit dhe nuk kisha kohë për këtë, por siç doli të ishte, kjo ishte e panevojshme.

Dërgoja loget sipas planifikuesit, në rast se kishte lidhje, çdo 6 orë: në orën 00:00, 06:00, 12:00 dhe 18:00. Dërgoja në mënyrën e mëposhtme.

from send_email import *
...
message_log = "Loget e testimit të bordit nr.1"
EmailForSend = ["dlinyj@trololo.ru", "pupkin@trololo.ru"]
files = ["/home/khadas/modems_speedtest/csv"]
...
def sendLogs():
	global EmailForSend
	curdata = datetime.now().strftime('%d.%m.%Y')
	curtime = datetime.now().strftime('%H:%M:%S')
	try:
		for addr_to in EmailForSend:
			send_email(addr_to, message_log, "Loget për " + curdata + " " + curtime, files)
	except:
		print("Problemi me rrjetin për dërgimin e emailit")
		return False
	return True

Gabimet gjithashtu u dërguan fillimisht. Në fillim ato u grumbulluan në një listë dhe pastaj u dërguan gjithashtu me ndihmën e planifikuesit, në rast se kishte lidhje. Megjithatë, më vonë erdhën probleme me faktin se Yandex ka një kufizim në numrin e mesazheve që mund të dërgohen në ditë (kjo është një dhimbje, pikëllim dhe poshtërim). Duke qenë se gabimet mund të ishin shumë në minutë, u detyruam të heqim dorë nga dërgimi i gabimeve në email. Prandaj, kini parasysh këtë problem gjatë dërgimit automatik përmes shërbimeve të Yandex.

Serveri i reagimit

Për të pasur qasje në harduerin e largët dhe për të pasur mundësinë për ta rregulluar dhe konfiguruar përsëri, më nevojitej një server i jashtëm. Në të vërtetë, për të qenë të sinqertë, do të ishte më mirë të dërgoheshin të dhënat në server dhe në ndërfaqen web të ngriheshin grafika të bukura. Por jo gjithçka mund të bëhet menjëherë.

Për si një VPS, zgjodha ruvds.com. Do të mund të merrja serverin më të thjeshtë. Dhe në përgjithësi për qëllimet e mia, kjo do të ishte mjaft e mjaftueshme. Por duke qenë se paguaja për serverin, vendosa të merrja një pak më shumë, nëse do të nisja një ndërfaqe web, server SMTP, VPN etj. Plus, të kem mundësi të konfiguroj një bot Telegram dhe të mos kam probleme me bllokimet e tij. Prandaj zgjodha Amsterdam dhe parametrat e mëposhtëm.

Si një mënyrë lidhjeje me harduerin vim2, zgjodha lidhjen e kthyer SSH dhe siç e tregoi praktika — nuk është mënyra më e mirë. Kur lidhja ndërpritet, serveri mban portin dhe nuk është e mundur të lidhem për një kohë. Prandaj, është më mirë të përdoren mënyra të tjera lidhjeje, siç është VPN. Në të ardhmen doja të kaloja në VPN, por nuk pata kohë.

Nuk do të shpjepqem në detajet e konfigurimit të firewall, kufizimeve të të drejtave, çaktivizimit të lidhjes SSH për root dhe të tjera rregulla të zakonshme për konfigurimin e VPS. Shpresoj se ju të gjithë e dini këtë. Për lidhjen e largët, krijoj një përdorues të ri në server.

adduser vimssh

Në harduerin tonë, gjeneroj çelësat e lidhjes SSH.

ssh-keygen

Dhe i kopjoj ato në serverin tonë.

ssh-copy-id vimssh@host.com

Në harduerin tonë krijoj lidhje automatike të kthyer SSH sa herë që ngarkohet.

[Unit]
Përshkrimi=Auto Reverse SSH
Kërkon=systemd-networkd-wait-online.service
Pas=systemd-networkd-wait-online.service
[Service]
Përdoruesi=khadas
ExecStart=/usr/bin/ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -CD 8080 -R 8083:localhost:22 vimssh@host.com
RestartSec=5
Rifillimi=always
[Install]
WantedBy=multi-user.target

Kujdesi me portin 8083: ai përcakton me cilin port do të lidhem përmes SSH të kthyer. Shtojmë këtë në autoload dhe e nisim.

sudo systemctl enable autossh.service
sudo systemctl start autossh.service

Madje mund të shikoni statusin:

sudo systemctl status autossh.service

Tani, në serverin tonë VPS, nëse ekzekutoj:

ssh -p 8083 khadas@localhost

Atëherë arrij në harduerin tim testues. Dhe nga hardueri mund të dërgoj gjithashtu logjet dhe çdo të dhëna në serverin tim përmes SSH, që është shumë e përshtatshme.

Mbledhim gjithçka së bashku

Nisja, fillojmë zhvillimin dhe debugimin

Ah, siç duket, e përshkrova të gjitha nodet. Tani ka ardhur koha të mbledhim gjithçka në një vend. Kodin mund ta shihni këtu.

Një moment i rëndësishëm me kodin: Ky projekt nuk do të funksionojë ashtu direkt, pasi është i përshtatur për një detyrë të caktuar me një arkitekturë të caktuar. Edhe pse po i jap burimet, pjesa më e vlefshme do ta shpjegoj këtu, drejtpërdrejt në tekst, përndryshe nuk do të kuptohet fare.

Në fillim kam inicuese GPS, GPIO dhe nisjen e një thread-i të veçantë për planifikuesin.

#запуск потока планировщика
pShedulerThread = threading.Thread(target=ShedulerThread, args=(1,))
pShedulerThread.start()

Planifikuesi është mjaft i thjeshtë: ai kontrollon nëse ka ardhur koha për dërgimin e mesazheve dhe cila është për momentin statusi i gabimeve. Nëse ka një flamur gabimi, ndriçojmë LED-in.

#sheduler
def ShedulerThread(name):
	global ready_to_send
	while True:
		d = datetime.today()
		time_x = d.strftime('%H:%M')
		if time_x in time_send_csv:
			ready_to_send = True
		if error_status:
			error_blink()
		else:
			good_blink()
		time.sleep(1)

Pika më e vështirë në këtë projekt është ruajtja e lidhjes së kthyer SSH gjatë çdo testi. Gjatë çdo testi, vendoset përsëri gateway-i i paracaktuar dhe serveri DNS. Duke qenë se askush nuk e lexon, mbani mend se treni nuk kalon mbi shinat e drurit. Kush e gjen një 'surprise', do të ketë një ëmbëlsirë.

Për këtë, krijoj një tabelë të veçantë të rutes —set-mark 0x2 dhe një rregull për redirektimin e trafikut.

def InitRouteForSSH():
	cmd_run("sudo iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 22 -j MARK --set-mark 0x2")
	cmd_run("sudo ip rule add fwmark 0x2/0x2 lookup 102")

Më shumë rreth mënyrës se si funksionon mund të lexohet në këtë artikull.

Pas kësaj, kaloj në një cikël të pafund, ku çdo herë merr lista e modemeve të lidhur (për të kuptuar nëse konfigurimi i rrjetit ka ndryshuar).

network_list = getNetworklist()

Marrja e listës së ndërfaqeve rrjet është mjaft e thjeshtë.

def getNetworklist():
	full_networklist = os.listdir('/sys/class/net/')
	network_list = [x for x in full_networklist if "eth" in x and x != "eth0"]
	return network_list

Pas marrjes së listës, vendos IP adresat për të gjitha ndërfaqet, siç ia përmenda në figurën në kapitullin për modem.

SetIpAllNetwork(network_list)

def SetIpAllNetwork(network_list):
	for iface in network_list:
		lastip = "%d" % (3 + network_list.index(iface))
		cmd_run ("sudo ifconfig " + iface + " 192.168.8." + lastip +" up")

Pastaj thjesht në një cikël kaloj nëpër çdo ndërfaqe. Dhe konfiguroni çdo ndërfaqe.

	for iface in network_list:
		ConfigNetwork(iface)

def ConfigNetwork(iface):
# Riset të gjitha konfigurimet
		cmd_run("sudo ip route flush all")
# Caktoji derën për default
		cmd_run("sudo route add default gw 192.168.8.1 " + iface)
# cakto dns-server (kjo është e nevojshme për funksionimin e speedtest)
		cmd_run ("sudo bash -c 'echo nameserver 8.8.8.8 > /etc/resolv.conf'")

Po kontrolloj interfacin për funksionim; nëse nuk ka rrjet, formoj gabimet. Nëse ka rrjet, është koha për të vepruar!

Këtu po konfiguroni rrjetin ssh për këtë interfacing (nëse nuk është bërë), dërgoj gabimet në server, dhe nëse koha ka arritur, dërgoj regjistrat dhe në fund bëj speedtest dhe ruaj regjistrat në një skedar csv.

if not NetworkAvalible():
....
# Këtu formojmë gabimet
....
else: # Ka rrjet, yay, punojmë!
# Nëse kemi një interfacing problematik ku është ssh, atëherë e ndryshojmë
  if (sshint == lastbanint or sshint =="free"):
    print("********** Konfiguro SSH ********************")
    if sshint !="free":
      cmd_run("sudo ip route del default via 192.168.8.1 dev " + sshint +" table 102")
    SetupReverseSSH(iface)
    sshint = iface
#Pasi që rrjeti po punon, le të dërgojmë gjithçka urgjentisht!!!
    if ready_to_send:
      print ("**** Gati për të dërguar!!!")
        if sendLogs():
          ready_to_send = False
        if error_status:
          SendErrors()
#dhe pastaj testojmë shpejtësinë dhe ruajmë regjistrat. 

Veç kësaj, duhet të them diçka për funksionin e konfigurimit të ssh të kundërt.

def SetupReverseSSH(iface):
	cmd_run("sudo systemctl stop autossh.service")
	cmd_run("sudo ip route add default via 192.168.8.1 dev " + iface +" table 102")
	cmd_run("sudo systemctl start autossh.service")

Natyrisht, gjithashtu, duhet ta shtoj këtë bukuri në ngarkimin automatik. Prandaj krijoj një skedar:

sudo vim /etc/systemd/system/modems_speedtest.service

Dhe e regjistroj në të:

[Unit]
Përshkrimi=Testi i Shpejtësisë së Modemit
Kërkon=systemd-networkd-wait-online.service
Pas=systemd-networkd-wait-online.service
[Service]
Përdoruesi=khadas
ExecStart=/usr/bin/python3.6 /home/khadas/modems_speedtest/networks.py
RestartSec=5
Rifillimi=always
[Install]
WantedBy=multi-user.target

Aktivizoj ngarkimin automatik dhe e nisim!

sudo systemctl enable modems_speedtest.service
sudo systemctl start modems_speedtest.service

Tani mund të shoh regjistrat e asaj që po ndodh përmes komandës:

journalctl -u modems_speedtest.service --no-pager -f

Rezultatet

Prandaj, tani është e rëndësishme të dimë se çfarë rezultati arritëm? Do të përmend disa grafika që arrita të kap në procesin e zhvillimit dhe rregullimit. Grafikat u ndërtuan me gnuplot nëpërmjet këtij skripti.

#! /usr/bin/gnuplot -persist
set terminal postscript eps enhanced color solid
set output "Rostelecom.ps"
 
#set terminal png size 1024, 768
#set output "Rostelecom.png"
 
set datafile separator ';'
set grid xtics ytics
set xdata time
set ylabel "Speed Mb/s"
set xlabel 'Time'
set timefmt '%d.%m.%Y;%H:%M:%S'
set title "Rostelecom Speed"

plot "Rostelecom.csv" using 3:6 with lines title "Download", '' using 3:7 with lines title "Upload"
 
set title "Rostelecom 2 Ping"
set ylabel "Ping ms"
plot "Rostelecom.csv" using 3:8 with lines title "Ping"

Eksperienca e parë ishte me operatorin Tele2, të cilën e zhvillova për disa ditë.

Këtu përdora një server matës dinamik. Matjet e shpejtësisë funksionojnë, por luhaten shumë, megjithatë ka një mesatare të dukshme, dhe ajo mund të merret duke bërë filtrimin e të dhënave, për shembull, mesatarja lëvizëse.

Më vonë ndërtova një seri grafikesh për operatorë të tjerë të komunikimit. Serveri i testimit në këtë rast ishte një, dhe rezultatet gjithashtu ishin shumë interesante.

Siç duket, tema është shumë e gjerë për kërkime dhe përpunimin e këtyre të dhënave dhe qartë nuk komandohet në disa javë punë. Por...

Përfundimi i punës

Puna u ndal papritur për shkak të rrethanave jashtë kontrollit tim. Një nga dobësitë e këtij projekti, sipas mendimit tim subjektiv, ishte modemi që nuk dëshironte të punonte në të njëjtën kohë me modeme të tjera, dhe me çdo ngarkim bëri kaq shumë truk shtëpiake. Për këto qëllime ekziston një mori modeli të tjerë që zakonisht kanë format Mini PCI-e dhe vendosen brenda pajisjes, dhe është shumë më e lehtë t'i konfigurosh. Por kjo është një histori krejt tjetër. Projekti ishte interesant dhe isha shumë i lumtur që arrita të merrja pjesë.

Burimi: habr.com