Umarł tropek, niech żyje tropek

Dzisiaj rano wysiadł prąd. Na chwilkę, ale domowy serwerek nie wstał. Używam go także do służbowej komunikacji, więc sprawa pilna. Przeszedłem się do mieszkania sprawdzić co jest, z założeniem, że trzeba power wcisnąć, albo pogadać z nim przez konsolę na temat sprawdzania dysku przy starcie… ale jednak nie. Po prostu uznał, że już nie wstanie. No cóż, już był czas.

Od drewnianego początku mój domowy serwerek był stawiany na używanym sprzęcie. A gdy taką paru letnią maszynę zamknie się w niewentylowanym pawlaczu i każe działać 24 godzin na dobę, to w końcu musi paść. Tak więc co 2-3 lata sprzęt wymieniał. Właśnie 3 lata minęły, więc bardzo zaskoczony nie byłem, chociaż na dodatkowy wydatek niespecjalnie byłem przygotowany.

Objawy wskazują na awarię zasilacza, lub płyty głównej. Zadzwoniłem do firmy, w której tego Della 760 kupiłem, czy nie mają może części do tego. Płytę główną może tak, zasilacza nie. Ale mają jeszcze takie małe Delle 760 za 140zł. Tyle, że słabsza wersja (jakiś Celeron zamiast Core 2 Duo). Jeśli padł zasilacz, to bym mógł przełożyć z takiego i byłoby ok. Jeżeli coś innego – mógłbym dysk przełożyć do tego nowego. Chodziłoby gorzej, ale by chodziło. Tyle, że ta maszyna już i tak trochę przestarzała była i czasem mocy brakowało (np. serwer Minecrafta ledwo się wyrabiał).

Wziąłem więc pod uwagę inną opcję – kupić nowszą maszynę. Ze 140zł robi się 1000zł, ale przynajmniej jest szansa, że to parę kolejnych lat pochodzi i może jeszcze coś większego się uda na tym odpalić. i5-2500 to już nie Core 2 Duo i pamięci do tego więcej wejdzie, a system można 64-bitowy odpalić. Po konsultacji z żoną zdecydowałem się na tą nową maszynę. Będzie, że od Zajączka. 😉

Do uruchomienia wystarczyło dysk ze starego przełożyć, ale jak już miałem to wyciągnięte i podpiętą klawiaturę z telewizorem, to od razu mały upgrade systemu zrobiłem. W sumie parę godzinek zeszło od tego krótkiego padu zasilania, ale może na parę lat będzie spokój. I jak rodzinka znowu sobie ciekawą gierkę multi-player znajdzie, to nie będzie trzeba się tak gimnastykować, żeby serwer uruchomić.

Dwa tygodnie bez opieki

Dwa tygodnie temu, dokładnie to 17 sierpnia po południu, wyjechaliśmy na rodzinne wczasy. To znaczy, że przez dwa tygodnie nie mogłem doglądać moich roślinek w biurze. Nie chciałem też, żeby ktoś mi się kręcił po biurze, a jasnym było, że dwa tygodnie bez podlewania to trochę dla nich za dużo… trzeba było coś wykombinować…

„Patent” z odwróconą butelką wsadzoną w doniczkę sprawdzałem i nie zdawał egzaminu – albo cała woda przelatywała przez doniczkę od razu (butelka bez zakrętki), albo nie leciała wcale (butelka z dziurką). W domu też wypróbowałem urządzenie w postaci ceramicznego stożka wsadzanego w doniczkę, połączonego rurką ze zbiornikiem z wodą, kupione w sklepie ogrodniczym – efekt taki sam jak w przypadku butelki bez zakrętki. Kiedyś w sieci znalazłem jeszcze jedno rozwiązanie, które, wydawało mi się, mogło zadziałać: Self-regulating watering system

Kupiłem więc na Allegro duże kuwety i zacząłem zbierać butelki po wodzie mineralnej – duże (1.5 l) i bardzo duże (5 l). Dzień przed wyjazdem zmontowałem system: ustawiłem kuwety na podłodze, wstawiłem w nie doniczki, podlałem i wlałem do każdej kuwety warstwę wody. W butelkach napełnionych wodą zrobiłem dziurki (dość duże – wcześniej sprawdziłem, że mała niespecjalnie działa) nieco powyżej dna i postawiłem butelki obok doniczek. Dodatkowo połączyłem kuwety ze sobą kawałkami sznurka odciętymi od mopa, kamyczkami dociśniętymi do dna.

System nawadniający

W dzień wyjazdu byłem jeszcze w pracy, to mogłem zobaczyć czy system się uruchomił. Jeden baniaczek i jedna butelka były do połowy puste, reszta wciąż pełna. Poziom wody w kuwetach różnych, ale w żadnej nie było sucho. Sznureczki łączące kuwety wilgotne. Dalekie to było od ideału i mogło znaczyć, że system nie działa, ale mogło być też wynikiem krzywej podłogi i różnej wysokości dziurek w butelkach. Jeśli to to drugie, to „samoregulacja” z czasem powinna załatwić sprawę (po opróżnieniu jednej butelki powinna się zacząć opróżniać druga). Pozostało mi już tylko zaufać tej konstrukcji.

Przygotowując samopodlewanie zauważyłem, że znowu czerwce wróciły… to korzystając z okazji, że i tak w najbliższym czasie nie będę nic z tego jadł, ani siedział w skażonym pokoju, to tuż przed wyjazdem jeszcze spryskałem roślinki pestycydem.

Wakacje się udały – dwa tygodnie miłego szeroko pojętego nic nierobienia.

Pozdrowienia znad morza ;) Krysia na plaży Ptaszek na plaży
Widok z latarni morskiej w Gąskach Zachód słońca Na statku

(więcej w wakacyjnym secie na Flickr)

Wczoraj wieczorem wróciliśmy i dzisiaj rano popędziłem do biura sprawdzić jak się czują moje roślinki. Spodziewałem się wszystkiego – zasuszonych badyli, lub przegniłych roślin. A tu zaskoczenie – papryczki mają się tak, jakby nic się nie stało:

Papryczki i pomidorek po 2 tygodniach bez opieki

Trochę wody było tylko w jednej małej i jednej dużej butelce, w jednej kuwecie wciąż woda stała (w tej, w której na początku było najwięcej – chyba jednak krzywa podłoga). We wszystkich doniczkach było wciąż mokro – jeszcze z tydzień by mogły tak postać. „Cayenne” uginało się pod nowymi owocami, na Tabasco, Twilight i na fuju masa dojrzałych owoców. Tylko Habanero skromnie – dwie nowe zielone papryczki. W każdym razie jestem bardzo zadowolony… i wciąż czeka mnie trudna decyzja, które roślinki przezimować, a których się pozbyć…

VPN L2TP/IPSEC między PLD Linuksem i Androidem

Jeszcze się tu nie chwaliłem, ale kupiłem sobie mojego pierwszego smartfonika (Samsung Galaxy S Plus). Oczywiście odkąd go mam (nieco ponad dwa tygodnie) bawię się wszelkimi możliwymi jego funkcjami… W głębi menu „ustawienia” znalazłem „sieci VPN”. W sumie dobrze by było mieć w komórce dostępne bezpieczne połączenie do domowej sieci lokalnej…

Telefonik fabrycznie obsługuje cztery opcje: „PPTP”, „L2TP”, „L2TP/IPSec PSK” i „L2TP/IPSec CRT”. PPTP jakoś źle mi się kojarzy (nie wiem czemu i nie wnikam), zerknąłem na opis L2TP w Wikipedii i uznałem, że L2TP/IPSec to będzie sensowny wybór, szczególnie że IPSec pewnie niedługo będę przerabiał w robocie. Od razu postanowiłem też użyć uwierzytelniania za pomocą certyfikatu.

Od początku zdawałem sobie sprawę, że zapewne dużo prościej byłoby znaleźć OpenVPN na Androida i tym tunel zestawić… ale to nie byłoby żadne wyzwanie ;-). Nie sądziłem jednak, że uruchomienie L2TP/IPSec będzie aż takim problemem…

Zacząłem tradycyjnie, jak to się w PLD robi: „poldek:/all-avail> ls *l2tp*„. Nic. „search -a *L2TP*” pokazało nie wiele więcej, nic czego bym szukał. Kolej na Google… tu parę różnych tekstów… Że w PLD obecnie do IPSec mamy tylko ipsec-tool i ten pakiet mam opanowany, to pominąłem wszystkie HOWTO dotyczące OpenSWAN/FreeSWAN itp… Zresztą, nie tylko mnogość implementacji IPSec była problemem. Samego L2TP też było wymienionych kilka implementacji i chyba żadna aktywnie nie rozwijana…

Znalazłem jakiś obiecujący opis użycia l2tpd… było tam wspomniane, że ten demon już nierozwijany, ale jest jakaś kontynuacja – xl2tpd. O, nawet w PLD spec był… okazało się, że niedokończony… a właściwie nawet dobrze nie zaczęty. Dokończyłem, zbudowałem, zainstalowałem…

IPSec w ogóle nie skonfigurowałem, chciałem tylko to xl2tpd wypróbować, a nawet nie do końca wiedziałem czy IPSec działa pod, czy nad L2TP (potem doczytałem – transmisja L2TP odbywa się wewnątrz IPSec, a więc IPSec należałoby skonfigurować najpierw). Telefon się nawet łączył, xl2tpd coś w logach pisał, ale wyglądało to, jakby telefon próbował otworzyć jeden tunel za drugim, żadnego nie zestawiając do końca. Późno już było, dałem sobie z tym spokój.

Wczoraj pogooglałem dalej i trafiłem na openl2tp. Projekt prawie żywy, ostatnie wydanie sprzed roku. Zrobiłem pakiet dla PLD. Żeby kod się skompilował wystarczyło „-Werror” z Makefile wywalić. Demon się uruchamiał, l2tpconfig działał.

Tym razem postanowiłem najpierw uruchomić IPSec. Racoonem już się kiedyś bawiłem, ale wciąż jego konfiguracja nie jest dla mnie całkiem jasna. Posiłkowałem się gotowcem z Quick Start Guide openl2tp, uzupełniłem tylko konfigurację, żeby uwierzytelnianie było zrobione certyfikatami (co wymagało wielu prób i błędów). Niby już było wszystko ok, ale:

racoon: ERROR: no policy found: 192.168.1.10/32[0] 192.168.0.1/32[1701] proto=udp dir=in
racoon: ERROR: failed to get proposal for responder.

…okazało się, że to błąd w rzeczonym Quick Start. Kolejność parametrów w skrypcie setkey była zła. Powinno być:

#!/usr/sbin/setkey -f
flush; 
spdflush;

spdadd 0.0.0.0/0 192.168.0.1 [1701] udp -P in ipsec esp/transport//require;

(192.168.0.1 to będzie adres serwera VPN, 192.168.1.10 – klienta) Policy ‚out’ na serwerze nie potrzebne, bo odpowiednie wpisy openl2tpd powinien dodać sam, dla konkretnych połączeć.

Po poprawieniu tego, Racoon uraczył mnie kolejnym błędem:

racoon: ERROR: long lifetime proposed: my:3600 peer:28800
racoon: ERROR: not matched
racoon: ERROR: no suitable policy found

Do było proste, trzeba było znaleźć „lifetime” w racoon.conf i poprawić na wartość oczekiwaną przez Androida.

Jak już poprawnie przychodziły requesty z telefonu po IPSec, przyszedł czas skonfigurować openl2tpd

. Jednak ten już przy starcie wołał:

openl2tpd[12257]: IPSec support disabled. No setkey found.

…i nie bardzo dalej działał. Nie podobało mi się to, ale od razu domyśliłem się o co chodzi – openl2tpd miał zaszytą złą ścieżkę do setkey. Szybko odnalazłem odpowiedni fragment kodu, w plugins/ipsec.c:

#define IPSEC_SETKEY_CMD        "/sbin/setkey"
#define IPSEC_SETKEY_FILE       "/tmp/openl2tpd-tmp"
#define IPSEC_SETKEY_ACTION     IPSEC_SETKEY_CMD " -f " IPSEC_SETKEY_FILE

Poprawka była oczywista (w PLD setkey leży w /usr/sbin), ale nie spodobało mi się coś innego… Moje obawy potwierdziły się niżej w kodzie:

FILE *f = fopen(IPSEC_SETKEY_FILE, "w");

…ciekawe co by było jakby jakiś user zrobił np. „ln -s /bin/sh /tmp/openl2tpd-tmp”…

Załatałem to (przenosząc plik tymczasowy do /var/run/openl2tp) razem z poprawkę ścieżki do setkey, ale trochę zaufania do tego kodu już utraciłem…

Połatany openl2tp już poprawnie ustawiał policy dla wysyłanych pakietów, ale znowu Racoon zaczął marudzić:

racoon: ERROR: phase1 negotiation failed due to send error. b842e7fcf5598054:0000000000000000
racoon: ERROR: failed to begin ipsec sa negotication.

To już była bardziej tajemnicza sprawa. Nawet bardziej szczegółowe logi nie mówiły nic konkretnego. Dopiero w źródłach udało mi się znaleźć co może powodować ten błąd, bez żadnego innego sensownego komunikatu. Dzieje się tak, gdy Racoon nie może znaleźć socketu z którego ma wysłać pakiet. Testowałem połączenie z sieci lokalnej, ale łączyłem się na zewnętrzny adres mojego routera i tylko do tego zewnętrznego adresu kazałem się Racoonowi przyczepić. A openl2tpd na żądania z sieci lokalnej odpowiadał z adresu lokalnego. Racoon próbował zestawić sesję IPSec z tego samego adresu i mu się nie udawało. Problem udało się rozwiązać wywalając całą sekcję „listen” z racoon.conf (sam niepotrzebnie tam adresy pododawałem – nadgorliwość się mści) oraz ustawiając ‚src_ipaddr’ w profilu tuneli openl2tpd. Dla pewności, że to samo nie będzie mi dalej zawadzać, dalsze próby robiłem z pominięciem lokalnego WiFi.

Problem Racoona rozwiązałem, ale openl2tpd dalej się nie łączył. Podobnie, jak w przypadku xl2tpd było widać wiele prób zestawienia tunelu, ale żadna nie kończyła się sukcesem. Żeby przyjrzeć się ruchowi tcpdumpem wyłączyłem IPSec i próbowałem kontynuować „gołym L2TP”.

Wymiana pakietów wyglądała mniej-więcej tak:

KLIENT -> SERWER:   UDP port xxxx -> port 1701
SERWER -> KLIENT:   UDP port yyyy -> port xxxx
KLIENT -> SERVER:  ICMP port xxxx unreachable

Winnym okazał się feature openl2tpd – demon domyślnie wykorzystuje „efemeryczne” porty UDP dla każdego połączenia. Żądanie przychodzi na port 1701, ale odpowiedź serwera już wychodzi z nowego, losowego portu. Najwyraźniej Android tego się nie spodziewa i odpowiada błędem „port unreachable”, jakby to po jego stronie czegoś brakowałem. Na szczęście można ten feature wyłączyć przez l2tpconfig:

tunnel profile modify profile_name=default our_udp_port=1701

Potem było już z górki… jeszcze jeden błąd z openl2tpd:

openl2tpd[9952]: PROTO: tunl 23305: STOPCCN error 5/0: The protocol version of the requester is not supported - no challenge response AVP received

Już nie pamiętam czym dokładnie to rozwiązałem, ale jakąś zmianą w konfiguracji openl2tpd. Potem pomarudził jeszcze pppd:

The remote system is required to authenticate itself
but I couldn't find any suitable secret (password) for it to use to do so.
(None of the available passwords would let it use an IP address.)

Tu wystarczyło poprawić /etc/ppp/pap-secret. Gdy już się telefon z serwerem połączył jeszcze takie w logach w kółko leciały:

pppd[14786]: sent [CCP ConfReq id=0x1 ]
pppd[14786]: rcvd [CCP ConfReq id=0x2]
pppd[14786]: sent [CCP ConfAck id=0x2]
pppd[14786]: rcvd [CCP ConfRej id=0x1 ]
pppd[14786]: Received bad configure-rej:  12 06 00 00 00 00

…najwyraźniej kolejne głupie rozszerzenie PPP do Microsoftu, nie wiedzieć czemu domyślnie włączone. Pomogło „nomppe” w /etc/ppp/options

Jeszcze tylko wyregulowanie firewalla i tunel wydaje się działać jak należy. Przynajmniej ze strony telefonu, w drugą nawet ping za bardzo nie chodzi, bo Android odpowiada z innego IP niż ten pingowany przez tunel. Ale z tym już raczej nic nie zrobię.

Ostatecznie moja konfiguracja wygląda mniej-więcej tak:

/etc/racoon/racoon.conf:

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/cert";
padding
{
        maximum_length 20;
        randomize off;
        strict_check off;
        exclusive_tail off;
}

timer
{
        counter 5;
        interval 20 sec;
        persend 1;
        phase1 30 sec;
        phase2 15 sec;
}

remote "l2tpclient"
{
        exchange_mode main;
        doi ipsec_doi;
        situation identity_only;

        ca_type x509 "cacert.pem";

        my_identifier asn1dn;
        certificate_type x509 "cert.pem" "key.pem";

        verify_identifier on;
        verify_cert on;
        peers_identifier asn1dn "CN=*, emailAddress=jajcus@example.com";
        peers_identifier user_fqdn "jajcus@example.com";
        peers_identifier asn1dn "CN=*, emailAddress=jajcus@example.org";
        peers_identifier user_fqdn "jajcus@example.org";

        nonce_size 16;
        initial_contact on;
        proposal_check strict;

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2;
        }
}

sainfo anonymous
{
        lifetime time 12 hour;
        encryption_algorithm aes 256, rijndael 256, blowfish 448, 3des;
        authentication_algorithm hmac_sha256, hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}

/etc/racoon/setkey.conf:

#!/usr/sbin/setkey -f
flush;
spdflush;

spdadd 0.0.0.0/0 192.168.0.1 [1701] udp -P in ipsec esp/transport//require;

/etc/openl2tpd.conf:

# system

# peer profiles
peer profile modify profile_name=default \
        lac_lns=lns \

# tunnel profiles
tunnel profile modify profile_name=default \
        auth_mode=none \
        host_name=tropek \
        src_ipaddr=192.168.0.1 \
        our_udp_port=1701 \

# ppp profiles
ppp profile modify profile_name=default \
        auth_mschapv1=no \
        auth_mschapv2=no \
        auth_eap=no \
        local_ipaddr=10.0.0.1 \
        ip_pool_name=l2tp \

# locally created tunnels and sessions

/etc/ipoold.conf:

# ip pools
pool create pool_name=l2tp \

pool address add pool_name=l2tp first_addr=10.0.0.100 num_addrs=100 \
        netmask=255.255.255.0

/etc/ppp/options:

ms-dns 192.168.0.1
ms-dns 192.168.0.2
asyncmap 0
auth
crtscts
lock
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx
nomppe

/etc/ppp/pap-secrets:

username hostname "passsword"        *

I jeszcze w firewallu regułka dla pewności sprawdzająca użycie IPSec (domyślna regułka u mnie to DROP dla wszystkiego):

iptables -A INPUT -p udp --dport 1701 -m policy --pol ipsec --dir in -j ACCEPT

Tak więc, działać już mi ten VPN działa i pozostaje mieć nadzieję, że jest bezpieczny. A wszystko to tu opisałem, żeby następnym razem wujek Google umiał pomóc, gdy ktoś tak jak ja będzie się męczył…

Update: Proste testy sugerują, że ze strony telefonu to ten VPN niespecjalnie bezpieczny jest. To się pobawiłem, ale na razie używać tego chyba nie będę na poważnie.

Update 2:: Tak, tak zestawiony tunel nie jest specjalnie bezpieczny, ale można sobie z tym poradzić (o ile telefon jest zrootowany).

Magia RTV…

Od jakiegoś czasu self-made nagrywarka powodowała „pierdzenie” w głośnikach podłączonych do wzmacniacza. Na każdym kanale poza tunerem. Na początku tylko gdy nagrywała, ostatnio jak tylko była włączona. Ciężko było cokolwiek oglądać przy takim akompaniamencie…

Dzisiaj próbowałem znaleźć usterkę. Kabelki audio ok. Zasilanie podłączone ok. W maszynce wszystkie kondensatory wyglądają ok. Poprzełączałem wszystkie wtyczki, odkurzyłem co się dało… chwilę było ok i znowu pierdzi… Nic nie wymyśliłem.

Przy okazji chciałem też sprawdzić kabelek z DVD (jeden kanał nie grał)… Przez przypadek zauważyłem, że pierdzenie znika, gdy… odpinam od wzmacniacza kabel z domowego serwerka (który robi też za szafę grającą)… WTF? Pierdzenie zależało od działania nagrywarki, nie serwerka…

Serwerek był podpięty przez „ground-loop-isolator” – transformatorek mający usuwać efekt „pętli masy”. Spróbowałem podłączyć go bezpośrednio… i nie pierdziało. Co więcej, też nie buczało (wszelkie pętle masy zerwane gdzie indziej? W sumie, drugi separator mam na kablu antenowym…).

Podsumowując: żeby usunąć zakłócenia z nagrywarki musiałem odpiąć urządzenie podłączone zupełnie gdzie indziej.

Niestety, prawdopodobnie nie usunąłem problemu całkiem, lecz tylko jego objawy… skoro kiedyś działało bez zarzutu, a ostatnio było coraz gorzej, to najwyraźniej się coś psuje. Najprawdopodobniej nagrywarka sieje jakimiś zakłóceniami, które transformatorek wyłapywał (czemu akurat on? samochodowy… powinien być dobrze ekranowany)… Mam nadzieję że nie przestanie nagle całkiem działać.

Zapamiętać!

Nigdy więcej nie kupować myszek A4Tech

I nie ważne, że:

  • Poprzednie doświadczenia z myszkami tego producenta są sprzed wielu lat. Z jakiegoś powodu tak wytrwale się trzymaliśmy OEMowych Logitechów, nie.
  • Że sprzedawca twierdzi, że sprzedaje od lat i nigdy nie było żadnych problemów. Pewnie zawiedzeni klienci po prostu tam nie wracali.
  • Że wydaje się niemożliwe, że jeden z najpopularniejszych producentów może od lat produkować buble. Widać może.

Poprzednim myszkom A4Tech do zgonu potrzebny był upadek z biurka, czy dwa (Logitechy za kilkanaście złotych mogły sobie zlatywać naście razy i nic im nie było), albo kilka miesięcy używania. Dzisiaj kupiona (prosty model, jedna z najtańszych) nie chciała tyle czekać. Po prostu, podłączona do kompa nie działa. Nowe urządzenie USB wykryte, ale nic poza tym. Podłączona do gniazda PS/2 (przez załączoną do myszki przejściówkę) też martwa…

Może mam pecha… ale nawet jeśli to mój osobisty pech, to jednego powinienem się trzymać: Nigdy więcej nie kupować myszek A4Tech

Jak kupowałem kabelek

W komentarzach do poprzedniego wpisu wspomniałem że chcę córce nowy „kabelek MIDI” kupić. Dokładnie to chodzi o konwerter USB-MIDI, żeby jej instrument do komputera podłączyć. Widziałem takie na Allegro za dwadzieścia-parę złotych i wyczytałem że nawet najtańsze byle-co powinno pod Linuksem zadziałać. Dzisiaj miałem do załatwienia coś na mieście, postanowiłem zobaczyć, czy gdzieś w sklepie tego nie ma. Przy okazji rozglądałem się też za jakimś fajnym ale tanim (kiepskim) mikrofonem do Performousa…

Najpierw trafiłem do sklepu z urządzeniami muzycznymi. Konwertera USB-MIDI nie mają, ale mieli/miewają… za jakieś 150zł (porządnej firmy). Pan był chyba trochę zniesmaczony tym, że ja chcę jakieś byle-co, sporo taniej. Jeszcze bardziej zniesmaczony był później, gdy pytałem o jakiś „tani mikrofon” dając do zrozumienia, że za 50zł to stanowczo za drogi. :-)

Następnie udałem się do jakiegoś sklepu komputerowego. Spytałem o mikrofony. Mieli sporo różnego badziewia, ale nic co można by trzymać w ręce i do tego „śpiewać”. Bez nadziei na sukces spytałem też o „kabelek USB-MIDI”. „Nie, takiego raczej nie. Mamy do drukarki…”. Stwierdziłem, że rozumiem, bo to raczej w muzycznym, nie komputerowym… to pani się coś przypomniało. „O, tu mam jakieś MIDI!” i pokazała jakiś zakurzony blister. Tak, to było dokładnie to, identyczne jak te na allegro. Pani stwierdziła jednak, że to drogie, że tak „po kosztach” to za 57zł mogłaby mi sprzedać. Gdy podziękowałem wspominając, że na Allegro są po 20zł zgodziła się sprzedać mi to za 30zł. „Od ponad pół roku to tu leży i nieprędko to raczej sprzedam. Myśleliśmy, że to coś innego…”. Fajnie udało mi się kupić to co chciałem, bo towar do sklepu trafił przez pomyłkę. :-)

Swoją drogą, lubię zakupy w tym sklepie i nie mogę powiedzieć, że sprzedawczyni jest niekompetentna, wręcz przeciwnie. Po prostu raz się trafił nietypowy towar.

Dziś zdobyłem sprawność mechanika samochodowego

Miesiąc temu mieliśmy problem z samochodem. Wpadał w wibracje na niskich obrotach. Problem udało się rozwiązać w nieautoryzowanym serwisie Renault, za 200zł. Niestety, wczoraj wieczorem, gdy żonka jechała na gimnastykę dla ciężarówek, stwierdziła, że autko znowu „się trzęsie”.

Przykre, bo to piątek wieczorem, a na weekend wolelibyśmy sprawny samochód. Zadzwoniłem do mechanika „zza płotu”, a on raczej bronił się przed zaglądaniem do samochodu: „to może być któraś z tych bardzo drogich części, to trzeba by pod komputer podłączyć, lepiej, żeby to ten fachowiec od Renault obejrzał… ale jak pan bardzo chce, to może podjechać w poniedziałek albo we wtorek, lepiej we wtorek”. Wtorek mnie nie ratuje. Na „fachowca od Renault” na sobotę nie liczyłem, a poza tym, czy na pewno trzeba kolejne 200zł wydawać? Bo wyglądało na to, że to dokładnie to samo co poprzednio, gdy cewka zapłonowa padła, a na Allegro takie cewki można znaleźć za 70zł…

Postanowiłem więc najpierw samemu się temu przyjrzeć. Poczytałem na Wikipedii o układach zapłonowych, potem spytałem wujka Google o cewki w silnikach Renault 16V i dowiedziałem się, z serwisu dla elektroników, że to powszechny problem w takich samochodach i jak to można próbować naprawić. Wiedząc już gdzie szukać tych cewek i czego się po nich spodziewać zajrzałem pod maskę. Okazało się, że na cztery cewki zapłonowe tylko dwie są takie same. Jedna z pozostałych to zapewne ta wymieniona miesiąc temu, druga musiała być wymieniona jeszcze gdy to teść był właścicielem samochodu (powinni mu wtedy wszystkie wymienić). Oczywiście te dwie „fabryczne” okazały się być marki Sagem. Lepić ich silikonem czy czymś innym jednak nie chciałem. Z ośmioletnim samochodem nie próbowałem nawet jechać na darmową wymianę do autoryzowanego serwisu. Na dostawę z Allegro mógłbym z tydzień czekać… postanowiłem poszukać gdzieś w Gliwicach.

Najpierw pojechaliśmy do Norauto… w końcu taki „hipermarket”, to może ma wszystko. Świece, czy kable zapłonowe były, cewek nie prowadzą. No to pojechaliśmy jeszcze do samochodowego sklepu w centrum. Tam cewki mieli na miejscu, ale za 150zł. Na poniedziałek mogą zamówić nieoryginalne zamienniki za 100zł. Nie chcieliśmy czekać, postanowiliśmy kupić te oryginalne. Teraz czas na chwilę prawdy…

Najpierw wymieniłem tę cewkę, którą podejrzewałem o usterkę (po eksperymentach z odłączaniem kabelków z każdej po kolei). Nic, dalej trzęsło. Pozostała druga. I po wymianie tej drugiej autko odżyło. Nie trzęsie no i moc ma znowu jak należy. :-)

Została nam jeszcze jedna felerna cewka Sagema w silniku… to zamówię sobie na Allegro i będziemy wozić ze sobą zapas. Na razie jeszcze ten Sagem działa.

Przy okazji taki wniosek: wcale te dzisiejsze samochody nie są takie skomplikowane jak niektórzy twierdzą. Układ zapłonowy wręcz wydaje się prostszy… gdyby jeszcze mieć kod źródłowy oprogramowania tego komputera co tym steruje i móc się do niego jakimś gdb podłączyć, to mógłby sobie w tym dłubać, jak jakiś dziadek w swoim „maluchu”. ;-)