Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez Grzesinski
Z moich ostatnich doświadczeń nie jestem już taki pewien czy problem dotyczył samego QoS czy był głębszy.
Mam wrażenie, że coś namieszane jest w firewallu ogólnie.
Nieaktywna reguła białej listy czasami przepuszczała mi ruch pomimo, że nie powinna mieć żadnego wpływu.
Usunięcie nieaktywnej reguły definitywnie rozwiązało problem.
Zweryfikuję to na nowej wersji.
Zauważyłem, że w bieżącej wersji nie działa prawidłowo (przynajmniej u mnie) limitowanie transferu.
Mam zdefiniowane dwie grupy IP, z limitem 30Gb/m-c każda. Po przekroczeniu lejek 16kb up/down.
I drugi miesiąc z rzędu przekroczenie łącznego transferu 100Gb po 3 tygodniach.
Zużycie dla pierwszej grupy raportowane 100% tj. 57Gb/30Gb (tak pokazuje zależnie od wyświetlania).
Dzienny transfer w ostatnim dniu 17Gb. To już po przekroczeniu limitu i nie da się tego pobrać przy takim lejku.
Czy ktoś może potwierdzić poprawne działanie tego mechanizmu?
W starszych wersjach działało to poprawnie i skutecznie blokowało.
/etc/config/firewall wydaje się ok.
config quota 'quota_7'
option combined_limit '37580963840'
option exceeded_up_speed '16'
option exceeded_down_speed '16'
option reset_interval 'month'
option ip '192.168.2.108,192.168.2.109,192.168.2.110'
option id '192.168.2.108_A'
option enabled '1'
option reset_time '1036800'
config quota 'quota_8'
option combined_limit '37580963840'
option exceeded_up_speed '16'
option exceeded_down_speed '16'
option reset_interval 'month'
option ip '192.168.2.104,192.168.2.105,192.168.2.106,192.168.2.112'
option id '192.168.2.104_B'
option enabled '1'
option reset_time '1036800'
Dziękuję za wyjaśnienie.
Przy takim punkcie widzenia jest OK.
Podkleję się pod wątek, żeby nie zakładać nowego tematu.
Zauważyłem, że w MiFI (MF286D, może w innych też) zakładki statystyk mają odwrotnie opisane Dane wysłane i Dane odebrane. Zarówno w statystykach dziennych jak i miesięcznych (dla hostów).
Możliwe, że ktoś już to zgłaszał ale nie znalazłem.
Nie wiem jak ze zliczaniem miesięcznym, tu też coś przez chwilę coś było źle (dane w miesiącu były radykalnie mniejsze niż dzienne, oraz sumaryczne zużycie). Ale muszę się dokładnie przyjrzeć.
Btw podobny problem ma Gargoyle.
Witam ponownie bo pojawiły się (w końcu) nowe fakty dotyczące problemu opisanego w poście 546.
Chodziło o losowe blokowanie się interfejsu WiFi z logami "deauthenticated due to inactivity".
W międzyczasie napisałem skrypt okresowo sprawdzający czy nie wystąpiło to zdarzenie i resetujący interfejs.
Ale niedawno zupełnie przypadkiem znalazłem winnego - stary Xbox360, który od zamierzchłych czasów działał ze starszymi wersjami Gargayle teraz kompletnie nie współpracuje z bieżącym wydaniem.
Urządzenie łączy się z routerem, dostaje IP z DHCP i zawiesza interfejs wyrzucając wszystkie stacje.
Z tego co znalazłem w sieci to XBOX podobno próbuje poprzez unpnp (nie mam zainstalowanego) przekierować jakieś porty routera pod swoje potrzeby. Opisy problemu (jak się już wie czego szukać) są w sieci. Rozwiązania nie znalazłem.
Jakieś pomysły?
Sprawdziłem, że Xbox bezproblemowo współpracuje z AP udostępnionym z telefonu.
Konfiguracja (nietypowe ustawienia legacy_rates, beacon_int, disassoc_low_ack to podzwonne walki z problemem)
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.hwmode='11g'
wireless.radio0.path='platform/10180000.wmac'
wireless.radio0.noscan='1'
wireless.radio0.country='PL'
wireless.radio0.channel='7'
wireless.radio0.htmode='HT20'
wireless.radio0.legacy_rates='1'
wireless.radio0.beacon_int='100'
wireless.ap_g=wifi-iface
wireless.ap_g.device='radio0'
wireless.ap_g.mode='ap'
wireless.ap_g.network='lan'
wireless.ap_g.disassoc_low_ack='0'
wireless.ap_g.macfilter='allow'
wireless.ap_g.maclist='xx.xx.....'
wireless.ap_g.ssid='XXX'
wireless.ap_g.encryption='psk2'
wireless.ap_g.key='pswd'
Sun Oct 9 21:42:50 2022 daemon.notice hostapd: wlan0: AP-STA-POLL-OK xx:xx:xx:xx:xx:xx
Sun Oct 9 21:43:00 2022 daemon.info hostapd: wlan0: STA yy:yy:yy:yy:yy:yy IEEE 802.11: authenticated
Sun Oct 9 21:43:00 2022 daemon.info hostapd: wlan0: STA yy:yy:yy:yy:yy:yy IEEE 802.11: associated (aid 6)
Sun Oct 9 21:43:00 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED yy:yy:yy:yy:yy:yy
Sun Oct 9 21:43:00 2022 daemon.info hostapd: wlan0: STA yy:yy:yy:yy:yy:yy RADIUS: starting accounting session C19DEDCB48D79F17
Sun Oct 9 21:43:00 2022 daemon.info hostapd: wlan0: STA yy:yy:yy:yy:yy:yy WPA: pairwise key handshake completed (RSN)
Sun Oct 9 21:43:00 2022 daemon.info dnsmasq-dhcp[31249]: DHCPDISCOVER(br-lan) yy:yy:yy:yy:yy:yy
Sun Oct 9 21:43:00 2022 daemon.info dnsmasq-dhcp[31249]: DHCPOFFER(br-lan) 192.168.2.110 yy:yy:yy:yy:yy:yy
Sun Oct 9 21:43:00 2022 daemon.info dnsmasq-dhcp[31249]: DHCPREQUEST(br-lan) 192.168.2.110 yy:yy:yy:yy:yy:yy
Sun Oct 9 21:43:00 2022 daemon.info dnsmasq-dhcp[31249]: DHCPACK(br-lan) 192.168.2.110 yy:yy:yy:yy:yy:yy Xbox
>>>
Sun Oct 9 21:45:04 2022 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED zz:zz:zz:zz:zz:zz:zz
Sun Oct 9 21:45:04 2022 daemon.info hostapd: wlan0: STA zz:zz:zz:zz:zz:zz:zz IEEE 802.11: disassociated
Sun Oct 9 21:45:05 2022 daemon.info hostapd: wlan0: STA zz:zz:zz:zz:zz:zz:zz IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Oct 9 21:45:14 2022 daemon.notice hostapd: wlan0: STA zz:zz:zz:zz:zz:zz:zz IEEE 802.11: did not acknowledge authentication response
Sun Oct 9 21:45:38 2022 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED oo:oo:oo:oo:oo:oo
Sun Oct 9 21:45:38 2022 daemon.info hostapd: wlan0: STA oo:oo:oo:oo:oo:oo IEEE 802.11: disassociated
Sun Oct 9 21:45:39 2022 daemon.info hostapd: wlan0: STA oo:oo:oo:oo:oo:oo IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Oct 9 21:45:44 2022 daemon.notice hostapd: wlan0: STA zz:zz:zz:zz:zz:zz:zz IEEE 802.11: did not acknowledge authentication response
Sun Oct 9 21:45:45 2022 daemon.notice hostapd: wlan0: STA zz:zz:zz:zz:zz:zz:zz IEEE 802.11: did not acknowledge authentication response
Sun Oct 9 21:45:55 2022 daemon.notice hostapd: wlan0: STA zz:zz:zz:zz:zz:zz:zz IEEE 802.11: did not acknowledge authentication response
Sun Oct 9 21:46:06 2022 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED yy:yy:yy:yy:yy:yy
NETGEAR R6220
Ta nazwa obowiązuje też dla: "OpenWrt 21.02 (bez LuCI)", "LuCI (OpenWrt 21.02)" oraz "OpenWrt 22.03 (bez LuCI)"Gdy po prawo wybierzesz wersję Gargoyle 1.13 i wybierz proponowaną nazwę:
Netgear R6220
to zobaczysz te obrazy. Ta nazwa obowiązuje też dla wersji "OpenWrt 19.07 (bez LuCI)" oraz dla "LuCI (OpenWrt 19.07)"
Ale to chyba nie problem wybierać nazwy z małej czy dużej litery, prawda?
Faktycznie pojawia się sugestia zmiany nazwy. Zafiksowałem się, że jak urządzenie raz wybrane to obowiązuje.
A co do poszukiwań to D-Link DWR-921 C1 gargoyle 1.13.0.0pre11 factory.
Najnowszej wersji G jeszcze nie testowałem, w zakresie sterowników WiFi coś się zmieniło?
Z tego co pamiętam, to ma być ostatnia z nieoficjalnych?
Ciekawe.
Z linku powyżej idzie.
Ale u mnie z wyszukiwarki (FF, Edge) pokazuje wszystko tylko nie Gargoyle.
I samo ściąganie plików (tych) idzie albo makaskrycznie wolno albo od strzału.
Niestety nic nie znalazłem. Trudno.
Ale przy okazji nowej wersji zauważyłem, że wyszukiwarka firmware nie wyłapuje Gargoyle dla NetGear R6220.
A pliki, mam wrażenie, są na miejscu.
BTW znajdę gdzieś gargoyle factory 1.13.0.0pre11 ?
Najbardziej elegancko byłoby gdyby demon sprawdzał czy wan jest podniesiony zanim zacznie sprawdzać coś dalej.
Tyle że w praktyce wyjdzie jak powyżej + dodatkowe modyfikacje więc nie ma sensu.
A GUI nie weźmie wartości z /etc/ddns_gargoyle.conf?
service ddns_1
enabled 1
service_provider opendns.com
ip_source internet
force_interval 3
force_unit days
check_interval 15
check_unit minutes
Czy zostanie ona zaktualizowana podczas testu?
Zastanawiam się czy nie prościej byłoby czasowo wyłączać ddns /etc/init.d/ddns_gargoyle stop i start.
A co po zmianie /etc/config/ddns_gargoyle źeby wczytał bieżącą konfigurację?
Wywołanie /etc/init.d/ddns_gargoyle nadpisze zmiany.
Chyba już nie szablon
3758 root 3824 S /usr/bin/ddns_gargoyle -P /etc/ddns_providers.conf -C /etc/ddns_gargoyle.conf -d
Rozszerzyłem działanie skryptu sheduled_wifi Gargoyle, tak aby oprócz wyłączania WiFi okresowo wyłączany był również Wan.
Działa to poprawnie ale przy okazji chciałbym wyłączyć lub wydłużyć interwał sprawdzania DDNS.
Ten ostatni nie sprawdza czy WAN działa i zasypuje log błędami.
Gargoyle korzysta z konfiguracji z /etc/ddns_gargoyle chciaż automatycznie aktualizuje też /etc/config/ddns_gargoyle.
Można dostać się z poziomu UCI do /etc/ddns_gargoyle żeby go zmodyfikować?
Nie udało mi się wydedukować jakie akcje są robione z chwilą nacięcia przycisku save ze strony /www/ddns.sh ( /etc/init.d/ddns_gargoyle ?)
Przyciski ogarnięte.
Nie wiem co było przyczyną bo w akcie desperacji przywróciłem czystą konfigurację i skonfigurowałem od zera.
Plik system oraz zawartość katalogu rc.button niby taka sama jak wcześniej, tyle że teraz całość działa.
No i trzeba pamiętać żeby wpisy sekcji przycisków miały unikatowe nazwy nawet jeśli dotyczą obsługi jednego klawisza.
Napisałem nazwy na skróty, ale dzięki za wyjaśnienie.
config button 'wps_button'
option button 'wps'
option action 'released'
option handler 'logger WPS WiFi toggle ; /sbin/wifionoff ;'
option min '0'
option max '2'
Plik podlinkowany
/etc/rc.button/wps -> /etc/rc.button/gargoyle_button_handler
I czasami działa, czasami nie reaguje. Nawet wpisu w logu nie ma więc nie ma co liczyć na wywołanie /sbin/wifionoff
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?
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.
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?
Warto aktualizować z 'nieoficjalnej' 1.13.0.0pre11 ?
A widzisz...zasugerowałem się.
Teraz działa jak ta lala...
Dla podsumowania
config interface 'vpnpptp'
option keepalive "4 15"
To z gruntu lepsze rozwiązanie niż zmiana w options.pptp (pomijam że ta ostania nie działa), bo dotyczy tylko jednego interfejsu
Wielkie dzięki...
Dodałem do /etc/ppp/options.pptp
option keepalive "4 15"
Tunel już nie wstał.
ifstatus vpnpptp
{
"up": false,
"pending": false,
"available": true,
"autostart": false,
"dynamic": false,
"proto": "pptp",
"data": {
},
"errors": [
{
"subsystem": "pptp",
"code": "OPTION_ERROR"
logread
Wed Dec 22 19:27:15 2021 daemon.info pppd[7602]: Plugin pptp.so loaded.
Wed Dec 22 19:27:15 2021 daemon.info pppd[7602]: PPTP plugin version 1.00
Wed Dec 22 19:27:15 2021 daemon.notice netifd: vpnpptp (7602): /usr/sbin/pppd: In file /etc/ppp/options.pptp: unrecognized option 'option'
Wed Dec 22 19:27:15 2021 daemon.err pppd[7602]: In file /etc/ppp/options.pptp: unrecognized option 'option'
Wed Dec 22 19:27:15 2021 daemon.notice netifd: Interface 'vpnpptp' is now down
A skoro nie odpowiada mu opcja 'option' to następna próba z wpisem keepalive "4 15"
Wed Dec 22 19:29:58 2021 daemon.notice netifd: Interface 'vpnpptp' is setting up now
Wed Dec 22 19:29:58 2021 daemon.info pppd[7719]: Plugin pptp.so loaded.
Wed Dec 22 19:29:58 2021 daemon.info pppd[7719]: PPTP plugin version 1.00
Wed Dec 22 19:29:58 2021 daemon.notice netifd: vpnpptp (7719): /usr/sbin/pppd: In file /etc/ppp/options.pptp: unrecognized option 'keepalive'
Wed Dec 22 19:29:58 2021 daemon.err pppd[7719]: In file /etc/ppp/options.pptp: unrecognized option 'keepalive'
Wed Dec 22 19:29:58 2021 daemon.notice netifd: Interface 'vpnpptp' is now down
Reasumując - plik konfiguracji jest parsowany jak widać.
Jak zmienić keepalive nie wiadomo.
Dziękuję za sugestię, sprawdzę.
Ew. zmodyfikuję skrypt.
Wrzuciłem
lcp-echo-interval 15
lcp-echo-failure 4
do /etc/ppp/options.pptp, później do /etc/ppp/options, a na końcu do obu.
Za każdym razem restart sieci i nic, bez zmian.
Dwa procesy (jednak pojawiają się dwa po podniesieniu interface)
/usr/sbin/pppd nodetach ipparam vpnpptp ifname pptp-vpnpptp lcp-echo-interval 1 lcp-echo-failure 5 lcp-ec
A te dwa identyczne procesy to tak ma być czy coś się pomieszało?
Na razie ich nie ubijam bo mogę się odciąć od urządzenia.
eko.one.pl → Posty przez Grzesinski
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc