-
Fototrend
Specifikációjához képest meglepően olcsó router, ami AC1200-as Wifi-t és gyári firmware-val is több hasznos szolgáltatást ígér (fájlmegosztás, dlna, nyomtató megosztás, stb.)
Új hozzászólás Aktív témák
-
#2143
dchard
veterán
Kisbatyu75
#2141
válasz
Kisbatyu75
#2141
üzenetére
Vargalex megelőzött.
-
#2140
dchard
veterán
Kisbatyu75
#2139
válasz
Kisbatyu75
#2139
üzenetére
Openwrt-n próbáld a legrissebb master-t, nekem azzal frankó. Master alatt nincs gui, azt az installálás után SSH-n kell megoldani: opkg update, és opkg install luci parancsokkal. Arra figyelj, hogy ha tiszta upgrade-et csinálsz (elfelejti a router az összes beállítást), akkor az install után kézzel SSH-n kell beállítanod a PPPoE-t, mielőtt a luci-t telepíteni tudod.
-
válasz
xabolcs
#2136
üzenetére
Nincs mit mesélni róla. A DSA átállás miatt a 4.14-en bevezetett HW offload-nak annyi, egyelőre SW flow offload van 5.4-en. Ezzel PPPoE mellett 7-800megabitet lehet elérni dróton. De legalább a switch driverből eltűntek a számomra érzékelhető bug-ok, nincsenek napok/hetek után felbukkanó hibák a kernel logban. Nekem a wifi-vel semmi gondom nincs Trunk-on, se 2.4-en, se 5GHz-en.
Mivel a DSA a jelenlegi és a jövőbeni fejesztési irány, és rengeteg ilyen MTK cuccot adtak el, így jók az esélyek a HW offload újra kifejlesztésére, de az látszik, hogy ez nem egy gyors folyamat.
-
Csak megjegyzésként írom be, hogy úgy tűnik: a hamar visszakapott HW offload az 5.4-es kernel alatt egyenlőre álomnak bizonyult. Az alap probléma az, hogy NDB által használt fejlesztői branch-ek nem nyilvánosak, így megjósolni is nehéz, hogy egyáltalán zajlik-e a munka, és ha igen akkor az hol tarthat...
-
válasz
xabolcs
#2105
üzenetére
Bootloader source egyáltalán nincs benne, pedig custom U-boot van az eszközön. Egyébként bátran beírom a gyártót: Huawei. Meg azt is, hogy mekkora ívben érdemes elkerülni... A büdös szemetek úgy játsszák ki a GPL licencet, hogy minden (ezer éves) V2-es licencelt SW, majd pedig az egyébként szabvány linux image-et "aláírják", amihez természetesen nem adnak kulcsot senkinek. TTL soros-t letiltják bootloader-ben. Az egyetlen lehetőség a konfig fájl hekkelés, amivel a telnetd elindítható, majd onnan az 5 karaketeres root jelszó megtörése után simán be lehet lépni, és engedélyezni lehet a telnetet meg a TTl-t is (SShd nincs benne természetesen). Soha az életben nem veszünk tőlük többet semmit, mondanom nem kell...
-
válasz
vargalex
#2085
üzenetére
Jól mondod, de nincs átnyúlás: az OFDM elég jól vág a sávhatáron. Mi több: az OBW mindig kisebb mint a csatorna sávszélesség:
Ez a 860L B1 által kiadott 100-as csatorna teljes terhelésen, spektrum analizátorral
Szépen látszik a DC offset középen.De hogy visszatérjek a témához: nálam évek ota 100-as csatornán megy a 860L, és még sosem váltott csatornát.
-
válasz
xabolcs
#2082
üzenetére
Nálam ma érdekes jelenség történt 5GHz-en:
Kernel log:
[386286.289285] device wlan0 left promiscuous mode[386286.298528] br-lan: port 5(wlan0) entered disabled state[386286.390128] br-lan: port 5(wlan0) entered blocking state[386286.400999] br-lan: port 5(wlan0) entered disabled state[386286.412183] device wlan0 entered promiscuous mode[386348.042589] br-lan: port 5(wlan0) entered blocking state[386348.053386] br-lan: port 5(wlan0) entered forwarding stat
És ez fogadott a syslog-ban:daemon.notice hostapd: wlan0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0Namost ezzel csak egy probléma van: hogy ezen a sávon nincs budapesti radar (hacsak éppen ma be nem kapcsoltak egyet), és az a kettő ami van, azt is kitakarja egy komplett hegy.
Tehát ez fals detektálás, még sosem láttam ilyet mt76-on...
-
Mai napon látott napvilágot néhány hír, miszerint mégsincs olyan messze a HWNAT az új 5.4-es kerneltől, mint ahogy elsőre tűnt
-
válasz
xabolcs
#2077
üzenetére
Sajnos nincs ismert mód a hiba előfordulásának a felgyorsítására. Nálam a leghosszabb idő 14 nap volt, ami után előjött. Van kifejezetten két olyan patch, ami mostmár a masterben van, amiknél legalább a vélt magyarázat logikusnak tűnik, és az ok mögött nincs foraglom függés. Egyébként 5.4-en még senkinél nem jött elő a korábbi ismert probléma, tehát bizakodó vagyok
MOD: úgy tűnik fordítási hiba miatt nem frissülnek a snapshot build-ek az openwrt oldalán, aki nem akar forgatni, attól kis türelmet kérnek a fejlesztők.
-
válasz
xabolcs
#2075
üzenetére
Nemtom mi a fene lehet, korábban legfeljebb 24 óránként volt build, de volt hogy napi kettő is. Én nem vártam ki, hanem forgattam magamnak egy sajátot már a master merge után. Faszán működik, de fontos megjegyezni, hogy legalább 14-15 napnyi uptime kell ahhoz, hogy a korábbi ismert hibákról kiderüljön, hogy valóban megoldották őket.
-
Örömmel jelentem, hogy az 5.4-es kernelre történő átállással kapcsolatos PR 3 órája bekerült az openwrt master-be. Néhány óra múlva - a következő napi snapshot-ban - már tesztelhető is a dolog. Így mostmár az is tud fájdalommentesen tesztelni, aki nem akar saját verzió fordításával bíbelődni. Ismét hangsúlyozom, hogy a sysupgrade-et (meglévő beállítások menétse) NE használja senki, mivel a switch architektúra jelentősen változik!
-
A probléma csak látszólag van a D-Link-kel (vagy a gyártókkal úgy általában). Ezek a cégek komplett SDK-t kapnak készen a Mediatek-től vagy a Qualcomm-tól, és utána már csak apró customizálásokat hajtanak végre a szoftveren, annak alapját valójában nem ők készítik, nincs is különösebb ráhatásuk.
Az alap probléma itt az, hogy maguk a chipset vendorok eleve nem frissítik a saját SDK-jukat, és a látottak alapján ki merem jelenteni: olyan trágya munkával hekkelik bele a - valami jellemzően ezer éves - kernelbe a szir-szar drivereiket, hogy azt akkor sem mergelné senki a linux kernelbe, ha erre hajlandóak lennének, de jellemzően ezerrel megy a titkolózás. A QCA sokat javult az elmúlt években (na nem hibátlan). A Mediatek támogatás viszont alapvetően nem a gyártó, hanem a megszállott fejlesztők elképesztő munkája, illetve némi szivárogtatás árán javult az elmúlt időszakban. 2019 szeptemberében kaptam "friss" Mediatek SDK-t pont mt7621 platformhoz az egyik gyártó partnerünktől, és egy pontosan 8 éves 2.6-os kernel köré épült... Elképesztő. És csodálkozunk, hogy ezekhez a tákolt szarokhoz nem érkezik támogatás... Szóval itt a chipset vendorokra kéne nyomást helyezni, de eszköz nem nagyon van senki kezében ehhez... A QCA ezt a szegmenst láthatóan nem akarja lefedni (budget 2 magos rendszer AC-s wifivel), így nincs verseny sem. Szóval amellett hogy egyetértek veled, ezt tartom alapvető problémának.
-
#2068
dchard
veterán
Kisbatyu75
#2067
válasz
Kisbatyu75
#2067
üzenetére
Nem, ez még nincs mergelve. Neked kell forgatni saját verziót master alapján és alkalmazva a fent linkelt PR-t. Fontos tudni, hogy a sysupgrade nem fog működni, mivel a switch rész teljesen megváltozik. Frissítés előtt mentett konfigok sem fognak működni. Tehát ha valaki ki akarja próbálni, a frissítésnél NE válassza ki a beállítások megtartása kapcsolót.
-
válasz
hudyfiu
#2065
üzenetére
Teljesen jó a Wifi (860L-en legalább is). 55/55Mbit 2.5gigán, SISO 20MHz-ben. 280/270Mbit AC-n SISO 80MHz-ben.
Amire te gondolsz, az újabb wifi chipsetekkel van (7615-tel főleg), de annak a fejlesztése még gőzerővel zajlik, tehát nehéz megítélni, hogy a kernel váltás e az oka vagy az mt76 driver-t kéne reszelni. Tekintve, hogy az ősrégi 7602,7603 és 7612 is csak tavaly érte el a stabil állapotot, így kell még ezekhez némi idő. Itt megint látsizk, hogy a Mediatek és a QCA között óriási a különbség a QCA javára. Ha olvasod a topikot, akkor láthatod hányszor kerül elő témaként az mt7621-ben lévő in-silicon bugok sora, vagy a második gmac interfésze amit ha beköt a gyártó akkor interferenciát okoz, és még sorolhatnám...
-
Ha valakit érdekel: gőzerővel folyik az 5.4-es LTS kernelre való áttérés Openwrt alatt. A minket is érintő ramips targeten mostmár elég jó eredményeket lehet elérni, a korábbi - alapvetően a switch chip meghajtóhoz köthető - problémák végre megszűnni látszanak, mivel az új upstream kernelben teljesen új switch chip meghajtó debütál. Egyelőre HW NAT nem lesz benne, de így is el lehet érni PPPoE-n 800-850megabites sebességet. Mostmár 3 hete tesztelem, eddig nem tapasztaltam vele problémát.
Természetesen ez nem csak a 860L-t, hanem minden mt7621-es SoC-kal szerelt routert érint.
Az érdeklődők itt követhetik nyomon a fejlesztést: [link]
-
-
-
Most tartok ott, hogy ki kellett vennem a 860L-t, mert napi szinten hasal meg.
Nem táp hiba, nem kondi hiba (mindet átmértem, ki is cseréltem már őket).
A jelenség ugyanaz: a router egyszerűen újraindul, előtte pár percre elérhetetlenné válik.
Kénytelen voltam visszarakni, a jó öreg, átkondizás után még mindig hibátlanul működő 1043ND-t (v1).
Nem nagyon van több ötletem, hogy ez mitől lehet...
-
Na várjál, nálad is előjött ez a jelenség ami nálam? Pár óránként vagy 1-2 napnként eltűnt a hálózat (a komplett hálózat), és csak restart után működödtt?
Nekem egyébként gyanús, hogy nem a kocka táp, hanema belső kondik adták meg magukat. Most még várok 2-3 napot az új táppal így átkondizás után, hogy lássam: tényleg megjavult. Utána visszarakom a gyári tápját (amiben még az eredeti kondik vannak), hogy kiderüljön hogy az jó-e.
Nálam amúgy elég melegben volt a cucc: éves átlagban 31-32 fokos "szoba"hőmérsékleten.
-
A kondi kiszáradás gyanúval kapcsolatban tovább nyomoztam:
A router panelján kicseréltem a 3 elkót (3 darab 35Volt 220uF kondi van rajta összesen), illetve ugyanolyan kocka tápból volt itthon egy 0km-es, azt kicseréltem.
És láss csodát: a router azóta stabilan működik.
A 3 kondi a nyákon nem tűnt púposnak (persze ettől még lehet szar, majd megmérem őket valamikor), a kocka táp viszont elég jól túl van méretezve: 12/2A, nálam (semmi nincs az USB-n) 5-6 watt körül megáll a téma.
Szóval az még nem világos, hogy az a 3 kondi a routerben, vagy a kocka táp (vagy mindkettő) volt a szar, de valamelyik egészen biztosan az volt. 2 év és 2 hónap használat után.... Ha jól rémlik ilyen hamar semmimben nem szart be elkó korábban...
-
Tegnap meglepő dolgot csinált a router: úgy kifagyott az Openwrt, hogy csak áramtalanítással lehetett kihozni belőle. Pingelni sem lehetett. Sosem csinált még korábban ilyet. Az Openwrt verziót is vagy 100 napja futtatom, tehát azzal biztosan nincs gond.
Azt hiszem így bő két év után lassan belépünk a kondi száradás varázslatos világába...
-
Ma jött meg a Mi 8 Lite telóm, 5GHz AC-n, 80MHz SISO mellett stabil 270/200-at mérek telóról, Openwrt trunk. Amit látok - a működő HW gyorsítás mellett - az a magas kernel load miközben wifiről mérek. Ha drótosba tolom, ott még a gigabit mellett is szinte nulla a load. Feltöltésnél konrkétan az egyik mag kikoppan a kernel load miatt.
Gondoltam megosztom.
-
#1842
dchard
veterán
csocsoszán
#1841
válasz
csocsoszán
#1841
üzenetére
Tudod mit? Mostmár kíváncsivá tettél. Áruld már el nekem, ránézésre hogy a fenébe tudod megmondani, hogy a beépített antenna gagyi-e vagy sem?
Egy antenna minőségét méregdrága műszerekkel lehet csak hitelt érdemlően megállapítani: vektor hálózat analizátorral az illesztettségét (nyereségét adott frekin), sugárzási teszttel az iránykarakterisztikáját. Ezek elvégézéséhez bő 10 millás eszközpark szükséges. Nem tudom komolyan venni azt, aki ránézésre meg tudja állapítani: egy antenna szar, vagy jó.
-
válasz
Gyurka6
#1835
üzenetére
Mély egyetértésem mellett kiegészíteném a következő dolgokkal:
1. Mindenfelé sugárzó antenna csak elméletben létezik. Még egy rendes omni-nak is van karakterisztikája: pédlául felfelé/lefelé alig vagy egyáltalán nem sugároz.
2. A router antennájának a csereberélésével én vigyáznék, ugyanis ezekenél a beépített panel antennák távolról sem biztos, hogy 50Ohm-ra illesztettek. Ha pedig nem, és valaki ráhekkel egy külső antenna csatlakozót, amire nyilván 50Ohm-os antenna kerül, kész is a baj (nem hogy nem nyert, de még rontott is az illető a helyzeten).
3. A memória bővítés engem is érdekelne, de a képen látható szabad hely a NYÁK-on biztosan nem RAM-nak van kiképezve. Sokkal inkább 48TSOP nand az amit oda be lehetne passzentolni. A RAM bővítés valószínűleg csak a mostani module leforrasztásával lehetséges. Tud valaki kompatibilis modult egyébként?
-
válasz
kormoczi
#1584
üzenetére
Még annyit a HW NAT-ról, most néztem újra, és még a korábbihoz képest is jobb az eredmény:
900/200-at PPPoE-n keresztül 5% alatti terheléssel tolja a cucc. Korábban a feltöltésnél jóval nagyobb volt a terhelés, most már azt is kireszelték, gyakorlatilag nulla terheléssel lehet átnyomni a gigabites kapcsolatot akár PPPoE-n is.
Dchard
-
Kicsit offtopik, de ha valaki megtenné, hogy leírja:pontosan hogyan kell ezt a patch-et helyesen alkalmazni az éppen aktuális trunk openwrt-re (ar71xx platform), azért nagyon hálás lennék:
https://github.com/juppin/openwrt_custom_builds_trunk/blob/master/patch/666-shortcut-fe_trunk.patch
Köszi előre is.
-
Valaki lője már le nekem a poént. Ha Openwrt-t buildelek magamnak akkor hová a fészkes fenébe kell rakni a saját config fájljaimat, hogy be is kerüljenek a buildbe?
Leírás szerint a buildroot/files tartalma a gyökér mappa, és ha azt akarom, hogy valami a /etc ben legyen akkor a buildroot/files/etc be kell raknom őket. De hiába mert nem forgatja be. Próbálkoztam a make FILES=files/ direktívával is, ugyanez a helyzet....
-
válasz
vargalex
#1503
üzenetére
Én így kapcsoltam be (az "optimalizált" builden):
uci set firewall.@defaults[0].flow_offloading=1
uci set firewall.@defaults[0].flow_offloading_hw=1
uci commit
/etc/init.d/firewall restartA HW offload működéséhez kell a sima offload is.
Normál körülmények között nyitott lennék bárminek a kipróbálására, de tekintve hogy 3 napon belül lelépek az országból hosszabb időre, igyekszem egy stabil, jól működő hálózatot hátra hagyni, amire elég kevés időm van. Valószínűleg úgy megyek el, hogy mindkét offload kikapcsolt állapotban marad.
-
válasz
vargalex
#1499
üzenetére
Igen, a normál soft offload mellett megcsinálták a HW offload-ot is:
Én ezt a verziót használom:
https://forum.lede-project.org/t/optimized-build-for-the-d-link-dir-860l/948
Baromi sokat dob, de egyelőre vannak vele kisebb gondok, ezért nincs még a trunk-ban. Mindenesetre nagyon sokat dob:
1. PPPoE-n minden nélkül 600mega körül mérek, 100%-on koppan a proci (mind a 4 szál).
2. PPPoE-n soft offload mellett 900+megabit 60-70%-os proci hazsnálattal.
3. PPPoE-n soft offload + HW offload mellett 900+megabit 15%-os proci hazsnálat mellett. -
Tegnap kipróbáltam az új flowoffload kernel infrastruktúrát és és az eredmény elég látványos: a korábbi 5-600megabit mellé 100%-os proci használat helyett most 900megát mérek 60-70%-os terhelés mellett PPPoE-n.
-
válasz
vargalex
#1329
üzenetére
Megáll az eszem. Note 4X-ben van 5gigás rádió és nem tud csak 20MHz-et alapból? Nekem Note 3 SE-m van, de sosem volt ilyen problémám, ahogy a korábbi hasonló 50 ezre forintos telóimnál sem. MIMO viszont egyikben sem volt/van
Függetlenül a te esetedtől: jellemző ez nagy általánosságban? Mármint hogy újabb 2-3 éves telók 20mega korláttal jönnek ki? Ha így van, az kész agyrém...
Dchard
-
válasz
xabolcs
#1275
üzenetére
2.5-3-szoros gyorsulásról írt a fejlesztő ami nagyjából egybe vág az SFE-n mért eredményekkel, kb. ugyanazt és ugyanúgy is csinálja. A linkben még jó esélyt írt a csávó a DSA szerű driverek későbbi merge-elésére, de a fogadnék egy vastagabb összegben, hogy előbb fogjuk látni a netflow megoldást, mint az SFE-t vagy a DSA-t masterben.
Dchard
-
válasz
xabolcs
#1264
üzenetére
Megkaptuk a válaszokat a kérdéseinkre:
1. A DSA branch azért nincs még masterben, mert egyelőre csak IPsec-kel működik, de azzal sem tökéletes a buli, mivel a működéséhez nyúlkálni kell a hálózati stack-be így jó eséllyel sosem kerül a master-be. Talán lesz belőle OpenVPN képes változat, de nem mostanában.
2. A netfilter flow offload elég egyszerű téma, mivel csak a 4.14-es kernelre váltás kell hozzá, ez folyamatban van (a ramips jelenleg 4.9-en van). Szerintem max. 1-2 hónap, és látni fogjuk ezt a master-ben. UGyancsak biztató, hogy a patchset mögötti developer a linux kernel netfilter ágának egy legendás alakja.
Gondolom a korábbi nagy üdvöskét, az SFE-t ezért sem erőltetik, mert lett helyette generikus kernel infrastruktúra.
Dchard
-
válasz
xabolcs
#1264
üzenetére
Nem próbáltam még, de érdekes, hogy John egyelőre nem gondolta úgy, hogy ez megérett a master merge-re, és elég régen abbahagyta. Engem elsősorban nem is a HWNAT, hanem a hardveres AES motor érdekelne VPN-hez.
A netfilteres megoldást valószínűleg előbb fogjuk látni, mivel az működik a 4.14-es kerneltől felfelé, de egyelőre csak az integrálást készítik elő LEDE oldalon, tehát ez is odébb van még.
Időm nem nagyon van erre, de ha valamelyik ismertebb működképes build-be belerakják, szívesen kipróbálom mindkettőt.
Dchard
-
válasz
Gyurka6
#1258
üzenetére
Igen, de az antenna nyereség miért változna? Van egy 3dBi-s antennám, amire most ki tudok nyomni 100mW-ot is (ha szükséges), míg egy olcsó kártyával 32mW-nál lesz a limit.
Az más kérdés, hogy mivel a kliens oldal többség (laptop, telefonok, tabletek) nem tud többet 32mW-nál, ezért felesleges ennél sokkal többel lövöldözni AP oldalon is, mert csak interferit csinálunk a szomszédoknak. Másik dolog, hogy a kliensnek szánt olcsó kártyák - hiába ugyanaz a chipset - valahogy nem működnek olyan jól AP módban, különösen ha több nagy sebességű kliens csatlakozik hozzájuk. Na mindegy, ez nem ide való, csak megjegyeztem mint érdekességet
Dchard
-
Nekem szerencsére nem gond, mert van egy microserverem minden másra, csak NAT+VPN van a routeren, arra pedig elég jó. De a következő beszerzésem biztosan egy OWRT/LEDE képes sima board lesz, és magamnak fogok építeni rá olyan rádiót amilyet akarok. Korábban woodworm által linkelt megoldások kifejezetten szimpatikusak, csak az a baj, hogy az olcsó laptopba való miniPCIe rádiók nem tudnak csak 32mW-ot a 100 helyett.
Dchard
-
Nem beszélve arról, hogy a 128MB ram ebben a routerben elég kevés --> kicsi cash méret ami még rádupláz a pendrive-ok legendásan szar random write/random read teljesítményére. Elég ha csak egy kis random write van a pendriveon, máris lehúzhatjuk az olvasási teljesítményt is. Egy pendrive teljesen alkalmatlan erre, vagy csak nagyon erős korlátokkal.
Dchard
-
válasz
vargalex
#1235
üzenetére
Van egy érdekes új MTK driver ami megy LEDE-vel is:
https://github.com/Nossiac/mtk-openwrt-feeds
Korai lenne örülni, mert egyelőre 4.9-el nem megy, de kíváncsi leszek rá, hogy mit tudnak belőle kirántani.
Bartvz már megpróbált buildelni belőle, egyelőre sikertelenül.
Dchard
-
válasz
vargalex
#1207
üzenetére
Nézd a képet amit linkelt, a MAC címből látszik hogy kinullázott mindent a routerében, pontosan ahogy írtad. Érdekes módon én pont ugyanazt a verziót futtatom mint ő, és sehogy sem sikerült 23dBm-re állítanom a 2.4G-t, viszont sosem volt 3dBm sem, korábbi verziókkal sem.
Én két lehetőséget látok:
1. Ordas nagy kamu az egész.
2. Valahogy a többszöri resetelés után úgy eltűntek a rádió adatok, hogy a LEDE nem tudja megállapítani a régiót, így enged nagyobb kimenő teljesítményt. Persze ez utóbbit is mérni kellene, mert tudjuk, hogy azért mert 23dBm-et ír ki, még távolról sem biztos, hogy ennyi szalad ki az antennára.Dchard
-
válasz
fireqpeg
#1204
üzenetére
"Én erre meg ma rácáfolok mivel júliustól 1 szer se mentettem le semmilyen mtd akármi partíciókat a routerröl, és ma megcsináltam egyedül semmilyen segítségem nem volt, azt hogy teljesen jól működik a wifi 2.4 Ghz LEDE/Openwrt alatt!"
Saját magadra cáfolsz rá, hiszen korábban azt ecsetelted, hogy LEDE alatt teljesen fos a 2.4giga és csak Padavan alatt működik rendesen. Most akkor melyik az igaz?
Dchard
-
Vargalexet kérdezném, hogy ez a sok látványosan rossz eredmény nem lehet annak az oka, hogy mindegyiküknek volt előtte padavan a routerén?
Én gyáriról egyből LEDE-re mentem, sosem volt nálam padavan. Ilyen rossz eredményeket talán csak a fél évvel ezelőtti első bughalmaz verziókkal mértem.
Most mértem megint egyet telóval (SISO): 2.4 giga 20MHz --> 55/50 stabilan.
5GHz SISO: 250/190mega stabilan. 3 méterről, alba fal után. Az 5gigás eredménnyel nem vagyok teljesen kibékülve, mivel ezzel a telóval SISO módban mértem már 350megát is (egy Cisco kábelmodemmel ráadásul), de azért totálisan szarnak nem mondanám.Dchard
-
válasz
woodworm
#1144
üzenetére
Sajnos amire én kíváncsi vagyok nem mérhető appal, használtan 6-8 milla egy értelmes műszer. De a te esetben sem hiszem, hogy egy telós mérés összehasonlítható eredményt ad. 3dB-t simán szórnak, az meg ugye fele-dupla különbség előjeltől függően.
Az antenna rendszert pedig pont azért alakítom át amit te is írsz. A routernek csak kb. 90 fokos térszögben kell működnie, a többi elpazarolt RF energia és potenciális interferi forrás. Tehát nem a nagyobb szint miatt fogok külső antennát használni.
Dchard
-
válasz
vargalex
#1142
üzenetére
Hamarosan át fogom alakítani a rendszert külső antennásra, akkor majd mérhetünk teljesítményt. Nem tudod véletlenül, hogy a benne lévő panel antennák vajon 50 OHm-ra illesztettek-e? Most éppen nem férek hozzá vektor hálózat analizátorhoz, hogy ezt meg tudjam állapítani
Mondjuk az U.FL elvileg szabványos 50 Ohm-os illesztést igényel, de láttam már olyat, hogy mégsem 50 Ohm-ra volt illesztve....A 2.4G nálam teljesen jó, nyilván az elvárható szintnek megfelelően (interferi, SISO, 20MHz, fal).
MOD: amúgy ha gyáriról csak LEDE-re mentem eddig, akkor ott nem cseszhettem el a kalibrációs adatokat, ugye?
Dchard
-
Rengeteg javítás jött ki a nyílt forrású mt76 driverhez az elmúlt hetekben, nálam sem volt mindig ilyen, bár a 12megánál azért mindig több volt.
Most ezt használom:
https://forum.lede-project.org/t/optimized-build-for-the-d-link-dir-860l/948
Majdnem teljesen master, de nem egészen, le van írva, hogy mi van benne pontosan.
5GHz is stabil. Nálam 5G AC-n 80MHz SISO-n stabilan tud 250/200-at 3 méter plusz albafal távolságról.
Dchard
-
válasz
vargalex
#882
üzenetére
Próbálgatom pár napja az SFE-t, hát mit mondjak: elég látványos a javulás. Egyrészt úgy tűnik működik PPPoE mellett is, másrészt legalább 35-40%-kal csökken a processzorterhelés azonos forgalom mellett. Míg korábban 900megabit környékén már eléggé kihasznált volt a proci (85-90% átlagban), addig most alig éri el a 60-at, de amikor conntrack elkezd dolgozni, ez inkább 50% környékére esik.
Eddig semmilyen zavaró anomáliát nem tapasztaltam. Mióta az ehternet drivert érintő javítások bekerültek (+NAPI), azóta a furcsa kernel warningokat sem látom. Szóval alakul ez.
Dchard
-
-
válasz
vargalex
#873
üzenetére
Amit szerintem még senki nem próbált ki itthon: mini jumbo frame. Meg fogom nézni, a digi támogatja-e ezt a formátumot. Ilyenkor 1500 helyett 1508 bájtot képes átvinni a hálózat, így PPPoE mellett is használható a normál 1500 bájtos MTU, és nincs MSS camping sem.
Mivel a 860L támogat jumbo frame-et 2000 bájtig, így router oldalon nem látok szűk keresztmetszetet, és mivel az ONT gigabites, így ott is esélyes hogy menni fog. A hálózat már más kérdés
Dchard
-
Átkértem magam bridge módba, így a héten már a router PPPoE kliense hajtja a gigabtes netet. A megállapításom az, hogy valóban jóval nagyobb a router processzor terhelése azonos sebességen, mint pppoe nélkül, most konkrétan a router koppan ki (550-600mbit-nél), a feltöltés megvan. És mérhetően többet fogja a procit, mint amikor PPPoE nélkül működött.
Mivel még mindig nehezemre esik elhinni ezt a mértékű különbséget, azon gondolkodom lehetséges-e, hogy a PPPoE-vel összefüggő egyéb folyamat okozza ezt a megnövekedett terhelést, például az MSS camp?
Amúgy letöltés közben a terhelés 98%-át a kernel okozza.
Dchard
-
-
válasz
woodworm
#733
üzenetére
Nem kell ezt offba rakni, szorosan ide kapcsolódik
Azt kell mondjam, hogy ebben a kérdésben veled értek egyet. Túl sok munka ezeket egyeséével belepakolni ahhoz, hogy ne egy egységes megoldáson, de minimum egy nyílt forrású megoldáson dolgozzanak, amit bárki bármikor tovább tud fejleszteni, karban tud tartani. Az SFE annyira általános megoldásnak tűnik, hogy azon sem lepődnék meg, ha előbb-utóbb egy átdolgozott változatát beemelnék a hivatalos kernelbe is.
Amiről inkább beszélnünk kéne az pont a WiFi. Mikor anno a Qualcomm felvásárolta az Atherost, mind be voltunk csokizva, hogy a viszonylagos nyílt világnak majd vége lesz, korábban számos példa volt rá, a QC általános hozzáállása is ezt tükrözte. Szerencsére sikerült megtalálni a középutat: az igazán értékes részt a digitális jelfeldogozással kapcsolatban egy jól védett csak binárisan elérhető mikrokódba rakták, amit alkalmasint frissítenek, a driver az inicializáláskor automaikusan betölti, az implementáláshoz szükséges részt pedig kinyitották. Ezért van ma a legjobb elérhető nyílt forrású támogatása a QCA chippel szerelt routereknek.
Nem érzi a Mediatek, hogy lépéshátrányba kerül a riválisával szemben, ha nem változtat a hozzáállásán?
Dchard
-
Akkor igazad is lenne, ha a HW NAT pontosan ugyanazt a feladatot csinálná meg hardveres gyorsítással. A probléma az, hogy ez nem így van. A HW NAT az esetek többségében egy csalás, ráadásul megtöri a kompatibilitást a linux kernel hálózati stack-jével, ebből számos limitáció és probléma fakad. Van olyan népszerű implementáció, amely például nem gyorsítja a forwardolt portokat. Tehát baromi jón néz ki a speedtest-es gigabites mérés, de amikor a NAS-ra torrenteznél, vagy FTP-znél, már nem működik a "HW NAT". Egyéb probléma még a késleltetés: például kis méretű csomagokat lassabban tol át magán, mint a normál software stack, különösen terhelés alatt. Vagy hogy mást ne mondjak: egyetlen jól működő QoS motorral sem működnek a jelenlegi HW NAT megoldások, ellenben az SFE működni fog velük.
Tehát bőven van limitáció a HW NAT-ban. Arról nem beszélve, hogy milyen nehéz implementálni driver szinten a különböző gyártók eltérő megoldásait a ki nem adott specifikációk miatt. Ennél sokkal jobb döntés volt az SFE generikus kódja, és az ebbe fektetett munka, amiből viszont mindenki profitál. Nem is emlékszem az elmúlt évekből hasonlóan széles réteget érintő, ennyire látványos méretű előrelépésre, ami egyetlen OWRT/LEDE fejlesztéshez köthető.
Hogy visszatérjek a saját házunk tájára
ebből a szempontból továbbra is a Wifi drivereket kéne tovább reszelni, de ahogy nézem eléggé leült az aktivitás az mt76 repóban.Dchard
-
Ennél sokkal érdekesebb a helyzet NAT ügyileg. Úgy tűnik, hogy nem kell majd a HW NAT-tal szórakozni, mert éppen születőben van egy gyors, de nem hardware függő megoldás: a Shortcut Forwarding Engine, vagy SFE röviden. Vargalex és többen már tesztelték, elég látványos 2-3 szorors gyorsulást lehet vele elérni, de láttunk már 3-4-szereset is. És ez generikus megoldás, ha végre betolják LEDE- alá, akkor az összes router profitál majd belőle.
Itt tudsz olvasni róla:
https://forum.lede-project.org/t/qualcomm-fast-path-for-lede/4582
Elég jól állnak már. Ne tévesszen meg a név, nem Qualcomm specifikus, csak a kód egy része tőlük származik.
Nem mintha a 860L ne tudná most is kinyomni LEDE alatt a gigabitet, de sosem baj ha marad processzor idő másra is
Dchard
-
válasz
woodworm
#684
üzenetére
Annyit tennék hozzá, hogy van valaki a LEDE fórumon, aki szintén custom buildet csinál ehhez a típushoz, csak LEDE alapon, és a következő 2-3 hétben próbálják a rendes LEDE mellé behekkelni a gyári wifi drivert. Így elméletileg megoldódik a wifis lassulásos probléma is, és lehet majd rendesen használni a LEDE-t is.
Dchard
-
vargalex:
A múlt hét pénteki patch-ek óta a trunk LEDE nem produkálja a korábbi kernel warning-okat/crash-t, akárhogy nyüstöltem nem jött elő. Mások is erre jutottak, ahogy néztem
Dchard
-
Ha valaki szeretné tesztelni, hogy előjön-e nála a hiba, azt a következőképpen tudja megtenni:
OpenSSL util teleítése:
opkg install openssl-utilTeszt indítása (4 szálon, az összes magot 100%-ra terheli):
openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048 dsa2048 rsa4096 -
multi 4Érdemes a fenti tesztet 2-3 alkalommal megismételni.
Utána a kernel logot kell figyelni (bármilyen hasonló jelenséget látsz, másold be ide):
[59583.098482] ------------[ cut here ]------------
[59583.107711] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x254/0x2f4
[59583.124187] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[59583.138032] Modules linked in: nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h3 23 nf_nat_amanda nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_ irc nf_conntrack_h323 nf_conntrack_broadcast nf_conntrack_amanda ts_kmp ts_fsm ts_bm pppoe ppp_async pppox ppp_generic nf_co nntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt _conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_connt rack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle ipta ble_filter ip_tables crc_ccitt mt76x2e ledtrig_usbport mt76 mac80211
[59583.278749] cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tab les x_tables leds_gpio xhci_mtk xhci_plat_hcd xhci_pci xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[59583.317243] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.37 #0
[59583.329007] Stack : 00000000 00000000 80547b2a 00000033 80402a44 00000000 00000000 80540000
[59583.345644] 87c4c99c 804e7ea7 8047e9ec 00000003 00000000 80543824 ffffffff 00000200
[59583.362281] 00200000 800699b0 00000001 80540000 804edfc4 804edfc8 8048361c 87c21ddc
[59583.378918] 00000003 800a7888 ffffffff 00000200 00200000 00000000 00000006 00c21ddc
[59583.395554] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[59583.412203] ...
[59583.417064] Call Trace:
[59583.421948] [<8000f764>] show_stack+0x54/0x88
[59583.430622] [<801db424>] dump_stack+0x84/0xc0
[59583.439283] [<8002a3e4>] __warn+0xe4/0x118
[59583.447419] [<8002a448>] warn_slowpath_fmt+0x30/0x3c
[59583.457302] [<8030b81c>] dev_watchdog+0x254/0x2f4
[59583.466656] [<8007bd20>] call_timer_fn.isra.3+0x24/0x84
[59583.477043] [<8007bf60>] run_timer_softirq+0x1e0/0x240
[59583.487264] [<8002deac>] __do_softirq+0x294/0x2e0
[59583.496614] [<8002e1a0>] irq_exit+0x7c/0x98
[59583.504937] [<8020a5a0>] plat_irq_dispatch+0xb4/0xdc
[59583.514871] ---[ end trace 4c3711a9da28dd27 ]---Dchard
-
válasz
vargalex
#636
üzenetére
Szia,
A kernel warningokat/összeomlásokat javító pacth-ek már benne vannak a mai legfrissebb snapshot-ban, fel is raktam tesztelni. Erről a két pacth-ről van szó egyébként:
ralink: fix rcu_sched stalls on mt7621
ramips: refresh the rcu_sched patch and remove debug info
Az eddigi tesztek elég bíztatóak.
A többivel kapcsolatban igazad van, azok nem a ramips tree-be kerültek, viszont mivel mindkettő mediatek, talán nem találták fel újra a spanyol viaszt, és hamarosan jön a HW crypto és a HW NAT is LEDE-n. Asszem padavan-ba hekkelt hw cryptóval értek el 6 vagy 9-szeres gyorsulást nagy méretű csomagoknál. Ha ezt megkapnánk LEDE-n elég boldog lennék
Dchard
-
-
Oké, akkor mondom én hogy csináltam:
1. Belépsz putty-tyal ssh-n a routerbe.
2. opkg update
3. opkg install vsftpd
4. Kiadod: ./etc/init.d/vsftpd enable
5. Kiadod: ./etc/init.d/vsftpd startÉs belépsz FTP-n (értelemszerűen így csak "root" felhasználóval fog menni amíg nem kreálsz másik user-t)
Innentől kezdve már csak a konfig állományt kell ízlés szerint beállítani (/etc/vsftpd.conf)
Pontosan 3 percbe telt felrakni, működik
Dchard
-
#631
dchard
veterán
csocsoszán
#630
válasz
csocsoszán
#630
üzenetére
Van ftp elérés, LEDE-n és openwrt-n is.
Dchard
-
Ezzel nem, de gyengébbel igen és simán működött. Belülről sem éred el? Nem lehet hogy tűzfal vagy konfig probléma van?
Vargalex:
http://www.t-firefly.com/download/FireWRT/hardware/MT7621.pdf
Hátha valakit érdekel.
Egyébként a egy csomó folyamatban lévő fejlesztés van LEDE alatt ami ezt a platformot - így minket is - érint. Érdemes ránézni erre (még nincs trunk-ben sem), például a HW NAT vagy a HW crypto:
Dchard
-
-
válasz
vargalex
#623
üzenetére
A patch-elt verziót töltöttem le, nem forgattam. Egy nap alatt nem jött elő a hiba egyszer sem. Wifi témában:
2.4GHz 20MHz-en MC9-el (SISO) 44-45mega stabilan az elméleti 72-ből.
5.Ghz 80MHz MCS) (SISO!) stabil 240-250megabit az elméleti 433-ból.A 2.4 nem tiszta, az 5giga tiszta volt. Szerintem ezek jó eredmények figyelembe véve hogy SISO mind a kettő.
Dchard
-
Nyomattam mind a 4 magot fullon egy órán át, csináltam egy órányi iperf3 tesztet 4 szállal, de a patchelt verzióban nem jön elő. Az jó hír mert korábban 5-10 perc után könnyen elő tudtam csalni.
Fontos, hogy a patch egyelőre sem a snapshot sem a stabil buildben nincs benne. Itt lehet a patchelt verzióhoz hozzáférni:
https://pub.polyno.me/lede-ramips-FS804/
Dchard
-
Még egy kérésem lenne. Ha valaki használ padavan-t, megtenné hogy a kernel log-ból (dmesg) kiszedni nekem ezt a részt:
[ 64.240000] mt76x2e 0000:01:00.0: ASIC revision: 76120044
[ 64.270000] mt76x2e 0000:01:00.0: ROM patch already applied
[ 64.340000] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[ 64.350000] mt76x2e 0000:01:00.0: Build: 1
[ 64.360000] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[ 64.400000] mt76x2e 0000:01:00.0: Firmware running!
[ 64.410000] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 64.410000] mt76x2e 0000:02:00.0: ASIC revision: 76020044
[ 64.430000] mt76x2e 0000:02:00.0: ROM patch already applied
[ 64.450000] mt76x2e 0000:02:00.0: Firmware Version: 0.0.00
[ 64.460000] mt76x2e 0000:02:00.0: Build: 1
[ 64.470000] mt76x2e 0000:02:00.0: Build Time: 201507311614____
[ 64.500000] mt76x2e 0000:02:00.0: Firmware running!?
Köszönöm!
-
válasz
vargalex
#615
üzenetére
vargalex:
Kérlek vess egy pillantást erre:
https://bugs.lede-project.org/index.php?do=details&task_id=764
Tegnap nyomtam fel az új trunk LEDE-t és akkor tűnt fel (kernel 4.9.37), de korábban is láttam már. Nálam fagyást, újraindulást nem okoz, viszont a leírtakkal ellentétben nem csak SQM vagy más QoS mellett, hanem erős terhelés mellett bármikor előjöhet. Pillanatnyi lassulás okoz: például 120megával jön a torrent (külön NAS-ra), beugrik a linken látható kernel warning, a letöltés egy pillanatra leesik 30-40megára, majd folytatja.
Van hozzá külön pacth is, most próbálom ki, de ennek a kernel warningnak MTK7621-en több inkarnációja is ismert. Érdemes volna odafigyelni rá, hátha másnál is előjön. Mivel egyértelműen minimum komoly időszakos teljesítmény vesztést (de van akinél fagyást) okoz ez a hiba, így lehet hogy a WiFi szarakodásának is részben vagy egészben ez lehet az oka.
Dchard
-
#610
dchard
veterán
PowerBuldog
#609
válasz
PowerBuldog
#609
üzenetére
Én LEDE-vel használom megelégedéssel. (17.01.2)
Dchard
-
-
-
Felraktam a 17.01.1 LEDE-t, és vége visszakaptam a telómat, úgyhogy most mértem egyet 5GHz AC-n, és SISO módban stabilan megvolt a 230Mbit/s, ami jó eredmény. 2.4gigán szintén SISO módban volt 55Mbit/s 20MHz-en, ami szintén baromi jó (72 elméleti maximumból).
A hírhedt intel 7260 kártyámmal még nem néztem meg, ha lesz egy kis időm akkor kipróbálom.
Dchard
-
#310
dchard
veterán
markussandor
#309
válasz
markussandor
#309
üzenetére
Dettó. Ráadásul a TM-et elég jól lehet finomhangolni ami a memória fogyasztást illeti. Persze továbbra is igaz, hogy alapvetően a szálszám és a cache méret határozza meg a memória fogyasztást.
Dchard
-
Az USB porttal semmi gond nincs, kifejezetten gyors (főleg USB3-mon). Egészen biztos vagyok benne, hogy az LTE hálózat lesz a szűk keresztmetszet, nem pedig az USB port a routeren.
mr3420-at utoljára DC+HSPA+-on használtunk, akkor elméleti max közelében (38Mbit-nél) tetőzött a sebesség, viszont a régebbi TP-Link-ekre jellemző volt az USB port alul méretezése, ezért sok volt a táplálási hiba. A 860L viszont legalább 1 ampert ki tud köhögni, tehát ilyen gond nem lehet, pláne egy USB2 modemmel.
Esetleg érdemes lehet a modemet USB hosszabbítóval előnyösebb helyzetbe hozni, vagy eleve úgy elhelyezni a routerrel együtt, hogy jobb rálátása legyen a modemnek a toronyra (ablak közelében, vagy emeletre ha családi ház), ezek befolyásolják leginkább a sebességet.
Dchard
-
válasz
MrSealRD
#222
üzenetére
Nézd, nekem a wifi sebesség nice to have, az én oldalam ki van kábelezve, csak a telóm lóg wifin. Ha lesz egy kis időm, kikábelezem lófütty méretű antennáit, és kipróbálok több felállást, mert nálam is volt teljesen jó 220-250mega LEDE-n (SISO-n az eléggé a vége a sztorinak, 433mega elvi maximummal számolj), szóval nem a hardver tűnik problémásnak.
Dchard
-
válasz
MrSealRD
#219
üzenetére
Én egyelőre kitartok, túl erős benne a SoC és engem ez (a vezetékes performansz) jobban érdekel. Lassan jön a 4.9-es kernel is, az is hozhat némi fejlődést.
Én már LEDE-n láttam elég jó AC-s sebességeket (lásd: korábbi hozzászólásaim), tehát számomra egyértelműnek tűnik a szoftveres gond, ezt ki fogják reszelni.
Dchard
-
-
válasz
vargalex
#162
üzenetére
Milyen fw volt rajta?
Egyébként most reszelik a 4.9-es kernelt lede alatt, amint kijön kipróbálom.
Nálam az intel AC-s kártyája rosszabb eredményt produkál 2x2 MIMO alatt, mint a Xiaomi telóm 1x1 SISO módban. Előbbi a már korábban linkelt hibákat generálja a router kernel logjában.
Dchard
Új hozzászólás Aktív témák
- Nem lesz Redmi Note 16, évet ugrik a sorozat
- exHWSW - Értünk mindenhez IS
- Motorola Edge 50 Ultra - szépen kifaragták
- Először beszélt bővebben az új Xbox konzolról a Microsoft
- Párduc a gépben: teszten az ASUS ExpertBook Ultra
- Idő előtt felbukkant a Galaxy A57 egy európai webshopban
- Konzolokról KULTURÁLT módon
- Xbox Series X|S
- Facebook és Messenger
- OpenMediaVault
- További aktív témák...
- LG 45GR65DC-B 45 / 5120x1440 / 200HZ / VA /
- Chieftec Smart Seriels GPS-500A8 80 Plus minősítésű 500W tápegység
- Apple iPhone 13 - 85% Akku - 128GB - Független - Hibátlan
- HONOR Magic8 Lite 5G 512GB + CHOICE Cubuds - Gyári Bontatlan, 2028-ig garanciális
- HONOR Magic8 Pro 5G 12/512GB (Black) - Új, Kártyafüggetlen, 2029-ig garanciális
- BASEUS Compact Quick Charger 2xUSB USB-C PD 3A 30W fekete
- REFURBISHED és ÚJ - Lenovo ThinkPad 40AY Universal USB-C Dock
- HP ZBOOK Firefly 16 G10 /i7-1355U/16GB/1 TB SSD/FHD+/IPS/NVIDIA 4 GB Magyar bill
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASUS B560M i5 11400 64GB DDR4 512GB SSD RTX 3070 8GB ZALMAN S2 TG CHIEFTEC 750W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest