🥇Gelyktydige spoedtoets op verskeie LTE-modems

In kwarantyn is ek aangebied om deel te neem aan die ontwikkeling van 'n toestel om die spoed van LTE-modems vir verskeie selfoonoperateurs te meet.

Die kliënt wou die spoed van verskeie telekommunikasie-operateurs in verskillende geografiese liggings evalueer om te kan verstaan watter selfoonoperateur die mees optimale vir hom is wanneer toerusting met behulp van 'n LTE-verbinding geïnstalleer word, byvoorbeeld vir video-uitsendings. Terselfdertyd moes die taak so eenvoudig en goedkoop moontlik opgelos word, sonder duur toerusting.

Ek moet dadelik sê dat die taak nie die maklikste en mees wetenskap-intensiewe is nie, ek sal jou vertel watter probleme ek teëgekom het en hoe ek dit opgelos het. So kom ons gaan.

Let daarop

Om die spoed van 'n LTE-verbinding te meet is 'n baie ingewikkelde saak: dit is nodig om die regte toerusting en meetmetodologie te kies, asook om 'n goeie begrip te hê van die topologie en werking van die sellulêre netwerk. Boonop kan verskeie faktore die spoed beïnvloed: die aantal intekenare per sel, weerstoestande, selfs van sel tot sel, die spoed kan dramaties verskil as gevolg van die netwerktopologie. Oor die algemeen is dit 'n probleem met 'n groot aantal onbekendes, en slegs 'n telekommunikasie-operateur kan dit korrek oplos.

Aanvanklik wou die kliënt bloot 'n koerier met operateurs se fone bestuur, metings direk op die foon neem en dan die resultate van spoedmetings in 'n notaboek neerskryf. My oplossing om die spoed van lte-netwerke te meet, hoewel nie ideaal nie, maar los die probleem op.

Weens 'n gebrek aan tyd het ek besluite geneem nie ten gunste van gerief of praktiese toepassing nie, maar ten gunste van spoed van ontwikkeling. Byvoorbeeld, omgekeerde ssh is verhoog vir afstandtoegang, in plaas van die meer praktiese vpn, om tyd te bespaar met die opstel van die bediener en elke individuele kliënt.

Tegniese taak

Soos in die artikel staan Sonder TK: hoekom wil die kliënt dit nie hê nie: Moenie sonder TK werk nie! Nooit, nêrens nie!

Die verwysingsbepalings was redelik eenvoudig, ek sal dit 'n bietjie uitbrei vir die begrip van die eindgebruiker. Die keuse van tegniese oplossings en toerusting is deur die kliënt bepaal. Dus, die TK self, na al die goedkeurings:

Gebaseer op 'n enkelbord rekenaar vim2 maak lte verbindingspoedtoetser via H-modemsuawei e3372h-153 verskeie telekommunikasie-operateurs (van een tot n). Dit is ook nodig om koördinate te ontvang vanaf 'n GPS-ontvanger wat via UART gekoppel is. Spoedmetings wat met die diens gedoen moet word www.spoedtoets.net en plaas dit in 'n tabel soos hierdie:

Tabel in csv-formaat. Stuur dan hierdie teken elke 6 uur per e-pos. In die geval van foute, flikker die LED wat aan die GPIO gekoppel is.

Ek het die TK in vrye vorm beskryf, na baie goedkeurings. Maar die betekenis van die taak is reeds sigbaar. Die spertyd vir alles oor alles is 'n week gegee. Maar in werklikheid het dit vir drie weke uitgerek. Dit is in die lig van die feit dat ek dit eers na die hoofwerk en oor naweke gedoen het.

Hier wil ek weereens u aandag daarop vestig dat die kliënt vooraf ingestem het om die spoedmetingsdiens en hardeware te gebruik, wat my vermoëns erg beperk het. Die begroting was ook beperk, so niks spesiaals is aangekoop nie. So ek moes volgens daardie reëls speel.

Argitektuur en ontwikkeling

Die skema is eenvoudig en voor die hand liggend. So ek los dit sonder veel kommentaar.

Ek het besluit om die hele projek in python te implementeer, ten spyte van die feit dat ek glad nie ontwikkelingservaring in hierdie taal gehad het nie. Ek het dit gekies omdat daar baie klaargemaakte voorbeelde en oplossings was wat ontwikkeling kon versnel. Daarom vra ek alle professionele programmeerders om nie my eerste ontwikkelingservaring in luislang te skel nie, en ek is altyd bly om opbouende kritiek te hoor om my vaardigheid te verbeter.

Ek het ook in die proses ontdek dat python twee lopende weergawes 2 en 3 het, en gevolglik het ek op die derde een besluit.

Hardeware nodusse

vim2 enkelbord

As die hoofmasjien het ek 'n enkelbetaler gekry vim2

'n Uitstekende, kragtige media-kombinasie vir 'n slimhuis en SMART-TV, maar uiters ongeskik vir hierdie taak, of, kom ons sê, swak geskik. Byvoorbeeld, sy hoofbedryfstelsel is Android, en Linux is 'n metgesel-bedryfstelsel, en gevolglik waarborg niemand die kwaliteitwerk van alle nodusse en drywers onder Linux nie. En ek neem aan dat sommige van die probleme verband hou met die USB-bestuurders van hierdie platform, so die modems het nie soos verwag op hierdie bord gewerk nie. Dit het ook baie swak en verspreide dokumentasie, so elke operasie het baie tyd geneem om deur die dokke te grawe. Selfs gewone werk met GPIO het baie bloed gedrink. Dit het my byvoorbeeld etlike ure geneem om die werk met die LED op te stel. Maar om objektief te wees, maak dit in beginsel nie saak watter soort enkelbord nie, die belangrikste ding was dat dit werk en daar was USB-poorte.

Eerstens moet ek Linux op hierdie bord installeer. Om nie almal deur die oerwoud van dokumentasie te skuur nie, asook vir diegene wat met hierdie enkelbetaler te doen sal kry, skryf ek hierdie hoofstuk.

Daar is twee opsies om Linux te installeer: op 'n eksterne SD-kaart, of op 'n interne MMC. Ek het saans met die kaart gesukkel, en nie 'n voorsmakie gekry van hoe om dit te laat werk nie, so ek het besluit om dit op MMC te installeer, hoewel dit sonder twyfel baie makliker sou wees om met 'n eksterne kaart te werk.

Oor firmware sleg vertel hier. Ek vertaal van vreemd in Russies. Om die bord te flits, moet ek 'n hardeware UART koppel. Het dit ingeprop op die volgende manier.

Tool Pin GND: <—> Pin17 van VIMs se GPIO
Tool Pin TXD: <—> Pin18 van VIMs se GPIO (Linux_Rx)
Tool Pin RXD: <—> Pin19 van VIMs se GPIO (Linux_Tx)
Tool Pin VCC: <—> Pin20 van VIMs se GPIO

Daarna het ek die firmware afgelaai vandaar. Spesifieke firmware weergawe VIM1_Ubuntu-bediener-bionic_Linux-4.9_arm64_EMMC_V20191231.

Om hierdie firmware in te vul, het ek nutsprogramme nodig. Meer besonderhede hieroor hier. Ek het nie probeer om dit onder Windows te flits nie, maar ek moet 'n paar woorde oor firmware onder Linux sê. Om mee te begin, sal ek die nutsprogramme installeer, volgens die instruksies.

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

Eee... Niks werk nie. Ek het 'n paar uur spandeer om die installasie skrifte te redigeer sodat alles korrek vir my geïnstalleer is. Ek onthou nie wat ek daar gedoen het nie, maar dit is ook daardie sirkus met perde. Wees dus versigtig. Maar sonder hierdie nutsprogramme is dit geen sin om vim2 verder te torring nie. Dit is beter om glad nie met hom te mors nie!

Na sewe sirkels van hel, skrifkonfigurasie en installering, het ek 'n pakket werkende nutsprogramme gekry. Ek het die bord via USB aan my Linux-rekenaar gekoppel, en die UART is ook volgens die diagram hierbo gekoppel.
Ek stel my gunsteling minicom-terminale op baud rate 115200, sonder hardeware of sagteware foutbeheer. En kom ons begin.

Wanneer ek VIM2 in die UART-terminaal laai, druk ek enige sleutel, soos spasie, om die aflaai te stop. Nadat die lyn verskyn het

kvim2#

Ek voer die opdrag in:

kvim2# run update

Op die gasheer waarvandaan ons laai, voer ek uit:

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

Alles, sjoe. Ek het gevra, daar is Linux op die bord. Aanmelding/wagwoord khadas:khadas.

Daarna, klein aanvanklike instellings. Vir verdere werk deaktiveer ek die wagwoord vir sudo (ja, nie veilig nie, maar gerieflik).

sudo visudo

Ek redigeer die reël na die aansig en stoor

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

Dan verander ek die huidige plek sodat die tyd in Moskou is, anders sal dit in Greenwich Mean Time wees.

sudo timedatectl set-timezone Europe/Moscow

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

As dit vir jou moeilik gelyk het, gebruik dan nie hierdie bord nie, Raspberry Pi is beter. Eerlik.

Modem Huawei e3372h - 153

Hierdie modem het veral my bloed gedrink, en dit het eintlik die bottelnek van die hele projek geword. Oor die algemeen weerspieël die naam "modem" vir hierdie toestelle glad nie die essensie van die werk nie: dit is 'n kragtige kombinasie, hierdie stuk yster het 'n saamgestelde toestel wat voorgee om 'n CD-ROM te wees om drywers te installeer, en gaan dan na netwerkkaartmodus.

Argitektonies, uit die oogpunt van 'n Linux-gebruiker na al die instellings, lyk dit soos volg: nadat ek die modem gekoppel het, het ek 'n eth*-netwerkkoppelvlak, wat die ip-adres 192.168.8.100 via dhcp ontvang, en die verstekpoort is 192.168.8.1.

En die belangrikste oomblik! Hierdie modemmodel weet nie hoe om in die modus van die modem te werk nie, wat deur AT-opdragte beheer word. Alles sou baie eenvoudiger wees, skep ppp-verbindings vir elke modem en werk dan daarmee. Maar in my geval skep "homself" (meer presies, 'n Linux-duiker volgens udev-reëls), 'n eth-koppelvlak en ken 'n IP-adres daaraan toe via dhcp.

Om nie verder deurmekaar te raak nie, stel ek voor om die woord "modem" te vergeet en te sê netwerkkaart en poort, want eintlik is dit soos om 'n nuwe netwerkkaart met 'n poort te koppel.
Wanneer daar een modem is, veroorsaak dit geen spesifieke probleme nie, maar wanneer daar meer as een is, naamlik n-stukke, dan verskyn die volgende netwerkprentjie.

Dit is n NIC's, met dieselfde IP-adres, elk met dieselfde verstekpoort. Maar in werklikheid is elkeen van hulle gekoppel aan sy eie operateur.

Aanvanklik het ek 'n eenvoudige oplossing gehad: gebruik die ifconfig- of ip-opdrag om alle koppelvlakke af te skakel en skakel net een om die beurt aan en toets dit. Die besluit was alles goed, behalwe dat ek op die oomblikke van oorskakeling nie aan die toestel kon koppel nie. En aangesien die oorskakeling gereeld en vinnig is, het ek eintlik glad nie die geleentheid gehad om aan te sluit nie.

Daarom het ek die pad gekies om die ip-adresse van die modems "handmatig" te verander en voort te gaan om verkeer te bestuur deur die roete-instellings te gebruik.

My probleme met modems het nie daar geëindig nie: in die geval van kragprobleme het hulle afgeval, ek het 'n goeie stabiele kragtoevoer vanaf die USB-hub nodig. Hierdie probleem is opgelos deur die krag direk aan die spilpunt hard te soldeer. Nog 'n probleem wat ek teëgekom het en wat die hele projek verwoes het: na 'n herlaai of 'n koue begin van die toestel, is nie alle modems opgespoor nie en nie altyd nie, en hoekom dit gebeur het en met watter algoritme ek nie kon installeer nie. Maar eerste dinge eerste.

Vir die modem om reg te werk, het ek die usb-modeswitch-pakket geïnstalleer.

sudo apt update
sudo apt install -y usb-modeswitch

Daarna sal die modem na verbinding korrek opgespoor en gekonfigureer word deur die udev-substelsel. Ek kyk deur bloot die modem te koppel en seker te maak dat die netwerk verskyn het.
Nog 'n probleem wat ek nie kon oplos nie: hoe om die naam van die operateur waarmee ons werk vanaf hierdie modem te kry? Die operateur se naam is vervat in die modem se webkoppelvlak by 192.168.8.1. Dit is 'n dinamiese webblad wat data deur ajax-versoeke ontvang, so net wget-druk die bladsy en ontleed die naam sal nie werk nie. Ek het dus begin kyk hoe om 'n webblad, ens. uit te werk, en besef dat ek een of ander nonsens doen. As gevolg hiervan het hy gespoeg, en die operateur het begin ontvang deur die API van Speedtest self te gebruik.

Dit sou baie makliker wees as die modem toegang het via AT-opdragte. Dit sou moontlik wees om dit te herkonfigureer, 'n ppp-verbinding te skep, 'n IP toe te wys, 'n diensverskaffer te kry, ens. Maar helaas, ek werk met wat hulle vir my gegee het.

GPS

Die GPS-ontvanger wat hulle vir my gegee het, het 'n UART-koppelvlak en krag gehad. Dit was nie die beste besluit nie, maar tog werkend en eenvoudig. Die ontvanger het so gelyk.

Om eerlik te wees, was dit die eerste keer dat ek met 'n GPS-ontvanger gewerk het, maar soos ek verwag het, is alles lankal vir ons uitgevind. Ons gebruik dus net klaargemaakte oplossings.

Eerstens skakel ek uart_AO_B (UART_RX_AO_B, UART_TX_AO_B) aan om GPS te koppel.

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

Nadat ek die sukses van die operasie nagegaan het.

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

Hierdie opdrag wysig blykbaar die devtree op die vlieg, wat baie gerieflik is.

Na die sukses van hierdie operasie, herlaai en installeer die gps daemon.

khadas@Khadas:~$ sudo reboot

Die installering van die gps daemon. Ek installeer alles en sny dit dadelik af vir verdere konfigurasie.

sudo apt install gpsd gpsd-clients -y
sudo killall gpsd
 
/* GPS daemon stop/disable */
sudo systemctl stop gpsd.socket
sudo systemctl disable gpsd.socket

Redigeer die instellingslêer.

sudo vim /etc/default/gpsd

Ek installeer UART, waaraan GPS sal hang.

DEVICES="/dev/ttyS4"

En dan skakel ons alles aan en begin.

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

Daarna koppel ek die GPS.

In die hande van die GPS-draad is die UART-ontfouterdrade onder die vingers sigbaar.

Ek herlaai en kontroleer die GPS met die gpsmon-program.

Daar is geen satelliete in hierdie kiekie nie, maar kommunikasie met die GPS-ontvanger is sigbaar, en dit sê dat alles in orde is.

In python het ek baie opsies probeer om met hierdie daemon te werk, maar ek het besluit op die een wat reg gewerk het met python 3.

Ek installeer die vereiste biblioteek.

sudo -H pip3 install gps3

En ek beeld die werkkode uit.

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("Ошибка GPS приемника!!!")
			return "NA", "NA"
		time.sleep(1.0)
...
f __name__ == '__main__':
...
	#gps
	agps_thread = AGPS3mechanism()  # Instantiate AGPS3 Mechanisms
	agps_thread.stream_data()  # From localhost (), or other hosts, by example, (host='gps.ddns.net')
	agps_thread.run_thread()  # Throttle time to sleep after an empty lookup, default '()' 0.2 two tenths of a second

As ek die koördinate moet kry, word dit gedoen deur die volgende oproep:

longitude, latitude = getPositionData(agps_thread)

En binne 1-10 sekondes sal ek of die koördinaat kry of nie. Ja, ek het tien pogings gehad om die koördinate te kry. Nie optimaal nie, skeef en skeef, maar dit werk. Ek het besluit om dit te doen, want GPS kan sleg vang en nie altyd data ontvang nie. As jy wag dat data ontvang word, sal die program op hierdie plek hang in die geval van werk in 'n afgeleë kamer. Daarom geïmplementeer so nie elegante variant.

In beginsel sou daar meer tyd wees, dit sou moontlik wees om data vanaf GPS direk via UART te ontvang, dit in 'n aparte draad te ontleed en daarmee te werk. Maar daar was glad nie tyd nie, vandaar die kwaai lelike kode. En ja, ek is nie skaam nie.

ligemissiediode

Met die aansluiting van die LED was alles eenvoudig en moeilik op dieselfde tyd. Die grootste probleem is dat die pennommer in die stelsel nie ooreenstem met die pennommer op die bord nie en omdat die dokumentasie met 'n linkerhak geskryf is. Om die hardeware-pennommer en die pennommer in die bedryfstelsel te pas, moet jy die opdrag uitvoer:

gpio readall

'n Pen-korrespondensietabel sal in die stelsel en op die bord vertoon word. Daarna kan ek reeds met 'n pen in die OS self werk. In my geval is die LED gekoppel aan GPIOH_5.

Ek sit die GPIO-pen in uitsetmodus.

gpio -g mode 421 out

Ek skryf nul.

gpio -g write 421 0

Ek skryf die eenheid neer.

gpio -g write 421 1

Alles is verlig nadat "1" geskryf is

#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)

Nou, in geval van foute, bel ek error_blink () en die LED flikker pragtig vir ons.

Sagteware nodusse

Spoedtoets API

Dit is 'n groot vreugde dat die speedtest.net-diens sy eie python-API het, jy kan kyk na GitHub.

Die goeie ding is dat daar bronkodes is wat ook bekyk kan word. Hoe om met hierdie API te werk (die eenvoudigste voorbeelde) kan gevind word in relevante afdeling.

Ek installeer die python-biblioteek met die volgende opdrag.

sudo -H pip3 install speedtest-cli

Byvoorbeeld, jy kan gewoonlik 'n spoedtoetser direk vanaf die rap in Ubuntu installeer. Dit is dieselfde python-toepassing, wat dan direk vanaf die konsole uitgevoer kan word.

sudo apt install speedtest-cli -y

En meet jou internetspoed.

speedtest-cli Retrieving speedtest.net configuration... Testing from B***** (*.*.*.*)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by MTS (Moscow) [0.12 km]: 11.8 ms Testing download speed................................................................................ Download: 7.10 Mbit/s Testing upload speed...................................................................................................... Upload: 3.86 Mbit/s

As gevolg hiervan, hoe ek dit gedoen het. Ek moes in die bronkodes van hierdie spoedtoets delf om dit meer volledig in my projek te implementeer. Een van die belangrikste take is om die naam van die telekommunikasie-operateur te kry om dit in die bord te vervang.

import speedtest
from datetime import datetime
...
#Указываем конкретный сервер для теста
#6053) MaximaTelecom (Moscow, Russian Federation)
servers = ["6053"]
# If you want to use a single threaded test
threads = None
s = speedtest.Speedtest()
#получаем имя оператора сотовой связи
opos = '%(isp)s' % s.config['client']
s.get_servers(servers)
#получаем текстовую строку с параметрами сервера
testserver = '%(sponsor)s (%(name)s) [%(d)0.2f km]: %(latency)s ms' % s.results.server
#тест загрузки
s.download(threads=threads)
#тест выгрузки
s.upload(threads=threads)
#получаем результаты
s.results.share()

#После чего формируется строка для записи в csv-файл.
#получаем позицию GPS
longitude, latitude = getPositionData(agps_thread)
#время и дата
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"
#тут идет запись в файл логов

Ook hier het alles geblyk nie so eenvoudig te wees nie, alhoewel dit baie makliker sou lyk. Aanvanklik was die bedienerparameter gelyk aan []Kies asseblief die beste bediener. Gevolglik het ek ewekansige bedieners gehad, en, soos jy dalk kan raai, drywende spoed. Dit is 'n taamlik komplekse onderwerp, die gebruik van 'n vaste bediener, indien wel, staties of dinamies, vereis navorsing. Maar hier is 'n voorbeeld van grafieke om die spoed van die Beeline-operateur te meet met 'n dinamiese keuse van 'n toetsbediener en 'n staties vaste een.

Spoedmetingsresultaat wanneer dinamiese bediener gekies word.

Die resultaat van spoedtoetsing, met een streng geselekteerde een bediener.

"Wol" tydens toetsing is hier en daar, en dit moet met wiskundige metodes verwyder word. Maar met 'n vaste bediener is dit effens minder en die amplitude is meer stabiel.
Oor die algemeen is dit 'n plek van groot navorsing. En ek sou spoedmetings na my bediener neem met die iperf-nutsding. Maar ons hou by TK.

Stuur pos en foute

Om pos te stuur, het ek 'n paar dosyn verskillende opsies probeer, maar as gevolg daarvan het ek op die volgende besluit. Ek het 'n posbus op yandex geregistreer en toe geneem hierdie voorbeeld van die stuur van pos. Ek het dit nagegaan en in die program geïmplementeer. Hierdie voorbeeld ondersoek verskeie opsies, insluitend stuur vanaf gmail, ens. Ek wou nie mors met die verhoging van my posbediener nie en het nie tyd daarvoor gehad nie, maar soos dit later geblyk het, was dit ook tevergeefs.

Logs is gestuur volgens die skeduleerder, as daar 'n verband is, elke 6 uur: om 00 uur, 06:12, 18:XNUMX en XNUMX:XNUMX. Gestuur soos volg.

from send_email import *
...
message_log = "Логи тестирования платы №1"
EmailForSend = ["[email protected]", "[email protected]"]
files = ["/home/khadas/modems_speedtest/csv"]
...
def sendLogs():
	global EmailForSend
	curdata = datetime.now().strftime('%d.%m.%Y')
	сurtime = datetime.now().strftime('%H:%M:%S')
	try:
		for addr_to in EmailForSend:
			send_email(addr_to, message_log, "Логи за " + curdata + " " + сurtime, files)
	except:
		print("Network problem for send mail")
		return False
	return True

Foute is ook aanvanklik gestuur. Om mee te begin, is hulle in die lys opgehoop, en dan ook met die skeduleerder gestuur, as daar 'n verbinding was. Daar was egter probleme met die feit dat yandex 'n beperking het op die aantal boodskappe wat per dag gestuur word (dit is pyn, hartseer en vernedering). Aangesien daar selfs per minuut 'n groot aantal foute kon wees, was dit nodig om te weier om foute per pos te stuur. Hou dus in gedagte wanneer u outomaties deur Yandex-dienste stuur oor so 'n probleem.

Terugvoerbediener

Om toegang tot 'n afgeleë stuk hardeware te hê en dit te kan konfigureer en herkonfigureer, het ek 'n eksterne bediener nodig gehad. Oor die algemeen, om regverdig te wees, sal dit reg wees om al die data na die bediener te stuur en al die pragtige grafieke in die webkoppelvlak te bou. Maar nie alles op een slag nie.

Ek het gekies as 'n VPS ruvds.com. Dit sou moontlik wees om die eenvoudigste bediener te neem. En in die algemeen, vir my doeleindes, sou dit genoeg wees vir die oë. Maar aangesien ek nie vir die bediener uit my eie sak betaal het nie, het ek besluit om dit met 'n klein marge te neem sodat dit genoeg sou wees as ons 'n webkoppelvlak, ons eie SMTP-bediener, vpn, ens. Plus, om 'n Telegram-bot op te stel en nie probleme met die blokkering daarvan te hê nie. Daarom het ek Amsterdam en die volgende opsies gekies.

Vim2 het die omgekeerde ssh-verbinding gekies as 'n manier om met die hardeware te kommunikeer, en soos die praktyk getoon het, is dit nie die beste nie. Wanneer die verbinding verbreek word, hou die bediener die poort en dit is onmoontlik om vir 'n rukkie daaraan te koppel. Daarom is dit steeds beter om ander kommunikasiemetodes te gebruik, soos vpn. In die toekoms wou ek oorskakel na vpn, maar het nie tyd gehad nie.

Ek sal nie ingaan op die besonderhede van die opstel van 'n firewall, die beperking van regte, die deaktivering van die ssh-verbinding met root, en ander algemene waarhede van die opstel van 'n VPS nie. Ek wil glo dat jy reeds alles weet. Vir 'n afstandverbinding skep ek 'n nuwe gebruiker op die bediener.

adduser vimssh

Op ons stuk yster genereer ek ssh-verbindingsleutels.

ssh-keygen

En ek kopieer hulle na ons bediener.

ssh-copy-id [email protected]

Op ons hardeware skep ek 'n outomatiese omgekeerde ssh-verbinding by elke selflaai.

[Unit] Description=Auto Reverse SSH Requires=systemd-networkd-wait-online.service After=systemd-networkd-wait-online.service [Service] User=khadas ExecStart=/usr/bin/ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -CD 8080 -R 8083:localhost:22 [email protected] RestartSec=5 Restart=always [Install] WantedBy=multi-user.target

Gee aandag aan poort 8083: dit bepaal op watter poort ek via omgekeerde ssh sal koppel. Voeg by outolaai en begin.

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

Jy kan selfs die status sien:

sudo systemctl status autossh.service

Nou, op ons VPS-bediener, as jy hardloop:

ssh -p 8083 khadas@localhost

Dan klim ek op my toetsstuk yster. En vanaf 'n stuk yster kan ek ook logs en enige data via ssh na my bediener stuur, wat baie gerieflik is.

Om dit alles saam te voeg

Skakel aan, begin ontwikkel en ontfout

Sjoe, dit lyk asof alles al die nodusse beskryf het. Nou is dit tyd om alles bymekaar te sit. Jy kan die kode sien hier.

'n Belangrike punt met die kode: Hierdie projek mag dalk nie so begin nie, want dit is opgeskerp vir 'n spesifieke taak, 'n spesifieke argitektuur. Alhoewel ek die bronkode gee, sal ek steeds die waardevolste hier ontleed, reg in die teks, anders is dit heeltemal onverstaanbaar.

Aan die begin begin ek gps, gpio en begin 'n aparte skeduleerderdraad.

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

Die skeduleerder is redelik eenvoudig: dit lyk of die tyd aangebreek het om boodskappe te stuur en wat die foutstatus nou is. As daar 'n foutvlag is, flikker dan die LED.

#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)

Die moeilikste deel van hierdie projek is om die omgekeerde ssh-verbinding lewendig te hou op elke toets. In elke toets word die verstekpoort en dns-bediener herkonfigureer. Aangesien niemand in elk geval lees nie, weet dat die trein nie op houtrelings ry nie. Wie 'n paaseier kry, kry lekkergoed.

Om dit te doen, skep ek 'n aparte roetetabel --set-mark 0x2 en 'n reël om verkeer te herlei.

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")

Jy kan meer leer oor hoe dit werk lees in hierdie artikel.

Daarna gaan ek in 'n oneindige lus in, waar ons elke keer 'n lys van gekoppelde modems kry (om uit te vind of die netwerkkonfigurasie skielik verander het).

network_list = getNetworklist()

Dit is redelik eenvoudig om 'n lys van netwerkkoppelvlakke te kry.

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

Nadat ek die lys ontvang het, het ek die IP-adresse op alle koppelvlakke gestel, soos ek in die prentjie in die modem-hoofstuk gewys het.

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")

Verder eenvoudig in 'n siklus gaan ek op elke koppelvlak. En ek konfigureer elke koppelvlak.

	for iface in network_list:
		ConfigNetwork(iface)

def ConfigNetwork(iface):
#сбрасываем все настройки
		cmd_run("sudo ip route flush all")
#Назначаем шлюз по умолчанию
		cmd_run("sudo route add default gw 192.168.8.1 " + iface)
#задаем dns-сервер (это нужно для работы speedtest)
		cmd_run ("sudo bash -c 'echo nameserver 8.8.8.8 > /etc/resolv.conf'")

Ek kyk na die koppelvlak vir werkbaarheid, as daar geen netwerk is nie, genereer ek foute. As daar 'n netwerk is, dan is dit tyd om op te tree!

Hier stel ek ssh-roetering op na hierdie koppelvlak (indien nie reeds gedoen nie), stuur foute na die bediener as dit tyd is, stuur logs en voer uiteindelik 'n spoedtoets uit en stoor die logs in 'n csv-lêer.

if not NetworkAvalible():
....
#Здесь мы формируем ошибки
....
else: #Есть сеть, ура, работаем!
#Если у нас проблемный интерфейс, на котором ssh, то меняем его
  if (sshint == lastbanint or sshint =="free"):
    print("********** Setup SSH ********************")
    if sshint !="free":
      сmd_run("sudo ip route del default via 192.168.8.1 dev " + sshint +" table 102")
    SetupReverseSSH(iface)
    sshint = iface
#раз сетка работает, то давай срочно все отправим!!!
    if ready_to_send:
      print ("**** Ready to send!!!")
        if sendLogs():
          ready_to_send = False
        if error_status:
          SendErrors()
#и далее тестируем скорость и сохраняем логи.

Tensy dit die moeite werd is om die omgekeerde ssh-konfigurasiefunksie te noem.

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")

En natuurlik moet jy al hierdie skoonheid by outolaai voeg. Om dit te doen, skep ek 'n lêer:

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

En ek skryf daaraan:

[Unit] Description=Modem Speed Test Requires=systemd-networkd-wait-online.service After=systemd-networkd-wait-online.service [Service] User=khadas ExecStart=/usr/bin/python3.6 /home/khadas/modems_speedtest/networks.py RestartSec=5 Restart=always [Install] WantedBy=multi-user.target

Ek skakel outolaai aan en begin!

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

Nou kan ek die logboeke sien van wat met die opdrag gebeur:

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

Bevindinge

Wel, nou die belangrikste ding, wat het as gevolg daarvan gebeur? Hier is 'n paar grafieke wat ek tydens ontwikkeling en ontfouting kon vasvang. Grafieke is gebou met behulp van gnuplot met die volgende skrif.

#! /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"

Die eerste ervaring was die Tele2-operateur, wat ek etlike dae spandeer het.

Hier het ek 'n dinamiese meetbediener gebruik. Spoedmetings werk, maar hulle sweef baie, maar 'n mate van gemiddelde waarde is steeds sigbaar, en dit kan verkry word deur die data te filter, byvoorbeeld deur bewegende gemiddelde.

Later het ek 'n aantal grafieke vir ander telekommunikasie-operateurs gebou. In hierdie geval was daar reeds een toetsbediener, en die resultate is ook baie interessant.

Soos u kan sien, is die onderwerp baie omvangryk vir navorsing en verwerking van hierdie data, en dit trek natuurlik nie vir 'n paar weke se werk nie. Maar …

Uitkoms van werk

Die werk is skielik afgehandel weens omstandighede buite my beheer. Een van die swakpunte van hierdie projek, na my subjektiewe opinie, was die modem, wat nie eintlik gelyktydig met ander modems wou werk nie, en het sulke truuks met elke selflaai gemaak. Vir hierdie doeleindes is daar 'n groot aantal ander modelle van modems, gewoonlik het hulle reeds die Mini PCI-e-formaat en word binne die toestel geplaas en is dit baie makliker om te konfigureer. Maar dit is 'n heeltemal ander storie. Die projek was interessant en ek was baie bly dat ek daaraan kon deelneem.

Bron: will.com

Gelyktydige spoedtoets op verskeie LTE-modems