Pentagram Cerberus P6361 – rzut okiem na bezpieczeństwo

tl;dr Router starawy, bezpieczeństwo żadne, Pentagram to Tenda.

Razem z laptopem rodzice kupili parę lat temu router, właśnie tytułowy Pentagram Cerberus P6361. Byłem lekko zły, że nie konsultowali ze mną zakupu, ale kupili go za grosze, nie wiem czy nie w Biedronce. Obejrzałem go, stwierdziłem, że co prawda OpenWrt się nie da zainstalować, ale sensowne minimum jest (802.11n, możliwość włączenia WPA2 i wyłączenia WPS), więc został, pełniąc tak naprawdę rolę AP, za routerem na Raspberry Pi. Pobór prądu znikomy, sprzęt działał zaskakująco stabilnie, z racji tego, że był w sieci lokalnej, logowanie tylko po HTTP nie miało większego znaczenia.

Często się słyszy o słabych zabezpieczeniach w routerach, zwłaszcza producentów specjalizujących się w tańszym sprzęcie, więc przy stwierdziłem, że poszukam błędów w ramach zabawy. Uruchomiłem Burp, zalogowałem się do routera i postanowiłem zrobić najprostszą rzecz, czyli zresetować router. Request trochę mnie zaskoczył, bo po skopiowaniu jako komenda curl wyglądał następująco:

curl -i -s -k -X $'GET' \
-H $'Host: 192.168.1.1:8081' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0' -H $'Accept: */*' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Referer: http://192.168.1.1:8081/system_reboot.asp' -H $'If-Modified-Since: 0' -H $'Cookie: language=en; admin:language=en' -H $'Connection: close' \
-b $'language=en; admin:language=en' \
$'http://192.168.1.1:8081/goform/SysToolReboot'

Zgadza się, nie ma tam żadnych danych związanych z sesją. Uruchomienie polecenia w konsoli, poza przeglądarką i następujący po tym reboot potwierdzają – po prostu wysyłamy request a router bez żadnego uwierzytelniania wykonuje polecenie.

No dobrze, to tylko reboot, czy można zrobić coś ciekawszego? Stwierdziłem, że najważniejsze co można z routera uzyskać, to hasło administratora i hasło do WiFi. Cerberus P6361 posiada możliwość backupu konfiguracji. Efektem jej pobrania jest plik tekstowy, zawierający otwartym tekstem pełną konfigurację, włącznie z wszystkimi hasłami. Zaskoczenia nie było – również ją można pobrać bez uwierzytelniania:

curl -i -s -k -X $'GET'     -H $'Host: 192.168.1.1:8081' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Referer: http://192.168.1.1:8081/system_backup.asp' -H $'Cookie: language=en; admin:language=en' -H $'Connection: close' -H $'Upgrade-Insecure-Requests: 1'     -b $'language=en; admin:language=en'     $'http://192.168.1.1:8081/cgi-bin/DownloadCfg/RouterCfm.cfg' 

Game over. Przyznaję, że po tym, co zobaczyłem, odeszła mnie ochota na dalszą zabawę, przynajmniej z tą wersją firmware:

Current system version: V5.07.18_pl_PEN; Publishing date: Nov 7 2011
Software version V5.07.18_pl_PEN
Hardware version V1.0

Pamiętałem, że dawno temu pobrałem nowszą wersję firmware’u (V5.07.21), ale nie zaktualizowałem go z braku czasu. Postanowiłem sprawdzić na stronie producenta, czy są nowsze wersje, żeby zaktualizować i sprawdzić przed zgłoszeniem czy bug nadal występuje i… niespodzianka. Strona producenta zniknęła. Liczyłem, że znajdę jakieś linki do firmware w necie, poszperałem więc nieco i okazało się, że Pentagram to tak naprawdę Tenda (co łatwo można potwierdzić na podstawie MAC adresu), czyli producent, którego routery zawierają mnóstwo podatności tego typu[1]. W znacznie nowszym firmware, którego, nawiasem nie widzę do pobrania ze strony producenta – jest 5.07.46 z 2013. Przy czym opieram się na tym, że wersja i rozmiar fimware są podobne, pewności, że Pentagram Cerberus P6361 to Tenda W316R nie mam, routera zepsuć nie chcę, więc chwilowo nie wymieniam – pobawię się intensywniej jak znajdę zastępcę.

Część smutna. Domyślnie router udostępnia interfejs do zarządzania na wszystkich interfejsach (adres 0.0.0.0) i wygląda, że nie ma dostępnego załatanego firmware’u. Rzut oka na portale z używanym sprzętem pokazuje, że sporo ludzi sprzedaje te routery. Ceny od 20 zł w górę. Jak się ktoś bardzo postara, to i nowy w sklepie znajdzie. Polecam kupić coś innego. Jeśli ktoś musi używać ww. routera, polecam pokombinować z niewystawianiem panelu zarządzania czy to przez zmianę adresu na którym słucha, czy trickiem z przekierowaniem portu opisanym przy podobnej okazji[2]. Wygląda na bardzo podobny błąd.

Przy czym najlepiej tego typu podatny router wymienić (co przy najbliższej okazji uczynię, choć jest używany sporadycznie), ponieważ za sprawą CSRF atak można wykonać od strony sieci LAN, więc brak wystawionego na świat interfejsu nie do końca zabezpiecza przed wykonaniem zdalnego ataku.

Shodan zwrócił zaskakująco mało wyników, ZoomEye nieco więcej, ale przypuszczam, że te sprzęty po prostu mają się już ku schyłkowi (patrz [2]). Ew. złe zapytania zrobiłem – niestety w tej chwili nie mam już dostępu do routera. Zdecydowałem się opisać, bo zabawa i przednia, i prosta, exploit opublikowany był jeszcze w zeszłym roku, choć sprzęt starawy, a o dziurach w routerze zawsze warto przypomnieć – może ktoś załata/wymieni.

[1] Zmiana serwerów DNS jest kolejną ważną rzeczą. W sumie ważniejszą, niż hasło do WiFi, zwł. jeśli mowa o zdalnym sprzęcie.
[2] Aktualnie zapytanie zwraca poniżej 7 tys. wyników. W masową aktualizację nie wierzę, czyżby sprzęty nie przeżywały 6 lat? W sumie w tym przypadku dobrze…

Nowy router (TP-Link Archer C50)

Poprzedni router wytrzymał cztery lata. Jakiś czas temu zaczął się wieszać – 50% strat pakietów po WiFi, pomagał restart prądowy. Nie było to może bardzo częste, ale na tyle drażniło, że dopisałem nawet codzienny reboot w cronie. Co zmniejszyło problem, ale go nie rozwiązało. I w ogóle problem jakby się nasilał. Od strony systemu (OpenWrt) nic ciekawego w logach, przełożenie w chłodniejsze miejsce, tj. zdjęcie z modemu kablowe jakby trochę pomogło, więc podejrzewam albo przegrzewanie się, albo wysychający kondensator. Tylko nie pasuje mi do tej teorii reset rozwiązujący problem na losowy okres czasu.

Teoretycznie nic, z czym nie mógłbym powalczyć, ale… trochę szkoda czasu. No i są inne powody. Po pierwsze, poprzedni router już się zwrócił. Po drugie jest to wspaniały pretekst do wymiany sprzętu na coś z 5 GHz, bo na 2,4 GHz od dawna robi się tłoczno, a coraz więcej sprzętów obsługuje 5 GHz. Wreszcie zajrzałem na stronę OpenWrt i tam wszędzie warningi, że sprzęty z 4 MB flash lub 32 MB RAM przestają być wspierane. Swoją drogą, może właśnie to była przyczyna niestabilności? Szczególnie, że trochę przeładowany softem i ogólnie na krawędzi był, zdecydowanie wbrew zaleceniom, jak je teraz czytam.

Tak czy inaczej, kupiłem sprzęt. Wybór był nieco skomplikowany, choć wymagania miałem proste: 8 MB flash, 64 MB RAM, wsparcie dla 5 GHz i 802.11ac i oczywiście wsparcie przez OpenWrt. Szybko ustaliłem, że jednym z tańszych urządzeń dostępnych w Polsce spełniających kryteria jest TP-Link Archer C50. Jednak żeby nie było zbyt prosto, okazało się, że wsparcie jest zależne od wersji hardware. Ogólnie nie rozumiem tej mody wśród producentów, żeby robić wiele różnych urządzeń z tą samą nazwą. Wersja hardware spokojnie mogła by być ujęta w nazwie, przynajmniej klient od razu wiedziałby, co kupuje.

Wyszło mi, że potrzebuję albo v3, albo v4. Przy czym sprzęt jest w zasadzie ten sam, a główny problem jest z formatem obrazu – prawdopodobnie v4 nie dorobi się „klikalnej” wersji obrazu na stronie i trzeba będzie się bawić w samodzielne składanie obrazu. Nie jest to jednak coś, co spędza mi sen z powiek.

Na Allegro nie jest łatwo ustalić wersję hardware. Mało który sprzedawca chwali się wprost. Zadałem pytanie o wersję chyba czterem albo pięciu, odpisał jeden. I kupiłbym tam, gdyby nie fakt, że zdążył zakończyć sprzedaż. Chociaż w sklepie na stronie nadal były dostępne. Ostatecznie kupiłem u innego sprzedawcy kota w worku. Kot okazał się być v4.

Tradycyjnie nie przechodziłem na OpenWrt od razu, tylko dałem szansę firmware’owi producenta. Okazało się, że wgrany jest najnowszy dostępny. Tradycyjnie dostępnych wiele opcji konfiguracyjnych. Można nawet wybrać z GUI cykliczny reboot, czego nie było w poprzednich wersjach. Można zdefiniować tryb nocny, kiedy diody mają być wyłączone i ustalić – niezależnie – moc każdej z kart sieciowych (low-medium-high). Wygląda to naprawdę przyzwoicie. Dwa zakresy oznaczają de facto dwa niezależne interfejsy sieciowe i prawdopodobnie dwie oddzielne karty z dwiema antenami każda. Obie sieci ustawiłem na średnią moc.

Ogólnie po trzech tygodniach korzystania jestem zadowolony. Na razie zostaje firmware producenta. Jak na sprzęt za 110 zł działa bardzo fajnie i stabilnie. Tam gdzie to możliwe korzystam z 5 GHz. Pokazuje niby słabszy sygnał, niż na 2,4 GHz ale działa bardzo dobrze i speedtest na luzie, powtarzalnie, pokazuje zarówno maksymalny upload, jak i download w stosunku do tego co oferuje ISP.

Testy szybkości sieci wewnętrznej i pomiary poboru prądu – jak mi się przypomni.

Jak usprawnić sieć w domu? cz. 5

Wpis, który chronologicznie powinien pojawić się jako drugi, ponieważ dotyczy stanu wyjściowego, czyli WiFi. Oczywiście sprzęt to opisywany niedawno TP-Link WR841 z OpenWrt. Banana Pi wpięte do portu LAN, czyli na 100 Mbps, ale głównym ogranicznikiem jest sieć bezprzewodowa. Jasności dodam, że są to wyniki sprzed optymalizacji, ale o poprawianiu WiFi napiszę innym razem. Warto też zaznaczyć, że wyniki jako jedyne są przeprowadzane na środowisku nieizolowanym, „produkcyjnym”, tj. z podłączonymi innymi urządzeniami. O ile nie powinny specjalnie rzutować na wynik, bo nie korzystały intensywnie, to na pewno wpływały w jakiś sposób ujemnie.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.04  sec   125 MBytes  17.5 Mbits/sec  10.997 ms  1908/16040 (12%)  
[  4] Sent 16040 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  67.7 MBytes  9.46 Mbits/sec  186             sender
[  4]   0.00-60.00  sec  67.6 MBytes  9.45 Mbits/sec                  receiver

3.
— 192.168.0.139 ping statistics —
600 packets transmitted, 598 received, 0% packet loss, time 61057ms
rtt min/avg/max/mdev = 0.766/2.303/42.995/4.036 ms

4.
— 192.168.0.139 ping statistics —
600 packets transmitted, 596 received, 0% packet loss, time 60280ms
rtt min/avg/max/mdev = 1.918/3.953/42.202/3.747 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.04 sec  6.27 GBytes  15.0 Mbits/sec  4.305 ms  71880/822270 (8.7%)
[  4] Sent 822270 datagrams
[…]
9.
Inea Orange

Jak widać stan wyjściowy nie był imponujący. Rzekłbym nawet, że zaskakująco słabe wyniki. Widać też, że brakuje części testów – przyznaję, że nie miałem ani cierpliwości, ani warunków. Ponieważ ustawienia lekko się zmieniły w międzyczasie, zostawię z brakiem, żeby nie fałszować. Zaskakuje słaby wynik transmisji w teście syntetycznym, w szczególności w porównaniu z testem do internetu.

Jak usprawnić sieć w domu? cz. 2

W poprzedniej części było o genezie cyklu, sposobach pomiaru i najlepszym możliwym połączeniu, czyli bezpośrednio skrętką. Ze względu na zainteresowanie paru osób wynikami testów PLC, przeskakuję WiFi i przechodzę do wyników testów PLC.

Na testy dostałem TL-PA4010P kit. Z tego co widzę, w wyszukiwarce znajduje zarówno, że jest to AV500 jak i AV600, ale na opakowaniu było AV600, więc link jest prawdopodobnie prawidłowy. Do podłączenia podszedłem zupełnie laicko – z tego miejsca w mieszkaniu internet ma trafić do tamtego – zupełnie nie wnikałem w to jakie są fazy i czy po drodze są listwy.

Błąd. Zalecane jest wpięcie w ten sam obwód i bezpośrednio do gniazdka, z pominięciem listew zasilających. W związku z tym wykonałem kilka testów, w tym wpisie zajmę się tylko wynikami pierwszej, najgorszej topologii – jeden kontroler bezpośrednio w gniazdku, drugi za listwą z włącznikiem i wpiętej w nią listwą zwykłą. Od razu podaję link do wskazówek jak najlepiej podłączyć PLC. Wyniki z optymalnego połączenia są lepsze i będą w kolejnym wpisie, ten to bardziej „jakoś wpiąłem i tak działało”.

Na wstępie miałem małe rozczarowanie, które rozwiewa dopiero lektura powyższego linka. AV600 oznacza 600 Mbps. I jakkolwiek przypuszczałem, że będzie to 300 upload, 300 download, to aby taki wynik osiągnąć, trzeba by mieć w urządzeniu port 1 GE. Tymczasem jak widać są tam porty 100 Mbps i taką prędkość linkowania się z urządzeniami osiągałem. Nie jest to dla mnie wielki problem, bo mój router także ma porty 100 Mbps, ale jeśli ktoś liczy na szybkie połączenie z NAS itp., to może się zawieść.

Samo podłączenie jest proste – sprowadza się do włożenia urządzeń w gniazdka, wpięcia ethernetu i naciśnięciu przycisku do parowania.

Wyniki z testu w niekomfortowych warunkach:

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec   547 MBytes  76.5 Mbits/sec  1.195 ms  0/70059 (0%) 
[  4] Sent 70059 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   418 MBytes  58.4 Mbits/sec    0             sender
[  4]   0.00-60.00  sec   417 MBytes  58.3 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60299ms
rtt min/avg/max/mdev = 3.310/3.657/13.757/0.965 ms
4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60338ms
rtt min/avg/max/mdev = 21.582/24.445/35.531/2.837 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  32.6 GBytes  77.9 Mbits/sec  1.447 ms  5136/4278660 (0.12%) 
[  4] Sent 4278660 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  24.6 GBytes  58.6 Mbits/sec    0             sender
[  4]   0.00-3600.00 sec  24.5 GBytes  58.6 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3625078ms
rtt min/avg/max/mdev = 2.759/4.280/16.010/1.247 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3618568ms
rtt min/avg/max/mdev = 22.662/24.105/106.475/2.133 ms, pipe 2

9.
Inea Orange

Jak widać nawet w tych niekomfortowych warunkach zestaw radził sobie przyzwoicie. Brak strat pakietów, niskie i stabilne opóźnienia. Widać wzrost czasu odpowiedzi w zależności od wielkości pakietu i jak sprawdziłem empirycznie pojawia się on przy rozmiarze pakietu między 900 a 1000 i jest to jedyna istotna różnica w stosunku do zwykłęgo ethernetu.

Niezła szybkość transmisji danych między urządzeniami nie wzbudziła mojej czujności; to, że coś chyba jest nie w porządku zacząłem podejrzewać dopiero po ostatnim teście, po podłączeniu jednego z końców kabla do routera. Dane z internetu pobierały się zwyczajnie wolno i… nie miało to pokrycia w testach syntetycznych. W tym momencie uprzedzę fakty i od razu napiszę, że przy zalecanym połączeniu wyniki w ostatnim teście były identyczne jak na kablu. Ale to już w kolejnym wpisie.

Na koniec słowo o zużyciu energii, ponieważ są to urządzenia aktywne. Podłączyłem urządzenie do watomierza. Bez podłączonego komputera pokazał 1,5W, po podłączeniu komputera i podczas transmisji danych 2,2-2,3W. Jeśli wyłączymy komputer, PLC po paru minutach przechodzi w stan uśpienia i pobiera wówczas 0,8W.

Jak usprawnić sieć w domu? cz. 1

Wstęp

Wpis jest wstępem do serii mini testów, które przeprowadziłem lub przeprowadzę w najbliższym czasie. Chodzi o rozwiązanie kwestii dostępu urządzeń w domu do internetu i zapewnienia ich łączności pomiędzy sobą. Powodem było moje WiFi, które choć doprowadzone aktualnie do zadowalającej używalności, niekoniecznie było optymalne zarówno jeśli chodzi o stabilność połączenia, jak i oferowane przepływności czy opóźnienia. Na rynku istnieje kilka rozwiązań, które mają za zadanie pomóc w dostarczeniu sieci, niedawny wpis o PLC przypomniał mi, że kiedyś interesowałem się bardziej tematem, a technika poszła naprzód.

Szybkie pytanie na wewnętrznym forum firmowym czy komuś nie zalega parka PLC spotkała się z pozytywnym odzewem (uroki pracy w większej firmie, z otwartymi geekami – ciekaw jestem czego nie dałoby się znaleźć… ;-)) i okazało się, że nie tylko zalega chwilowo, ale są różnego typu, stąd pomysł na porównanie i podzielenie się wnioskami.

Nie ma to być test uniwersalny ani profesjonalny – robię go przede wszystkim dla siebie i w dostępnym mi środowisku (a np. typ ścian czy otoczenie może mieć kolosalne znaczenie dla WiFi, podobnie wygląda kwestia sieci elektrycznej dla PLC), mam jednak nadzieję, że uda się wyciągnąć jakieś wnioski ogólne i może komuś pomoże w wyborze rozwiązania.

O ile nie napisano inaczej, wykorzystywany jest firmware dostarczony z urządzeniami. Systemy nie są specjalnie tuningowane – ot, linuksowy default. Z oczywistych względów trudno mi wypowiadać się na temat stabilności poszczególnych rozwiązań w dłuższym okresie czasu.

Topologia sieci

Topologia sieci jest następująca: modem ISP (kablówka) w przedpokoju, podłączony ethernetem do routera. Router (obecnie TL-841) z wgranym OpenWRT/LEDE dostarcza internet reszcie urządzeń po WiFi. Przedpokój to w miarę centralny punkt w mieszkaniu, odległość od urządzeń końcowych (laptopy, smartfony) ok. 7 metrów, część urządzeń pracuje w 802.11n, część w 802.11g i tak zostanie – modernizacja czy wymiana końcówek są nieopłacalne.

Dla jasności: to działa od lat i w zasadzie wystarcza, jeśli chodzi o przepływność. Wystarczało i na 802.11g, gdy transfery (do mojego laptopa) wynosiły 15-18 Mbps (wg speedtest.net). Po zmianie routera na nowszy jest lepiej – 30 Mbps. Nadal jest to gorzej niż to, co oferuje operator (60 Mbps), ale w zupełności wystarcza do transferów „z zewnątrz”. Zobaczymy jednak, czy są jakieś alternatywy i czego się spodziewać.

Ani mieszkanie w kamienicy, ani dość zaszumiony eter na 2,4 GHz, nie pomagają w dobrym działaniu WiFi, więc nieco gorzej wygląda sytuacja, jeśli chodzi o stabilność. Rzadko, bo rzadko, ale zdarzały się problemy (straty do routera, wzrost czasów odpowiedzi). Zwykle, w czasach gdy korzystałem z oryginalnego firmware producenta, wystarczał restart routera lub sprawdzenie jak wygląda sytuacja w eterze przy pomocy WiFi Analyzera i zmiana kanału na wskazany jako najlepszy (czyli najmniej używany).

Swoją drogą zmiana kanału na nieużywany jest najprostszym sposobem na poprawę zasięgu czy jakości WiFi, więc jeśli ktoś szuka odpowiedzi na pytanie jak poprawić sygnał WiFi, to zdecydowanie polecam zacząć od tego.

Pomiary

Wykonywane są cztery testy wewnętrzne, oraz ogólny test przy pomocy speedtest.net (beta, czyli bez Flash). Testy wewnętrzne wykonywane były w dwóch wariantach: krótkim (w założeniu ok. 60s) i długim (ok. 3600s).

  1. iperf3 -u -b 0 -t 60 -c 192.168.10.126
  2. iperf3 -t 60 -c 192.168.10.126
  3. ping -i 0.1 -c 600 192.168.10.126
  4. ping -s 1500 -i 0.1 -c 600 192.168.10.126
  5. iperf3 -u -b 0 -t 3600 -c 192.168.10.126
  6. iperf3 -t 3600 -c 192.168.10.126
  7. ping -i 0.1 -c 36000 192.168.10.126
  8. ping -s 1500 -i 0.1 -c 36000 192.168.10.126
  9. speedtest.net

Jak widać jest to pomiar przepływności przy użyciu pakietów UDP, TCP oraz pomiar opóźnień przy pomocy ping ze standardową oraz maksymalną (MTU 1500) wielkością pakietu. Ostatni test to „realne” połączenie z internetem. Wykorzystywane serwery mojego ISP oraz Orange, który często był wskazywany jako najlepszy.

Za klienta służy mój laptop z Debianem, za sondę posłużyło Banana Pi (jedyny SoC z gigabitowym portem, który miałem pod ręką). W obu systemach wykorzystany iperf3. Pomiar nie był jedyną czynnością wykonywaną przez laptopa, ale – poza testami WiFi – był wykorzystany osobny interfejs, a obciążenie było typowe, bez ekstremów.

Dodatkowo mogą pojawić się uwagi, jeśli coś nieplanowanego podczas testów rzuci mi się w oczy.

Wyniki bazowe

Na wstępie spiąłem oba urządzenie kablem „na krótko” i uruchomiłem testy. Synchronizacja oczywiście 1 Gbps.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec  6.07 GBytes   869 Mbits/sec  0.136 ms  592341/795464 (74%)
2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  5.47 GBytes   784 Mbits/sec  138             sender
[  4]   0.00-60.00  sec  5.47 GBytes   783 Mbits/sec                  receiver
3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62319ms
rtt min/avg/max/mdev = 0.291/0.372/0.549/0.031 ms
4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62290ms
rtt min/avg/max/mdev = 0.427/0.549/24.612/0.996 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec   374 GBytes   893 Mbits/sec  0.220 ms  36944269/49033499 (75%)
6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec  8735             sender
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec                  receiver
7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745436ms
rtt min/avg/max/mdev = 0.278/0.369/40.914/0.398 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745111ms
rtt min/avg/max/mdev = 0.260/0.500/2.861/0.046 ms

9.
Inea Orange [1]

Jak widać bez większych niespodzianek – osiągnięte wyniki wynikają raczej z ograniczenia samego Banana Pi. Mimo to widać, że jest szybko, czasy odpowiedzi niskie i jest stabilnie.

[1] W przypadku pomiaru łącz topologia była nieco inna – laptop wpięty po kablu do portu routera (port 100 Mbps). W zasadzie dokładniej byloby wpiąć go bezpośrednio w modem kablowy, ale router jest stałym elementem zestawu w pozostałych topologiach… Dostawca internetu (Inea) deklaruje 60/10 Mbps.