Na tej stronie opisano, jak symulować różne warunki sieciowe na urządzeniach z Androidem Automotive w skalowalny i niewymagający dużej konserwacji sposób. Ta symulacja sieci niezależna od środowiska korzysta z powszechnie dostępnych narzędzi Linuksa, które mogą działać na urządzeniach z Androidem Automotive.
W następnych sekcjach znajdziesz instrukcje konfigurowania i uruchamiania symulacji sieci na urządzeniach z Androidem Automotive.
Wymagania dotyczące jądra
Aby włączyć symulację sieci na urządzeniu testowym, musisz skonfigurować w pliku konfiguracyjnym jądra moduły Linuxa ifb i netem, 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
Konfigurowanie symulacji
Wszystkie symulacje sieci lub symulacje ograniczania przepustowości muszą być przeprowadzane na urządzeniu testowanym (DUT). Ta symulacja wykorzystuje narzędzia tc i NetEm systemu Linux do kontrolowania ruchu sieciowego na kontrolerze interfejsu sieciowego (NIC) na podstawie zasad i reguł kontroli.
Aby skonfigurować symulację:
- Połącz testowany obiekt i serwer hosta z internetem.
- Utwórz skrypt
NetworkSimulation.sh, kopiując go z kodu podanego w sekcji skryptNetworkSimulation.sh, a następnie pobierz go na serwerze hosta. - Połącz serwer hosta z badanym urządzeniem. Upewnij się, że DUT znajduje się na liście połączonych urządzeń. Aby to sprawdzić, uruchom
adb devices -l.
Ilustracja architektury konfiguracji:
Rysunek 1. Konfiguracja architektury.
Skrypt NetworkSimulation.sh
Plik skryptu NetworkSimulation.sh zawiera polecenia adb, które uruchamiają symulację sieci. Skopiuj ten kod 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 tymi argumentami wiersza poleceń:
- Opóźnienie podane w milisekundach.
- Przepustowość podana w kb/s lub Mb/s.
- Utrata pakietów (jako wartość procentowa).
Aby na przykład ustawić opóźnienie 300 ms, przepustowość 100 kbitów i utratę pakietów 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%
Weryfikacja symulacji
Po wykonaniu skryptu NetworkSimulation.sh sprawdź, czy symulacja sieci jest prawidłowo skonfigurowana i działa zgodnie z oczekiwaniami. W tym celu użyj poleceń systemu Linux ping i curl. Aby sprawdzić opóźnienie, użyj polecenia ping, a aby sprawdzić przepustowość, użyj polecenia curl.
Oto przykład oczekiwanych danych wyjściowych funkcji ping w przypadku symulacji wykonanej za pomocą funkcji 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%, a średni czas oczekiwania wynosi około 108 ms, co jest zgodne z oczekiwaną wartością 100 ms określoną w symulacji. Jest to normalne, że zgłaszany czas oczekiwania różni się od określonej wartości o niewielką wartość.
W tym samym przykładzie dane wyjściowe polecenia curl powinny wyglądać tak:
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 podaje średnią szybkość pobierania na poziomie 49220 b/s, co jest zgodne z oczekiwaniami w przypadku 500 kbitów określonych w simulacji. Jest to normalne, że podana przepustowość różni się od określonej wartości o niewielką wartość.