Odp: Zmiany w wydaniu OpenWrt 21.02
U mnie są pustki. Nie mam sąsiadów blisko. Miałem przez kilka dni ustawione na normal mode i mi jakoś wifi dziwnie chodziło. Teraz mam wyłączone i jest ok.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Zmiany w wydaniu OpenWrt 21.02
Strony Poprzednia 1 … 8 9 10 11 12 … 22 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
U mnie są pustki. Nie mam sąsiadów blisko. Miałem przez kilka dni ustawione na normal mode i mi jakoś wifi dziwnie chodziło. Teraz mam wyłączone i jest ok.
Kilka postów wyżej pisałem o tym - czekam jak prowadzą obsługę vlanów w luci. Nie, aż tak dużo się nie zmieniło.
A nie zostało to właśnie dodane razem z https://github.com/openwrt/luci/pull/4307
?
Inne pytanie. Czy używa ktoś na 21.02 luci-app-statistics? Mam problem bo zainstalowałem ale żadne dane przez collectd nie trafiają do influxdb
Na 19.07 działało bez problemów.
Cezary napisał/a:Kilka postów wyżej pisałem o tym - czekam jak prowadzą obsługę vlanów w luci. Nie, aż tak dużo się nie zmieniło.
A nie zostało to właśnie dodane razem z https://github.com/openwrt/luci/pull/4307
?
A sprawdziłeś to chociaż sam? Nie, nie zostało dodane, jest nadal tylko w wersji rozwojowej, do 21.02 tego jeszcze nie przenieśli.
paradix napisał/a:A nie zostało to właśnie dodane razem z https://github.com/openwrt/luci/pull/4307
?
A sprawdziłeś to chociaż sam? Nie, nie zostało dodane, jest nadal tylko w wersji rozwojowej, do 21.02 tego jeszcze nie przenieśli.
Spokojnie to było tylko pytanie.
Sam szukałem rozwiązania dla vlan w luci w 21.02 i trafiłem na ten PR a potem na Twój post.
Jak zawsze cierpliwie czekam na nowe wersje twoich kompilacji. Dzięki za twoja pracę i pozdrawiam
U mnie już siedzi. Zaczynam testowanie: C2600.
Fajna ta "tablica"
i jak przemyślenia? działa sensownie? zachowałeś ustawienia czy upgrade był bez zachowania ustawień?
Ciekawe czy też co 14dni będzie samoistny restart
w 19.07 zadziałało u mnie obejście na gazomierzu:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
Witam,
Posiadam router NETGEAR R6350. Wgrałem openwrt 21.02 (Build time: 2021-03-02 19:25 CET) i mam problem z wifi 5Ghz. Maksymalna moc nadawania to 6 dBm. Czytałem, że w wersji 19.07 miała być latka, ale niestety jest tak samo jak w 21.02.
Czy ktoś jest mi w stanie jakoś pomóc??
root@OpenWrt:~# iw list
Wiphy phy1
wiphy index: 1
max # scan SSIDs: 4
max scan IEs length: 2304 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0xf RX 0xf
Configured Antennas: TX 0xf RX 0xf
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 2:
Capabilities: 0x1ff
RX LDPC
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-31
VHT Capabilities (0x338001f8):
Max MPDU length: 3895
Supported Channel Width: 160 MHz, 80+80 MHz
RX LDPC
short GI (80 MHz)
short GI (160/80+80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Frequencies:
* 5180 MHz [36] (6.0 dBm)
* 5200 MHz [40] (6.0 dBm)
* 5220 MHz [44] (6.0 dBm)
* 5240 MHz [48] (6.0 dBm)
* 5260 MHz [52] (6.0 dBm) (radar detection)
* 5280 MHz [56] (6.0 dBm) (radar detection)
* 5300 MHz [60] (6.0 dBm) (radar detection)
* 5320 MHz [64] (6.0 dBm) (radar detection)
* 5500 MHz [100] (6.0 dBm) (radar detection)
* 5520 MHz [104] (6.0 dBm) (radar detection)
* 5540 MHz [108] (6.0 dBm) (radar detection)
* 5560 MHz [112] (6.0 dBm) (radar detection)
* 5580 MHz [116] (6.0 dBm) (radar detection)
* 5600 MHz [120] (6.0 dBm) (radar detection)
* 5620 MHz [124] (6.0 dBm) (radar detection)
* 5640 MHz [128] (6.0 dBm) (radar detection)
* 5660 MHz [132] (6.0 dBm) (radar detection)
* 5680 MHz [136] (6.0 dBm) (radar detection)
* 5700 MHz [140] (6.0 dBm) (radar detection)
* 5720 MHz [144] (6.0 dBm) (radar detection)
* 5745 MHz [149] (6.0 dBm)
* 5765 MHz [153] (6.0 dBm)
* 5785 MHz [157] (6.0 dBm)
* 5805 MHz [161] (6.0 dBm)
* 5825 MHz [165] (6.0 dBm)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-G O } <= 16,
total <= 16, #channels <= 1, STA/AP BI must match, radar dete ct widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: 0
max scan plan iterations: 0
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 con trol port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 1:
Capabilities: 0x1fe
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-G O } <= 4,
total <= 4, #channels <= 1, STA/AP BI must match
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
* [ RRM ]: RRM
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IE s in scans
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 con trol port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
Niedawno była w 21.02 kolejna duża aktualizacja sterownika mt76, więc poczekaj na następną aktualizację.
Ew wgraj wersje rozwojową i zobacz jak będzie, jeżeli nadal będzie tyle to zgłoś to na bugs.openwrt.org
Tutaj: https://forum.openwrt.org/t/netgear-r68 … z/90984/18 pisali o podobnym problemie w R6850 i nawet zamieścili builda, który ponoć zadziałał.
Wg opisu to dts musi być zmieniony i ma pobrać dane do radia 5GHz z innego miejsca niż jest teraz w dts.
Właśnie sprawdziłem w R6350 – na czarkowym 19.07 w 5 GHz wszystko jest w porządku z TX (coś ponad 20 dBm – nie pamiętam dokładnie, bo już odłączyłem sprzęt). Szerokość 160 MHz też jest dostępna (chyba do kanału 136 włącznie bez kombinowania z regionami). 21.02 jeszcze nie instalowałem.
Za to w Archerze C2 V1 w 5 GHz było tylko 11 dBm – zarówno w 19.07, jak i w 21.02.
W w/w wątku jest informacja że może to być spowodowane bad blokami w nandzie (zresztą identyczna sytuacja była dla R6220), które powoduję ze "przesuwa" się offset danych kalibracyjnych. I w zależności od tego czy masz bad bloki czy nie to masz dane w tym lub w innym miejscu i trzeba sięgnąć kodem w inne miejsce.
Powoli zaczyna się to chyba robić standardem w NAND-ach.
A jak sprawdzić czy się ma bad blocki? W logach bedzie pisać dosłownie error bad block coś tam.?
0.721676] mt7621-nand 1e003000.nand: Using programmed access timing: 31c07388
[ 0.736506] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[ 0.749167] nand: Macronix MX30LF1G18AC
[ 0.756811] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.771893] mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
[ 0.784938] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
[ 0.799503] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
[ 0.814066] Scanning device for bad blocks
[ 2.121212] 6 fixed-partitions partitions found on MTD device mt7621-nand
[ 2.134734] Creating 6 MTD partitions on "mt7621-nand":
[ 2.145153] 0x000000000000-0x000000100000 : "u-boot"
[ 2.156398] 0x000000100000-0x000000200000 : "SC PID"
[ 2.167632] 0x000000200000-0x000000600000 : "kernel"
[ 2.178896] 0x000000600000-0x000002200000 : "ubi"
[ 2.189859] 0x000002e00000-0x000002f00000 : "factory"
[ 2.201348] 0x000004200000-0x000007e00000 : "reserved"
Chyba nie mam errorów.
Wypisał by w logu jak by były
Scanning device for bad blocks
Czy to oznacza, że skanuje bloki i nic nie znajduje?
Tak.
No i sorry, ogłosili -rc1 bez wprowadzania obsługi vlanów do luci. Ehh, co zrobić. Na weekend będą nowe buildy.
Jaki tam kernel będzie. 5.4.113?
5.4.111 jeżeli nie ruszą repo.
Czy ma kroś możliwość wrzucenia samych paczek lub czy jest ktoś w stanie powiedzieć gdzie w obrazie sysupgrade mogę to znaleźć?
ksmbd-server_3.3.4-1_arm_cortex-a7_neon-vfpv4.ipk
ksmbd-utils_3.3.4-1_arm_cortex-a7_neon-vfpv4.ipk
Poleciałem z aktualizacją i okazało się, że moduły do kernela są starsze i serwer już nie działa.
U mnie są: https://dl.eko.one.pl/openwrt-21.02/pac … /packages/
A tak w ogóle to zrób zaraz aktualizację systemu bo ta wersja 3.3.4 mała znaczące błędy.
Dzięki. Będę wypatrywał aktualizacji.
PS,
Nie wiem czy celowo nie chciałeś, ale gdyby była indeksacja domeny dl.eko.one.pl włączona to bym znalazł
Nie chciałem. Bo mam całą masę później strzałów z jakiś crawlerów które patrzą czy pliki nadal są.
Strony Poprzednia 1 … 8 9 10 11 12 … 22 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Zmiany w wydaniu OpenWrt 21.02
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc