Esta página descreve como simular diferentes condições de rede em dispositivos de hardware Android Automotive de maneira escalonável e com pouca manutenção. Essa simulação de rede independente de ambiente usa ferramentas Linux comumente disponíveis que podem ser executadas em dispositivos de hardware Android Automotive.
As seções a seguir descrevem como configurar e executar uma simulação de rede em dispositivos de hardware Android Automotive.
Requisito de kernel
Para habilitar a simulação de rede em um dispositivo em teste (DUT), os módulos ifb e netem do Linux devem ser configurados no arquivo de configuração do kernel, conforme mostrado abaixo:
# Network simulation config fragment start
CONFIG_NET_SCH_NETEM=y
CONFIG_IFB=y
CONFIG_NET_ACT_MIRRED=y
# Network simulation config fragment end
Configurar simulação
Todas as simulações de rede ou simulações de limitação devem ser conduzidas em um dispositivo em teste (DUT). Esta simulação usa os utilitários Linux tc e NetEm para controlar o tráfego de rede no controlador de interface de rede (NIC) com base na política e nas regras de controle.
Para configurar a simulação, faça o seguinte:
- Conecte o DUT e o servidor host à Internet.
- Crie o script
NetworkSimulation.shcopiando-o do código fornecido na seção de scriptNetworkSimulation.she faça download dele no servidor host. - Conecte o servidor host ao DUT. Certifique-se de que o DUT apareça na lista de dispositivos conectados executando
adb devices -l.
Para obter uma ilustração da arquitetura de configuração, consulte a figura a seguir:
Figura 1. Arquitetura de configuração.
Script NetworkSimulation.sh
O arquivo de script NetworkSimulation.sh contém comandos adb que executam a simulação de rede. Copie o seguinte em um arquivo chamado 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"
Executar simulação
Para executar uma simulação de rede, os comandos adb no arquivo de script NetworkSimulation.sh usam argumentos de linha de comando para definir valores.
Para especificar a latência, a largura de banda e a perda de pacotes que você deseja simular, execute o script NetworkSimulation.sh com os seguintes argumentos de linha de comando:
- Latência, especificada em ms.
- Largura de banda, especificada em kbit ou mbit.
- Perda de pacotes, como porcentagem.
Por exemplo, para definir uma latência de 300 ms, largura de banda de 100 kbit e perda de pacotes de 50%, execute:
bash NetworkSimulation.sh 300ms 100kbit 50%
Para definir uma latência de 100 ms, largura de banda de 1 mbit e perda de pacote de 0%, execute:
bash NetworkSimulation.sh 100ms 1mbit 0%
Verifique a simulação
Depois de executar o script NetworkSimulation.sh , verifique se a simulação de rede está configurada corretamente e funcionando conforme esperado usando os comandos ping e curl do Linux. Use o comando ping para verificar a latência e o comando curl para verificar a largura de banda.
Por exemplo, a seguir está a saída esperada de ping para uma simulação executada com 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
Este exemplo mostra que ping reporta uma perda de pacotes de 10% e uma latência média próxima de 108ms, o que é esperado para o valor de 100ms especificado na simulação. É normal que a latência relatada seja um pouco diferente do valor especificado.
Para o mesmo exemplo, a seguir está a saída esperada da execução do comando 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
Este exemplo mostra que curl relata a velocidade média de download de 49.220 Bps, que é a esperada para os 500 kbit especificados na simulação. É normal que a largura de banda relatada seja um pouco diferente do valor especificado.