Na tej stronie opisano, jak symulować różne warunki sieciowe na urządzeniach sprzętowych z systemem Android Automotive w skalowalny i niewymagający konserwacji sposób. Ta symulacja sieci niezależna od środowiska wykorzystuje powszechnie dostępne narzędzia systemu Linux, które można uruchomić na urządzeniach sprzętowych z systemem Android Automotive.
W poniższych sekcjach opisano sposób konfigurowania i uruchamiania symulacji sieci na urządzeniach sprzętowych z systemem Android Automotive.
Wymagania jądra
Aby włączyć symulację sieci na testowanym urządzeniu (DUT), moduły ifb i netem systemu Linux muszą być skonfigurowane w pliku konfiguracyjnym jądra, jak pokazano poniżej:
# 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 symulacje ograniczania przepustowości muszą być przeprowadzane na testowanym urządzeniu (DUT). Ta symulacja wykorzystuje narzędzia Linux tc i NetEm do kontrolowania ruchu sieciowego na kontrolerze interfejsu sieciowego (NIC) w oparciu o politykę i reguły kontroli.
Aby skonfigurować symulację, wykonaj następujące czynności:
- Podłącz urządzenie DUT i serwer hosta do Internetu.
- Utwórz skrypt
NetworkSimulation.sh, kopiując go z kodu podanego w sekcji skryptuNetworkSimulation.shi pobierz go na serwer hosta. - Podłącz serwer hosta do urządzenia DUT. Upewnij się, że urządzenie testowane pojawia się na liście podłączonych urządzeń, uruchamiając polecenie
adb devices -l.
Ilustrację architektury konfiguracji można znaleźć na poniższym rysunku:
Rysunek 1. Architektura instalacji.
Skrypt NetworkSimulation.sh
Plik skryptowy NetworkSimulation.sh zawiera polecenia adb , które uruchamiają symulację sieci. Skopiuj poniższy tekst 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 pliku skryptu NetworkSimulation.sh używają argumentów wiersza poleceń do ustawiania wartości.
Aby określić opóźnienie, przepustowość i utratę pakietów, które chcesz symulować, uruchom skrypt NetworkSimulation.sh z następującymi argumentami wiersza poleceń:
- Opóźnienie określone w ms.
- Przepustowość określona w kbit lub mbit.
- Utrata pakietów, procentowo.
Na przykład, aby ustawić opóźnienie 300 ms, przepustowość 100 kbitów i utratę pakietów na poziomie 50%, uruchom:
bash NetworkSimulation.sh 300ms 100kbit 50%
Aby ustawić opóźnienie 100 ms, przepustowość 1 Mbit i utratę pakietów 0%, uruchom:
bash NetworkSimulation.sh 100ms 1mbit 0%
Sprawdź symulację
Po wykonaniu skryptu NetworkSimulation.sh sprawdź, czy symulacja sieci jest poprawnie skonfigurowana i działa zgodnie z oczekiwaniami, używając poleceń ping i curl systemu Linux. Użyj polecenia ping , aby sprawdzić opóźnienie i polecenia curl , aby sprawdzić przepustowość.
Na przykład poniżej oczekiwany wynik polecenia ping dla symulacji wykonanej za pomocą 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 ping zgłasza utratę pakietów na poziomie 10% i średnie opóźnienie bliskie 108 ms, co jest zgodne z oczekiwaniami dla wartości 100 ms określonej w symulacji. To normalne, że zgłoszone opóźnienie różni się nieznacznie od określonej wartości.
W tym samym przykładzie poniżej przedstawiono oczekiwany wynik uruchomienia 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
Ten przykład pokazuje, że curl zgłasza średnią prędkość pobierania na poziomie 49220 Bps, co jest zgodne z oczekiwaniami dla 500 kbitów określonych w symulacji. To normalne, że zgłoszona przepustowość różni się nieznacznie od określonej wartości.