Z tego artykułu dowiesz się, jak symulować różne warunki sieci na Androidzie Urządzenia samochodowe, które można skalować i nie wymagają wielu konserwacji. Ten symulacja sieci niezależnej od środowiska wykorzystuje powszechnie dostępne narzędzia dla systemu Linux, mogą działać na urządzeniach z Androidem Automotive.
W poniższych sekcjach opisano, jak skonfigurować i uruchomić symulację sieci na Urządzenia z Androidem Automotive.
Wymaganie jądra systemu
Aby włączyć symulację sieci na testowanym urządzeniu, należy
ifb
oraz
netem
moduły muszą być skonfigurowane w pliku konfiguracji jądra w następujący sposób:
# Network simulation config fragment start
CONFIG_NET_SCH_NETEM=y
CONFIG_IFB=y
CONFIG_NET_ACT_MIRRED=y
# Network simulation config fragment end
Skonfiguruj symulację
Wszystkie symulacje sieci lub ograniczania muszą być prowadzone
urządzenia w trakcie testów (DUT). Ta symulacja używa systemu Linux
tc i
NetEm
narzędzia do kontrolowania ruchu sieciowego w kontrolerze interfejsu sieciowego
(NIC) w oparciu o zasadę kontroli i reguły.
Aby skonfigurować symulację:
- Połącz urządzenie DUT i serwer hosta z internetem.
- Utwórz skrypt
NetworkSimulation.sh, kopiując go z podanego kodu w sekcjiNetworkSimulation.shskrypt i pobierz go na serwerze hosta. - Połącz serwer hosta z urządzeniem DUT. Sprawdź, czy na liście jest widoczna usługa DUT
połączonych urządzeń po uruchomieniu
adb devices -l.
Architektura konfiguracji znajdziesz na tej ilustracji:
Rysunek 1. Architektura konfiguracji.
Skrypt NetworkSimulation.sh
Plik skryptu NetworkSimulation.sh zawiera adb polecenia, które uruchamiają
i symulację sieci. Skopiuj kod podany poniżej do pliku o nazwie NetworkSimulation.sh:
#!/bin/bash
latency=$1
bandwidth=$2
packetloss=$3
# root device and set it to permissive mode
adb root
adb shell setenforce 0
#Clear the current tc control
adb shell tc qdisc del dev ifb0 root
adb shell ip link set dev ifb0 down
adb shell tc qdisc del dev wlan0 ingress
adb shell tc qdisc del dev wlan0 root
# Create a virtual device for ingress
adb shell ip link set dev wlan0 up
adb shell ip link set dev ifb0 up
adb shell tc qdisc del dev wlan0 clsact
adb shell tc qdisc add dev wlan0 handle ffff: ingress
adb shell tc filter add dev wlan0 parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev ifb0
# Throttle upload bandwidth / latency / packet loss
adb shell tc qdisc add dev wlan0 root handle 1: htb default 11
adb shell tc class add dev wlan0 parent 1: classid 1:1 htb rate "$bandwidth"
adb shell tc class add dev wlan0 parent 1:1 classid 1:11 htb rate "$bandwidth"
adb shell tc qdisc add dev wlan0 parent 1:11 handle 10: netem delay "$latency" loss "$packetloss"
# Throttle download bandwidth
adb shell tc qdisc add dev ifb0 root handle 1: htb default 10
adb shell tc class add dev ifb0 parent 1: classid 1:1 htb rate "$bandwidth"
adb shell tc class add dev ifb0 parent 1:1 classid 1:10 htb rate "$bandwidth"
Wykonaj symulację
Aby wykonać symulację sieci, polecenia adb w
NetworkSimulation.sh plik skryptu do ustawienia – użyj argumentów wiersza poleceń
.
Aby określić czas oczekiwania, przepustowość i utratę pakietów do symulowania, uruchom
NetworkSimulation.sh skrypt z tymi argumentami wiersza poleceń:
- Czas oczekiwania określony w ms.
- Przepustowość określona w kb lub mbitach.
- Utracone pakiety (jako wartość procentowa).
Aby na przykład ustawić opóźnienie na poziomie 300 ms, przepustowość 100 kb/s i utratę pakietów na poziomie 50%, uruchom polecenie:
bash NetworkSimulation.sh 300ms 100kbit 50%
Aby ustawić opóźnienie na 100 ms, przepustowość 1 mbit i utratę pakietów 0%, uruchom polecenie:
bash NetworkSimulation.sh 100ms 1mbit 0%
Zweryfikuj symulację
Po wykonaniu skryptu NetworkSimulation.sh sprawdź, czy sieć
symulacja jest prawidłowo skonfigurowana i działa zgodnie z oczekiwaniami przy użyciu
Linux ping oraz
curl
poleceń. Za pomocą polecenia ping sprawdź opóźnienie, a polecenia curl –
sprawdzić przepustowość.
Oto oczekiwane dane wyjściowe funkcji ping w symulacji:
wykonane przy użyciu bash NetworkSimulation.sh 100ms 500kbit 10%:
BUILD:/ # ping -c 20 www.google.com PING www.google.com (172.217.5.100) 56(84) bytes of data. 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=1 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=2 ttl=119 time=105 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=3 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=5 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=6 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=7 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=9 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=10 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=11 ttl=119 time=185 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=12 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=13 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=14 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=15 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=16 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=17 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=18 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=19 ttl=119 time=103 ms 64 bytes from sfo03s07-in-f4.1e100.net (172.217.5.100): icmp_seq=20 ttl=119 time=103 ms --- www.google.com ping statistics --- 20 packets transmitted, 18 received, 10% packet loss, time 19040ms rtt min/avg/max/mdev = 103.394/108.307/185.756/18.791 ms
Ten przykład pokazuje, że interfejs ping zgłasza utratę pakietów na poziomie 10% i średni czas oczekiwania
prawie 108 ms, co jest zgodne z oczekiwaniami przy wartości 100 ms określonej w
symulację. To normalne, że raportowany czas oczekiwania różni się od podanego
o niewielką wartość.
W tym samym przykładzie poniżej przedstawiamy oczekiwane dane wyjściowe uruchomionego polecenia
curl.
BUILD:/sdcard/DCIM # curl https://images-assets.nasa.gov/image/PIA15416/PIA15416~orig.jpg -o foo.jpg
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6598k 100 6598k 0 0 49220 0 0:02:17 0:02:17 --:--:-- 47574
W tym przykładzie widać, że curl podaje średnią prędkość pobierania wynoszącą 49 220 B/s,
co odpowiada 500 kbitom określonym w symulacji. To normalne
aby raportowana przepustowość odbiegała od określonej wartości o niewielkim odchyleniu.