Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez samuel.obiedzinski
@jarek7714
z Tobą nie ma sensu dyskutować bo to obraża elementarne zasady logiki.
To nie wina hardware/sprzętu, że działa nie stabilnie tylko software.
Co jest chyba oczywiste skoro na oryginalnym firmware działa stabilnie całymi miesiącami.
I nie o cudownościach mówimy tylko o stabilności.
Ale jaki jest sens pisania z Tobą skoro logika nic dla Ciebie nie znaczy.
Wiec ja na tym kończę.
@jarek7714
tylko, że to nie z Netgear R6220 jest problem tylko z OpenWRT na nim.
Dziwi mnie to podejście - restartowanie co chwila i nie ma problemu.
A jak pracujesz zdalnie tez nie jest dla Ciebie problemem jak Cię od sieci odcina?
A jak pojedziesz w delegacje i żona Ci dzwoni, że Internet nie działa itp. itd.
No nie. To ma działać bezobsługowo.
Skonfigurować raz i zapomnieć.
Jasne. Ale mam przykład z rutera którego używam ileś lat:
Netgear R6220
Na OpenWRT maksymalnie kilka dni (+ co jakiś czas problemy z połączeniem z WiFi, albo rozłączanie i łącznie), na firmware producenta + pare swoich usług odpalonych i nigdy nie robię żadnych restartów.
A przecież prace wykonuje te samą i na tym samym łączu i obsługuje tych samych klientów.
Z doświadczenia z branży wiem, że duża firma produkująca hardware + software naprawdę ma porządny proces SQA. Jednym z takich wytycznych jest właśnie testowanie "starzenia" się systemu w jakiejś wcale nie małej jednostce czasu.
Jeszcze wiesz jak problem jest prosty np. zbierają sobie programy jakieś logi w pamięci, czy program ma wyciek mały pamięci to ja to jeszcze przeżyje ustawie sobie restart raz na dobę i OK. To już mi się nie podoba bo problemy należy przeanalizować znaleźć i rozwiązać, a nie obchodzić, ale OK.
Najgorsze są randowowe crashe, i randomowe niestabilności, to zaakceptować ciężko, bo tego objeść się nie da restartem raz na dobę o określonej porze.
Dziś wróciłem do walki z Zyxel T56 - moje obejście na problemy z konwerterami USB <-> UART jest takie, że znalazłem bardzo starego huba pasywnego USB 1.1 i jak podepnę przez huba to te przejściówki magicznie są wykrywane.
Pytanie tylko jak będzie ze stabilnością podczas obciążenia.
A tak w ogóle to wiele problemów OpenWRT pokrywa się po prostu z problemami nowych kernelów linux i driverów.
Wraz z nowymi rozwiązaniami stabilność niestety spada, a niestety OpenWRT tylko czeka by podnieść wersje kernela. Bardzo nad tym ubolewam.
Tymczasem trzeba niekiedy lat by wyłapać i zapatchowac większość błędów w danym wydaniu kernela, czy driverów. Zespół OpenWRT nie ma na to czasu bo biegną do przodu kosztem stabilności.
No to ciekawe. Bo u mnie jak wyżej. Ten sam konwerter działa pod PC nim wyrwałem OpenWRT.
Wygrzebałem ze szpargałów drugi na innym chipsecie CP210X i też to samo.
Port USB w routerze niby sprawy bo po podłączeniu pendrive wykrywa go bez problemu.
Coś nie mam szczęścia do OpenWRT. Na R6220 poużywałem chwile było niestabilnie średnio raz na 4 dni samoczynny restart routera w miedzy czasie masa restartów konwertera USB <-> serial. Wgrałem oficjalny firmware do kompilowałem sobie sam co trzeba i działa do teraz całymi miesiącami. Chciałem się przesiać na coś lepszego by mieć lepsze transfery po WiFi i znów OpenWRT... tu już tego samego myku nie zrobię z oficjalnym firmware bo ono niewiele oferuje.
ehh - ewidentnie coś z OpenWRT nie możemy się polubić ostatnie OpenWRT którego używałem i działało to było jakieś na kernelu 2.4 na WRT54GL ale może dlatego, że sterowniki były wyciągnięte z oficjalnego firmware.
I to działo faktycznie stabilnie.
Wszystko później to już tylko frustracja, że nie da się wrzucić za szafę tylko wiecznie trzeba to restartować pilnować sprawdzać logi itd. Bo a to pamięć RAM zapycha, a to kernel co jakiś czas crash, a to podpięte urządzenia po USB się restartują i tak w koło macieju.
Podziwiam Was ale ja musze znów od tego odpocząć.
Czy to jest znany problem, że podłaczenie jakiegokolwiek konvertera USB <-> serial do portu routera T-56 nie działa
[ 2471.433099] usb 2-1: USB disconnect, device number 2
[ 2477.980512] usb 1-2: new full-speed USB device number 15 using xhci-mtk
[ 2498.864127] usb usb1-port2: disabled by hub (EMI?), re-enabling...
[ 2498.870585] usb 1-2: USB disconnect, device number 15
[ 2499.220525] usb 1-2: new full-speed USB device number 16 using xhci-mtk
[ 2500.411484] usb usb1-port2: disabled by hub (EMI?), re-enabling...
[ 2500.417938] usb 1-2: USB disconnect, device number 16
[ 2517.550508] usb 1-2: new full-speed USB device number 17 using xhci-mtk
[ 2657.551638] usb 1-2: authorized to connectlata temu używałem OpenWRT były z tym problemy myślałem, że coś się poprawiło.
OK dzięki.
Dziękuje bardzo za info.
Wiem, że nękam, ale czy podpowiesz jak kompletnie wyłączyć wsparcie dla ipv6 na tej kompilacji?
@Cezary
czy mógłbyś proszę podpowiedzieć, czy to:
There's currently an issue with OpenWRT causing the 2.5gbit ports to misbehave when ran at 1gbit.
Problem can be worked around by adding the following two lines (for each port) to /etc/rc.local:
ethtool -s eth1 advertise 0x028
ethtool -s eth1 speed 1000 duplex full autoneg on
jest nadal aktualne na Twojej kompilacji:
https://dl.eko.one.pl/firmware/?version … 0-ubootmod
T-56 WAN będzie miało podłączony do routera Vectry który ma 1Gb port.
samuel.obiedzinski napisał/a:Cześć,
szybkie pytanie. Lepiej wgrywać pierwszy raz OpenWRT przez ssh, czy przez UART?
Czy efekt końcowy jest identyczny, czy nie.
Trochę poczytałem ale widać za małoJa wgrywałem przez UART na 4 szt.
pierwszy raz godzinka, ostatni 20 minBez backupu mozna w 10 min.
W instrukcji są błędy , bo nowe wersje mają inne partycje, ale ma.znaczenie to tylko przy backupie.
Nie wiem, czy ten backup oryginalnego softy w ogóle się do czegoś przyda i czy jest odtwarzalny.
hmm wydaje mi się, że robiąc backup użyłeś złego kennela z initramfs dlatego nazwy partycji mtd były inne.
Jeśli tak było to generalnie ten dump nie wyszedł Ci za dobry.
OK. Ja pod pojęciem zablokowany rozumiem coś innego. Stąd moje wątpliwości.
A jak ktoś ma dostęp do JTAG i konfiguracje do niego to może też reanimować bez bootloadera ale nie wchodźmy w te tematy.
Jasne ale chyba nikt się nie spodziewa, że jakikolwiek release bootloader routera przywita go znakiem zachęty.
W każdym razie odpowiem sobie sam na pytanie.
Wgrywając "metodą UART" zmienia się podział pamięci flash.
Wygrywając przez ssh layout musi zostać taki jak oryginalny.
Wiec, NIE efekt końcowy jest inny.
W takim razie pamięć flash w której jest bootloader nie jest zablokowana - nie ma przepalonych fuse'ów
Wiec nie bardzo wiem co rozumiecie przez zablokowany bootloader.
No napisałeś,. że mogę przez serial zmienić bootloader.
Zablokowany bootloader mogę nadpisac?
Mam wersje od Odido, a z tego co czytałem to bootloader jest zablokowany. To ja już nic z tego nier rozumeim.
Cześć,
szybkie pytanie. Lepiej wgrywać pierwszy raz OpenWRT przez ssh, czy przez UART?
Czy efekt końcowy jest identyczny, czy nie.
Trochę poczytałem ale widać za mało
Chwila, chwila. Moim zdaniem ten router to naprawdę super sprzęt, działa na nim stabilnie i WiFi 5 i 2,4GHz nie grzeje się i działa mega stabilnie. Warunek jest jeden - oryginalny firmware.
Sam miałem 2 sztuki i dokupiłem kolejne 2, żeby w razie uszkodzenia w czasie burzy, czy czegoś podobnego mieć na podmianę.
Router działa super stabilnie na oryginalnym firmware co więcej ciągle widać, że łatają krytyczne błędy wypuszczając aktualizacje.
Zabawa w OpenWrt to zabawa jeśli komuś zależy na zabawie to może się bawić, może w jego konfiguracji akurat będzie działać stabilnie jakiś konkretny build, albo będzie tak często zmieniał oprogramowanie, że ewentualnych niestabilności nawet nie zauważy 
Producent nie dba o to. Z wielkimi bólami łata soft jeżeli musi (jak było np. z KRACK czy ktoś znajdzie jakiegoś buga w gui i jest afera w internecie), a tak - cały czas bazuje na jednej wersji sdk którą dostał od producenta chipów. Naprawdę prawie się nie zdarza żeby któryś bawił się w aktualizację czegokolwiek. Jako przykład - problem z netgearami który wyszedł ostatnimi dniami.
Tak jestem wstanie to zrozumieć, ale warto mieć na uwadze pewien jeden zasadniczy fakt - jak się używa kernela vanilia to trzeba się spodziewać, że to będzie działać gorzej.
Producenci chipów wkładają naprawę duży wysiłek, żeby poprawić wydajność, czy stabilność.
Duże firmy maja SQA który testuje pod względem stabilności, maja specjalne laby komory atmosferyczne itd.
Dla mnie jako użytkownika gonienie za wersja kernela nie jest najważniejsze, bo coś te wersje jak na moje gusta za szybko się zmieniają, a i są też zmiany bardzo rozległe które nie wpływają na nic oprócz widzimisię autorów, że tak będzie ładniej.
Przez co trafiają się błędy, które wynikają z błędów przy zmianach API.
Warto pamiętać i pochylać się nad patchami chip vendorów, czasem robią coś po najprostszej linii oporu przez co takie zmiany nie maja szans być z mergowanymi, ale jednak.
A tak z ciekawości. Oryginalne firmware nowych routerów na rynku bazują na nowszych wydaniach kernela, czy jednak bazują na starszych wersjach. Bo pytanie, czy te problemy OpenWRT nie biorą się z ślepej walki o wyższe numerki kernela za czym nie idzie, a ni stabilność, ani funkcjonalność.
podtor napisał/a:Zawsze masz 14 dni na zwrot lub reklamację.
Na reklamację to akurat jest 2 lata w przypadku nówki, ale że jest to używka to będzie to rok. Sam router mam od marca.
Tylko, że jeśli działa poprawnie na orginalnym firmware to za bardzo nie ma podstawy do reklamowania.
Kup sobie masc na bol...
Znam historie, zas Ty nie zachowujesz sie tak, by z Toba rozmawiac. Ja Ciebie nie usiluje obrazac.Baw sie dobrze i narzekaj dalej. To, ze cos umiesz nie znaczy, ze jestes nieomylny.
EoT
To piszesz do mnie czy kłomnie? To nie ja się wymądrzałem ale ty.
Na domiar złego pisałeś bzdury.
Pisałem o czasach kiedy WRT54GL był na topie i wtedy jak działał OpenWRT, a ty coś mi na to odpisał?
Może by teraz przeprosić wypadało - nie uważasz?
"Z bani" to jesteś drogi Panie Ty
Weź Ty se poczytaj skąd się w ogóle wzięło OpenWRT bo coś widać z wiedzą u Pana na bakier.
OpenWrt – dystrybucja Linuksa pierwotnie przeznaczona dla urządzeń WLAN produkowanych przez firmę Linksys, a w szczególności dla routerów z serii WRT54G.
Równo pojechałeś Wykazałeś się kompletną ignorancją i niewiedzą, a na dodatek zwykłym buractwem.
To, że nowe obrazy być może działają "kulawo" nie oznacza, że tak było kiedy właśnie OpenWRT rozwijało się na tych wiekowych już routerach.
Proponuje się rozpędzić i walnąć pustym łbem o ścianę - być może nie zmądrzejesz od tego, ale zapamiętasz, żeby się nie wypowiadać na tematy o których pojęcia zielonego nie masz.
@viper_lasser
A z ciekawości ile masz wolnej pamięci RAM po 43 dniach?
W ogóle to trochę smutne, że kiedyś soft OpenWRT był gwarancją stabilności.
Tzn. chciałeś mieć stabilnie działający router to wgrywałeś OpenWRT.
Choć problemy z rozłączaniem klientów po WiFi na OpenWRT to ja pamiętam od czasów WRT54GL.
Teraz wgrywanie OpenWRT ma jedynie sens jak potrzebujesz funkcjonalności której nie daje soft producenta i nie jesteś wstanie go rozszerzyć samodzielnie o taką funkcjonalność. Lub z sentymentu. Darze olbrzymim sentymentem OpenWRT ale z przykrością muszę stwierdzić, że wybieram stabilność.
I jak wygląda sytuacja na kernelu 5.4?
Ktoś testuje - czy działa stabilnie - czy problem z cieknięciem pamięci nie występuje?
Tymczasem u mnie na oficjalnym sofcie + moja customizacja opisana tutaj:
https://openrouter.info/forum/viewtopic … 223#p47223
# cat /proc/uptime && free && cat /proc/interrupts
3350552.59 6587317.75
total used free shared buffers
Mem: 122308 51776 70532 0 2184
Swap: 0 0 0
Total: 122308 51776 70532
CPU0 CPU1
3: 237731670 0 MIPS GIC eth2
4: 188 294993048 MIPS GIC rai0
7: 837637552 837636866 MIPS GIC timer
12: 0 0 MIPS GIC ralink_gpio
18: 0 0 MIPS GIC Ralink_SPDIF
22: 3355990067 0 MIPS GIC xhci-hcd:usb1
23: 172 0 MIPS GIC Ralink_ESW
25: 798 360900863 MIPS GIC ra0
26: 14650816 0 MIPS GIC serial
56: 14163517 0 MIPS GIC IPI_resched
57: 0 14789059 MIPS GIC IPI_resched
58: 0 0 MIPS GIC IPI_resched
59: 0 0 MIPS GIC IPI_resched
60: 97443134 0 MIPS GIC IPI_call
61: 0 72333163 MIPS GIC IPI_call
62: 0 0 MIPS GIC IPI_call
63: 0 0 MIPS GIC IPI_call
ERR: 0
#uptime 3350552.59 ~= 38 dni
I jeszcze bo z flushowaniu cache:
# sync; echo 3 > /proc/sys/vm/drop_caches; free
total used free shared buffers
Mem: 122308 42772 79536 0 220
Swap: 0 0 0
Total: 122308 42772 79536EDIT:
Pobieżna lektura https://forum.openwrt.org/t/mtk-soc-eth … /50000/232
wskazuje na to, że na Kenelu 5.4 problem ze switchem ciągle występuje... Niestety
Jedna para jest przylutowana, a druga (wchodzi pod blaszkę?) nie widać dobrze przez tę przyklejoną taśmę, a router ciągle działa wiec mam utrudniony do niego dostęp.
Na naklejce jest Ver. 1.3
EDIT:
Otworzyłem drugi router tam jest Ver. 1.4 i faktycznie aluminiowa blaszka + anteny podłączone przez złącza.
Przypomnę, że testowałem na obydwu i na obydwu były te same problemy - akurat z oryginalnym zacząłem się bawić na tym, który teraz jest w sieci i otworzyłem go, żeby dolutować RS'a, tego drugiego do tej pory nie miałem potrzeby otwierać dlatego nie wiedziałem, o tym, że w zależności od rewizji jest albo ceramiczny albo aluminiowy radiator.
Więc zdaje się nie jest to kwestia rewizji płyty. Dobrze, że @Cezary poruszył tę kwestię no i też widać miałem to "szczęście", że sprzedający wysłał mi Ver. 1.3 i Ver. 1.4
@Cezary
A to nie wiedziałem - przepraszam.
eko.one.pl → Posty przez samuel.obiedzinski
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc