Uroki korzystania z telefonu starego typu na przykładzie pobierania aplikacji moBILETu

Od początku lipca zmieniły się ceny biletów w Poznaniu[1]. Jestem przekleństwem sprzedawców telefonów GSM i od 6 lat mam niezawodny telefon Nokia 3110c. Z Javą. Bateria od początku ta sama, trzyma tydzień, ale mniejsza. Próbowałem zaktualizować cennik dla Poznania – system wykonał błąd itp. komunikaty. „OK, bywa” – myślę. Spróbowałem parokrotnie, w różnych dniach – to samo. Stwierdziłem, że zaktualizuję aplikację, tym bardziej, że w sumie nie wiem, czy to mój system wykonał błąd, czy moBILETu.

Przypomnienie hasła działa OK, teraz możesz się zalogować. Natomiast loginu nie sposób przypomnieć, a zalogować można się tylko jednym, wybranym kiedyś sposobem i może to być numer telefonu, adres email (który?), login (jaki?). A może błędne hasło, bo jeszcze coś się nie zaktualizowało? Nie wiadomo, bo komunikat to Niepoprawne hasło lub nazwa użytkownika. Proszę sprawdzić wpisywane dane. Skądinąd słuszny, ale czemu nie ma możliwości przypominania loginu? Np. wysyłanie go na adres email podany w systemie (hasło można przypomnieć tylko na komórkę, więc wysyłanie loginu na komórkę to słaby pomysł w przypadku jej przejęcia).

OK, w końcu zalogowałem się. Wybieram pobranie aplikacji, przepisuję CAPTCHA. Bo nie ma po prostu „pobierz”, jest personalizowany, unikatowy link, pod konkretny model telefonu (moBILET ma te dane u siebie) ważny 30 minut[2]. Kiedyś przysyłano SMS pobierający aplikację od razu na komórkę. Teraz nie. Zwykły SMS z linkiem. O takim: http://p.mobilet.info/ota/m/?DQ2OFQPTHN Zastanawiam się, jaki piękny umysł na to wpadł. Po pierwsze, na telefonach starego typu nie ma multitaskingu, więc trzeba gdzieś zapisać na boku. Po drugie, klepanie 43 znaków klasy wielkie, małe litery i znaki specjalne na komórce starego typu (a wiedzą, komu wysyłają linka) to szczyt ergonomii.

I część najlepsza: po dobraniu się do linka dostajemy Server not found (to już komunikat z desktopa). A czemu? Ano temu, że domena p.mobilet.info nie istnieje. Gwoli ścisłości, mobilet.info też nie istnieje. I wygląda na domenę dostępną do rejestracji. Ciekawe czy byłby to dobry sposób rozsyłania malware’u?

Normalnie wronan groteska! A bilet muszę kupić papierowy.

[1] Na absurdalnie drogie, więc korzystam z tego, że nie muszę korzystać z komunikacji miejskiej i poruszam się inaczej, głównie pieszo/rower, a z moBILETu nie korzystam już praktycznie, ale warto mieć bilet pod ręką. Nie to jednak jest przedmiotem notki.

[2] Można to (było) obejść o czym pisałem w notce o zabezpieczeniach moBILETu, ale zachowujmy się jak cywilizowani ludzie.

Banana Pi – krótka recenzja

Jak wspomniałem, zamówiłem Banana Pi. Zamówienie na Aliexpress, cena – 50 dolarów z wysyłką do Polski. Zdziwieniem i niejakim problemem był fakt, że mało kto na Aliexpress obsługuje PayPala. Przynajmniej ze sprzedających Banana Pi z darmową wysyłką. Tu porada – WBK oferuje coś takiego jak karty internetowe. Tanie, bezpieczne (prepaid), wygodne, ekologiczne (są wirtualne, otrzymujemy tylko PDF, bez plastiku), działają. Można doładowywać. Polecam.

Sprzęt przybył do mnie do domu 14 dni od dokonania płatności. Trochę szczęścia, bo kumpel, który zamówił kilka dni wcześniej, dostał równocześnie, a ze śledzenia paczki[1] wynikało, że przyleciały jednym samolotem. Cła itp. nie ma z uwagi na wartość – zwolnione z cła są przesyłki do 150, tylko nigdy nie pamiętam czy euro, czy dolarów.

Jako dystrybucję wybrałem Raspbiana dla Banana Pi 3.0. Nagrałem na kartę microSD Goodram[2] (się naprawiła), podłączyłem identycznie, jak Raspberry Pi, czyli aktywny hub UnitekY-206P, jeden kabel do dysku, drugi do Banana Pi do gniazda zasilania, trzeci (sygnał) z Banana do huba. Włączenie zasilania i… nic.

Odłączyłem dysk, nadal nic. W końcu odłączyłem kabel sygnałowy do huba i… ruszyło. Jest zauważalnie szybciej, niż na rpi. Znajomy podłączał z monitorem i stwierdził, że spokojnie nadaje się do komfortowego przeglądania poczty i WWW (oczywiście bez flasha). Tak na szybko: jest jeden LED, którym można sterować analogicznie jak w rpi, na dodatek umieszczony w miejscu, gdzie go widać. Przygotowany obraz działa, ale szału nie czyni – jest trochę śmieci, które można usunąć, typu pakiety w cache apta. Zgłoszone, pewnie poprawią przy następnym wydaniu.

Nie udało mi się uzyskać działającej konfiguracji z podłączeniem dysku. Zarówno podłączenie kabla sygnałowego do huba, jak i dysku 2,5″ powodują u mnie zgaśnięcie wszystkich LEDów i zwis Banana Pi (prąd jest pobierany, więc nie wyłączenie). Podejrzewałem problem z USB lub ładowaniem modułu kernela (nie wiedziałem jeszcze o naprawieniu się karty microSD). Ale nie, podłączenie samego kabla czy pendrive nie powoduje problemów.

Ostatecznie wziąłem ładowarkę od komórki i podłączyłem Banana do niej, a dysk do huba USB. W takiej konfiguracji działa[3]. Tyle, że tak nie może zostać. Zadałem pytanie na forum o Banana Pi, parę osób odpisało. Nie jestem sam. Wygląda, że albo Banana Pi jest bardziej wrażliwe, albo znaczenie ma feature Raspberry Pi pozwalający na zasilanie po USB (czego Banana Pi nie ma).

Podsumowując, zapowiada się ciekawie, choć pracowicie (znaczy będzie zabawa). Już przytargałem multimetr i będę starał się wyjaśnić o co chodzi z zasilaniem. Parę pomysłów mam, ale brakuje mi kabelków do testów.

Poza tym, developerzy ciężko pracują i przepraszają, że nie opublikowali źródeł sterownika do karty sieciowej (łamiąc GPL, nawiasem). Czyli obecnie 1 Gbit można mieć działający, ale tylko pod warunkiem użycia zamkniętego kernela/modułu, ze źródeł się nie da. Mam nadzieję, że się uwiną szybko, bo Banana Pi zapowiada się ciekawie.

[1] W pozytywnym szoku byłem, jak dzień czy dwa po płatności dostałem maila z numerem przesyłki i mogłem śledzić na stronie Poczty Polskiej.

[2] Wcześniej tradycyjne zdjęcie journala z ext4, zgłoszone devom, dla odmiany przyjęli do wiadomości, więc jest szansa, że kolejne wydania będą przyjazne dla nośników flash by default.

[3] Zwykle, bo czasem w momencie podłączania huba do Banana Pi potrafi zwisnąć. Ale jak wszystko jest podłączone przy starcie, działa OK.

OpenSSL AES benchmark

Mam dostęp do paru różnych maszyn, więc postanowiłem zrobić mini benchmark OpenSSL. Głównie z procesorami ARM. Wraz z kumplem z netu zebrało nam się na porównywanie wydajności różnych sprzętów. Poszło o nierewelacyjne osiągi OpenVPN na jego Banana Pi (nawiasem, do mnie też już Banan dotarł, wkrótce coś skrobnę).

Wszystkie testy na Linuksie (pochodne Debiana). Warunki niezupełnie „czyste”, bo maszyny normalnie działają (jakieś Xy, zwykłe usługi itp.), ale raczej dobrze oddaje możliwości – różnice między wynikami z netu pomijalne, maszyny raczej się nudzą. Testowane poleceniem openssl speed aes, w przypadku maszyn w których Linux widzi więcej niż jeden procesor, dodane –multi N, gdzie N  to ilość rozpoznawanych przez system rdzeni (z HT).

Na początek, w ramach punktu odniesienia, procesory Intela (testowane na architekturze amd64):

Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz (N=2)

aes-128 cbc     124896.83k   138273.46k   141166.08k   298696.36k   303164.07k
aes-192 cbc     105477.06k   116211.63k   117732.95k   246287.70k   249443.67k
aes-256 cbc      91720.90k    99602.26k   100765.95k   214892.54k   218794.67k

Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz (N=1)

aes-128 cbc      63276.43k    69732.33k    71320.92k   149509.14k   152286.27k
aes-192 cbc      53920.87k    58297.88k    59832.94k   126354.09k   128532.21k
aes-256 cbc      46232.08k    49934.93k    50964.99k   109278.55k   110320.76k

Intel(R) Atom(TM) CPU D525 @ 1.80GHz (N=4)

aes-128 cbc      30904.81k    46265.24k    53263.58k    55370.66k    55836.67k
aes-192 cbc      28137.17k    40040.66k    45127.08k    46556.50k    47162.91k
aes-256 cbc      29979.57k    36609.58k    39015.17k    39410.69k    39343.52k

Intel(R) Atom(TM) CPU N2800  @ 1.86GHz (N=4)

aes-128 cbc      63529.34k    67116.33k    67479.30k    69077.33k    70063.45k
aes-192 cbc      53305.24k    55930.01k    56726.87k    58294.95k    58384.38k
aes-256 cbc      46324.97k    48419.43k    49031.42k    49620.99k    49569.79k

Intel(R) Atom(TM) CPU N2800  @ 1.86GHz (N=1)

aes-128 cbc      25546.13k    28152.09k    29100.80k    29257.82k    29417.47k
aes-192 cbc      21745.97k    23033.45k    24188.43k    24440.15k    24491.35k
aes-256 cbc      18760.60k    20222.36k    20786.01k    20862.38k    20971.52k

Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz (N=2)

aes-128 cbc     139806.09k   153189.03k   157513.39k   329881.60k   336000.34k
aes-192 cbc     118517.33k   128203.82k   131191.81k   279747.24k   283568.81k
aes-256 cbc     102364.69k   110147.39k   111865.51k   240238.25k   242586.97k

Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz (N=1)

aes-128 cbc      69509.47k    76975.27k    79176.79k   166760.11k   168293.72k
aes-192 cbc      59564.63k    64345.22k    65814.19k   140067.50k   141836.29k
aes-256 cbc      51423.55k    55281.11k    56354.30k   120643.58k   121760.43k

Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (N=4)

aes-128 cbc     152665.50k   160758.55k   162619.56k   162693.12k   160432.13k
aes-192 cbc     128774.61k   134266.73k   136237.23k   136946.01k   136850.09k
aes-256 cbc     111035.63k   113086.31k   115218.09k   115126.95k   115452.59k

Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (N=1)

aes-128 cbc      64605.45k    79469.89k    80944.90k    81767.94k    81679.70k
aes-192 cbc      62476.10k    66903.19k    67975.42k    68745.33k    68009.98k
aes-256 cbc      54233.60k    56778.67k    57951.06k    58175.49k    58541.29k

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (N=4)

aes-128 cbc     178233.37k   197070.14k   202821.72k   204553.22k   203276.29k
aes-192 cbc     155289.71k   164140.12k   164286.98k   167794.69k   170915.16k
aes-256 cbc     134427.71k   141611.71k   145087.32k   145325.74k   144921.94k

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (N=1)

aes-128 cbc      93122.37k   101039.38k   104341.59k   105117.70k   104237.74k
aes-192 cbc      79544.40k    85362.03k    86720.00k    87005.87k    87758.17k
aes-256 cbc      69556.44k    73458.50k    74518.87k    74227.71k    73815.38k

AMD Sempron(tm) 2300+ (N=1) Test oczywiście dla architekury i386

aes-128 cbc      29157.09k    31077.91k    31887.50k    76258.89k    76728.08k
aes-192 cbc      25055.40k    26304.51k    26871.69k    65190.10k    65563.40k
aes-256 cbc      21279.27k    22447.52k    22859.69k    56840.22k    57122.08k

Tyle jeśli chodzi o procesory Intela, pora na benchmark openssl dla procesorów ARM:

Dockstar. Debian, architektura armel Feroceon 88FR131 rev 1 (v5l) 1,2GHz

aes-128 cbc      14013.23k    16435.69k    16982.28k    17336.92k    17317.89k
aes-192 cbc      12337.22k    14112.71k    15303.21k    14970.88k    14815.53k
aes-256 cbc      10989.90k    12474.70k    12831.67k    13312.00k    13218.91k

Raspberry Pi. Raspbian ARMv6-compatible processor rev 7 (v6l) 700 MHz

 aes-128 cbc      13241.53k    14935.94k    15386.52k    15716.75k    15576.54k
aes-192 cbc      11420.51k    13032.96k    13501.64k    13664.95k    13465.79k
aes-256 cbc      10378.09k    11521.94k    11991.62k    11855.19k    11988.44k

Banana Pi (N=2).

aes-128 cbc      38453.65k    45557.42k    47889.49k    48539.99k    48715.09k
aes-192 cbc      33638.03k    38975.96k    41001.13k    41532.42k    41694.55k
aes-256 cbc      30360.07k    34568.62k    36124.25k    36553.39k    36672.85k

Banana Pi (N=2) Debian armhf

aes-128 cbc      35393.00k    47858.58k    50317.74k    50995.88k    51183.62k
aes-192 cbc      35339.90k    40943.62k    43078.57k    43647.32k    43797.16k
aes-256 cbc      31896.82k    36317.72k    37956.01k    38405.80k    38532.44k

Feroceon 88F6282 rev 1 (v5l) 2,0 GHz

aes-128 cbc     20192.02k     24452.77k    25681.19k    25715.66k    26231.83k 
aes-192 cbc    18020.95k   21192.76k   22311.17k   22520.40k   22832.65k
aes-256 cbc    16372.28k    18963.20k   19705.60k   19748.15k  20109.48k

Cubieboard 3 (N=1)

aes-128 cbc 18192.97k 21387.56k 22688.77k 22623.23k 20960.60k 
aes-192 cbc 17613.03k 18595.58k 19475.20k 19543.38k 19595.26k
aes-256 cbc 15075.22k 16513.19k 17151.57k 17167.36k 17246.89k

Cubieboard 3 (N=2)

aes-128 cbc 40631.59k 43845.70k 44627.97k 45086.38k 45211.65k 
aes-192 cbc 35388.95k 36886.19k 38698.50k 38691.16k 39335.25k
aes-256 cbc 30851.77k 33802.65k 34321.41k 34171.56k 33778.35k

ODROID U3 (N=1)

aes-128 cbc 54399.00k 58485.80k 59575.38k 60536.83k 60385.96k 
aes-192 cbc 47215.06k 50994.73k 52349.35k 52738.73k 52731.90k
aes-256 cbc 41830.65k 44747.37k 45808.98k 46029.82k 45796.01k

ODROID U3 (N=4)

aes-128 cbc 216401.55k 233187.14k 237574.06k 237451.26k 239610.54k 
aes-192 cbc 187925.35k 203781.87k 209056.51k 202832.55k 210911.23k
aes-256 cbc 166399.47k 178351.36k 182334.38k 183437.99k 183795.71k

Jetson TK 1 (N=1)

aes-128 cbc 101615.96k 105911.73k 109555.46k 110431.91k 110553.77k 
aes-192 cbc 87593.79k 92699.41k 95376.04k 96003.75k 96133.12k
aes-256 cbc 76532.53k 80948.01k 83111.77k 83704.15k 83817.81k

Jetson TK 1 (N=4)

aes-128 cbc 400560.99k 417232.81k 426956.88k 411591.68k 423813.12k 
aes-192 cbc 327749.78k 351935.28k 364130.73k 377968.98k 379052.03k
aes-256 cbc 300564.41k 319599.06k 325819.65k 328858.28k 330391.55k

Marvell Armada 370/XP (Device Tree) (N=1)

aes-128 cbc      41961.95k    50546.82k    53594.28k    54535.26k    53449.35k
aes-192 cbc      37750.78k    44366.68k    46631.68k    47299.58k    46623.40k
aes-256 cbc      33172.31k    37925.33k    40553.30k    41431.04k    40962.73k

Marvell Armada 370/XP (Device Tree) (N=4)

aes-128 cbc     166412.45k   201555.37k   213535.57k   217358.68k   213336.06k
aes-192 cbc     149429.29k   177001.39k   186009.77k   189066.24k   186086.74k
aes-256 cbc     131774.20k   151056.06k   161813.59k   165605.38k   163482.28k

Raspberry Pi 3 (N=1; 32 bit OS)

aes-128 cbc      41017.91k    48669.00k    51254.02k    51984.38k    52215.81kaes-192 cbc      35728.01k    41270.60k    43058.26k    43608.06k    43783.51kaes-256 cbc      32115.97k    36434.37k    38004.48k    38426.71k    38482.83k

Jak widać, trochę przepaść między ARM a Intelami w wynikach całkowitych. Dodatkowo sprawę wydajności pogarsza fakt, że OpenVPN nie wątkuje (podobno ma być dodane w wersji 3), czyli klient wykorzystuje tylko jeden rdzeń, co w przypadku Banana Pi oznacza w praktyce połowę podanej wyżej wydajności.

PS. Wpis będzie edytowany/uzupełniany.

UPDATE: dodaję wyniki dla Banana Pi uzyskane osobiście na czystym Debianie w normalnej architekturze armfh. Nie jestem pewien, czy wcześniejsze nie były na „niepełnym” armfh dla Raspbiana robione…

Własna namiastka dyndns

Po ostatniej akcji Microsoftu z przejęciem i zablokowaniem domen należących do No-IP miałem przez moment umiarkowany problem z dostępem do jednej z moich maszyn, bo nie znałem IP. Nic krytycznego i szybko rozwiązałem, ale stwierdziłem, że warto by się zabezpieczyć na przyszłość. Początkowo chciałem uruchomić po prostu innego dostawcę dyndns, z inną domeną, co dałoby całkiem niezłą – jak mi się wydaje – redundancję w tym względzie, ale prowizorycznie uruchomiłem coś innego, własnego i znacznie prostszego. W komentarzu do poprzedniego wpisu padło pytanie co dokładnie zrobiłem, więc opisuję.

Tak się składa, że mam serwer dedykowany ze stałym IP (nie jest konieczne zamiast tego można skorzystać z domeny), na którym stoi serwer WWW (lighttpd). Na wszystkich maszynkach potrzebujących dyndns mam dostęp do crona (zresztą, korzystałem z crona już przy zwykłym koncie dyndns, patrz update wpisu). Rozwiązanie jest proste: klient wywołuje okresowo unikatowy URL na moim serwerze, serwer okresowo parsuje log w poszukiwaniu tego unikatowego ciągu znaków i zapisuje IP z którego nastąpiło odwołanie w określonym pliku.

Poniżej wklejki ze wszystkimi onelinerami (gotowiec dla lighttpd, w przypadku innego serwera WWW trzeba dostosować):

# po stronie klienta*/5 * * * * /usr/bin/wget -4 -q -O /dev/null http://mojadomena.com/losowyciagznakow4346456543324645 > /dev/null
 # po stronie serwera*/5 * * * * /usr/bin/awk '/losowyciagznakow4346456543324645/ {ip=$1} END {print ip}' /var/log/lighttpd/access.log > /var/www/dyndns_host1.txt
 # pobranie IPwget -O - http://mojadomena.com/dyndns_host1.txt

Po namyśle, rozwiązanie nawet lepsze niż drugi dostawca dyndns. Mniej kont, prostsza konfiguracja, mając stałe IP na upartego można całkowicie uniezależnić się od DNSów, jeśli ktoś odczuwa potrzebę.

Oczywiście nie od razu tak to wyglądało, w szczególności po stronie serwera był grep, awk, tail w użyciu. Ale skoro da się wszystko załatwić awk (a nie tylko wyświetlanie określonej kolumny, chyba najczęstsze zastosowanie awk…), to czemu nie? Tu polecam zbiór przydatnych onelinerów w awk.

UPDATE: IPv6 się popularyzuje. Okazało się, że mój skrypt nie działa poprawnie, bo łączenie między maszynami następuje po IPv6. Dodany parametr -4 do wget w celu naprawy tego problemu.

Raspberry Pi, Raspbian i problemy z kartami microSD

Jakieś siedem tygodni temu pisałem, że padła mi karta microSD (Kingston) w Raspberry Pi. Wymieniłem na nową (Goodram). Zamontowana oszczędnie, tj. bez journala i z symlinkiem /var/lib/transmission-daemon/info kierującym na dysk twardy. Wczoraj robię aktualizację systemu, a tu nagle:

Preparing to replace libssl1.0.0:armhf 1.0.1e-2+rvt+deb7u7 (using .../libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb) ...
Unpacking replacement libssl1.0.0:armhf ... dpkg: error processing /var/cache/apt/archives/libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb (--unpack):
error creating directory `./usr/share/doc/libssl1.0.0': Input/output error
Segmentation fault Segmentation fault -bash: mbrtowc.c:92: __mbrtowc: Assertion `status == __GCONV_OK || status == __GCONV_EMPTY_INPUT || status == __GCONV_ILLEGAL_INPUT || status == __GCONV_INCOMPLETE_INPUT || status == __GCONV_FULL_OUTPUT' failed.

Piękne, prawda? Oczywiście kluczowy jest input/output error. Fsck, są błędy, naprawiony filesystem. Coś mnie tknęło i sprawdziłem badblocks (badblocks -sv). Tak jest, błędy w okolicy 90% karty (dead link). Sztuk prawie 30. Wygląda, że karta Goodram wytrzymała w komfortowych warunkach raptem 7 tygodni. Masakra.

Z tego wszystkiego zacząłem sprawdzać, co pisze na dysk (iotop -ao). Wyniki (sortowane po ilości zapisów, czas działania kilka godzin) są ciekawe:

3192 be/4 root 8.00 K 4.03 M 0.00 % 0.00 % rsyslogd -c5
2184 be/4 root 240.00 K 880.00 K 0.00 % 0.00 % nmbd -D
3341 be/4 ntp 248.00 K 188.00 K 0.00 % 0.00 % ntpd -p /var/run/ntpd.pid -g -u 102:104
5256 be/4 root 0.00 B 160.00 K 0.00 % 0.00 % [kworker/u2:2]
2911 be/4 root 208.00 K 88.00 K 0.00 % 0.00 % -bash

Jak widać, głównie rsyslog. I raczej nie ma tego wiele.

I tu zaczyna się część najciekawsza. Pamiętacie uszkodzoną kartę Kingstona? Przygotowałem się do pozbycia się jej, poleciał shred. Stwierdziłem, że uruchomię badblocks na niej. I… niespodzianka. Teraz nie zgłasza błędów. Ani w teście odczytu (domyślny), ani w niedestrukcyjnym teście zapisu (badblocks -nvs). Naprawiło się?

Zaczynam podejrzewać jakiegoś buga z przejściówką microSD -> SD (ale są dwie różne, bo każda karta miała swoją), gniazdem w rpi (ale działało OK, poza tym i badblocks, i fsck robię w laptopie). Zagadka.

Ostatecznie zmniejszyłem rozmiar partycji ext4 na karcie Kingstona i działa do tej pory bez problemu. Czyli jakieś 3 tygodnie bezproblemowego działania, bo wpis zacząłem tworzyć 12 czerwca.

UPDATE: Zwariowałem. Goodram, który ewidentnie miał błędy, bo nie tylko badblocks je wykazywał, ale nawet shred puszczony przed wyrzuceniem powodował błędy IO i nie mógł dobrnąć do końca (a próbowałem nie raz), teraz działa. Nagrałem Raspbiana dla Banana Pi, test badblockiem i… czysto. WTF?