TERM=linux mc -x
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez Jazz
TERM=linux mc -x
U mnie taki problem nie występuje. Po przełączeniu AP w dowolną stronę mam pełną prędkość. Nawet udało mi się zmierzyć prędkość w trakcie przemieszczania się od jednego AP do drugiego. Widać było jak prędkość płynnie spada, a po przełączeniu rośnie.
Androidy to Honor Magic6 Pro i Realme 14 Pro+. WiFimana mam i używam do testów FT. Na aplikacji wszystko wygląda OK, telefon gładko przełącza się między AP. Spadków prędkości nie zauważyłem. Ale jak wrócę do domu zrobię test dokładnie wg. Twojej instrukcji.
Wi-Fi Calling testowałem na 2 Androidach różnych producentów. Po pytaniu Cezarego sprawdziłem 2 iPhone-y i okazało się, że na nich nie zrywa. W logach różnicy między Androidem i iOS nie ma.
Walczę z roamingiem Wi-Fi i Wi-Fi Calling. Problem polega na tym, że przy zmianie AP rozmowa się przerywa. W logach mam:
Tue Jan 6 11:09:04 2026 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'phy1-ap0'
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authentication OK (FT)
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx MLME: MLME-AUTHENTICATE.indication(xx:xx:xx:xx:xx:xx, FT)
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: association OK (aid 5)
Tue Jan 6 11:09:04 2026 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 5)
Tue Jan 6 11:09:04 2026 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx auth_alg=ft
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx MLME: MLME-REASSOCIATE.indication(xx:xx:xx:xx:xx:xx)
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'phy1-ap0'
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx WPA: event 6 notification
Tue Jan 6 11:09:04 2026 daemon.debug hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx WPA: FT authentication already completed - do not start 4-way handshakePrzypuszczam, że powodem zrywania połączenia jest ten błąd: daemon.err hostapd: nl80211: kernel reports: key addition failed. Nie potrafię się go pozbyć. Moja wyjściowa konfiguracja była taka:
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/18000000.wifi'
option band '2g'
option channel '6'
option htmode 'HE40'
option country 'PL'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'nazwa'
option encryption 'sae-mixed'
option key 'hasło'
option ieee80211r '1'
option ft_over_ds '0'
option ieee80211k '1'
option bss_transition '1'
option ocv '2'
option max_inactivity '90'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/18000000.wifi+1'
option band '5g'
option channel '100'
option htmode 'HE160'
option country 'PL'
option cell_density '3'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'nazwa'
option encryption 'sae-mixed'
option key 'hasło'
option ieee80211r '1'
option ft_over_ds '0'
option ieee80211k '1'
option bss_transition '1'
option ocv '2'
option max_inactivity '90'Od tego czasu zmieniłem szyfrowanie na psk2. Przełączałem ft_over_ds, ft_psk_generate_local. Dodawałem pmk_r1_push. Jawnie zadeklarowałem: mobility_domain, nasid, r1_key_holder. Zmieniłem cell_density i ocv na 0. W odruchu desperacji dodałem nawet:
option time_advertisement '2'
option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
option wnm_sleep_mode '1'
option wnm_sleep_mode_no_keys '1'Miałem zainstalowane wszystkie pełne wersje wpad: wpad-mbedtls, wpad-openssl, wpad-wolfssl. Oczywiście nie wypróbowałem wszystkich możliwych kombinacji, ale nie mam już siły na błądzenie we mgle. Czy ktoś spotkał się z podobnym problemem i udało mu się goo rozwiązać? Mój sprzęt to: GL.iNet GL-MT6000 oraz Xiaomi Mi Router AX3000T jako dumb AP.
Mam ten router od 3 dni i faktycznie statystyki są mocno zawyżone, np mój TV pobrał w tym czasie 4,4 TiB a wysłał 3,7 TiB.
Odgrzeję wątek, bo właśnie przetestowałem ten build Konga i generalnie działa. Mam łączę PPPoE 350/350. Na buildzie Cezarego sppedtest wykazywał 240/260. Teraz skoczyło do 380/380 przy symbolicznym użyciu procesora.
Wady, na zrazie znalazłem 2:
1. Build Konga nie korzysta ze standardowych repozytoriów, tylko z własnych, w których nie ma wszystkich pakietów np. luci-mod-rpc, którego akurat potrzebuję.
2. Przekierowanie portów działa dziwnie. Tzn. działa z zewnątrz, działa z wewnątrz z urządzeń podłączonych przez Wi-Fi, ale nie działa z wewnątrz z urządzeń podłączonych przewodowo. Żeby było jaśniej, z kompa podłączonego przewodowo wchodzę na swoją stronę i nic, przełączam się na Wi-Fi, strona wskakuje. Na standardowych buildach OpenWrt czy Cezarego takich jaj nigdy nie miałem. Rozwiązałem ten problem tak, że w DHCP and DNS w sekcji CNAME dodałem przekierowanie mojej domeny na adres wewnętrzny mojego serwera. Czy to jest zgodne ze sztuką, nie wiem, pewnie nie, ale działa.
Owszem. Ja mam heyah, Wi-Fi calling działa mi w każdym hotelu / pensjonacie / itp. Nic niczego nie konfiguruje.
A na OpenWrt wystarczy do /etc/rc.local dodać:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state0/disable
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state0/disable
echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state1/disableA jak sprzedawca powie, że to najszybszy router na świecie to też uwierzysz?
Właśnie dlatego go kupiłem ;-)
Panowie dzięki. Wgrałem obaz z LuCi i oczywiście jest OK.
Pewnie tak zrobię, ale dziwne jest to, że sprzedawca zarzeka się, że wgrał wersję z luci. I ja mu wierzę. Wysłał mi nawet zrzut ekranu z luci.
Czy jest możliwe, że przywrócenie ustawień domyślnych / firstboot nie działa w tym modelu prawidłowo?
Kupiłem używanego TP-Linka C2600. Sprzedawca przed wysyłką wgrał mi najnowsze OpenWrt z LuCi od Cezarego. Ale ja nie mogłem się do niego dostać. Zalogowałem się przez ssh i zrobiłem firstboot - nie pomogło. Potem z poziomu ssh doinstalowałem luci no i niby LuCi się pojawiło, ale wygląda jak z oryginalnego OpenWrt - jest po angielsku (brak możliwości wyboru polskiego) i bez dodatków od Cezarego jak adblock, czy WoL. Dziwna sprawa, bo przedstawia się jako OpenWrt 21.02-SNAPSHOT r16295-3a051a234a / LuCI openwrt-21.02 branch git-21.295.67054-13df80d. Spróbowałem jeszcze zresetować ustawienia z poziomu LuCI, ale skończyło się to powrotem do stanu wyjściowego - brak LuCI.
Czy ktoś spotkał się z podobną sytuacją? Jak to naprawić?
Od pewnego czasu mój router TP-Link TL-WDR4900 po utracie zasilania pada. Można go w łatwy sposób przywrócić do życia wchodząc w tryb failsafe i wykonując mtd -r erase rootfs_data. Ale na dłuższą metę jest to upierdliwe, np. dziś rano musiałem ratować router, żeby rodzina miała internet.
Czy da się coś z tym trwale zrobić, czy raczej szykować się na zakup nowego routera?
Jestem autorem tego skryptu, ale ostatnio rzadko tu bywam. Jak wszedłem na podanego linka, trochę się zdziwiłem. Po co ja tam pisze o WINS, skoro skrypt działa na tylko na połączenia z WAN-u??? I wtedy sobie przypomniałem. Skrypt, a właściwie conntrack, *widział* połączenia w LAN-ie, ale na starej wersji OpenWrt. W czasach kiedy skrypt powstał, aktualną wersją OpenWrt była chaos calmer. Potem nastąpiła aktualizacja, potem kolejna duża i już conntrack nie widział połączeń w obrębie LAN-u. Szukałem, pytałem mi.in. tu, ale nikt nie był mi w stanie pomóc. Ostatecznie pogodziłem się z częściową utratą funkcjonalności.
Do oglądania TVN musisz odblokować tvn.adocean.pl Jakby jeszcze coś nie działało listę wyjątków możesz wyciągnąć z mojej wersji adblocka http://jazz.tvtom.pl/adblock-w-openwrt-gargoyle/
Mam pytanie odnośnie mojego własnego skryptu z postu powyżej. Skrypt oparty jest na conntrack. Teoretycznie wszystkie połączenia w obrębie LAN-u przechodzą tylko przez switch i router ich nie widzi. Ale ten mój skrypcik, wtedy gdy go napisałem widział lokalne połączenia. Teraz po aktualizacji do najnowszego LEDE już ich nie widzi - czyli teoria zgadza się z praktyką. Przypuszczam,że domyślna konfiguracja LEDE i OpenWrt CC jest nieco inna, skoro conntrack wcześniej widział połączenia w obrębie LAN-u. Krótko rzecz ujmując co trzeba zrobić, żeby conntrack widział połączenia lokalne?
Sprawdź jeszcze http://jazz.tvtom.pl/waking-server-incoming-connection/ Wydaje mi się prostsze.
Czuję, że do problemów z Sambą powrócimy jak się "aktualizacja dla upadłych twórców" Windowsa 10 upowszechni. Do tego czasu zwykli użytkownicy nie będę sobie zdawać sprawy, że jesienią niektóre urządzenia przestaną im ze sobą gadać. Podniesie się lament i może to zmusi developerów do działania. Ja na razie chcąc nie chcąc musiałem wrócić do SMB v1, bo mi siadło domowe centrum rozrywki - na TV mam zainstalowane Kodi, które ma wbudowanego klienta SMB bazującego na Sambie <3.6, która oczywiście nie obsługuję SMB v2.
Jednak wgrałem LEDE i jest postęp. Mam SMB2, ale router nie jest już widoczny w tzw. otoczeniu sieciowym, choć jest dostępny zarówno po IP \\192.168.1.1 jak i po nazwie \\LEDE Wygląda to tak http://jazz.tvtom.pl/download/otoczenie.png Da się coś z tym zrobić?
Moja aktualna konfiguracja Samby:
[global]
netbios name = |NAME|
display charset = |CHARSET|
interfaces = |INTERFACES|
server string = |DESCRIPTION|
unix charset = |CHARSET|
workgroup = |WORKGROUP|
local master = yes
browseable = yes
deadtime = 30
domain master = yes
encrypt passwords = yes
enable core files = no
guest ok = yes
invalid users = root
load printers = no
map to guest = Bad User
min protocol = SMB2
max protocol = SMB2
min receivefile size = 16384
null passwords = yes
passdb backend = smbpasswd
preferred master = yes
security = user
smb passwd file = /etc/samba/smbpasswd
syslog = 2
use sendfile = yes
writeable = yes
bind interfaces only = yes
name resolve order = wins lmhosts hosts bcast
os level = 99
wins support = yes
Wypróbowałem wszystkie możliwe kombinacje parametrów server/client max/min protocol, także te z komentarzy i nic nie udało mi się osiągnąć. Nadal komp nie widzi routera. Upgrade do LEDE też mi niewiele pomoże, bo i w OpenWrt i w LEDE Samba jest strasznie stara - 3.6.25. Za to zasoby Samba z Ubuntu 17.04 są bezproblemowo widziane z Windows 10 i to na domyślnej konfiguracji. Przypuszczam więc, że problemem jest Samba w OpenWrt. Jeśli się mylę i komuś się udało to ogarnąć to dajcie znać.
MS zapowiada wywalenie obsługi SMB v1 z Win10. W związku z czym nasuwa się pytanie, czy Samba w OpenWrt lub LEDE obsługuje protokół SMB v2 lub wyższy? A jeśli tak, to jak włączyć jego obsługę w konfiguracji Samby? Testowo usunąłem obsługę SMB v1 z mojego Win10, no i oczywiście zima - przestał widzieć router.
Hmmm, nie spotkałem się z takim problemem u siebie.
Spróbuj "ip addr flush dev br-lan" ale nie wiem czy pomoże.
Panowie, nie czytacie ze zrozumieniem - w przypadku OpenWrt trzeba użyć komendy:
ip neigh add 192.168.1.254 lladdr ff:ff:ff:ff:ff:ff nud permanent dev br-lan
Nie rób przekierowania na adres IP HTCP, bo ten adres w chwili budzenia nie istnieje - komp jest przecież włączony. Poczytaj tu http://jazz.tvtom.pl/wake-on-lan-z-openwrt-dd-wrt/
Jak masz przekierowane porty to działa i to bardzo... Dlatego właśnie musiałem wprowadzić filtrowanie adresów IP klientów, bo mi się komp co chwilę budził.
eko.one.pl → Posty przez Jazz
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc
