Hirdetés
- Sony MILC fényképezőgépcsalád
- Azonnali alaplapos kérdések órája
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Epson nyomtatók
- Melyik tápegységet vegyem?
- OLED TV topic
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Milyen TV-t vegyek?
- Minden korábbinál több LED zóna került a TCL új Mini LED tévéjébe
-
PROHARDVER!
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
-
woodworm
veterán
Nem akartam a padavan eltérő felosztásával többet foglalkozni, mivel egyes partíciókat egyesíteni, míg a maradékot darabolni kellene, hogy egy lede alatt készített mentést visszarakj. Hogy a csavar teljes legyen, ha az átmeneti fw felületén mentettél, ugyanazt kapod vissza.
Tehát egyesítettem a lede alatt mentett következő három partíciót:u-boot-env.backup
radio.backup
factory.backupA létrejött fájlt felírtam a defaults.backup partícióval egyetemben, az írás végeztével áramtalanítottam a routert és recovery módban indítottam, raktam rá a kívánt fw-t.
-
Tyrel
őstag
Erről a HW-NAT-os, új WiFi driveres LEDE-ről majd írtok ide?
Vagy mi ennek a (branchnek??) a pontos neve, hol lehet nyomon követni a fejlődését?@csocsoszán:
Azt végül is nézted hogy nem ütközik-e valamelyik ~router CPU limitbe? (bár a huawei-n nem tudom hogyan lehetne)
Amúgy igen, a digi jóval olcsóbb mint mások, de mint tudjuk olcsó húsnak... Telekom drága és amúgy egy istentelen balfasz banda, sokszor akasztottak már ki (csak így vidékiként nincs más szolgáltató itt, max. még Invitel...), de eddigi tapasztalataim és ismerőseimnél látottak szerint ők jellemzően azt, vagy közel azt adják amiért fizettél nekik. Amúgy egy fejetlen idióta banda, a szoftveres részlegük is béna, de netem 56k modem óta (még Axelero-nak hívták őket) végig tőlük van, és sosem volt vele gond... Ill. egyszer sok éve két napig nem volt net, mert valami részeg vadbarmok május fát állítottak a fő telefon vezetékbe, de hát arról nem a Telekom tehet... (amúgy utána hetekig ezen röhögött a város, konkrétan ott volt a május fa mellett kidöntve a fűben a telefonvezetéket jelölő tábla... biztos nem tudták mi lehet az...)Turenkarn
-
dchard
veterán
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
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
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
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
suste
veterán
Nekem pont az volt a célom, hogy a valós (átlag)sebességet mérjem. Szóval valamit elkezdesz letölteni az mennyi idő alatt jön le.
De persze gigabites sebességhez már kevés lehet így a router procija, bár a load nem megy fel ilyenkor sem az egekbe.
A speedtestes és hasonló mérések nekem azért nem szimpik, mert igaz hogy nem a csúcsot mutatja, de nem is valós átlagsebességet amivel majd ha letölteni akarsz azt fogod elérni....persze ez már a szerveren is nagyban múlik majd. De ha valaki csak az epéniszre hajt, akkor arra tökéletes -
vargalex
Topikgazda
Nincs ebben semmi érdekes. A jellemzően 1500 byte-os frame-okat szét kell tördelnie, hogy a PPPoE header-el együtt beférjen az ethernet keretbe, újra checksum-olnia kell, stb.. Szerver oldalon természetesen a ugyan ezt el kell játszani, az összetartozó frame-okat egybe kell rakni, stb. Jól látható, hogy ez mindkét oldalon jelentős többlet erőforrás igénnyel jár.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
Miért ne mondhatná azt az 1043ND-n, hogy a wifi nem a LAN-hoz tartozik, külön hálózatot alkot saját DHCP szerverrel, sávszélesség korlátozással. Akár még NAT-olhat is a kettő között. Külön szabállyal pedig felveheti, hogy a szomszéd tartományból a saját tartomány nem érhető el (kivéve az ott futó DNS szerver), csak a WAN.
Alex
-
kzkz
őstag
Végülis megcseréltem, sőt csak a dlink maradt. Felment rá a stable lede, és később a snapshot is. Hát a wifi rögtön használhatlan is lett, ott volt mellette a laptop és 0,05mbps volt a sebesség.
Kénytelen voltam visszarakni a gyárit, ezzel 50mbps.Viszont itt ha átállítom a dns szervert, hogy ne a 0.1-et ossza, hanem 1.1-től,akkor újraindul kis idő múlva
Ez a gyári fw egy nagy fos. Miért csak max 15 fix ip-t, és 15 port forward-ot lehet beállítani???????Azt hiszem visszaviszem, és veszek egy TP-LINK TL-WR1043ND v4-et, a v1.1 helyett...
-
Empotempo
csendes tag
válasz xabolcs #1000 üzenetére
Köszönöm. Sikerült a telepítés minden gond nélkül. Már csak be kell lakni az "új" routert. Fogalmam sincs mi lehetett a gond a gyári fw-rel, de mint már írtam egyik-napról a másikra nem tudtam elérni a felületet, sem wifin sem vezetéken. Csak a reset segített és ha már úgyis mindent újra kellett állítani, gondoltam megprópálom a padavant. Vargalexnek külön köszönet és pacsi!
-
vargalex
Topikgazda
válasz xabolcs #1208 üzenetére
ar71xx platformon is volt gond vele, de a TP-Link ilyen szempontból "szerencsés". Ott a factory firmware=0-kkal feltöltött sysupgrade firmware. De a különböző routereknél nem ez az általános. Úgyhogy érdemes úgy megszokni, hogy OpenWrt/LEDE-re sysupgrade, gyárira factory firmware megy.
Alex
-
xabolcs
őstag
válasz xabolcs #1227 üzenetére
Most nem tudom reprodukalni ... nem tudom mi a kulonbseg az akkor es most kozott.
Annyit viszont bizton allithatok, hogy ha kihagyom a hub-ot, akkor a letoltes 10~20 MBittel felgyorsul. Ezt mar akkor is eszrevettem, es most is ugyanugy viselkedik.
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
dchard
veterán
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
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
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
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
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
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
suste
veterán
válasz xabolcs #1348 üzenetére
én azt várom, hogy végre legyen egy mediaserver és wifi ügyileg is jó fw
de mint látod mindig van valami bug
a következő stabilra még várni kell, így marad a saját build, ha egyéni igényeid vannak és elfogyott a türelem
ha a stabil előtt sikerül összehozni valakinek egy jól működőt, akkor azt szívesen megosztom saját tárhelyen, és használnám is a saját routeren
vargalex és headless is tesztelget.....[ Szerkesztve ]
-
suste
veterán
válasz xabolcs #1375 üzenetére
megvan, csak kivettem a 17.01 mappából és csináltam egy 18.01-et neki
mindjárt átlinkelem az aktuális verziót (06) a 17.01-be, hogy a 9092-ről is lehessen flashelnipár apróbb hibát találtunk már benne, de mindegyiket meg lehet oldani akár új verzió flashelése nélkül is
a 18.01 mappában van changelog, ami tartalmazza a hibák kézi javítását is
szerintem a következő verzió (07) már a végleges lesz -
suste
veterán
-
suste
veterán
válasz xabolcs #1383 üzenetére
nálam mindig sokkal rosszabbul teljesít minden router wifi ügyileg (pl tplink1043v1 használhatatlan volt nálam), mivel elég zsúfolt az elrendezés (Modem, Router, USB3-HDD), és elég sok a saját wifi hálózat
5-6 napja van fent az új fw,
-TM, SAMBA azóta hibátlanul megy,
-a libffmpeg csere óta a minidlna is tökéletes,
-a vsftpd sajnos mégsem tökéletes, alapkonfiggal, user/pass -szal megy, de írási jogokat tartalmazó konfigokkal már nem ..... azért ez is több/jobb, mint amilyen volt2-3 napja költöztettem át a saját wifi SSID-t a dlinkre, azóta semmi hiba nem volt vele, minden egyből kapcsolódik, nem dobál le egyik freki sem
pont olyan amilyennek lennie kell[ Szerkesztve ]
-
veterán
válasz xabolcs #1903 üzenetére
pont az. ennyire nem súlyos, mint a levelekben (elsőre két napig stabil volt, utána reboot után 4 órán át bírta, most egyelőre négy és fél órája megy), de akkor rápróbálom ezt a snapshotot, köszi
aztán meglátjuk, hogy marad-e egyáltalán ez a router, mert nálam 60 négyzetméteren teljesen jó volt, de a mostani helyén a kétszintes házban sajnos gyengébb az előző telekomos eszköznél.istálló? gazemberség? hupákolás?
-
dchard
veterán
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.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
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.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
xabolcs
őstag
válasz xabolcs #2077 üzenetére
Hahaha! Muszaj leszek megiscsak forditani!
A "Tue Apr 7 05:04:05 2020" datumu, r12857-7daab62861 verzioju OpenWrt SNAPSHOT nekem csak az "openwrt-ramips-mt7621-dlink_dir-860l-b1-initramfs-kernel.bin" fajl segitsegevel indul el.
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
You choosed 3
0
3: System Boot system code via Flash.
## Booting image at bfc50000 ...
addr:80500000
We have SEAMA, Image Size = 2424768
Verifying Checksum ...
Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to recoverAz initramfs-t Linux alol, dnsmasq-kal szolgalom ki, Windows alol nem erte el a tftpd32-t.
$ sudo dnsmasq --no-daemon --port=0 --enable-tftp --tftp-root=/tmp dnsmasq: started, version 2.79 DNS disabled dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dnsmasq-tftp: TFTP root is /tmp dnsmasq-tftp: sent /tmp/openwrt-ramips-mt7621-dlink_dir-860l-b1-initramfs-kernel.bin to 192.168.0.1
Bootlog:
Got it
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
####################
done
Bytes transferred = 3761449 (396529 hex)
NetBootFileXferSize= 00396529
Automatic boot of image at addr 0x80A00000 ...
## Booting image at 80a00000 ...
Image Name: MIPS OpenWrt Linux-5.4.28
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 3761385 Bytes = 3.6 MB
Load Address: 80001000
Entry Point: 80001000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
[ 0.000000] Linux version 5.4.28 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r12857-7daab62861)) #0 SM0
[ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 0001992f (MIPS 1004Kc)
[ 0.000000] MIPS: machine is D-Link DIR-860L B1
[ 0.000000] Initrd not found or empty - disabling initrdEz a "Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to recover" hiba pedig egyszer mar felutotte a fejet itt, az MT7621 SoC-nal, amin jow igazitott egy kicsit.
A problema viszont egyaltalan nem ujkeletu: Uboot - Not enough buffer for decompression LZMA ERROR 1
Ott irja hnyman, hogy 2012-ben is osszefutott egy ilyennel.Most 20 bittel probalkozok, remelem meggyogyul tole.
diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk
index cdae42f3e4..5f1e200e71 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -6,7 +6,7 @@ include ./common-tp-link.mk
DEFAULT_SOC := mt7621
-KERNEL_DTB += -d21
+KERNEL_DTB += -d20
DEVICE_VARS += UIMAGE_MAGIC SERCOMM_HWNAME
# The OEM webinterface expects an kernel with initramfs which has the uImageSiker!
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
0
3: System Boot system code via Flash.
## Booting image at bfc50000 ...
addr:80500000
We have SEAMA, Image Size = 4718532
Verifying Checksum ...
Uncompressing SEAMA linux.lzma ... OK
## Transferring control to Linux (at address 00000000) ...
## Giving linux memsize in MB, 128
Starting kernel ...
[ 0.000000] Linux version 5.4.28 (xabolcs@ut1804) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r12857-7daab62861)) #0 SMP M0
[ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 0001992f (MIPS 1004Kc)
[ 0.000000] MIPS: machine is D-Link DIR-860L B1
[ 0.000000] Initrd not found or empty - disabling initrd[ Szerkesztve ]
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
xabolcs
őstag
válasz xabolcs #2081 üzenetére
Az a dnsmasq parancs nem sikerult tul jol
$ sudo dnsmasq --no-daemon --port=0 --enable-tftp --tftp-root=/tmp
dnsmasq: started, version 2.79 DNS disabled
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
dnsmasq-tftp: TFTP root is /tmp
dnsmasq-tftp: sent /tmp/factory.bin to 192.168.0.1
dnsmasq-tftp: sent /tmp/factory.bin to 192.168.0.1
dnsmasq-tftp: sent /tmp/initramfs.bin to 192.168.0.1Most 20 bittel probalkozok, remelem meggyogyul tole.
Igazi SNAPSHOT-ot forditva sikerult nem indulo image-eket keszitenem!
Nem tudom milyen hibaval allok szemben, de 19 bittel is "Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to recover" hibat kaptam.
Csokkentem tovabb a dictionary meretet ...aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
dchard
veterán
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=0
Namost 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...
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
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...
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]