Migracja z Aero2 na a2mobile

The world’s changing. Music’s changing. Even internet is changing.

Tak to się jakoś pomału kręci z tymi zmianami i mam pomysł na notkę z obserwacjami na temat zmian szybkości komputerów i łącz, ale to innym razem. Internet u rodziców miał się dobrze (via modem GSM i Raspberry Pi robiące za router). Tylko coś pakiety Aero2 schodziły ciut szybciej, niż przewidywałem. Znaczy chyba raz zdarzyło się, by zeszły więcej niż dwa w miesiącu, ale dwa na miesiąc IIRC schodziły regularnie.

Do tego doszedł średni panel Aero2 (klikasz „dodaj do koszyka” i jak nie pamiętasz, że dodawanie trwa, to możesz dodać kolejny raz, nim pierwszy „zaskoczy”). No i zaliczyli wyciek danych klientów. A także – last but not least – pojawiły się inne oferty na rynku. W szczególności ciekawie wyglądała oferta a2mobile, gdzie za 10 zł na miesiąc mamy internet bez limitu transferu. Tj. innego niż prędkość łącza, a ta spada wraz ze zużyciem transferu, czyli klasyczny lejek. Do 5 GB transferu jest bez limitu prędkości, do 10 GB jest limit 3 Mbps (modem bez LTE, w praktyce właśnie w tych okolicach łącze działa),. Potem do 15 GB jest limit 1 Mbps, a potem 512 kbps. Zakładam, że powyżej 10 GB nie zostanie zużyte.

Głównym wyzwaniem okazało się… zdobycie startera a2mobile. Nie chciałem zamawiać kurierem, w FAQ pisali, że startery są do kupienia w sklepach Żabka. Właściwsze byłoby sformułowanie bywają, bo kupić udało mi się jakoś przy czwartym podejściu. Po czym musiałem zaliczyć wizytę na poczcie w celu rejestracji. Chyba więc lepiej wziąć tego kuriera, zakładam, że umie on potwierdzić dane kupującego.

Konfiguracja wvdial dla a2mobile jest w zasadzie analogiczna do tej od Aero2. Zmienia się jedynie APN oraz wypadają user i hasło, czyli finalnie sekcja w wvdial.conf wygląda tak:

[Dialer a2mobile]
Modem = /dev/ttyUSB0
Init1 = AT+CGDCONT=1,"IP","a2mobile.pl"
Phone = *99#
Stupid mode = yes
Username = "blank"
Password = "blank"
Dial Attempts = 0
Auto DNS = "off"

Wrzucam, bo podobne wpisy na blogu już były, a nie znalazłem gotowca w sieci dla a2mobile. Tak naprawdę wszystko jest do siebie podobne i łatwo zmienić konfigurację, jeśli ma się skonfigurowany APN na telefonie z Androidem… Kiedyś jeszcze była konfiguracja wvdial dla Orange.

Feedburner wymaga IPv6

Od jakiegoś czasu w zadaniach do zrobienia miałem następujące zadanie związane z migracją bloga w nowe miejsce: poprawić RSS Feedburner. Teoretycznie to są trzy kliknięcia, ale przy próbie zmiany źródła feeda dostawałem niewiele mówiący komunikat:

An error occurred connecting to the URL: unknown error

W logach serwera brak jakiejkolwiek informacji połączenia, komunikat enigmatyczny, myślałem, że coś po stronie Google, jakiś cache, DNS, coś takiego. Chciałem nawet napisać do supportu, ale Feedburner nie posiada takowego – jak widać Google niezbyt dba o ten serwis. Są nawet głosy, żeby przenieść się z Feedburnera – może niebawem, póki co zostaje jak jest.

Sprawa była niezbyt pilna – tam gdzie mi zależało najbardziej, podałem bezpośredni URL do feedu RSS. Część ludzi ma jednak podany stary feed, tak też kieruje stary blog i zapowiadałem, że będzie on aktualny, więc wypadało naprawić.

Dziś zrobiłem test SSL i w oczy rzuciło mi się, że serwer WWW słucha tylko na IPv4. Zamierzona zaszłość. Teoretycznie przy braku łączności po IPv6 w większości popularnych implementacji powinno nastąpić połączenie po IPv4 (mechanizm Happy Eyeballs i podobne), ale jak widać Feedburner tego nie robi i wymaga serwera słuchającego na adresie IPv6, jeśli tylko domena bloga posiada rekord AAAA.

Błędu nie zgłoszę, skoro Google nie chce. Poprawiłem konfigurację serwera, by słuchał także na IPv6 i feed działa. W sumie mój błąd, że nie odpaliłem sniffera od razu przy diagnostyce, ale odrobinę lepszy komunikat błędu, np. connection to ADRES_IP failed wyjaśniał by wszystko.

W każdym razie do zapamiętania: jeśli chcemy, by Feedburner działał dla domeny rozwiązującej się na IPv4 i IPv6, to serwer musi słuchać na IPv6.

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.