Na tej stronie opisujemy, jak w skalowalny i niewymagający częstej konserwacji sposób symulować różne warunki sieciowe na urządzeniach z Androidem Automotive. Ta niezależna od środowiska symulacja sieci korzysta z ogólnodostępnych narzędzi systemu Linux, które mogą działać na urządzeniach z Androidem Automotive.
W kolejnych sekcjach opisujemy, jak skonfigurować i uruchomić symulację sieci na urządzeniach z Androidem Automotive.
Wymagania dotyczące jądra
Aby włączyć symulację sieci na testowanym urządzeniu, w pliku konfiguracyjnym jądra należy skonfigurować moduły Linux
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 ograniczania przepustowości muszą być przeprowadzane na testowanym urządzeniu. Ta symulacja wykorzystuje narzędzia Linux
tc i
NetEm
do kontrolowania ruchu sieciowego na kontrolerze interfejsu sieciowego (NIC) na podstawie zasad i reguł kontroli.
Aby skonfigurować symulację:
- Połącz DUT 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 urządzeniem DUT. Sprawdź, czy DUT znajduje się na liście połączonych urządzeń, uruchamiając polecenie
adb devices -l.
Ilustrację architektury konfiguracji znajdziesz na tym rysunku:
Rysunek 1. Architektura konfiguracji.
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"
Uruchamianie symulacji
Aby przeprowadzić 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ń:
- Czas oczekiwania podany w milisekundach.
- Przepustowość podana w kbitach lub Mbitach.
- Utrata pakietów (jako wartość procentowa).
Aby na przykład ustawić opóźnienie 300 ms, przepustowość 100 kbit i utratę pakietów na poziomie 50%, uruchom:
bash NetworkSimulation.sh 300ms 100kbit 50%
Aby ustawić opóźnienie na 100 ms, przepustowość na 1 Mbit i utratę pakietów na 0%, uruchom polecenie:
bash NetworkSimulation.sh 100ms 1mbit 0%
Weryfikowanie symulacji
Po wykonaniu skryptu NetworkSimulation.sh sprawdź, czy symulacja sieci jest prawidłowo skonfigurowana i działa zgodnie z oczekiwaniami, używając poleceń Linux ping i curl. Aby sprawdzić opóźnienie, użyj polecenia ping, a aby sprawdzić przepustowość, użyj polecenia curl.
Na przykład poniżej znajdziesz oczekiwane dane wyjściowe polecenia ping w przypadku symulacji wykonanej za pomocą polecenia 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 średni czas oczekiwania bliski 108 ms, co jest zgodne z wartością 100 ms określoną w symulacji. Zgłaszane opóźnienie może się nieznacznie różnić od określonej wartości.
W tym samym przykładzie poniżej przedstawiono oczekiwane dane wyjściowe po uruchomieniu 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 podaje średnią szybkość pobierania na poziomie 49220 bajtów na sekundę, co jest zgodne z oczekiwaniami w przypadku szybkości 500 kbitów określonej w symulacji. To normalne, że raportowana przepustowość nieznacznie różni się od podanej wartości.