Stick ALLNET ALL4781-VDSL2-SFP w Turris Omnia resynchronizuje się co 30 do 120 minut
W końcu przeniosłem linię VDSL2 z boksu od ISP i zakończyłem ją bezpośrednio na Turris Omnia, głównie po to, żeby PPPoE działało na routerze, a nie na drugim urządzeniu w trybie mostu. Sama konfiguracja była przyjemna: osadzasz stick w klatce i interfejs WAN po prostu przenosi się na moduł, zostawiając gniazdo metaliczne poza obrazem, a wewnętrzny link wstaje sam. Zielona dioda śledzi synchronizację DSL, pomarańczowa - stronę zwróconą do routera.
- Turris Omnia, PPPoE skonfigurowane na interfejsie od strony modemu
- stick modemowy ALLNET ALL4781-VDSL2-SFP w klatce SFP
- linia VDSL2, która trenuje na pełne 100 Mbit w dół
option ifname 'eth1.7', bo moja linia chce tagu VLAN 7
Dziesięć minut konfiguracji plus restart i było na pełnej prędkości linii. Problem w tym, że to się nie utrzymuje. Gdzieś między pół godziny a dwie godziny DSL traci synchronizację i potrzebuje dwóch do trzech minut, żeby wrócić:
LCP terminated by peer
Modem hangup
eth1: link is downCo już zrobiłem:
- wyjąłem i osadziłem ponownie stick oraz zrestartowałem router, odstęp potem jest taki sam
- podmieniłem kabel patchowy DSL i przeniosłem stick do pierwszego gniazdka na linii
- odłączyłem miedziany kabel WAN, żeby nic nie mogło rywalizować o interfejs
Nic z tego nie zmienia wzorca. Czy to stick, moja linia, czy sposób, w jaki Omnia steruje klatką? Czy ktoś prowadzi ten stick modemowy długoterminowo bez resynchronizacji?
Comments 4
To jest znana zła kombinacja: firmware 3.4 na linii, która faktycznie potrafi 100 Mbit. Stick jako taki nie jest zepsuty - znam inną Omnię, która od dawna prowadzi ten sam moduł na linii VDSL2 profil 17a i ani razu się nie resynchronizowała, i dlatego zgłoszenia na temat tego sprzętu tak się rozjeżdżają. Która linia trafi do której grupy, nie da się wyczytać wcześniej z żadnej karty katalogowej.
Dwie rzeczy, w tej kolejności.
Po pierwsze, idź do producenta w sprawie firmware'u. Przyznali się, że 3.4 źle się zachowuje tam, gdzie linia potrafi osiągnąć 100 Mbit, a nowsza wersja nic nie kosztuje, więc nie ma powodu, żeby jej nie uruchomić.
Po drugie, dalej obserwuj diody. Zielona, która gaśnie jako pierwsza, oznacza DSL, pomarańczowa - stronę klatki. Jeśli zielona nadal spada na nowszej wersji, firmware nie był całą historią na twojej linii.
Będąc szczerym co do wyniku, bo i tak zapytasz: znam co najmniej jedną linię, gdzie aktualizacja nic nie zmieniła i resynchronizacje trwały dalej w tych samych trzydziestu minutach do dwóch godzin. Stabilność tego sticka zależy chyba tyle samo od charakterystyki linii, co od wersji, więc traktuj firmware jako najtańszą rzecz do wypróbowania, a nie gwarantowaną naprawę. Jeśli nadal się sypie, niezbyt efektowna alternatywa to postawić z powrotem modem z przodu i trzymać sesję PPPoE na routerze przez
eth1.7- zostajesz przy konfiguracji, którą już masz, i przestajesz gonić za synchronizacją.Jaki firmware jest na sticku? W obiegu jest więcej niż jedna wersja i nie zachowują się tak samo na szybkich liniach, więc to pierwsza rzecz do ustalenia.
Jeszcze dwie rzeczy, zanim obwinisz routera. W momencie, kiedy traci synchronizację, zielona dioda gaśnie, czy zostaje zapalona, a rusza się pomarańczowa? To pokaże, czy traci się synchronizację DSL, czy tylko link w stronę Omnii. I czy da się wyciągnąć coś użytecznego z samego sticka w minutach przed spadkiem - osiągalna przepływność, margines SNR, liczniki błędów? Synchronizacja, która trzyma swoją prędkość aż do sekundy, w której umiera, czyta się zupełnie inaczej niż taka, która najpierw pełznie w dół.
Firmware 3.4 na sticku.
Usiadłem przy urządzeniu i złapałem trzy spadki z rzędu: zielona gaśnie pierwsza, pomarańczowa świeci cały czas. Czyli link w stronę routera się nie rusza, to synchronizacja DSL umiera, a sesja PPPoE idzie za nią w dół. To też sprawia, że
LCP terminated by peerjest skutkiem, a nie przyczyną, co podejrzewałem, ale nie miałem na to dowodu.Jeśli chodzi o liczniki, nie mam nic do pokazania. Osiągalna przepływność, margines, liczniki błędów - stick nigdzie tego nie udostępnia, przynajmniej nigdzie, gdzie bym to znalazł, a router pokazuje mi tylko prędkość synchronizacji i nic więcej. Ta wartość stoi na pełnej prędkości linii aż do sekundy, w której znika, więc nic nie pełznie w dół, po prostu znika. Profil też się nie zmienił, odkąd przed linią stał modem od ISP.
Inny stick, ta sama klatka, warto wiedzieć, skoro testujesz.
Miałem stick GPON HALNy HL-GSFP w Omnii: kernel podjął go bez sprzeciwu, port przeskoczył w inband/1000base-x, a potem eth2 siedziało tam w down na zawsze. Kwestia czasu, nie kompatybilności. Moduł niesie w sobie mały własny system i potrzebuje niemal minuty, zanim na cokolwiek odpowie, podczas gdy klatka jest odpytywana kilka sekund po włączeniu zasilania. Odpytanie nie zastaje nikogo w domu, router po cichu zostaje na metalicznym WAN, a interfejs SFP nigdy się nie budzi.
fw_setenv bootdelay 60w u-boot załatwiło to na dobre.To nie wytłumaczy resynchronizacji w środku sesji, więc to nie jest twoja odpowiedź. Ale jeśli kiedyś zrestartujesz po spadku i znajdziesz się z powrotem na miedzi, to jest właśnie ten mechanizm, a nie martwy moduł.