Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Gargoyle 1.13.x
Strony Poprzednia 1 … 19 20 21 22 23 24 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Ok, dzięki, to wracam do 21.02 
A to "trudno powiedzieć" to powiedzmy 3 miesiące czy bardziej 3 lata? Szczerze mówiąc mam wrażenia że już częściej kolejne Windowsy mają premierę niż coś większego w OpenWrt ale w sumie może to i lepiej.
OpenWrt jest wydawane mniej więcej co rok, z kilkoma poprawkami dla danego wydania.
Gargoyle - cóż, potrzebuje więcej czasu.
Ok. To póki Pan jest i śledzi forum... LuCi 21.02 dla R6350 jest niepoprawny/uszkodzony, zgadza się tylko suma kontrolna. Da radę to szybko naprawić? Szczerze mówiąc boję się wymuszać instalację teoretycznie niezgodnego softu z urządzeniem ;p
W tym samym momencie wydania Gargoyle się nie czepia oczywiście, plik pobierałem 3 razy.
W jakim jest jest niepoprawny/uszkodzony? Jak się suma kontrolna zgadza to obraz jest poprawny.
Dla pliku luci-21.02-snapshot-r16521-b1c3539868-ramips-mt7621-netgear_r6350-squashfs-sysupgrade.bin
Może się zgadza ale Gargoyle twierdzi inaczej ;p
Bardzo stanowczo na przyszłość sugeruję zapoznawać się z opisem danej wersji, chociaż by moje: https://eko.one.pl/forum/viewtopic.php?id=20877
Obraz jest dobry, zmienił się zaś sposób w jaki tworzona jest sieć (DSA) i wymaga wgrania na czysto bez zachowania konfiguracji i ew wymuszeniem. Co też gargoyle napisało na ekranie. Czytać, czytać i jeszcze raz czytać.
No to ok z tym że do linku nie mam uprawnień a na https://eko.one.pl/?p=openwrt-21.02 nic nie ma, w luci też nie ma, w gargoyle również jak i na stronie głównej eko.one.pl. Nie widzę miejsca gdzie miałbym się o tym w sumie dowiedzieć a kiedyś jak skakałem z Gargoyla na LuCi i z powrotem to nikdy takiego komunikatu nie miałem. To co się zmieniło to czerwony napis że aktualizacja może uszkodzić urządzenie dlatego też tu napisałem bo wziąłem to po prostu za jakiś błąd kompilacji skoro ani plik nie jest prawidłowy ani wspierane urządzenie. Chyba że coś przegapiłem ale to już nieistotne, wgrywam więc.
Już, poprawiłem link. To zwykły temat na forum.
Pozwolę sobie zapytać o kwestię formalną: tutaj Gargoyle 1.13 jest uznawane za wydane już stabilnie (w przeciwieństwie do wersji rozwojowych "preX"), ale na gargoyle-router jest oznaczona jako "experimental" (podobnie jak każda inna nieparzysta wersja) -- to jak to jest? Jest 1.13 stabilna, czy nie, czy tak pół-stabilna? 
Bo z tego co się orientuję, to "stable" 1.14, gdy kiedyś wyjdzie, to będzie normalnie nowe wydanie, na nowszym OpenWRT, a nie jakoś doszlifowane "experimental" 1.13, prawda?
Niezbyt istotne pytanie, ale może komuś będzie się chciało napisać skąd takie oznaczenia na gargoyle-router... Z góry dziękuję!
Kiedyś tak i było. Biorąc pod uwagę że 1.13 ma sporo nowości (gui, ipv6) to można to traktować jako eksperymentalne. Następne wydanie będzie na nowej wersji openwrt (na chwilę obecną: 21.02 i ma oznaczenie 1.15.x). Czy będzie 1.14 tego nikt nie, tym bardziej że wsparcie dla openwrt 19.07 na którym jest 1.13 właśnie się kończy.
Nie jestem pewny, czy nie znalazłem buga... Mam układ taki, że Gargoyle 1.13.0.1 mam zainstalowane na R6220, który znów jest podpięty przez WAN do modemu Arris od Vectry. I wszystko pięknie działa, jeśli w konfiguracji Gargoyle mam ustawione serwery DNS od ISP. Jeśli ustawię jakiekolwiek inne z proponowanej listy (np. od Cloudflare), to Gargoyle nie pobiera adresu IP po DHCP od operatora (żeby być dokładnym to raz na kilkanaście prób udaje się; zazwyczaj, choć nie zawsze, jeśli po zmianie DNS uruchomię ponownie Arrisa). Nie wiem czy problem u mnie dotyczy tylko nakładki Gargoyle, czy jest głębszy -- nie próbowałem jeszcze zmienić konfiguracji DNS przez SSH. Ale czy ktoś mógłby spróbować u siebie raz czy dwa zmienić DNS na inne niż operatora i np potwierdzić, że "u mnie DHCP działa"? Z góry dziękuję!
P.S. Na pewno nie miałem tego problemu z Gargoyle 1.12.
Nie notowałem tego objawu na Xiaomi Mini (przenosiłem router między operatorami, więc razem z IP zmieniał się DNS (operatorski). Niestety nie mam jak tego teraz sprawdzić
Za to zauważyłem, że nie działał w ogóle reset w tej wersji Gargoyle, co jest dość ryzykowne.
Jaki reset? W sensie przycisk?
Ciąg dalszy sprawdzania w opisanym powyżej układzie:
Ręczne wpisanie DNS w konsoli (#uci set network.wan.dns="...", #uci set network.wan.peerdns=0, #uci commit network, #ifup wan) działa poprawnie -- tak wpisany DNS zaczyna być wykorzystywany, a router uzyskuje pozostałe ustawienia wan, w tym swój adres, z DHCP dostawcy. Natomiast w panelu konfiguracji sieci w Gargoyle wciąż widać opcję, że DNS jest od ISP. Za to próba dodania adresów DNS w panelu Gargoyle poprawnie dopisuje opcje "dns" i "peerdns" w /etc/config/network, ale na koniec nie zaciąga z DHCP adresu dla wan.
Jeżeli identycznie wyglądają wpisy to przecież musi pobierać adres z dhcp. Tym bardziej że te wpisu nijak się mają do adresu.
U mnie działa. Gagroyle 1.13.0.1, na R6220. Domyślna konfiguracja - na wanie pobiera adres. Zmieniam dnsy na cloudflare - mam adres na wanie. Zrobię zwolnij dzierżawę - nie mam adresu, robię odśwież dzierżawę - mam adres. Wyłączam cloudflare, zapisuje - mam adres.
Bardzo dziękuję za sprawdzenie! Może u mnie ten Arris coś miesza... Albo sam przekombinowałem, bo trochę konfigurowałem ruter przez Gargoyle, trochę przez konsolę.
A z ciekawości, gdzie sama nakładka Gargoyle zapisuje ustawienia, skoro nie widzi adresów DNS wpisanych komendami uci w sekcji 'wan' w /etc/config/network?
Widzi. Tylko musi być w sekcjach lan/wan oraz być to odpowiednie dnsy żeby gui wiedziało czym to jest, inaczej pokaże że są "inne"
Jaki reset? W sensie przycisk?
Tak
Zaktualizowałem D-Link DWR-921 C1 z wersji Cezarego 1.13.0.0pre11 na oficjalną.
No i zaczęły się dziwne problemy z WiFi.
Okresowo co 2-3dni urządzenie nie przyjmuje żadnych stacji.
Pomaga restart urządzenia, zdarzyło się też raz że po jakimś czasie problem samoistnie ustąpił.
Za którymś razem wbiłem się VPNem z drugiej strony i cały log zasypany:
daemon.notice hostapd: wlan0: STA xxx IEEE 802.11: did not acknowledge authentication response
daemon.notice hostapd: wlan0: STA xxx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
daemon.notice hostapd: wlan0: STA xxx IEEE 802.11: did not acknowledge authentication response
daemon.notice hostapd: wlan0: STA xxx IEEE 802.11: did not acknowledge authentication response
dla wszystkich macadresów urządzeń.
Restart wifi rozwiązał problem ale na pewno chwilowo.
Wróciłem do wersji 1.13.0.0pre11 z zachowaniem ustawień + rekonfiguracja. I póki co wygląda że się uspokoiło.
To raczej tytułem informacji, bo rozwiązania nie znalazłem. Problemy z flashem raczej można odrzucić.
Ale przy okazji chciałem zrestartować WiFi przyciskiem i tu niespodzianka.
Przycisk wywołujący wifi on/of wyłącza sieć ale włączyć jej nie daje rady. Sam skrypt działa prawidłowo w obie strony.
Zachowanie identyczne we wszystkich FW.
W konfiguracji (domyślnej - nie była zmieniana) jest:
config button 'wps_button'
option button 'wps'
option action 'released'
option handler 'logger reboot ; /sbin/wifionoff ;'
option min '0'
option max '2'
config button 'rfkill_button'
option button 'rfkill'
option action 'released'
option handler 'logger reboot ; /sbin/wifionoff ;'
option min '0'
option max '2'
config button 'btn2_button'
option button 'BTN_2'
option action 'released'
option handler 'logger reboot ; /sbin/wifionoff ;'
option min '0'
option max '2'
Według opisu ze strony eko Gargoyle obsługuje przyciski też na swój sposób (bezpośrednie skrypty w katalogu).
Czy przypadkiem nie są uruchamiane jednocześnie dwa skrypty i tu następuje konflikt?
Na przestrzeni tych paru miesięcy pomiędzy pre11 a finalną wersją został raz zaktualizowany mac80211 oraz kilka razy kernel i biblioteki kryptograficzne. Niestety wydanie openwrt 19.07 dotarło już do końca swoich dni, i nawet jak byś to zgłosił jak problem to już nie zostanie rozwiązane bo nic nie będzie aktualizowane.
Mam zamiar jeszcze zrobić kolejną wersje gargoyle (w której nic się nie zmieniło) żeby było na aktualnych źródłach openwrt 19.08 (w którym też już nic nie poprawiają), więc możesz zobacz później jak to Ci się będzie zachowywało.
Sprawdzę oczywiście.
Obie testowane wersje oparte były na tej samej bazie, dlaczego oficjalna sprawia problemy?? Dziwne.
Ja w każdym razie pozostaje przy twojej linii wydań.
A odnośnie przycisku?
Jak to dokładnie jest wywoływane w Gargoyle (skrypty w katalogu Gargoyle vs wpisy pliku system).
Opis na stronie nie wyjaśnia tego do końca.
Problem jest również w nieoficjalnych starszych wersjach pre.
Zrób
rm /etc/rc.button/rfkill
ln -s /etc/rc.button/gargoyle_button_handler /etc/rc.button/rfkill
I zobacz co będzie.
Baza też się zmienia, jest (była) aktualizowana.
Z tego co wyszukałem urządzenie DWR-921 C1 ma dwa przyciski GPIO
wps {
label = "wps";
gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WPS_BUTTON>;
};
reset {
label = "reset";
gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
W konfiguracji systemu wpisane mam dodatkowo buttony: reboot, rfkill, btn2.
To celowe wpisy czy jakieś pozostałości?
Z czego wynika wykorzystywanie rfkill a nie standardowej obsługi klawiszy skonfigurowanej na np. wifi on/of?
Gargoyle definiuje wszystkie możliwe przyciski a nie że jest indywidualnie dla danego modelu routera. Jak nie ma danego przycisku to po prostu jego akcje nie są wykorzystywane.
Masz przycisk o nazwie wps, wic jego akcja pownna być wykorzystywane (nie skrypt rfkill). Skrypt z /etc/rc.button/wps to link do gargoyle_button_handler a on na podstawie /etc/config/system szuka co z tym zrobić. Woła wifionoff, a tam jest tylko wifi up i wifi down.
Strony Poprzednia 1 … 19 20 21 22 23 24 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Gargoyle 1.13.x
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc