Současný test rychlosti na několika LTE modemech

V karanténě mi byla nabídnuta účast na vývoji zařízení pro měření rychlosti LTE modemů pro několik mobilních operátorů.

Zákazník chtěl vyhodnotit rychlost různých telekomunikačních operátorů v různých geografických lokalitách, aby mohl pochopit, který mobilní operátor je pro něj nejoptimálnější při instalaci zařízení využívajících připojení LTE, například pro video vysílání. Problém přitom bylo třeba vyřešit co nejjednodušeji a nejlevněji, bez drahého vybavení.

Hned řeknu, že úkol není nejjednodušší a nejnáročnější na znalosti; řeknu vám, s jakými problémy jsem se setkal a jak jsem je vyřešil. Tak pojďme.

Poznámka

Měření rychlosti LTE připojení je velmi složitá záležitost: musíte zvolit správné vybavení a techniku ​​měření a také dobře rozumět topologii a provozu celulární sítě. Navíc rychlost může být ovlivněna několika faktory: počtem účastníků v buňce, povětrnostními podmínkami, dokonce i mezi buňkou a buňkou se rychlost může dramaticky lišit v důsledku topologie sítě. Obecně se jedná o problém s velkým množstvím neznámých a správně jej může vyřešit pouze telekomunikační operátor.

Zpočátku chtěl zákazník jen vozit kurýra s telefony operátorů, měřit přímo na telefonu a výsledky měření rychlosti si pak zapisovat do sešitu. Moje řešení pro měření rychlosti lte sítí, i když není ideální, problém řeší.

Kvůli nedostatku času jsem se rozhodoval nikoli ve prospěch pohodlnosti nebo praktičnosti, ale ve prospěch rychlosti vývoje. Například reverzní ssh bylo použito pro vzdálený přístup místo praktičtější VPN, aby se ušetřil čas na nastavení serveru a každého jednotlivého klienta.

Technický úkol

Jak je uvedeno v článku Bez technických specifikací: proč to klient nechce: Bez technických specifikací nepracujte! Nikdy, nikde!

Technický úkol byl vcelku jednoduchý, pro pochopení koncového uživatele jej trochu rozšířím. Volba technických řešení a vybavení byla diktována zákazníkem. Takže samotná technická specifikace, po všech schváleních:

Založeno na jednom palubním počítači vim2 udělat test rychlosti pro lte připojení přes H modemyuawei e3372h - 153 několik telekomunikačních operátorů (od jednoho do n). Je také nutné přijímat souřadnice z GPS přijímače připojeného přes UART. Provádějte měření rychlosti pomocí služby www.speedtest.net a dejte je do tabulky jako:

Tabulka ve formátu csv. Toto znamení pak posílejte e-mailem každých 6 hodin. V případě chyb zablikejte LED, která je připojena k GPIO.

Technické specifikace jsem popsal volně, po mnoha schváleních. Ale smysl úkolu je již viditelný. Na všechno byl dán týden. Ale ve skutečnosti to trvalo tři týdny. Je to s přihlédnutím k tomu, že jsem to dělal jen po hlavní práci a o víkendech.

Zde chci ještě jednou upozornit na skutečnost, že zákazník se předem dohodl na využití služby měření rychlosti a hardwaru, což značně omezovalo mé možnosti. Rozpočet byl také omezený, takže se nic zvláštního nenakupovalo. Takže jsme museli hrát podle těchto pravidel.

Architektura a development

Schéma je jednoduché a jasné. Proto jej ponechám bez zvláštních komentářů.

Celý projekt jsem se rozhodl implementovat v pythonu, přestože jsem s vývojem v tomto jazyce neměl vůbec žádné zkušenosti. Vybral jsem si to, protože tam byla spousta hotových příkladů a řešení, která by mohla urychlit vývoj. Proto žádám všechny profesionální programátory, aby nenadávali na mé první zkušenosti s vývojem v pythonu, a vždy rád slyším konstruktivní kritiku pro zlepšení mých dovedností.

Během procesu jsem také zjistil, že python má dvě běžící verze 2 a 3, v důsledku toho jsem se rozhodl pro třetí.

Hardwarové uzly

Jednodeskový vim2

Jako hlavní stroj jsem dostal jednodeskový počítač vim2

Vynikající, výkonný mediální procesor pro chytrou domácnost a SMART-TV, ale pro tento úkol krajně nevhodný, nebo řekněme špatně vhodný. Například jeho hlavní OS je Android a Linux je sekundární OS, a proto nikdo nezaručuje kvalitní provoz všech uzlů a ovladačů pod Linuxem. A předpokládám, že některé problémy souvisely s USB ovladači této platformy, takže modemy na této desce nefungovaly podle očekávání. Má také velmi špatnou a roztroušenou dokumentaci, takže každá operace zabrala spoustu času prohrabáváním se v docích. I obyčejná práce s GPIO vzala hodně krve. Například nastavení LED mi trvalo několik hodin. Ale abych byl objektivní, v podstatě nebylo důležité, co to bylo za jednodesku, hlavní bylo, že to fungovalo a byly tam USB porty.

Nejprve musím na tuto desku nainstalovat Linux. Abychom nehrabali v divočině dokumentace pro všechny a také pro ty, kteří se budou tímto jednodeskovým systémem zabývat, píšu tuto kapitolu.

Existují dvě možnosti instalace Linuxu: na externí SD kartu nebo na interní MMC. Večer jsem se snažil přijít na to, jak to s kartou zprovoznit, a tak jsem se rozhodl ji nainstalovat na MMC, i když bezesporu by bylo mnohem jednodušší pracovat s externí kartou.

O firmware zde křivě řečeno. Překládám z divného do ruštiny. Abych mohl flashnout desku, potřebuji připojit hardwarový UART. Připojeno jak je uvedeno níže.

• Tool Pin GND: <—> Pin 17 GPIO VIM
• Tool Pin TXD: <—> Pin18 GPIO VIM (Linux_Rx)
• Tool Pin RXD: <—> Pin19 GPIO VIM (Linux_Tx)
• Tool Pin VCC: <—> Pin20 GPIO VIM

Poté jsem si stáhl firmware proto. Konkrétní verze firmwaru VIM1_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20191231.

K nahrání tohoto firmwaru potřebuji nástroje. Další podrobnosti o tom zde. Nezkoušel jsem to flashovat pod Windows, ale musím vám říct pár slov o firmwaru pod Linuxem. Nejprve nainstaluji nástroje podle pokynů.

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

Aaa... Nic nefunguje. Strávil jsem pár hodin úpravou instalačních skriptů, aby se mi vše správně nainstalovalo. Nepamatuji si, co jsem tam dělal, ale byl tam i ten cirkus s koňmi. Buď opatrný. Ale bez těchto nástrojů nemá smysl vim2 dále mučit. Je lepší se s ním vůbec nemazlit!

Po sedmi kruzích pekla, konfiguraci skriptu a instalaci jsem obdržel balíček pracovních utilit. Desku jsem připojil přes USB k mému linuxovému počítači a také jsem připojil UART podle schématu výše.
Nastavuji svůj oblíbený minicom terminál na rychlost 115200, bez kontroly chyb hardwaru a softwaru. A začneme.

Při načítání VIM2 v terminálu UART stisknu klávesu, například mezerník, abych zastavil načítání. Poté, co se objeví řádek

kvim2# 

Zadávám příkaz:

kvim2# run update

Na hostiteli, ze kterého načítáme, spustím:

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

To je ono, fuj. Zkontroloval jsem, že na desce je Linux. Přihlášení/heslo khadas:khadas.

Poté několik drobných počátečních nastavení. Pro další práci deaktivuji heslo pro sudo (ano, není bezpečné, ale pohodlné).

sudo visudo

Řádek upravím do formuláře a uložím

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

Poté změním aktuální lokalitu tak, aby byl čas v Moskvě, jinak bude v Greenwichi.

sudo timedatectl set-timezone Europe/Moscow

nebo

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

Pokud se vám to zdá obtížné, pak tuto desku nepoužívejte, Raspberry Pi je lepší. Upřímně řečeno.

Modem Huawei e3372h – 153

Tento modem byl pro mě významným zdrojem krve a v podstatě se stal úzkým hrdlem celého projektu. Obecně název „modem“ pro tato zařízení vůbec neodráží podstatu práce: jedná se o výkonnou kombinaci, tento kus hardwaru má složené zařízení, které předstírá, že je CD-ROM, aby bylo možné nainstalovat ovladače, a poté se přepne do režimu síťové karty.

Architektonicky to z pohledu uživatele Linuxu po všech nastaveních vypadá takto: po připojení modemu mám síťové rozhraní eth*, které přes dhcp přijímá IP adresu 192.168.8.100 a výchozí bránu je 192.168.8.1.

A nejdůležitější okamžik! Tento model modemu nemůže pracovat v režimu modemu, který je řízen AT příkazy. Vše by bylo mnohem jednodušší, vytvořit připojení PPP pro každý modem a poté s nimi pracovat. Ale v mém případě si „sám“ (přesněji linuxový potápěč podle pravidel udev) vytvoří eth rozhraní a přes dhcp mu přidělí IP adresu.

Aby se předešlo dalším zmatkům, navrhuji zapomenout na slovo „modem“ a říci síťová karta a brána, protože v podstatě je to jako připojení nové síťové karty s bránou.
Když je jeden modem, nezpůsobuje to žádné zvláštní problémy, ale když je více než jeden, konkrétně n-kusů, vzniká následující obrázek sítě.

To znamená, že n síťových karet se stejnou IP adresou, každá se stejnou výchozí bránou. Ale ve skutečnosti je každý z nich napojen na svého operátora.

Zpočátku jsem měl jednoduché řešení: pomocí příkazu ifconfig nebo ip vypněte všechna rozhraní a jednoduše jedno postupně zapněte a otestujte. Řešení bylo dobré pro všechny, až na to, že během přepínacích momentů jsem se nemohl připojit k zařízení. A jelikož je přepínání časté a rychlé, vlastně jsem neměl možnost se vůbec připojit.

Zvolil jsem proto cestu ruční změny IP adres modemů a následného řízení provozu pomocí nastavení směrování.

Tím mé problémy s modemy nekončily: v případě problémů s napájením odpadly a bylo potřeba dobré stabilní napájení USB hubu. Tento problém jsem vyřešil tvrdým připájením výkonu přímo k náboji. Další problém, na který jsem narazil a který zničil celý projekt: po restartu nebo studeném startu zařízení nebyly detekovány všechny modemy a ne vždy a nemohl jsem určit, proč se to stalo a jakým algoritmem. Ale nejdřív.

Aby modem fungoval správně, nainstaloval jsem balíček usb-modeswitch.

sudo apt update
sudo apt install -y usb-modeswitch

Poté bude modem po připojení správně detekován a nakonfigurován subsystémem udev. Zkontroluji jednoduchým připojením modemu a ujistím se, že se zobrazí síť.
Další problém, který jsem nedokázal vyřešit: jak mohu z tohoto modemu získat jméno operátora, se kterým pracujeme? Jméno operátora je obsaženo ve webovém rozhraní modemu na adrese 192.168.8.1. Toto je dynamická webová stránka, která přijímá data prostřednictvím požadavků Ajax, takže pouhé wgeting stránky a analýza názvu nebude fungovat. Začal jsem tedy hledat, jak vytvořit webovou stránku atd., a uvědomil jsem si, že dělám nějaký nesmysl. V důsledku toho si odplivl a operátor začal přijímat pomocí samotného Speedtest API.

Mnohem jednodušší by bylo, kdyby měl modem přístup přes AT příkazy. Bylo by možné to překonfigurovat, vytvořit ppp připojení, přidělit IP, získat telekomunikačního operátora atd. Ale bohužel, pracuji s tím, co mi bylo dáno.

GPS

Přijímač GPS, který jsem dostal, měl rozhraní UART a napájení. Nebylo to nejlepší řešení, ale stále bylo funkční a jednoduché. Přijímač vypadal asi takto.

Abych byl upřímný, bylo to poprvé, co jsem pracoval s GPS přijímačem, ale jak jsem očekával, vše bylo pro nás vymyšleno už dávno. Takže používáme jen hotová řešení.

Nejprve povolím uart_AO_B (UART_RX_AO_B, UART_TX_AO_B) pro připojení GPS.

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

Poté zkontroluji úspěšnost operace.

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

Tento příkaz zřejmě upravuje devtree za běhu, což je velmi pohodlné.

Po úspěchu této operace restartujte a nainstalujte démona GPS.

khadas@Khadas:~$ sudo reboot

Instalace démona GPS. Vše nainstaluji a hned odříznu pro další konfiguraci.

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

Úprava souboru nastavení.

sudo vim /etc/default/gpsd

Instaluji UART, na kterém bude viset GPS.

DEVICES="/dev/ttyS4"

A pak vše zapneme a spustíme.

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

Poté připojím GPS.

GPS drát je v mých rukou, dráty UART debuggeru jsou vidět pod prsty.

Restartuji a zkontroluji fungování GPS pomocí programu gpsmon.

Na tomto snímku obrazovky nevidíte satelity, ale můžete vidět komunikaci s přijímačem GPS, což znamená, že je vše v pořádku.

V pythonu jsem vyzkoušel mnoho možností pro práci s tímto démonem, ale rozhodl jsem se pro tu, která fungovala správně s pythonem 3.

Nainstaluji potřebnou knihovnu.

sudo -H pip3 install gps3 

A vyřezal jsem pracovní kód.

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

Pokud potřebuji získat souřadnice, udělám to pomocí následujícího volání:

longitude, latitude = getPositionData(agps_thread)

A během 1-10 sekund buď dostanu souřadnice, nebo ne. Ano, měl jsem deset pokusů získat souřadnice. Není optimální, křivý a nakřivo, ale jde to. Rozhodl jsem se to udělat, protože GPS může mít špatný příjem a ne vždy přijímat data. Pokud čekáte na příjem dat, pak pokud pracujete ve vzdálené místnosti, program na tomto místě zamrzne. Proto jsem implementoval tuto nevkusnou možnost.

V zásadě, kdyby bylo více času, bylo by možné přijímat data z GPS přímo přes UART, analyzovat je v samostatném vláknu a pracovat s nimi. Ale nebyl vůbec čas, proto ten brutálně ošklivý kód. A ano, nestydím se.

Světelná dioda

Zapojení LED bylo jednoduché a náročné zároveň. Hlavním problémem je, že číslo pinu v systému neodpovídá číslu pinu na desce a protože dokumentace je psána levou rukou. Chcete-li porovnat hardwarové číslo PIN a číslo PIN v operačním systému, musíte spustit příkaz:

gpio readall

Zobrazí se tabulka shody pinů v systému a na desce. Poté již mohu pin obsluhovat v samotném OS. V mém případě je LED připojena k GPIOH_5.

Přepnu GPIO pin do výstupního režimu.

gpio -g mode 421 out

Zapisuji nulu.

gpio -g write 421 0

Jeden si zapíšu.

gpio -g write 421 1

Vše svítí, po napsání „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)

Nyní v případě chyb zavolám error_blink() a LED bude krásně blikat.

Softwarové uzly

Speedtest API

Je velkou radostí, že služba speedtest.net má vlastní python-API, můžete se podívat na GitHub.

Dobrá věc je, že existují zdrojové kódy, které lze také prohlížet. Jak s tímto API pracovat (jednoduché příklady) najdete v příslušný oddíl.

Nainstaluji knihovnu python pomocí následujícího příkazu.

sudo -H pip3 install speedtest-cli

Například můžete dokonce nainstalovat tester rychlosti v Ubuntu přímo ze softwaru. Jedná se o stejnou pythonovou aplikaci, kterou lze následně spustit přímo z konzole.

sudo apt install speedtest-cli -y

A změřte si rychlost internetu.

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

Ve výsledku stejně jako já. Musel jsem se dostat do zdrojových kódů tohoto testu rychlosti, abych je mohl plněji implementovat do svého projektu. Jedním z nejdůležitějších úkolů je získat jméno telekomunikačního operátora, aby bylo možné jej nahradit na štítku.

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

I zde se ukázalo, že vše není tak jednoduché, i když by se to zdálo mnohem jednodušší. Zpočátku byl parametr servery roven [], říkají, vybrat nejlepší server. V důsledku toho jsem měl náhodné servery a, jak asi tušíte, proměnlivou rychlost. Toto je poměrně složité téma, použití pevného serveru, pokud ano, statického nebo dynamického, vyžaduje výzkum. Zde je ale příklad grafů měření rychlosti pro operátora Beeline při dynamickém výběru testovacího serveru a staticky pevného.

Výsledek měření rychlosti při výběru dynamického serveru.

Výsledek testování rychlosti s jedním přísně vybraným serverem.

Při testování je na obou místech „srst“ a je třeba ji odstranit pomocí matematických metod. Ale s pevným serverem je to o něco méně a amplituda je stabilnější.
Obecně je to místo velkého výzkumu. A změřil bych rychlost svého serveru pomocí nástroje iperf. Držíme se ale technických specifikací.

Odesílání pošty a chyby

Pro odesílání pošty jsem vyzkoušel několik desítek různých možností, ale nakonec jsem se rozhodl pro následující. Zaregistroval jsem poštovní schránku na Yandex a pak jsem ji vzal Toto je příklad odesílání pošty. Zkontroloval jsem to a implementoval do programu. Tento příklad zkoumá různé možnosti, včetně odesílání z Gmailu atd. Nechtěl jsem se obtěžovat nastavováním poštovního serveru a neměl jsem na to čas, ale jak se později ukázalo, bylo to také marné.

Protokoly byly odeslány podle plánovače, pokud existuje spojení, každých 6 hodin: v 00:06, 12:18, XNUMX:XNUMX a XNUMX:XNUMX. Odešlete to následovně.

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

Původně byly také odeslány chyby. Nejprve byly shromážděny v seznamu a poté odeslány také pomocí plánovače, pokud existovalo spojení. Pak však nastaly problémy s tím, že Yandex má limit na počet zpráv odeslaných za den (to je bolest, smutek a ponížení). Protože mohlo dojít k velkému počtu chyb i za minutu, museli jsme upustit od odesílání chyb poštou. Mějte tedy na paměti při automatickém odesílání informací o takovém problému prostřednictvím služeb Yandex.

Server zpětné vazby

Abych měl přístup ke vzdálenému kusu hardwaru a mohl jej přizpůsobit a překonfigurovat, potřeboval jsem externí server. Obecně řečeno, abychom byli spravedliví, bylo by správné poslat všechna data na server a vytvořit všechny krásné grafy ve webovém rozhraní. Ale ne všechny najednou.

Pro VPS jsem si vybral ruvds.com. Můžete si vzít nejjednodušší server. A obecně, pro mé účely by to stačilo. Protože jsem ale server neplatil z vlastní kapsy, rozhodl jsem se to brát s malou rezervou, aby nám stačilo nasadit webové rozhraní, vlastní SMTP server, VPN atd. Navíc můžete nastavit telegramového bota a nemít problémy s jeho blokováním. Proto jsem zvolil Amsterdam a následující parametry.

Jako způsob komunikace s hardwarem zvolil vim2 reverzní ssh připojení a jak ukázala praxe, není nejlepší. Pokud dojde ke ztrátě spojení, server drží port a není možné se přes něj nějakou dobu připojit. Proto je stále lepší používat jiné způsoby komunikace, například VPN. V budoucnu jsem chtěl přejít na VPN, ale neměl jsem čas.

Nebudu zabíhat do podrobností o nastavení firewallu, omezování práv, deaktivaci root ssh připojení a dalších pravidlech nastavení VPS. Rád bych věřil, že už všechno víte. Pro vzdálené připojení vytvořím nového uživatele na serveru.

adduser vimssh

Generuji klíče připojení ssh na našem hardwaru.

ssh-keygen

A zkopíruji je na náš server.

ssh-copy-id [email protected]

Na našem hardwaru vytvářím automatické reverzní připojení ssh při každém spuštění.

[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

Pozor na port 8083: ten určuje, který port použiji pro připojení přes reverzní ssh. Přidejte jej do spuštění a spusťte.

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

Můžete dokonce vidět stav:

sudo systemctl status autossh.service

Nyní, na našem serveru VPS, pokud spustíme:

ssh -p 8083 khadas@localhost

Pak se dostanu ke svému testovacímu kusu hardwaru. A z hardwaru mohu také posílat protokoly a jakákoli data přes ssh na svůj server, což je velmi pohodlné.

Dáte je dohromady

Zapnutí, začněme vývoj a ladění

Fuj, no, to je ono, popsal jsem všechny uzly. Nyní je čas dát to všechno dohromady. Můžete vidět kód zde.

Důležitý bod s kódem: Tento projekt nemusí začít takto, protože byl přizpůsoben pro konkrétní úlohu, konkrétní architekturu. I když uvádím zdrojový kód, to nejcennější vysvětlím zde, přímo v textu, jinak je to naprosto nesrozumitelné.

Na začátku inicializujem gps, gpio a spustím samostatné vlákno plánovače.

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

Plánovač je docela jednoduchý: zjišťuje, zda nastal čas odeslat zprávy a jaký je aktuální chybový stav. Pokud je příznak chyby, blikáme 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)

Nejobtížnější částí tohoto projektu je udržování reverzního připojení ssh pro každý test. Každý test zahrnuje překonfigurování výchozí brány a serveru DNS. Protože stejně nikdo nečte, vězte, že vlak nejezdí po dřevěných kolejích. Kdo najde velikonoční vajíčko, dostane nějaké cukroví.

K tomu vytvořím samostatnou směrovací tabulku -set-mark 0x2 a pravidlo pro přesměrování provozu.

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ůžete se dozvědět více o tom, jak to funguje přečtěte si v tomto článku.

Poté přejdu do nekonečné smyčky, kde pokaždé dostaneme seznam připojených modemů (abychom zjistili, zda se náhle nezměnila konfigurace sítě).

network_list = getNetworklist()

Získání seznamu síťových rozhraní je poměrně jednoduché.

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

Po obdržení seznamu jsem všem rozhraním nastavil IP adresy, jak jsem ukázal na obrázku v kapitole o modemu.

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

Pak jednoduše procházím každé rozhraní ve smyčce. A nakonfiguruji každé rozhraní.

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

Kontroluji funkčnost rozhraní, pokud není síť, tak generuji chyby. Pokud existuje síť, pak je čas jednat!

Zde nakonfiguruji ssh routování na toto rozhraní (pokud nebylo provedeno), posílám chyby na server, pokud nadešel čas, posílám logy a nakonec spustím speedtest a uložím logy do csv souboru.

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

Za zmínku stojí funkce nastavení zpětného ssh.

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

A samozřejmě je potřeba přidat všechnu tu krásu do startupu. K tomu vytvořím soubor:

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

A píšu do něj:

[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

Zapnu automatické načítání a startuji!

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

Nyní vidím protokoly toho, co se děje pomocí příkazu:

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

výsledky

No a teď je nejdůležitější, co se ve výsledku stalo? Zde je pár grafů, které se mi podařilo zachytit během procesu vývoje a ladění. Grafy byly vytvořeny pomocí gnuplot s následujícím skriptem.

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

První zkušenost byla s operátorem Tele2, kterou jsem vedl několik dní.

Zde jsem použil dynamický měřicí server. Měření rychlosti fungují, ale velmi kolísají, ale stále je viditelná nějaká průměrná hodnota, kterou lze získat filtrováním dat například pomocí klouzavého průměru.

Později jsem vytvořil řadu grafů pro další telekomunikační operátory. V tomto případě již jeden testovací server existoval a výsledky byly také velmi zajímavé.

Jak vidíte, téma je pro výzkum a zpracování těchto dat velmi rozsáhlé a zjevně netrvá na pár týdnů práce. Ale…

Výsledek práce

Práce byla náhle dokončena kvůli okolnostem, které jsem nemohl ovlivnit. Jednou ze slabin tohoto projektu byl podle mého subjektivního názoru modem, který ve skutečnosti nechtěl pracovat současně s jinými modemy a dělal takové triky při každém načtení. Pro tyto účely existuje velké množství dalších modelů modemů, obvykle jsou již ve formátu Mini PCI-e a jsou instalovány uvnitř zařízení a jejich konfigurace je mnohem jednodušší. Ale to je úplně jiný příběh. Projekt byl zajímavý a byla jsem moc ráda, že jsem se ho mohla zúčastnit.

Zdroj: www.habr.com