הדמיה של רשתות ב-Android Automotive OS (AAOS)

בדף הזה מוסבר איך לדמות תנאי רשת שונים במכשירי חומרה של Android Automotive בצורה שניתנת להרחבה ודורשת תחזוקה מועטה. סימולציית הרשת הזו לא תלויה בסביבה, והיא משתמשת בכלים נפוצים של Linux שאפשר להפעיל במכשירי חומרה עם Android Automotive.

בקטעים הבאים מוסבר איך להגדיר ולהפעיל סימולציה של רשת במכשירי חומרה של Android Automotive.

דרישות ליבה

כדי להפעיל סימולציה של רשת במכשיר שנבדק (DUT), צריך להגדיר את המודולים של Linux‏ ifb ו-netem בקובץ התצורה של ליבת המערכת, כמו שמוצג בהמשך:

# Network simulation config fragment start
CONFIG_NET_SCH_NETEM=y
CONFIG_IFB=y
CONFIG_NET_ACT_MIRRED=y
# Network simulation config fragment end

הגדרת סימולציה

כל הסימולציות של רשתות או של הגבלת רוחב פס חייבות להתבצע במכשיר שנבדק (DUT). הסימולציה הזו משתמשת בכלי השירות של Linux‏ tc ו-NetEm כדי לשלוט בתעבורת הרשת בבקר ממשק הרשת (NIC) על סמך מדיניות הבקרה והכללים.

כדי להגדיר את הסימולציה:

  1. מחברים את המכשיר הנבדק ואת שרת המארח לאינטרנט.
  2. יוצרים את הסקריפט NetworkSimulation.sh על ידי העתקה שלו מהקוד שמופיע בקטע הסקריפט NetworkSimulation.sh ומורידים אותו לשרת המארח.
  3. מחברים את שרת המארח ל-DUT. מוודאים שה-DUT מופיע ברשימת המכשירים המחוברים על ידי הפעלת adb devices -l.

האיור הבא מציג את ארכיטקטורת ההגדרה:

nw-sim

איור 1. ארכיטקטורת ההגדרה.

הסקריפט NetworkSimulation.sh

קובץ הסקריפט NetworkSimulation.sh מכיל פקודות adb שמריצות את סימולציית הרשת. מעתיקים את הקוד הבא לקובץ בשם 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"

ביצוע הסימולציה

כדי להריץ סימולציה של רשת, הפקודות adb בקובץ הסקריפט NetworkSimulation.sh משתמשות בארגומנטים של שורת הפקודה כדי להגדיר ערכים.

כדי לציין את זמן האחזור, רוחב הפס ואובדן המנות שרוצים לדמות, מריצים את הסקריפט NetworkSimulation.sh עם הארגומנטים הבאים של שורת הפקודה:

  • זמן האחזור, שצוין באלפיות השנייה.
  • רוחב פס, שצוין ביחידות kbit או mbit.
  • אובדן מנות, כאחוז.

לדוגמה, כדי להגדיר זמן אחזור של 300 אלפיות השנייה, רוחב פס של 100kbit ואובדן של 50% מהחבילות, מריצים את הפקודה:

bash NetworkSimulation.sh 300ms 100kbit 50%

כדי להגדיר זמן אחזור של 100ms, רוחב פס של 1mbit ואובדן חבילות של 0%, מריצים את הפקודה:

bash NetworkSimulation.sh 100ms 1mbit 0%

אימות הסימולציה

אחרי שמריצים את סקריפט NetworkSimulation.sh, צריך לוודא שסימולציית הרשת מוגדרת בצורה נכונה ופועלת כמצופה באמצעות הפקודות ping ו-curl של Linux. משתמשים בפקודה ping כדי לבדוק את זמן האחזור ובפקודה curl כדי לבדוק את רוחב הפס.

לדוגמה, הפלט המצופה של ping עבור סימולציה שהופעלה באמצעות 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

בדוגמה הזו אפשר לראות ש-ping מדווח על אובדן מנות בשיעור של 10% ועל חביון ממוצע של כ-108 אלפיות השנייה, שזה מה שצפוי לערך של 100 אלפיות השנייה שצוין בסימולציה. בדרך כלל יש הבדל קטן בין זמן האחזור שמדווח לבין הערך שצוין.

בדוגמה הזו, הפלט הצפוי של הרצת הפקודה 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

בדוגמה הזו אפשר לראות ש-curl מדווח על מהירות הורדה ממוצעת של 49,220 Bps, שזה מה שצפוי ל-500kbit שצוין בסימולציה. זה נורמלי שרוחב הפס המדווח יהיה שונה מהערך שצוין בהפרש קטן.