- Android alkalmazások - szoftver kibeszélő topik
- CMF Buds Pro 2 - feltekerheted a hangerőt
- iPhone topik
- Samsung Galaxy Watch7 - kötelező kör
- Megjelent a Poco F7, eurós ára is van már
- Telekom mobilszolgáltatások
- One mobilszolgáltatások
- Vivo X200 Pro - a kétszázát!
- Mobil flották
- Okosóra és okoskiegészítő topik
-
Mobilarena
OpenWrt topic
Új hozzászólás Aktív témák
-
petir
senior tag
válasz
attilav2
#17883
üzenetére
Nekem igazából egy alap konfig kell + LuCi, hogy GUI-n keresztül tudjak állítani dolgokat : portforward, DNS , távoli elérés végett és esetleg egy OpenVPN bár igazából az nem is fontos mert xpenology is megoldja.
Ha ezeket meg tudom oldani pont elég.
Torrrent ,NFS,stb..nekem nem kellenek arra ott az Xpeno
A padavanról való váltás oka is főképp, hogy az OpenWRT frissebb jobban támogatott amennyire én tudom.
Persze javítsatok ki ha nem így van.
-
vargalex
Topikgazda
válasz
attilav2
#17859
üzenetére
Teljesen más architechtúra. Nyers erőben az mt7622 jóval fölötte áll. Érdemes összehasonlítani az azonos kapcsolókkal futtatott benchmark eredményeket. Nem mellesleg az AX3200 természetesen AX-es wifi-t tud. De egyébként nekem is van MT7621: D-Link DIR-860L és Asus RT-AC65P. Nincs velük gondom.
-
stopperos
senior tag
válasz
attilav2
#17830
üzenetére
Ennek törvényileg kell benne lennie
(a flash-en van egy erre elkülönített rész), az openwrt ebből olvassa ki a szabályokat, mint ahogy más gyártó firmware-je is. Használj olyan csatornát ami nem DFS köteles. Az 5 GHz amúgy sem nagyon megy át két falon.Szerk: a flash rész nem minden esetre igaz.
-
vargalex
Topikgazda
válasz
attilav2
#17830
üzenetére
A regdb-t a mainline kernelben található wireless-regdb-ből állítja elő az OpenWrt. Csinálhatsz egy ehhez hasonló patch-et, amiben módosítod a neked megfelelőre. Vagy első körben megpróbálhatsz átállni Dél Afrikára, mivel ott a 100-as csatorna környékén nincs DFS.
De, ha direkt nem akarsz megfelelni a szabályozásoknak, akár bírságra is számíthatsz...
Nem véletlenül van ez kitalálva és ahogy a linkjeimen láthatod, nem is az OpenWrt oldja ezt meg, hanem ahogy írtam, már mainline kernel szinten egyértelműen definiált.
-
attilav2
őstag
válasz
attilav2
#16784
üzenetére
Működik a kerülő megoldás a 21.02.0 DFS hibájára. Szépen átváltott 124-ről az option channels ben felsorolt tartalék csatornák egyikére(44-48) mikor radart észlelt. Most DFS csatornákat soroltam fel a channels részben (100-116), jelenleg a 124-esen van, kíváncsi vagyok hogy a legközelebbi radar észleléskor működni fog e ez a kerülő megoldás DFS tartalék csatornákkal is.
-
attilav2
őstag
válasz
attilav2
#16769
üzenetére
Egy másik (Chieftec) usb-s házzal működik az fstrim OpenWrt és Arch alatt! Érdekes hogy a delock házzal padavan alatt ment az fstrim, viszont Arch és OpenWrt alatt már nem. Lehet hogy azért ment padavan alatt a trim mert 3.x-es kernel van alatta és az jóban van ezzel a delock házzal. Arch és OpenWrt 21.02 alatt viszont 5.x-es kernel van, ezzel lehet trim szempontból inkompatibilis a delock ház
A chieftec ház 3.5"-ös, a delock 2.5"-ös. Szereznem kell a torrentező routeres ssd-nek egy 5.x kernel fstrim kompatibilis 2.5" házat. -
vargalex
Topikgazda
válasz
attilav2
#16775
üzenetére
149-es csatorna fölött valóban nincs DFS, de európában csak 25 mW-al sugározhatsz... És kérdés, hogy a kliensek látják-e ezt a frekvenciát.
De egyébként ezt megmondja neked az iw list parancs is:
...Frequencies:* 5180 MHz [36] (23.0 dBm)* 5200 MHz [40] (23.0 dBm)* 5220 MHz [44] (23.0 dBm)* 5240 MHz [48] (23.0 dBm)* 5260 MHz [52] (20.0 dBm) (radar detection)* 5280 MHz [56] (20.0 dBm) (radar detection)* 5300 MHz [60] (20.0 dBm) (radar detection)* 5320 MHz [64] (20.0 dBm) (radar detection)* 5500 MHz [100] (26.0 dBm) (radar detection)* 5520 MHz [104] (26.0 dBm) (radar detection)* 5540 MHz [108] (26.0 dBm) (radar detection)* 5560 MHz [112] (26.0 dBm) (radar detection)* 5580 MHz [116] (26.0 dBm) (radar detection)* 5600 MHz [120] (26.0 dBm) (radar detection)* 5620 MHz [124] (26.0 dBm) (radar detection)* 5640 MHz [128] (26.0 dBm) (radar detection)* 5660 MHz [132] (26.0 dBm) (radar detection)* 5680 MHz [136] (26.0 dBm) (radar detection)* 5700 MHz [140] (26.0 dBm) (radar detection)* 5720 MHz [144] (13.0 dBm) (radar detection)* 5745 MHz [149] (13.0 dBm)* 5765 MHz [153] (13.0 dBm)* 5785 MHz [157] (13.0 dBm)* 5805 MHz [161] (13.0 dBm)* 5825 MHz [165] (13.0 dBm)* 5845 MHz [169] (13.0 dBm)* 5865 MHz [173] (13.0 dBm)...Vagy részletesebben:
root@RT-AC65P:~# iw phy phy1 channelsBand 2:* 5180 MHz [36]Maximum TX power: 23.0 dBmChannel widths: 20MHz HT40+ VHT80 VHT160* 5200 MHz [40]Maximum TX power: 23.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80 VHT160* 5220 MHz [44]Maximum TX power: 23.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80 VHT160* 5240 MHz [48]Maximum TX power: 23.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80 VHT160* 5260 MHz [52]Maximum TX power: 20.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: available (for 2422549 sec)DFS CAC time: 60000 ms* 5280 MHz [56]Maximum TX power: 20.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: available (for 2422549 sec)DFS CAC time: 60000 ms* 5300 MHz [60]Maximum TX power: 20.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: available (for 2422549 sec)DFS CAC time: 60000 ms* 5320 MHz [64]Maximum TX power: 20.0 dBmRadar detectionChannel widths: 20MHz HT40- VHT80 VHT160DFS state: available (for 2422549 sec)DFS CAC time: 60000 ms* 5500 MHz [100]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5520 MHz [104]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5540 MHz [108]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5560 MHz [112]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5580 MHz [116]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5600 MHz [120]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5620 MHz [124]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5640 MHz [128]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5660 MHz [132]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5680 MHz [136]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5700 MHz [140]Maximum TX power: 26.0 dBmRadar detectionChannel widths: 20MHz HT40- HT40+ VHT80 VHT160DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5720 MHz [144]Maximum TX power: 13.0 dBmRadar detectionChannel widths: 20MHz HT40- VHT80DFS state: usable (for 2422616 sec)DFS CAC time: 60000 ms* 5745 MHz [149]Maximum TX power: 13.0 dBmChannel widths: 20MHz HT40+ VHT80* 5765 MHz [153]Maximum TX power: 13.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80* 5785 MHz [157]Maximum TX power: 13.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80* 5805 MHz [161]Maximum TX power: 13.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80* 5825 MHz [165]Maximum TX power: 13.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80* 5845 MHz [169]Maximum TX power: 13.0 dBmChannel widths: 20MHz HT40- HT40+ VHT80* 5865 MHz [173]Maximum TX power: 13.0 dBmChannel widths: 20MHz HT40- VHT80Szerk.: most olvastam el a HUP témát, látom ott is leírták ezt.
-
vargalex
Topikgazda
válasz
attilav2
#16714
üzenetére
A kinézet egy sima OpenWrt 2020 téma:
Ahogy a neve is sugallja, 2020 óta az összes snapshot build-ben és természetesen a 21.02-es build-ekben is elérhető.
A gyári felület is gyári módszert alkalmaz a firmware frissítésére, semmivel nem biztonságosabb a tftp módszer... Az OpenWrt frissítés pedig saját módszer használ.
-
vargalex
Topikgazda
válasz
attilav2
#16711
üzenetére
Nem is azt írta a kolléga, hogy nem fogod tudni felrakni... Hanem azt, hogy nem fogsz tudni visszaállni régebbi verzióra.
Az OpenWrt-t felesleges ilyen esetben resetelni, hiszen filerendszerben tárolja a config-okat, amit a tftp firmware felrakás úgyis felülír. NVRAM-hoz nem nyúl az OpenWrt, ezért van az, hogy visszaálláskor a korábban gyári firmware alatt beállított konfiguráció marad.
-
válasz
attilav2
#16708
üzenetére
Tessék, itt van az, amit a leírásban linkeltem. Az "us-up_version" név az újabbakban van. Ezekről hivatalos formában már nem lehet visszamenni a 2 verzióval ezelőttiekre. (ha jól emléxem még figyelmeztetés is van a TP-lInk weboldalán....Hinweis: Nach der Aktualisierung dieser Firmware können Sie kein Downgrade auf die vorherige Firmware-Version durchführen.) Amit én megosztottam, az probléma nélkül felment és működik visszatétel után.
-
válasz
attilav2
#16701
üzenetére
Szia!
Ez alapján csináltam, hibátlanul ment.
Ha sűrűn szoktad módosítani a hálózati kártya beállításait, akkor a gyors hálózati konfiguráláshoz a NetSetMan programot ajánlom.
Restore Factory Firmware
(tested for V5)
1) Setup ethernet adapter to use IP 192.168.0.66 mask 255.255.255.0 gateway 192.168.0.1
2) Use tftpd32 (32Bit exactly as stated), in global settings leave only TFTP Server running, verify that it's listening on port 69 in cmd with netstat by typing: netstat -an 3 | find “66:69”
3) Download original firmware. In my case I used Archer C7(EU)_V5_190726.bin. (Én ezt tettem vissza: c7v5_[20201120-rel50406]_2020-11-20_14.00.44.bin)
Rename to ArcherC7v5_tp_recovery.bin and place to folder selected in tftpd32
4) Connect ethernet cable to ethernet port 1 on the router
5) While holding “Reset” button (not the WPS/Wi-Fi!) press “Power” button and wait until data transfer LED lights up (Two arrows pointing different directions).
If everything went right - you will see “Read request for file <ArcherC7v5_tp_recovery.bin>. in tftpd log window. The flash operation took me about 3 to 5 minutes.A végén a router újra fog indulni, akkor van kész. Közben én semmilyen folyamatot nem láttam. Kb 3 percig tartott.
-
vargalex
Topikgazda
válasz
attilav2
#16545
üzenetére
Egyetlen típus egyetlen környezetben való viselkedése alapján a teljes MTK-ra következtetést levonni szerintem elég inkorrekt.
Én MTK SoC-al szerelt routereket használok már 2016 óta. Kezdtem a D-Link DIR-860L-el, majd Asus RT-AC57U-val, aztán 2019 július óta az Asus RT-AC65p-vel. Minden routerre OpenWrt forrásból, master brach-ból fordítottam magamnak firmware-t (kivéve idén áprilistól, mert azóta a 21.02 branch-ból fordítok). A DIR-860L esetén eleinte voltak problémák (inkább csak a wifivel), de később teljesen stabil volt mindig. Soha nem találkoztam egyetlen random reboot-al sem, amit te jellemzőnek írsz MTK-ra...
Már az RT-AC65P-t is a 19.07 megjelenésénél korábban használom (az ugye még nem is került be végül a 19.07-be), de anno sem tapasztaltam semmi rendellenességet. Nálam még a 100-as csatornát is viszonylag stabilan tartotta mindegyik router, ha DFS miatt közbe kellett avatkoznia, akkor is ment tovább másik csatornán.
De az Asus topic-ban egyébként olvashatsz olyan Asus routerekről (nem csak MTK SoC-al szereltről), aminél még gyári firmware-nál is azt tapasztalják, amit te is írsz: egyszerűen eltűnik az 5 GHz-es wifi és ott csak egy áramtalanítás hozta helyre. -
attilav2
őstag
válasz
attilav2
#16457
üzenetére
A 2 napos pppoe uptime is megvan 21-rc1 alatt:
Transmission is jól működik, bár a transmission-web-control csomag elég régi, -ennek annyi a hátránya hogy a tracker infókat nem jelzi, másik klienbsben pl a transmission-remote-gtk ban ez működik- padavanban transmission-remote-control -ból a legújabb van.
Összességében elég stabilnak tűnik az új stabil release előzetes, 19.x -hez képest látok előrelépést, 19.x restartolgatott és dobálta a wan-t AC57U/1200GU-n. Wifi is stabilnak tűnik. Aki kíváncsi annak mindenképp ajánlom az új release előzetes kipróbálását -
krealon
veterán
válasz
attilav2
#16448
üzenetére
"13-as csatornát(ezen vannak felénk a legkevesebben) 40mhz-t és annak kikényszerítését állítottam be"
Gratulalok.
A 2.4GHz kozeli 60 MHz szeles savban (1-13 csatorna, 2.412-2.472 GHz), ugy kenyszeriteni a 40 MHz-es savszelesseget, hogy bevallottan telitett a teljes spektrum, nem kifejezetten atgondolt cselekedetnek tunik. Ebben a felallasban csak az 1-4 csatornan, 20 MHz-en uzemelo eszkozokkel nincs utkozes.A sok adatatviteli hibabol adodo ismetles miatt, a hatasos atvitel biztosan alacsonyabb lesz annal, mintha 20 MHz-es csatorna szelesseget hasznalnal.
-
vargalex
Topikgazda
-
vargalex
Topikgazda
válasz
attilav2
#16439
üzenetére
Persze, az RC véglegesnek szánt configgal fordul, azaz kell legyen benne LuCI.
Egyébként érdekes az a 300 Mbps. Igaz, nálam DHCP net van, de még sw flow offload nélkül is megvan az 500 Mbps. Emlékeim szerint közel gigabitet tud így is...
4.x kernelen MT7621 esetében volt hw flow offload is.
-
ledgeri
nagyúr
válasz
attilav2
#16430
üzenetére
& #16431 vargalex
Elnézést akkor én voltam túlbuzgó (talán).Gondolom minden eszközt vissza kell igazolgatni, hogy "Igen, ezzel is, továbbra is jó", akkortól kaphatja meg a megfelelő mező az új verziót.
Abból indultam ki, hogy ha a főoldalon kint van akkor már főbb/kiforrottabb verzió.... Mit takar az rc1?
-
vargalex
Topikgazda
válasz
attilav2
#16430
üzenetére
Talán azért, mert ahogy a nevéből láthatod, a 21.02 még csak rc1, oda a stabil verziókat szokás írni. Valamint a wiki oldalakat a felhasználók szerkesztik, nem a fejlesztők.
Egyébként a 21.02.0-rc1 már a bejelentés előtt 5-6 nappal (platformtól függően) elérhető volt...
-
-
vargalex
Topikgazda
válasz
attilav2
#16410
üzenetére
Azért ne felejtsük el, hogy az 1200GU-ban egy 2 magos, 4 szálas SoC van, HW NAT támogatással. Ne hasonlítsunk ahhoz egy 1043ND v1-et. Gondolom egyébként PPPoE WAN kapcsolattal mérted, mert a kolléga DHCP-n 500 Mbps-t mért.
Egyébként a TFTP valószínűleg azért nem ment, mert a TL-WR1043ND v1 esetében egy későbbi gyári firmware-ba fordítottak TFTP szervert, a kezdetiekben nem volt. Gyaníthatóan a nálad lévőn TFTP nélküli bootloader volt.
-
attilav2
őstag
válasz
attilav2
#16409
üzenetére
Nos, gyorsan leteszteltem ezt a Gwlim fw-t, rájöttem hogy nem kell ehhez áramtalanítani az 1200GU-t
, az 1043nd v1.10 sebessége gwlim fw-rel ~300mbps körül van miközben az 1200GU padavannal ~900mbps. Hát ez a Gwlim féle Owrt fw sem hozza el a megváltást -
vargalex
Topikgazda
válasz
attilav2
#15874
üzenetére
Megnéztem, legutóbb áthelyezés miatt volt 15 napja újraindítva a router, de semmi kernel hiba nincs.
Hardware hibás wifi chip-ről egyébként én éppen Qualcomm esetén beszélgettem OpenWrt fejlesztőkkel... Szóval, sajnos ez bárhol megesik, így software-ból kell kezdeni vele valamit.
Most jutott eszmbe, hogy éppen használatban van a DIR-860L is. Igaz, csak switch-ként, de 31 napja megy, nyoma nincs kernel hibának.
-
vargalex
Topikgazda
válasz
attilav2
#15870
üzenetére
Azt tudom mondani, hogy az Asus RT-AC65P-ben is ez a SoC van, már több, mint egy éve megy teljesen stabilan OpenWrt-vel. Előtte volt RT-AC57U-m rövid ideig, ott sem volt gondom. Azelőtt pedig legalább 1 évig D-Link DIR-860L. Ott eleinte a 2,4 GHz-en voltak problémák, később már az is jó volt. Dchard-nak, ha jól tudom, csak DIR-860L-el van tapasztalata. Viszont a különböző tipusok különböző revíziójú SoC-al szereltek, akár külső wifi chip-et használva, így lehetnek eltérések.
Ahogy írtam, nálam az RT-AC65P stabil, nem indul újra és nem is kell újraindítani. Kernel hibák sincsenek.
-
korcsi
veterán
válasz
attilav2
#15870
üzenetére
Xiaomi 3G-be ez a SOC van azt használtam OpenWrt-+vel, ott a 2,4GHz volt problémás.
A Mikrotik Hex-ben ez van, azzal nincs baj.
Most egy említett eszköz megy nálam (csak AP módba), a kernel log "üres" 4 napos uptime-al.#15869 dynax: Az openwrt fórumon és a githubon van leírás, illetve youtube-on is vannak jó videók, egyszer kétszer végig kell rajta menni, hogy megértse az ember mikor mi történik, ha minden feltétel adott pár perc alatt fel lehet rakni az openwrt-t. A linkelt openwrt fórumon scp07 linkelte a saját nem nightly-t az eszközre
-
-
wigyori
tag
válasz
attilav2
#15786
üzenetére
Akkor csereld majd le
Arra figyelj, hogy a wpad-basic csomagot le kell rugni - ha csak elkezded felrakni a wpad-openssl-t, ossze fognak akadni. Illetve persze mielott nekiugranal, nezd meg h mekkora a flash a routeredben, legalabb 8Mb flash fog kelleni ahhoz h felferjen.-w-
-
wigyori
tag
válasz
attilav2
#15784
üzenetére
Nekem ezek vannak fent egy 19.07.4-en WPA3-hoz, ami relevans:
root@q-base-pop:~# opkg list_installed |egrep "hostapd|wpa|ssl"
hostapd-common - 2019-08-08-ca8c2bd2-4
libopenssl1.1 - 1.1.1h-1
libustream-openssl20150806 - 2020-03-13-40b563b1-1
wpad-openssl - 2019-08-08-ca8c2bd2-4(a wpad-basic le van rugva)
Illetve fontos megjegyezni, hogy az a kartya amit hasznalok ebben, nem egy mai csirke:
[ 15.976120] ieee80211 phy0: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0 mem=0xb0000000, irq=40
Azt, hogy mi kell ahhoz, hogy a "luci-ban megjelenjen a wpa3", konzolhuszarkent nem tudom, de gondolom hostapd capabilityk alapjan listazza az elerheto opciokat. (itt most jonne egy kep egy luci screenshottal, de valamiert nem huzza be.)
A DSA-s tokoreszest nem kommentalom, jobb ugy mindenkinek.
-w-
-
wigyori
tag
válasz
attilav2
#15779
üzenetére
Ize, nekem mind az ajfonom, mind a regi droid4g-m tudott csatlakozni a wpa2/3-as halozatra, ami "sae-mixed"-kent van fellove. Ha hostapd_cli-vel belenezel a client status-okba, akkor ha ottvan a "sae_group" parameter, akkor wpa3-mal csatlakozott a kliensed.
A trukk amugy az, hogy a hostapd-openssl-t kell felrakni, az alap mbedtls/wolftls-es buildek valoban nem mukodnek wpa3-mal trunkban (legalabbis a ket honappal ezelotti buildemben me'g el voltak.)
-w-
-
vargalex
Topikgazda
válasz
attilav2
#15765
üzenetére
Nem zavart, hogy van több routerem, mert így is több van, mint kellene. Csak MT7621-ből van már elég (1 db D-Link DIR-860L, 2 db Asus RT-AC65P). Ezen kívül azért van még néhány itthon: TP-Link TL-WR741ND, TP-Link TL-WR1043ND v1 és v2, TP-Link TL-WDR3600, TP-Link TL-WDR4300, D-Link DIR-825 B2, TP-Link TL-WDR4900, Linksys WRT3200ACM, Mikrotik hAP ac². Szóval, túl sok...
Stabil custom firmware-t nem sokból tart készíteni, hiszen csak az eszköz dts-ét, image makefile-ját kell hozzáadni és néhány default scriptet kiegészíteni. Viszont a kernel checksum más lesz, mint az OpenWrt oldalon, így kernel csomag telepítése force nélkül nem fog menni (hacsak a build előtt nem módosítjuk kézzel a checksum-ot). -
korcsi
veterán
válasz
attilav2
#15765
üzenetére
Igen pontosan azt raktam rá amit linkeltél, a rendelkezésre álló információk szerint ezen lehetőségek közül ezen az eszközön melyik áll fent?
1. switch less? (nem hiszem)
2. switch dedikált wan port-al?
3. switch vlan-os megoldással (erős a gyanúm, hogy ő a jó megoldás)Mindegy, próbálkozok, ha gebasz van, failsafe...
Majd írok mire jutottam.
-
attilav2
őstag
válasz
attilav2
#15755
üzenetére
Újabb próbát tettem a Wrt-vel, ezúttal az 1200GU-n. A gyári fw-t reseteltem, majd tftp-vel feltoltam a 19.07.4-et. Most stabilnak tűnik a PPPoE kapcsolat, 22 órája él a session. Sebességeket mértem: Nat gyorsítás nélkül ~500mbit, sw offloaddal ~700mbit, hw offloaddal ~800mbit-et értem el, ez utóbbira háromszor rámértem és rendre hozta a ~800mbit-et. Végre a chrome-val is beenged a luci, 19.07.3-nál nem lehetett chrome-ból belépni. Nem tudom 57U-nál miért szakadozott 19.07.4-nél a PPPoE, talán egy reset rendbehozta volna, de akkor nem akartam a Wrt újra konfigolással bíbelődni így csuklóból ment fel rá a padavan ami persze tartotta a kapcsolatot stabilan. Szűk egy hónapig használtam az 57U-t padavannal, aztán nem bírtam magammal, illetve a kíváncsiságommal, és előkaptam az akkor még cfw szűz 1200GU-t, ment rá a Wrt és láss csodát most egyelőre gond nélkül működik
Szóval a 19.07.3 -> 19.07.4 váltásnál lehet hogy elkél a reset ha netán szakadozna a PPPoE.
A hw nat Wrt alat nem valami hatékony, legalábbis ezt a következtetést vontam le a sebesség tesztemből, hiszen sw offloaddal megvan a ~700mbit, a hw offload csak ~100mbittel többet tudott rádobni erre, gyári és padavan alatt simán megy a ~900mbit. A következtetésem az, hogy _szerintem_ az 57U/1200GU-val azonos architektúrájú (MIPS) qualcomm SoC-os routereken is meg kell legyen a ~700mbit sw offloaddal, kinek mi a tapasztalata ezügyben? -
vargalex
Topikgazda
válasz
attilav2
#15735
üzenetére
Ahogy a kolléga írta, vannak ilyen eszközök. Nem feltétlenül kell egészen WRT3200-as árig elmenni hozzá...
Viszont gigás net van Telekomnál úgy is, hogy nem engedélyezik a bridge módot (IPTV esetén, ha jól tudom), akkor nyilván a saját routered már DHCP-n kér IP-t...Anno én DIR-860L esetén mértem PPPoE-n is (egy notebook volt a PPPoE szerver), kb. 900 Mbps át is ment rajta. Igaz, az jóval régebbi kernelen volt. (Viszont azonos SoC az RT-AC57u-val.)
-
fatal`
titán
válasz
attilav2
#15735
üzenetére
Van néhány router, amivel simán eléri így is. Pl. Linksys WRT3200ACM. Illetve talán valamelyik Qualcomm chippel szerelt routereknek sem jelent problémát.
Persze ha QoS vagy SQM is kell mellé akkor már más a helyzet (bár ha jól rémlik akkor a linksysen a software flow offloaddal még SQM-mel is bírja).
-
vargalex
Topikgazda
válasz
attilav2
#15733
üzenetére
Azért azt tudni kell, hogy gyári firmware, illetve Padavan esetén gyári MTK kernel modulok használatával van HW NAT, OpenWrt alatt open source. Illetve OpenWrt alatt szerintem soha nem lesz teljes értékű HW NAT, hiszen akkor a netfilter rengeteg szolgáltatását buknák.
Egyébként DHCP-n (nem PPPoE neten) tudja a gigabitet, de a PPPoE plusz tehet a Soc-nak. -
Headless
őstag
válasz
attilav2
#15626
üzenetére
köszi ránézek, mivel most jövőhétig kell valószínű inkáb helyi eszközt szeretnék, még van tartalékba egy mir3g-m lehet az lesz és aztán upgradelek valamikor vagy itthon, vagy ott.. Am snapshottól nem félek, báűr valószínű, akkor inkább buildelek egy sajátot, amibe benne van minden ami kell.
wireguard teljesítményre mondjuk azért kíváncsi lennék, mert most nem raknék össze emiatt egy külön eszközt. régen nekem a mir3G openwrt-vel hozta a 7-8 mbyte/s-et ha kicsivel tudna többet nem lenne rossz.
-
attilav2
őstag
válasz
attilav2
#15588
üzenetére
Megvan az OpenWrt kísérletezésem első áldozata, a régi wrt160nl -em. Azthittem túlélte a 15.05.1-ről 19.07.3-ra frissítést, a frissítés után még bebootolt, alap dolgokat állítottam csak be, jelszavat és ssh elérést, semmi mást, majd elraktam, ma próbálnám ki és nem érzékeli a lan portra dugott kábelt, nem jön létre a link
A wan portot érzékeli, ha bedugom a kábelt világít. Na készülhetek életem első debrick-jére. Még jó hogy vettem egy 1200GU-t tarteléknak, mert az AC57U-n az Owrt-vel időnként kísérletezek, guest wlan-t állítottam be, második nekifutásra sikerült a leírás szerint megcsinálni úgy hogy ne k*rjam szét a tűzfalszabályokat, a 2. próbálkozás előtt nyomtam egy hard resetet - umount /overlay && jffs2reset && reboot now - hagytam dolgozni amíg a power led villogott, és amikor már világított folyamatosan, akkor kezdtem neki a konfigurálásnak tiszta lappal
Dchard szerint fejlődő pályára állhat az Owrt az 5-ös kernelre és a DSA architektúrára való átállással. -
vargalex
Topikgazda
válasz
attilav2
#15580
üzenetére
Privátban válaszoltam, de azt gondoltam, hogy más routerrel (vagy inkább gyári és Padavan firmware-val, mert nagyjából úgy fogalmaztad meg) ment 40 MHz-en a 2,4 GHz-es wifi.
Egyébként igen, a legtöbb Qualcomm SoC-al szerelt mobil default-ban 2,4 GHz-en csak 20 MHz-es csatornaszélességet tud, mivel a Qualcomm driverben gyárilag nem engedélyezett a channel bonding 2,4 GHz-en. Xiaomi telefonok esetén root után módosítható, vagy pl. xiaomi.eu romot kell feltenni. -
attilav2
őstag
válasz
attilav2
#15579
üzenetére
Úgy néz ki rootolni kell a Xiaomi-kat hogy 2.4g-en 40mhz-en csatlakozzanak:
Link
Én nem fogok belerondítani, meg garivesztéssel is jár. Valószínűleg a samsung tabletet is csak így -rootolva átírva valami configot- lehetne rávenni a 40mhz-re, anyám használja, így abba sem rondítok bele. Akkor ez van, 5ghz-es Ac-s készülékekre kell majd cserélni a 2.4g only készülékeket.
Szerencsére az LG webos tv és a 2db Mi Box S tudják az 5ghz-et, így videó streamelési problémáink nem lesznek. Max telókon tableten lehet gond. -
attilav2
őstag
válasz
attilav2
#15578
üzenetére
vargalex:
Nem említettem de egy Himedia Q30 lejátszó(android 7) is csatlakozik időnként 2.4-es wifi-n (általában kábelen használom) most kipróbáltam és 40mhz-en csatlakozik
Valamint van egy Redmi 1S is(android 7.1), de az is csak 20mhz-en tud csatlakozni mint a redmi 8 és a samsung tablet.
Himedia Q30 csatlakozási adatai Luci-ból screenshotolva, valamint az újabb iw dev parancs kimenetét is elküldtem privátban - ezek szerintem szenzitív adatokat tartalmaznak, ezért nem merem nyilvánosan megosztani - -
vargalex
Topikgazda
válasz
attilav2
#15562
üzenetére
Szia!
A HW NAT megjelenéséhez a Software flow offloading-ot is be kell kapcsolni... De már maga a software-os is sokat segít.
A tftp recovery (amit a restoration tool is használ) továbbra is elérhető, hiszen az OpenWrt nem módosítja a bootloader partíciót. Visszaálláskor resetelni semmit nem kell, mert az OpenWrt a beállításokat filerendszeren tárolja, nem az NVRAM-ban.
-
vargalex
Topikgazda
-
vargalex
Topikgazda
válasz
attilav2
#8157
üzenetére
Ezek szerint nem a router a DNS szervered. Véletlenül nem egy másik router mögött használod switch módban? Vagy nincs megadva a klienseknek másik (pl. a google) DNS szerver? Ugyanis utóbbi esetben a dnsmasq birizgálása nem segít, de előbbi esetben a tűzfal config sem.
-
Headless
őstag
válasz
attilav2
#8153
üzenetére
Mivel a wdtvlive.com átirányít egy oldalra a wdc.com-ra elég gyanús, hogy az csak egy minimális index.html amit becachelt a böngésződ, vagyis folyton átirányít a wdc.com-ra az meg betölt, mert nem az van letiltva.
Probáld meg inkognító módban megnézni, vagy másik böngészővel,, vagy cache ürítéssel..
-
Headless
őstag
válasz
attilav2
#8143
üzenetére
WINSCP nem megoldás? vagy esetleg webcommander, mentésként felrakod a basic*.tar.gz-t?
ám a /etc/config/firewall fájlba kell berakni.erre lenne jó az "-m match string" kapcsoló iptablesben de most nem akarja elfogadni.(bénázok valamit)
A chieftec ház 3.5"-ös, a delock 2.5"-ös. Szereznem kell a torrentező routeres ssd-nek egy 5.x kernel fstrim kompatibilis 2.5" házat.
, az 1043nd v1.10 sebessége gwlim fw-rel ~300mbps körül van 
Én nem fogok belerondítani, meg garivesztéssel is jár. Valószínűleg a samsung tabletet is csak így -rootolva átírva valami configot- lehetne rávenni a 40mhz-re, anyám használja, így abba sem rondítok bele. Akkor ez van, 5ghz-es Ac-s készülékekre kell majd cserélni a 2.4g only készülékeket.
Valamint van egy Redmi 1S is(android 7.1), de az is csak 20mhz-en tud csatlakozni mint a redmi 8 és a samsung tablet.
Új hozzászólás Aktív témák
Hirdetés
vargalex- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Revolut
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Vezetékes FEJhallgatók
- 3D nyomtatás
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Hálózati / IP kamera
- A Micron újszerű módszerrel javítja QLC-s SSD-jének sebességét
- Otthoni időjárás-állomás
- További aktív témák...
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Assassin's Creed Shadows Collector's Edition PC
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- Csere-Beszámítás! RTX Számítógép PC Játékra! I3 10100F / RTX 2060 12GB / 32GB DDR4 / 500GB SSD
- DELL PowerEdge R730xd 12LFF+2SFF rack szerver - 2xE5-2680v3,64GB RAM,4x1GbE,H730 RAID v ZFS
- HP Omen - 27" IPS - UHD 4K - 144Hz 1ms - NVIDIA G-Sync - FreeSync - HDR 400 - USB-C - KVM Switch
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged