Samtidig speedtest på flera LTE-modem

Under quarantine, I was invited to participate in the development of a device for measuring the speed of LTE modems for several mobile operators.

The client wanted to assess the speed of various telecommunications operators in different geographical locations to understand which mobile operator would be most optimal for installing equipment that uses LTE connections, such as for video streaming. The task needed to be solved as simply and cheaply as possible, without expensive equipment.

I will say right away that this task is not the simplest and requires scientific knowledge; I will share the problems I encountered and how I solved them. So, let's go.

Anmärkning

Measuring LTE connection speed is quite complex: it is necessary to choose the right equipment and measurement methodology, and also to have a good understanding of the topology and operation of the mobile network. Additionally, several factors can affect speed: the number of subscribers on the cell, weather conditions, and even from cell to cell, the speed can vary drastically due to network topology. In general, this task comes with a huge number of unknowns, and only a mobile operator can solve it correctly.

Initially, the client just wanted to have a courier run with phones from different operators, conducting measurements directly on the phones and then writing the speed measurement results in a notebook. My solution for measuring LTE network speeds, while not perfect, meets the task at hand.

Due to a lack of time, I made decisions not in favor of convenience or practicality, but in favor of the speed of development. For example, for remote access, I set up reverse SSH instead of a more practical VPN, to save time on server and client setup.

Teknisk specifikation

As stated in the article Without a technical specification: why the client doesn't want one: Do not work without a technical specification! Never, anywhere!

The technical specification was quite simple; I will expand on it a bit for the end user to understand. The choice of technical solutions and equipment was dictated by the client. So, the specification itself, after all agreements:

Based on a single-board computer vim2 to create an LTE connection speed tester through Huawei e3372h — 153 flera operatörer (från en till n). Det är också nödvändigt att få koordinater från GPS-mottagaren, ansluten via UART. Hastighetsmätningar ska utföras med hjälp av tjänsten www.speedtest.net och sammanställa dem i en tabell av typ:

Tabell i csv-format. Därefter ska denna tabell skickas via e-post var sjätte timme. Vid fel ska en LED-lampa, som är kopplad till GPIO, blinka.

Tekniska specifikationer har jag beskrivit i friform, efter många godkännanden. Men syftet med uppgiften är redan tydligt. Tiden för allt detta var en vecka. Men i verkligheten sträckte den sig över tre veckor. Detta med beaktande av att jag gjorde det endast efter mitt ordinarie jobb och på helger.

Här vill jag återigen påpeka att uppdragsgivaren i förväg hade avtalat om användning av hastighetsmätningstjänsten och hårdvaran, vilket kraftigt begränsade mina möjligheter. Budgeten var också begränsad, så det köptes knappt något ytterligare. Så jag var tvungen att spela med de angivna reglerna.

Arkitektur och utveckling

Schemat är enkelt och uppenbart. Därför lämnar jag det utan kommentarer.

Jag beslutade att genomföra hela projektet i Python, trots att jag inte hade någon erfarenhet av att utveckla i detta språk. Jag valde det eftersom det fanns många färdiga exempel och lösningar som kunde snabba upp utvecklingen. Därför ber jag alla professionella programmerare att inte kritisera min första erfarenhet av att utveckla i Python, och jag är alltid villig att höra konstruktiv kritik för att förbättra mina färdigheter.

Jag upptäckte också att Python har två populära versioner, 2 och 3, så jag fastnade för den tredje.

Hårdvarunoder

Enkortsdator vim2

Som huvudmaskin fick jag en enkortsdator vim2

Ett utmärkt, kraftfullt mediacombo för smarta hem och SMART-TV, men sällsynt olämpligt för denna uppgift, eller låt oss säga, svagt lämpligt. Till exempel, dess huvud-OS är Android, medan Linux är ett biprodukt-OS, och därför kan ingen garantera att alla komponenter och drivrutiner fungerar bra under Linux. Jag misstänker att en del av problemen var relaterade till USB-drivrutinerna för denna plattform, så modem fungerade inte som jag förväntat mig. Det finns också väldigt dålig och spridd dokumentation, så varje operation tog mycket tid på att gräva i dokumentationen. Till och med en vanlig uppgift med GPIO tog mycket tid. Till exempel, för att konfigurera en LED-lampa tog det mig flera timmar. Men för att vara objektiv, så var det principiellt sett inte viktigt vilken enskild kortdator det var, så länge den fungerade och hade USB-portar.

Först måste jag installera Linux på denna platta. För att inte behöva leta runt i dokumentationen, och också för de som ska arbeta med denna enskilda kortdator, skriver jag detta kapitel.

Det finns två alternativ för att installera Linux: på ett externt SD-kort eller på intern MMC. Jag kämpade med kortet en kväll och fick det inte att fungera, så jag bestämde mig för att installera på MMC, även om det utan tvekan skulle vara mycket enklare att arbeta med ett externt kort.

Om flashning berättas snett här. Jag översätter från ett konstigt språk till ryska. För att kunna blinka plattan måste jag ansluta en hårdvaru-UART. Jag anslöt den på följande sätt.

• Tool Pin GND: Pin17 av VIM:s GPIO
• Tool Pin TXD: Pin18 av VIM:s GPIO (Linux_Rx)
• Tool Pin RXD: Pin19 av VIM:s GPIO (Linux_Tx)
• Tool Pin VCC: Pin20 av VIM:s GPIO

Efter det laddade jag ner firmware härifrån. Den specifika versionen av firmware VIM1_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20191231.

För att ladda denna firmware behöver jag vissa verktyg. Mer information om detta beskrivs ). Ett typiskt exempel på användning:. Jag har inte försökt att blinka under Windows, men det behöver sägas ett par ord om flashning under Linux. Först installerar jag verktygen enligt instruktionerna.

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

Och… inget fungerar. Jag lade ner ett par timmar på att redigera installationsskripten för att allt skulle installeras korrekt för mig. Vad jag gjorde minns jag inte, men det var också ett rikt circus. Så var försiktig. Men utan dessa verktyg finns det ingen mening att fortsätta med vim2. Bättre att överhuvudtaget inte knyta an till den!

Efter sju helveten, konfigurationer av skript och installation fick jag paketet med fungerande verktyg. Jag kopplade brädan via USB till min Linux-dator, och UART kopplades också enligt skissen ovan.
Jag konfigurerar min favoritterminal minicom till 115200 hastighet, utan hårdvaru- och programvaruövervakning av fel. Och vi sätter igång.

Vid uppstart av VIM2 i UART-terminalen trycker jag på någon tangent, till exempel mellanslag, för att stoppa uppstarten. När raden visas

kvim2# 

Skriver in kommandot:

kvim2# run update

På värden där vi laddar ner, utför jag:

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

Det är klart, puh. Jag har flasht, brädan har Linux. Inloggning/lösenord khadas:khadas.

Därefter gör jag några små grundinställningar. För vidare arbete inaktiverar jag lösenordet för sudo (ja, inte säkert, men praktiskt).

sudo visudo

Redigerar raden så att den ser ut så här och sparar.

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

Efter det ändrar jag nuvarande lokal så att tiden är enligt Moskva, annars blir det enligt Greenwich.

sudo timedatectl set-timezone Europe/Moscow

eller

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

Om du tyckte att det verkade komplicerat, använd då inte denna bräda, bättre Raspberry Pi. Ärligt.

Modem Huawei e3372h — 153

Detta modem har verkligen gett mig en del problem, och det blev till slut den svagaste länken i hela projektet. Egentligen, namnet "modem" för dessa enheter speglar inte alls deras funktion: det är en kraftfull kombination, den har en komponent som låtsas vara en CD-ROM för att installera drivrutiner, och sedan går den över i läge som nätverkskort.

Arkitektoniskt, sett ur en Linux-användares perspektiv efter alla inställningar, ser det ut så här: efter att ha anslutit modemet, får jag ett nätverksgränssnitt eth*, som via DHCP får IP-adressen 192.168.8.100, och standardgateway 192.168.8.1.

Och den viktigaste punkten! Denna modemmodell kan inte fungera i läge som modem, som styrs av AT-kommandon.. Allt skulle varit mycket enklare, om man skapade PPP-anslutningar för varje modem och sedan opererade med dem. Men i mitt fall skapar "den" (närmare bestämt Linux-drivrutiner enligt reglerna för udev) ett eth-gränssnitt och tilldelar det en IP-adress via DHCP.

För att inte förvirra längre, föreslår jag att vi glömmer ordet "modem" och istället pratar om nätverkskort och gateway, eftersom det i grunden är som att ansluta ett nytt nätverkskort med en gateway.
När det är ett modem, orsakar det inga särskilda problem, men när det finns mer än ett, nämligen n stycken, då uppstår följande nätverksbild.

Det vill säga n nätverkskort, alla med samma IP-adress och samma standardgateway. Men i verkligheten är varje kort kopplat till sin egen operatör.

Initialt hade jag en enkel lösning: genom att använda kommandot ifconfig eller ip stänga av alla gränssnitt och sedan slå på dem ett i taget för att testa dem. Lösningen fungerade bra, förutom att jag under bytena inte hade möjlighet att koppla upp mig mot enheten. Eftersom bytena var frekventa och snabba, hade jag faktiskt ingen möjlighet att koppla upp mig överhuvudtaget.

Därför valde jag att manuellt ändra IP-adresserna på modemen och sedan styra trafiken genom routingen.

Mina problem med modemen slutade inte här: vid strömbortfall kopplade de ifrån, så jag behövde en stabil USB-hubb. Jag löste detta genom att löda strömmen direkt till hubben. Ett annat problem jag stötte på, som satte stopp för hela projektet, var att efter omstart eller kallstart kände enheten inte alltid igen alla modem, och jag kunde inte fastställa varför eller enligt vilket algoritm det inträffade. Men låt oss ta det steg för steg.

För att modemet skulle fungera korrekt installerade jag paketet usb-modeswitch.

sudo apt update
sudo apt install -y usb-modeswitch

Efter detta kommer modemet att kännas igen korrekt och konfigureras av udev-systemet vid anslutning. Jag kontrollerar genom att helt enkelt koppla in modemet och försäkra mig om att nätverket har dykt upp.
Ett annat problem jag inte kunde lösa var hur man får namnet på operatören som vi arbetar med från detta modem? Operatörens namn finns i modemens webgränssnitt på adressen 192.168.8.1. Detta är en dynamisk webbsida som får data via ajax-förfrågningar, så det är inte möjligt att bara wget:a sidan och parsa namnet. Därför började jag leta efter sätt att hantera webbsidan och liknande, och insåg att jag pysslar med en massa strunt. Resultatet blev att jag gav upp och började hämta operatörens namn via Speedtests API.

Mycket skulle vara enklare om modemet hade tillgång via AT-kommandon. Man skulle kunna omkonfigurera det, skapa ppp-anslutningar, tilldela IP, få operatörens namn osv. Men tyvärr får jag arbeta med det jag har.

GPS

GPS-mottagaren som jag fick hade en UART-gränssnitt och strömförsörjning. Det var inte den bästa lösningen, men det var funktionellt och enkelt. Mottagaren såg ungefär ut så här.

Ärligt talat, det var första gången jag arbetade med en GPS-mottagare, men som jag misstänkte har andra redan tänkt på allting. Så vi använder bara färdiga lösningar.

Först aktiverar jag uart_AO_B (UART_RX_AO_B, UART_TX_AO_B) för att ansluta GPS.

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

Därefter kontrollerar jag om operationen lyckades.

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

Denna kommando verkar redigera devtree i realtid, vilket är mycket praktiskt.

Efter att denna operation lyckats, startar vi om och installerar gps-daemonen.

khadas@Khadas:~$ sudo reboot

Installation av gps-daemonen. Jag installerar allt och stänger av den direkt för ytterligare konfiguration.

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

/* GPS-daemon stoppa/inaktivera */
sudo systemctl stop gpsd.socket
sudo systemctl disable gpsd.socket

Jag redigerar konfigurationsfilen.

sudo vim /etc/default/gpsd

Jag ställer in UART som GPS-enheten kommer att ansluta till.

DEVICES="/dev/ttyS4"

Och sedan aktiverar vi allt och startar det.

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

Sedan ansluter jag GPS.

I händerna har jag GPS-kabeln och jag känner UART-debuggerns kablar under fingrarna.

Jag startar om och testar GPS:en med programmet gpsmon.

I den här skärmbilden syns inga satelliter, men man kan se kommunikationen med GPS-mottagaren, vilket betyder att allt är i sin ordning.

Jag har testat många alternativ på python för att arbeta med denna daemon, men jag fastnade för den som fungerade korrekt med python 3.

Jag installerar den nödvändiga biblioteken.

sudo -H pip3 install gps3 

Och jag skriver koden för att arbeta.

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 ("Väntar gps räknare = %d" % counter)
		if counter == 10:
			ErrorMessage("Fel GPS-mottagare!!!")
			return "NA", "NA"
		time.sleep(1.0)
...
f __name__ == '__main__':
...	#gps
	agps_thread = AGPS3mechanism()  # Instansiera AGPS3-mekanismer
	agps_thread.stream_data()  # Från localhost (), eller andra värdar, till exempel, (host='gps.ddns.net')
	agps_thread.run_thread()  # Tidsbegränsning för att somna efter en tom sökning, standard '()' 0.2 två tiondelar av en sekund

Om jag behöver hämta koordinater, görs det med följande anrop:

longitude, latitude = getPositionData(agps_thread)

Och inom 1-10 sekunder kommer jag antingen att få koordinaten eller inte. Ja, jag har gjort tio försök att få koordinater. Inte optimalt, klumpigt och krångligt, men det fungerar. Jag beslutade att göra så här eftersom GPS kan ha dålig mottagning och ibland inte få data. Om man väntar på att få data kan programmet hänga sig i tysta miljöer. Därför implementerade jag denna mindre eleganta lösning.

I princip, om jag hade haft mer tid, skulle jag kunna ta emot data från GPS via UART direkt, parsa dem i en separat tråd och arbeta med dem. Men jag hade ingen tid alls, därav den helt fula koden. Och ja, jag skäms inte.

LED

Anslutningen av LED-lampan var både enkel och svår på samma gång. Den största svårigheten är att pin-nummer i systemet inte motsvarar pin-nummer på kortet och att dokumentationen är skriven med venstre fot. För att matcha hårdvarupinnens nummer och systemets pinnummer måste jag köra kommandot:

gpio readall

Det kommer att visas en tabell som motsvarar pinnen i systemet och på kortet. Efter det kan jag arbeta med pinnen i själva OS:et. I mitt fall är LED-lampan ansluten till GPIOH_5.

Jag sätter GPIO-pin i utgångsläge.

gpio -g mode 421 out

Jag skriver 0.

gpio -g write 421 0

Jag skriver 1.

gpio -g write 421 1

Allt lyser efter att ha skrivit '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)

Nu, vid fel, anropar jag error_blink() och LED-lampan blinkar vackert.

Programvarunoder

Speedtest API

En stor glädje är att tjänsten speedtest.net har sitt eget python-API, som kan ses på Github.

Det är bra att det finns källkoder som också kan ses. Hur man arbetar med detta API (de enklaste exemplen) kan ses i den relevanta sektionen.

Jag installerar python-biblioteket med följande kommando.

sudo -H pip3 install speedtest-cli

Som exempel kan du helt enkelt installera hastighetstestaren i Ubuntu direkt från repos. Det är samma python-applikation som sedan kan startas direkt från konsolen.

sudo apt install speedtest-cli -y

Och mäta hastigheten på din internetuppkoppling.

speedtest-cli
Hämtar speedtest.net-konfiguration...
Testar från B***** (*.*.*.*)...
Hämtar serverlista från speedtest.net...
Väljer bästa server baserat på ping...
Värd av MTS (Moskva) [0.12 km]: 11.8 ms
Tester nedladdningshastighet................................................................................
Nedladdning: 7.10 Mbit/s
Tester uppladdningshastighet......................................................................................................
Uppladdning: 3.86 Mbit/s

Som resultat av hur jag gjorde detta. Jag var tvungen att dyka ner i källkoderna för detta hastighetstest för att mer fullständigt integrera dem i mitt projekt. En av de viktigaste uppgifterna är att få även namnet på teleoperatören för att sätta in det i tabellen.

import speedtest
from datetime import datetime
...
# Ange specifik server för testet
#6053) MaximaTelecom (Moskva, Ryska federationen)
servers = ["6053"]
# Om du vill använda ett entrådat test
threads = None
s = speedtest.Speedtest()
# Hämtar namnet på mobiloperatören
opos = '%(isp)s' % s.config['client']
s.get_servers(servers)
# Hämtar en textsträng med serverparametrar
testserver = '%(sponsor)s (%(name)s) [%(d)0.2f km]: %(latency)s ms' % s.results.server
# Nedladdningstest
s.download(threads=threads)
# Uppladdningstest
s.upload(threads=threads)
# Hämtar resultaten
s.results.share()

# Därefter skapas en sträng för att skriva till csv-fil.
# Hämtar GPS-positionen
longitude, latitude = getPositionData(agps_thread)
# Tid och datum
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"
# Här skrivs loggfilen

Det visade sig att det inte heller var så enkelt, även om det borde vara enklare. Ursprungligen var parametern servers lika med [], som sa att jag skulle välja den bästa servern. Resultatet blev att jag hade slumpmässiga servrar, och som man kan gissa, fluktuerande hastigheter. Det är en ganska komplex fråga att använda en fast server, och om ja, så kräver det forskning om den är statisk eller dynamisk. Men här är ett exempel på hastighetsmätningar från operatören Beeline med dynamisk val av testserver och en statiskt fastställd.

Resultatet av hastighetsmätningen med val av dynamisk server.

Resultatet av hastighetstestet med en strikt valt server.

Det finns "brus" i testerna både här och där, och det behöver tas bort med matematiska metoder. Men med en fast server är det lite mindre brus och amplituden är mer stabil.
Detta är faktiskt ett område för omfattande forskning. Jag skulle göra hastighetsmätningar till min server med hjälp av verktyget iperf. Men vi följer kraven i specifikationen.

E-postskickning och fel

För att skicka e-post testade jag flera olika alternativ, men slutligen fastnade jag vid följande. Jag registrerade en e-postadress på yandex och därefter tog jag detta exempel på e-postskickning. Jag testade det och implementerade det i programmet. I detta exempel går vi igenom olika alternativ, inklusive att skicka från gmail med mera. Jag ville inte bråka med att sätta upp min egen e-postserver och hade inte tid för det, men som det visade sig var det också förgäves.

Jag skickade loggar via schemaläggaren, om det fanns en anslutning, var sjätte timme: klockan 00, 06, 12 och 18. Jag skickade på följande sätt.

from send_email import *
...
message_log = "Testloggar för kort #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, "Loggar för " + curdata + " " + curtime, files)
	except:
		print("Nätverksproblem för att skicka mail")
		return False
	return True

Fel skickades också initialt. Först samlades de i en lista, och jag skickade dem också via schemaläggaren, om det fanns en anslutning. Men det uppstod sedan problem eftersom Yandex har en gräns för antalet meddelanden som kan skickas per dag (detta är smärta, sorg och förnedring). Eftersom det kunde finnas ett stort antal fel på en minut, tvingades jag avstå från att skicka fel via e-post. Så ha det i åtanke när du skickar automatiskt via Yandex-tjänster angående detta problem.

Feedbackserver

För att få tillgång till den fjärranslutna hårdvaran och kunna finjustera och omkonfigurera den behövde jag en extern server. Egentligen skulle det vara rättvist att skicka all data till servern och bygga alla fina diagram i webbgränssnittet. Men inte allt på en gång.

Som VPS valde jag ruvds.com. Jag kunde ha tagit den enklaste servern. Och för mina syften skulle det i stort sett ha varit mer än tillräckligt. Men eftersom jag inte betalade för servern ur min egen plånbok, beslutade jag mig för att ta en med lite extra kapacitet, så att det skulle räcka om vi skulle rulla ut ett webbgränssnitt, egen SMTP-server, VPN, osv. Dessutom ville jag kunna ställa in en Telegram-bot och undvika problem med dess blockeringar. Därför valde jag Amsterdam och följande parametrar.

Som anslutningsmetod till enheten vim2 valde jag omvänd ssh-anslutning och, som praktiken visade, är det inte det bästa. Vid avbrott i anslutningen håller servern porten, och det är inte möjligt att ansluta under en tid. Därför är det ändå bättre att använda andra anslutningsmetoder, som VPN. I framtiden ville jag byta till VPN, men jag hann inte.

Jag kommer inte att gå in på detaljer om konfigurationen av brandväggen, begränsningar av rättigheter, avstängning av ssh-anslutning för root och andra grundläggande konfigurationer av VPS. Jag hoppas att ni redan vet allt detta. För fjärranslutning skapar jag en ny användare på servern.

adduser vimssh

På vår maskin genererar jag ssh-nycklar.

ssh-keygen

Och jag kopierar dem till vår server.

ssh-copy-id vimssh@host.com

På vår maskin skapar jag en automatisk återanslutning via ssh vid varje uppstart.

[Enhet]
Beskrivning=Auto Reverse SSH
Kräver=systemd-networkd-wait-online.service
Efter=systemd-networkd-wait-online.service
[Service]
Användare=khadas
ExecStart=/usr/bin/ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -CD 8080 -R 8083:localhost:22 vimssh@host.com
RestartSec=5
Restart=alltid
[Install]
WantedBy=multi-user.target

Observera port 8083: den avgör vilken port jag kommer att använda för att ansluta via återanslutning. Vi lägger till detta i autostart och startar det.

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

Man kan även kolla status:

sudo systemctl status autossh.service

Nu, på vår VPS-server, om jag kör:

ssh -p 8083 khadas@localhost

Då kommer jag åt min testmaskin. Och från maskinen kan jag även skicka loggar och data via ssh till min server, vilket är mycket praktiskt.

Sammanfattar allt

Nu börjar vi utveckla och debugga

Puh, jag har nog beskrivit alla noder. Nu är det dags att sammanfoga allt till en enhet. Koden kan ses här här.

En viktig punkt med koden: Detta projekt kan inte starta som det är, eftersom det är inriktat på en viss uppgift och specifik arkitektur. Även om jag ger källkoden, är det viktigaste förklarat här i texten, annars är det helt oklart.

I början har jag initialization av gps, gpio och start av en separat tråd för planering.

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

Planeraren är ganska enkel: den kollar om det är dags att skicka meddelanden och vad den nuvarande felstatusen är. Om det finns en felflagga, blinkar vi med en lysdiod.

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

Det svåraste momentet i detta projekt är att behålla den omvända ssh-anslutningen vid varje test. I varje test ställs standardgateway och dns-server på nytt. Eftersom ingen ändå läser, vet att tåget inte rullar på träspår. Den som hittar påskägget får godis.

För detta skapar jag en separat routingtabelle —set-mark 0x2 och en regel för att omdirigera trafik.

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

Mer om hur detta fungerar kan läsa i denna artikel.

Efter det går jag in i en oändlig loop där jag varje gång får en lista över anslutna modem (för att se om nätverkskonfigurationen har ändrats).

network_list = getNetworklist()

Att hämta listan över nätverksgränssnitt är ganska enkelt.

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

Efter att ha fått listan tilldelar jag IP-adresser till alla gränssnitt, som jag visade på bilden i kapitlet om 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')

Därefter går jag helt enkelt igenom varje gränssnitt i en loop. Och konfigurerar varje gränssnitt.

	for iface in network_list:
		ConfigNetwork(iface)

def ConfigNetwork(iface):
#återställer alla inställningar
		cmd_run('sudo ip route flush all')
#Tillsätter standardgateway
		cmd_run('sudo route add default gw 192.168.8.1 ' + iface)
#tilldelar dns-server (detta behövs för att köra speedtest)
		cmd_run('sudo bash -c "echo nameserver 8.8.8.8 > /etc/resolv.conf"')

Jag kontrollerar gränssnittet för funktionalitet, om det inte finns något nätverk, så genererar jag fel. Om det finns ett nätverk, så är det dags att agera!

Här konfigurerar jag ssh-routing för detta gränssnitt (om det inte redan har gjorts), skickar fel till servern, och om det är dags, skickar jag loggar och till sist genomför jag en speedtest och sparar loggarna i en csv-fil.

if not NetworkAvalible():
....
#Här generar vi fel
....
else: #Det finns nätverk, hurra, vi jobbar!
#Om vi har ett problematiskt gränssnitt, på vilket ssh, så ändrar vi det
  if (sshint == lastbanint or sshint == 'free'): 
    print('********** Setup SSH ********************')
    if sshint != 'free':
      cmd_run('sudo ip route del default via 192.168.8.1 dev ' + sshint + ' table 102')
    SetupReverseSSH(iface)
    sshint = iface
#eftersom nätverket fungerar, låt oss skicka allt!!!
    if ready_to_send:
      print('**** Ready to send!!!')
        if sendLogs():
          ready_to_send = False
        if error_status:
          SendErrors()
#och sedan testar vi hastigheten och sparar loggar. 

Det är värt att nämna funktionen för att konfigurera omvänd 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')

Och självklart är det nödvändigt att lägga till allt detta i autostart. För detta skapar jag en fil:

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

Och jag skriver in den:

[Enhet]
Beskrivning=Modem Hastighetstest
Kräver=systemd-networkd-wait-online.service
Efter=systemd-networkd-wait-online.service
[Service]
Användare=khadas
ExecStart=\/usr\/bin\/python3.6 \/home\/khadas\/modems_speedtest\/networks.py
RestartSec=5
Restart=alltid
[Install]
WantedBy=multi-user.target

Jag aktiverar autostarten och startar!

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

Nu kan jag se loggarna för vad som händer med kommandot:

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

Resultat

Men nu är den viktigaste frågan, vad blev resultatet? Jag kommer att ge några grafer som jag lyckades fånga under utvecklings- och debuggningsprocessen. Graferna skapades med hjälp av gnuplot enligt följande skript.

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

Den första erfarenheten var från operatören Tele2, som jag genomförde under flera dagar.

Här använde jag en dynamisk mätserver. Mätningarna av hastighet fungerar, men varierar kraftigt, ändå syns en viss genomsnittlig siffra, och den kan erhållas genom att filtrera data, till exempel med ett glidande medelvärde.

Senare byggde jag ytterligare ett antal grafer för andra operatörer. Testservern i det här fallet var en och samma, och resultaten var också mycket intressanta.

Som syns är ämnet mycket omfattande för forskning och bearbetning av dessa data, och drar uppenbarligen inte bara ett par veckors arbete. Men…

Slutsats av arbetet

Arbetet avslutades plötsligt på grund av omständigheter som jag inte kunde påverka. En av de svaga punkterna i detta projekt, enligt min personliga åsikt, var modemet, som inte riktigt ville fungera samtidigt med andra modem, och gjorde knep vid varje omstart. För dessa ändamål finns det ett stort antal andra modemmodeller, vanligtvis har de redan formatet Mini PCI-e och sätts in i enheten, vilket gör dem mycket enklare att konfigurera. Men det är en helt annan historia. Projektet var intressant och jag var mycket glad över att jag fick delta.

Källa: habr.com