Egyidejű sebességteszt több LTE modemen

A karantén ideje alatt felajánlották, hogy részt vegyek egy LTE modemek sebességét mérő eszköz fejlesztésében több mobilszolgáltató számára.

Egyidejű sebességteszt több LTE modemen

Az ügyfél fel akarta mérni a különböző földrajzi helyeken működő különböző távközlési szolgáltatók sebességét, hogy megértse, melyik mobilszolgáltató a legoptimálisabb számára, amikor LTE kapcsolatot használó berendezéseket telepít, például videó adásokhoz. Ugyanakkor a problémát a lehető legegyszerűbben és olcsóbban kellett megoldani, drága berendezések nélkül.

Rögtön leszögezem, hogy a feladat nem a legegyszerűbb és a legtöbb tudásigényes, elmondom, milyen problémákkal találkoztam és hogyan oldottam meg azokat. Akkor gyerünk.

Megjegyzés

Az LTE kapcsolat sebességének mérése nagyon összetett dolog: meg kell választani a megfelelő berendezést és mérési technikát, valamint jól ismerni kell a mobilhálózat topológiáját és működését. Ráadásul a sebességet több tényező is befolyásolhatja: az előfizetők száma egy cellán, időjárási viszonyok, a sebesség akár cellánként is drasztikusan változhat a hálózati topológiától függően. Általában ez egy nagy számú ismeretlen probléma, és csak egy távközlési szolgáltató tudja helyesen megoldani.

Kezdetben az ügyfél csak a futárt akarta vezetni a kezelők telefonjaival, közvetlenül a telefonon mérni, majd a sebességmérés eredményeit feljegyezni egy notebookba. Az én megoldásom az lte hálózatok sebességének mérésére, bár nem ideális, de megoldja a problémát.

Időhiány miatt nem a kényelem vagy a praktikusság, hanem a fejlődés gyorsasága mellett döntöttem. Például a fordított ssh-t használták a távoli eléréshez, a praktikusabb VPN helyett, hogy időt takarítsanak meg a szerver és az egyes kliensek beállításánál.

Műszaki feladat

Ahogy a cikkben is szerepel Műszaki adatok nélkül: miért nem akarja az ügyfél: Műszaki előírások nélkül ne dolgozzon! Soha, sehol!

A technikai feladat meglehetősen egyszerű volt, kicsit kibővítem a végfelhasználó megértése érdekében. A műszaki megoldások és felszerelések kiválasztását a megrendelő diktálta. Tehát maga a műszaki specifikáció, minden jóváhagyás után:

Egy fedélzeti számítógépen alapul vim2 készítsen sebességmérőt a H modemen keresztüli lte kapcsolatokhozuawei e3372h - 153 több távközlési szolgáltató (egytől n-ig). Szükség van az UART-on keresztül csatlakoztatott GPS-vevő koordinátáinak vételére is. Végezzen sebességmérést a szolgáltatás segítségével www.speedtest.net és tedd őket egy ilyen táblázatba:

Egyidejű sebességteszt több LTE modemen

Táblázat csv formátumban. Ezután küldje el ezt a jelet e-mailben 6 óránként. Hiba esetén villogjon a GPIO-hoz csatlakoztatott LED.

A műszaki leírást szabad formában, sok jóváhagyás után leírtam. De a feladat értelme már látszik. Egy hét mindenre adott volt. De a valóságban ez három hétig tartott. Ez figyelembe veszi azt a tényt, hogy ezt csak a főállásom után és hétvégén csináltam.

Itt szeretném még egyszer felhívni a figyelmet arra, hogy a megrendelő előre megállapodott a sebességmérő szolgáltatás és hardver igénybevételéről, ami erősen korlátozta a lehetőségeimet. A költségvetés is korlátozott volt, így semmi különöset nem vásároltak. Tehát ezeknek a szabályoknak megfelelően kellett játszanunk.

Építészet és fejlesztés

A séma egyszerű és kézenfekvő. Ezért minden különösebb megjegyzés nélkül hagyom.

Egyidejű sebességteszt több LTE modemen

Úgy döntöttem, hogy a teljes projektet pythonban valósítom meg, annak ellenére, hogy egyáltalán nem volt tapasztalatom ezen a nyelven való fejlesztésben. Azért választottam, mert volt egy csomó kész példa és megoldás, ami felgyorsíthatta a fejlesztést. Ezért arra kérek minden professzionális programozót, hogy ne szidja az első python fejlesztési tapasztalatomat, és mindig örömmel hallom az építő kritikát a képességeim fejlesztésére.

A folyamat során azt is felfedeztem, hogy a pythonnak két futó verziója van, a 2-es és a 3-as, ennek eredményeként a harmadik mellett döntöttem.

Hardver csomópontok

Egylemezes vim2

Főgépemként egy egylapos számítógépet kaptam vim2

Egyidejű sebességteszt több LTE modemen

Kiváló, erős médiaprocesszor okosotthonba és SMART-TV-be, de erre a feladatra rendkívül alkalmatlan, vagy mondjuk rosszul. Például a fő operációs rendszer az Android, a Linux pedig egy másodlagos operációs rendszer, és ennek megfelelően senki sem garantálja az összes csomópont és illesztőprogram kiváló minőségű működését Linux alatt. És feltételezem, hogy a problémák egy része ennek a platformnak az USB-illesztőprogramjaihoz kapcsolódik, így a modemek nem működtek a várt módon ezen az alaplapon. Nagyon szegényes és szétszórt a dokumentációja is, így minden művelet sok időt vett igénybe a dokkokban való kotorászat során. Még a GPIO-val végzett hétköznapi munka is sok vért vett fel. Például több órába telt, amíg beállítottam a LED-et. De, hogy objektív legyek, alapvetően nem volt fontos, hogy milyen egylapos, a lényeg, hogy működjön, és legyenek USB portok.

Először is telepítenem kell a Linuxot erre a táblára. Azért írom ezt a fejezetet, hogy ne mindenki számára kutassam a dokumentáció vadvilágát, és azoknak is, akik ezzel az egytáblás rendszerrel foglalkoznak.

A Linux kétféleképpen telepíthető: külső SD-kártyára vagy belső MMC-re. Egy estét töltöttem azzal, hogy kitaláljam, hogyan lehet a kártyával működni, ezért úgy döntöttem, hogy az MMC-re telepítem, bár kétségtelenül sokkal egyszerűbb lenne egy külső kártyával dolgozni.

A firmware-ről ferdén mondták itt. Furcsa nyelvről fordítok oroszra. Az alaplap felvillantásához csatlakoztatnom kell az UART hardvert. Összekötötte a következő módon.

  • Eszköz Pin GND: <—> VIM-ek GPIO-jának 17. tűje
  • Eszköz Pin TXD: <—> A VIM-ek GPIO-jának 18. érintkezője (Linux_Rx)
  • Eszköz Pin RXD: <—> A VIM-ek GPIO-jának 19. érintkezője (Linux_Tx)
  • Eszköz Pin VCC: <—> VIM-ek GPIO-jának 20. tűje

Egyidejű sebességteszt több LTE modemen

Utána letöltöttem a firmware-t ezért. Konkrét firmware verzió VIM1_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20191231.

A firmware feltöltéséhez segédprogramokra van szükségem. További részletek erről itt. Windows alatt még nem próbáltam flashelni, de mondanom kell néhány szót a firmware-ről Linux alatt. Először telepítem a segédprogramokat az utasításoknak megfelelően.

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

Aaand... Semmi sem működik. Pár órát töltöttem a telepítő szkriptek szerkesztésével, hogy minden megfelelően települjön nekem. Nem emlékszem, mit csináltam ott, de volt az a cirkusz is lovakkal. Szóval légy óvatos. De ezen segédprogramok nélkül nincs értelme tovább kínozni a vim2-t. Jobb, ha egyáltalán nem vacakolsz vele!

A pokol hét köre, a szkriptek konfigurálása és telepítése után kaptam egy csomag működő segédprogramot. A kártyát USB-n keresztül csatlakoztattam a Linuxos számítógépemhez, és az UART-ot is csatlakoztattam a fenti ábra szerint.
A kedvenc minicom terminálomat 115200-as sebességre állítom be, hardveres és szoftveres hibakezelés nélkül. És kezdjük is.

Egyidejű sebességteszt több LTE modemen

A VIM2 UART terminálba való betöltésekor megnyomok egy billentyűt, például a szóközt, hogy leállítsam a betöltést. A vonal megjelenése után

kvim2# 

Beírom a parancsot:

kvim2# run update

Azon a gazdagépen, amelyről betöltünk, végrehajtom:

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

Ennyi, hú. Megnéztem, Linux van az alaplapon. Bejelentkezés/jelszó khadas:khadas.

Ezt követően néhány kisebb kezdeti beállítás. A további munkához letiltom a sudo jelszavát (igen, nem biztonságos, de kényelmes).

sudo visudo

A sort szerkesztem az űrlapra és elmentem

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

Aztán megváltoztatom az aktuális területet, hogy az idő Moszkvában legyen, különben Greenwichben.

sudo timedatectl set-timezone Europe/Moscow

vagy

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

Ha nehéznek találja, akkor ne használja ezt a táblát; a Raspberry Pi jobb. Őszintén.

Modem Huawei e3372h – 153

Ez a modem jelentős vérforrás volt számomra, sőt, ez lett az egész projekt szűk keresztmetszete. Általánosságban elmondható, hogy ezeknek az eszközöknek a „modem” elnevezése egyáltalán nem tükrözi a munka lényegét: ez egy erős kombájn, ez a hardver egy összetett eszközzel rendelkezik, amely CD-ROM-nak adja ki magát az illesztőprogramok telepítéséhez, majd hálózati kártya módba kapcsol.

Építészetileg egy Linux felhasználó szemszögéből minden beállítás után így néz ki: a modem csatlakoztatása után van egy eth* hálózati interfészem, ami dhcp-n keresztül megkapja a 192.168.8.100 IP címet, és az alapértelmezett átjárót. a 192.168.8.1.

És a legfontosabb pillanat! Ez a modemmodell nem működik modem módban, amelyet AT parancsok vezérelnek. Minden sokkal egyszerűbb lenne, minden modemhez hozzon létre PPP kapcsolatokat, majd működjön velük. De az én esetemben „maga” (pontosabban egy Linux búvár az udev szabályai szerint), létrehoz egy eth interfészt és dhcp-n keresztül IP címet rendel hozzá.

A további félreértések elkerülése érdekében azt javaslom, hogy felejtsük el a „modem” szót, és mondjuk a hálózati kártya és az átjáró kifejezést, mert lényegében ez olyan, mintha egy új hálózati kártyát csatlakoztatnánk egy átjáróhoz.
Ha egy modem van, ez nem okoz különösebb problémát, de ha több, nevezetesen n darab, akkor a következő hálózati kép jön létre.

Egyidejű sebességteszt több LTE modemen

Vagyis n hálózati kártya, ugyanazzal az IP-címmel, mindegyik ugyanazzal az alapértelmezett átjáróval. Valójában azonban mindegyik a saját operátorához kapcsolódik.

Kezdetben volt egy egyszerű megoldásom: az ifconfig vagy ip paranccsal kapcsolja ki az összes interfészt, és egyszerűen kapcsolja be az egyiket, és tesztelje. A megoldás mindenkinek jó volt, csakhogy a kapcsolási pillanatokban nem tudtam csatlakozni a készülékhez. És mivel a váltás gyakori és gyors, tulajdonképpen egyáltalán nem volt lehetőségem csatlakozni.

Ezért azt az utat választottam, hogy manuálisan módosítom a modemek IP-címét, majd irányítom a forgalmat az útválasztási beállításokkal.

Egyidejű sebességteszt több LTE modemen

Ezzel még korántsem ért véget a modemekkel kapcsolatos problémáim: áramprobléma esetén leestek, és az USB hub jó stabil tápellátására volt szükség. Ezt a problémát úgy oldottam meg, hogy az áramot közvetlenül a hubhoz keményforrasztottam. Egy másik probléma, amellyel találkoztam, és amely tönkretette az egész projektet: az eszköz újraindítása vagy hidegindítása után nem minden modemet észleltek, és nem mindig, és nem tudtam meghatározni, hogy ez miért történt, és milyen algoritmussal. De először a dolgok.

A modem megfelelő működéséhez telepítettem az usb-modeswitch csomagot.

sudo apt update
sudo apt install -y usb-modeswitch

Ezután a csatlakozás után az udev alrendszer megfelelően észleli és konfigurálja a modemet. Az ellenőrzéshez egyszerűen csatlakoztatom a modemet, és megbizonyosodtam arról, hogy megjelenik-e a hálózat.
Egy másik probléma, amit nem tudtam megoldani: hogyan tudom lekérni a modemről az operátor nevét, akivel dolgozunk? Az operátor nevét a modem webes felülete a 192.168.8.1 címen tartalmazza. Ez egy dinamikus weboldal, amely Ajax kéréseken keresztül fogad adatokat, így az oldal egyszerű wgetelése és a név elemzése nem fog működni. Így hát elkezdtem utánanézni, hogyan lehet weblapot fejleszteni stb., és rájöttem, hogy valami hülyeséget csinálok. Ennek eredményeként kiköpött, és az operátor magával a Speedtest API-val kezdett fogadni.

Sokkal egyszerűbb lenne, ha a modem hozzáférne az AT parancsokon keresztül. Lehetne átkonfigurálni, ppp kapcsolatot létrehozni, IP-t kijelölni, távközlési szolgáltatót szerezni stb. De sajnos azzal dolgozom, amit kaptam.

GPS

A kapott GPS vevő UART interfésszel és táppal rendelkezett. Nem ez volt a legjobb megoldás, de így is működőképes és egyszerű. A kagyló valahogy így nézett ki.

Egyidejű sebességteszt több LTE modemen

Őszintén szólva először dolgoztam GPS-vevővel, de ahogy számítottam rá, már régen mindent kitaláltak nekünk. Tehát csak kész megoldásokat használunk.

Először engedélyezem az uart_AO_B-t (UART_RX_AO_B, UART_TX_AO_B) a GPS csatlakoztatásához.

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

Utána ellenőrzöm a művelet sikerességét.

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

Ez a parancs láthatóan menet közben szerkeszti a devtree-t, ami nagyon kényelmes.

A művelet sikeressége után indítsa újra és telepítse a GPS-démont.

khadas@Khadas:~$ sudo reboot

A GPS démon telepítése. Mindent telepítek és azonnal levágom a további konfigurációhoz.

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

A beállítási fájl szerkesztése.

sudo vim /etc/default/gpsd

Telepítek egy UART-ot, amin lóg a GPS.

DEVICES="/dev/ttyS4"

Aztán mindent bekapcsolunk és elkezdjük.

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

Utána csatlakoztatom a GPS-t.

Egyidejű sebességteszt több LTE modemen

A GPS vezeték a kezemben van, az UART hibakereső vezetékek látszanak az ujjaim alatt.

Újraindítom és ellenőrzöm a GPS működését a gpsmon programmal.

Egyidejű sebességteszt több LTE modemen

Ezen a képernyőképen nem láthatja a műholdakat, de láthatja a kommunikációt a GPS-vevővel, és ez azt jelenti, hogy minden rendben van.

A pythonban számos lehetőséget kipróbáltam, hogy ezzel a démonnal dolgozhassak, de a python 3-mal megfelelően működött.

Telepítem a szükséges könyvtárat.

sudo -H pip3 install gps3 

És kifaragom a munkakódot.

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

Ha koordinátákat kell kérnem, ezt a következő hívással tehetem meg:

longitude, latitude = getPositionData(agps_thread)

És 1-10 másodpercen belül vagy megkapom a koordinátát, vagy nem. Igen, tíz alkalommal próbálkoztam koordináták megszerzésével. Nem optimális, ferde és ferde, de működik. Azért döntöttem így, mert a GPS-nek rossz a vétele, és nem mindig fogad adatokat. Ha vár az adatok fogadására, akkor ha távoli helyiségben dolgozik, a program lefagy ezen a helyen. Ezért megvalósítottam ezt az elegáns lehetőséget.

Elvileg ha több idő lenne, akkor UART-on keresztül közvetlenül lehetne adatokat fogadni a GPS-ről, külön szálban elemezni és dolgozni vele. De egyáltalán nem volt idő, ezért a brutálisan csúnya kód. És igen, nem szégyellem.

Fénykibocsátó dióda

A LED csatlakoztatása egyszerű és nehéz volt egyszerre. A fő nehézség az, hogy a rendszerben lévő PIN-kód nem egyezik meg a táblán lévő PIN-kóddal, és mert a dokumentációt bal kézzel írják. A hardver és az operációs rendszer PIN-kódjának összehasonlításához futtassa a parancsot:

gpio readall

Megjelenik a rendszerben és a táblán lévő gombos megfeleltetés táblázata. Utána már magában az OS-ben tudom működtetni a pint. Az én esetemben a LED csatlakoztatva van GPIOH_5.

Egyidejű sebességteszt több LTE modemen

A GPIO pin-t kimeneti módba kapcsolom.

gpio -g mode 421 out

nullát írok le.

gpio -g write 421 0

Leírok egyet.

gpio -g write 421 1

Egyidejű sebességteszt több LTE modemen
Minden világít az „1” beírása után

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

Most hiba esetén meghívom az error_blink()-et és szépen villog a led.

Szoftver csomópontok

Speedtest API

Nagy öröm, hogy a speedtest.net szolgáltatásnak saját python-API-ja van, meg lehet nézni GitHub.

Az a jó, hogy vannak forráskódok is, amelyeket meg is lehet nézni. Az API-val való munkavégzés módja (egyszerű példák) itt található vonatkozó szakaszt.

A python könyvtárat a következő paranccsal telepítem.

sudo -H pip3 install speedtest-cli

Például akár közvetlenül a szoftverből is telepíthet egy sebességtesztelőt az Ubuntuba. Ez ugyanaz a python alkalmazás, amely ezután közvetlenül a konzolról indítható.

sudo apt install speedtest-cli -y

És mérje meg az internet sebességét.

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

Ennek eredményeként, ahogy én is tettem. Be kellett jutnom ennek a sebességtesztnek a forráskódjaiba, hogy még teljesebben beépítsem őket a projektembe. Az egyik legfontosabb feladat a távközlési szolgáltató nevének beszerzése, hogy behelyettesítsük a táblába.

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"
#тут идет запись в файл логов

Itt is kiderült, hogy nem minden olyan egyszerű, bár sokkal egyszerűbbnek tűnik. Kezdetben a szerverek paramétere egyenlő volt a [], azt mondják, válassza ki a legjobb szervert. Ennek eredményeként véletlenszerű szervereim voltak, és ahogy sejtheti, változó sebességgel. Ez egy meglehetősen összetett téma, fix szerver használata, ha igen, statikus vagy dinamikus, kutatást igényel. De itt van egy példa a sebességmérési grafikonokra a Beeline operátor számára, amikor dinamikusan választ ki egy tesztszervert és egy statikusan rögzített szervert.

Egyidejű sebességteszt több LTE modemen
A sebességmérés eredménye a dinamikus szerver kiválasztásakor.

Egyidejű sebességteszt több LTE modemen
A sebességteszt eredménye, egy szigorúan kiválasztott szerverrel.

A tesztelés során mindkét helyen „bunda” van, amelyet matematikai módszerekkel kell eltávolítani. De egy fix szervernél valamivel kevesebb, és az amplitúdója is stabilabb.
Általában véve ez egy nagyszerű kutatás helye. A szerverem sebességét pedig az iperf segédprogram segítségével mérném. De ragaszkodunk a műszaki előírásokhoz.

Levélküldés és hibák

A levelek küldéséhez több tucat különböző lehetőséget kipróbáltam, de végül a következőre telepedtem. Regisztráltam egy postafiókot a Yandexen, majd vettem Ez egy példa a levélküldésre. Megnéztem és beillesztettem a programba. Ez a példa különféle lehetőségeket vizsgál, beleértve a Gmailből való küldést stb. Nem akartam vesződni a levelezőszerverem beállításával és nem is volt rá időm, de mint később kiderült, ez is hiábavaló volt.

A naplók az ütemező szerint lettek elküldve, ha van kapcsolat, 6 óránként: 00 órakor, 06 órakor, 12 órakor és 18 órakor. A következőképpen küldte el.

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

Eredetileg hibákat is küldtek. Kezdetben felhalmozódtak a listában, majd az ütemezővel is elküldték, ha volt kapcsolat. Ezután azonban problémák merültek fel azzal a ténnyel, hogy a Yandex korlátozza a naponta elküldött üzenetek számát (ez fájdalom, szomorúság és megaláztatás). Mivel akár percenként is rengeteg hiba fordulhat elő, fel kellett hagynunk a hibák postai úton történő küldésével. Ezért ne feledje, amikor automatikusan információt küld egy ilyen problémáról a Yandex szolgáltatásain keresztül.

Visszajelzési szerver

Ahhoz, hogy hozzáférjek egy távoli hardverhez, testreszabhassam és újrakonfigurálhassam, külső szerverre volt szükségem. Általában az igazság kedvéért helyes lenne az összes adatot a szerverre küldeni, és az összes gyönyörű grafikont a webes felületen elkészíteni. De nem egyszerre.

VPS-hez választottam ruvds.com. Elviheti a legegyszerűbb szervert. És általában, az én céljaimra ez elég lenne. De mivel nem a saját zsebemből fizettem a szervert, úgy döntöttem, kis tartalékkal veszem, hogy elég legyen, ha telepítünk webes felületet, saját SMTP szervert, VPN-t stb. Ráadásul beállíthat egy Telegram botot, és nem lesz probléma a blokkolással. Ezért Amszterdamra és a következő paraméterekre esett a választásom.

Egyidejű sebességteszt több LTE modemen

A hardverrel való kommunikáció módjaként a vim2 fordított ssh-kapcsolatot választott, és amint a gyakorlat azt mutatja, ez nem a legjobb. Ha a kapcsolat megszakad, a kiszolgáló tartja a portot, és egy ideig nem lehet csatlakozni rajta. Ezért még mindig jobb más kommunikációs módszereket, például VPN-t használni. A jövőben VPN-re akartam váltani, de nem volt időm.

Nem megyek bele a tűzfal beállításának, a jogok korlátozásának, a root ssh-kapcsolatok letiltásának és a VPS beállításának egyéb tényeinek részleteibe. Szeretném hinni, hogy már mindent tudsz. Távoli kapcsolathoz létrehozok egy új felhasználót a szerveren.

adduser vimssh

Ssh csatlakozási kulcsokat generálok a hardverünkön.

ssh-keygen

És átmásolom őket a szerverünkre.

ssh-copy-id [email protected]

A hardverünkön minden rendszerindításkor létrehozok egy automatikus fordított ssh kapcsolatot.

[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

Ügyeljen a 8083-as portra: ez határozza meg, hogy melyik portot használjam a fordított ssh-n keresztüli csatlakozáshoz. Adja hozzá az indításhoz, és indítsa el.

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

Még az állapotot is láthatja:

sudo systemctl status autossh.service

Most, a VPS szerverünkön, ha futtatjuk:

ssh -p 8083 khadas@localhost

Aztán rátérek a próba hardveremre. A hardverről pedig naplókat és bármilyen adatot is tudok küldeni ssh-n keresztül a szerveremre, ami nagyon kényelmes.

Összeszereljük

Egyidejű sebességteszt több LTE modemen
Bekapcsolás, kezdjük el a fejlesztést és a hibakeresést

Fú, hát ez az, leírtam az összes csomópontot. Most itt az ideje, hogy mindent összerakjunk. A kódot láthatod itt.

Egy fontos pont a kóddal kapcsolatban: Előfordulhat, hogy ez a projekt nem így indul, mert egy konkrét feladatra, egy adott architektúrára szabták. Hiába adom meg a forráskódot, a legértékesebb dolgokat akkor is itt, közvetlenül a szövegben fejtem ki, különben teljesen érthetetlen.

Az elején inicializálom a gps-t, a gpio-t és elindítok egy külön ütemező szálat.

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

Az ütemező meglehetősen egyszerű: megnézi, hogy eljött-e az idő az üzenetek küldésére, és mi az aktuális hibaállapot. Ha hibajelző van, akkor villogtatjuk a LED-et.

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

A projekt legnehezebb része a fordított ssh-kapcsolat fenntartása minden tesztnél. Minden teszt magában foglalja az alapértelmezett átjáró és a DNS-kiszolgáló újrakonfigurálását. Mivel úgysem olvas senki, tudd, hogy a vonat nem fasíneken közlekedik. Aki megtalálja a húsvéti tojást, édességet kap.

Ehhez létrehozok egy külön útválasztó táblát -set-mark 0x2 és egy szabályt a forgalom átirányítására.

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

Többet megtudhat a működéséről olvassa el ebben a cikkben.

Ezután egy végtelen hurokba megyek, ahol minden alkalommal megkapjuk a csatlakoztatott modemek listáját (hogy megtudja, hogy a hálózati konfiguráció hirtelen megváltozott-e).

network_list = getNetworklist()

A hálózati interfészek listájának beszerzése meglehetősen egyszerű.

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

A lista kézhezvétele után minden interfészhez beállítottam IP címet, ahogy a modemről szóló fejezetben a képen is bemutattam.

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

Ezután egyszerűen végigmegyek minden felületen egy ciklusban. És minden interfészt beállítok.

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

Ellenőrzöm az interfész működőképességét, ha nincs hálózat, akkor hibákat generálok. Ha van hálózat, akkor ideje cselekedni!

Itt konfigurálom az ssh útválasztást erre az interfészre (ha még nem tette meg), hibaüzeneteket küldök a szervernek, ha eljött az ideje, naplókat küldök és végül lefuttatok egy speedtestet és elmentem a naplókat csv fájlba.

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()
#и далее тестируем скорость и сохраняем логи. 

Érdemes megemlíteni a fordított ssh beállításának funkcióját.

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

És persze mindezt a szépséget hozzá kell adnia az induláshoz. Ehhez létrehozok egy fájlt:

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

És azt írom bele:

[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

Bekapcsolom az automatikus betöltést és indítom!

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

Most már látom a naplókat arról, hogy mi történik a következő paranccsal:

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

Álláspontja

Nos, most az a legfontosabb, hogy mi történt ennek eredményeként? Íme néhány grafikon, amelyeket sikerült rögzítenem a fejlesztési és hibakeresési folyamat során. A gráfok gnuplot segítségével készültek a következő szkripttel.

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

Az első tapasztalat a Tele2 szolgáltatónál volt, amit több napon keresztül folytattam.

Egyidejű sebességteszt több LTE modemen

Itt egy dinamikus mérőszervert használtam. A sebességmérések működnek, de nagyon ingadoznak, de némi átlagérték még mindig látható, és ez az adatok szűrésével, például mozgóátlaggal érhető el.

Később számos grafikont készítettem más távközlési szolgáltatók számára. Ebben az esetben már volt egy tesztelő szerver, és az eredmények is nagyon érdekesek voltak.

Egyidejű sebességteszt több LTE modemen

Egyidejű sebességteszt több LTE modemen

Egyidejű sebességteszt több LTE modemen

Egyidejű sebességteszt több LTE modemen

Amint láthatja, a téma nagyon kiterjedt ezen adatok kutatására és feldolgozására, és nyilvánvalóan nem tart néhány hétig. De…

A munka eredménye

A munka rajtam kívül álló körülmények miatt hirtelen befejeződött. Ennek a projektnek az egyik gyengesége szubjektív véleményem szerint a modem volt, ami nem igazán akart egyidejűleg más modemmel működni, és minden betöltéskor ilyen trükköket csinált. Ebből a célból rengeteg más modemmodell létezik, amelyek általában már Mini PCI-e formátumban vannak, és az eszközbe vannak telepítve, és sokkal könnyebben konfigurálhatók. De ez egy teljesen más történet. A projekt érdekes volt, és nagyon örültem, hogy részt vehettem benne.

Egyidejű sebességteszt több LTE modemen

Forrás: will.com

Hozzászólás