Przejdź do treści forum
eko.one.pl
OpenWrt, Linux, USB, notebooki i inne ciekawe rzeczy
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Opcje wyszukiwania (Strona 1 z 58)
Strony 1 2 3 … 58 Następna
Payti napisał/a:Zdecydowanie, jak sie rozważa przed zakupem na jakim SoC kupić router to Mediatek najlepszy i bez problemów z OpenWRT. Jak ktoś już ma sprzęt bo kupił w dobrej cenie na IPQ50xx, IPQ60xx czy IPQ807x to można sie ratować ewentualnie jak wyżej NSS jak sie da...
Co nie zmienia faktu, że sprzęty pod gołym OpenWrt działają specyficznie, czyli albo będzie wolniej albo nie zauważysz akurat różnicy bo wgrane stery odrobinę potrafią.
lukasz3134 napisał/a:A technicznie mówiąc, to juz nie było by OpenWRT tylko QSDK. Na razie po prostu nie będzie NSS i tyle. Ja też juz pisałem do kolejnej osoby która się na tym zna, ale jak zwykle, brak odzewu, przynajmniej na razie.
Pytanie czy obecne obrazy dopakowane nss to jeszcze OpenWrt, wystarczy spojrzeć na ilość pakietow, ktore musza być dodane aby magiczny procesor sieciowy dzialal.
No nic, moze kiedyś coś się odmieni i ktoś to "odblokuje".
lukasz3134 napisał/a:Poza tym, przecież stockowy obraz jest na kernelu 5.4 i ma nss, więc po co jeszcze raz to robić ? Wystarczy odinstalować niepotrzebne pakiety i tyle.
Na moje to bardziej chodzi o sam fakt powtorzenia dzialajacego obrazu na wlasnych warunkach, pakietach. Moze jest to samo, ale mamy na to wiekszy wplyw.
Odnosniki są do zrodel jak masz ochote powalczyc
https://eko.one.pl/forum/viewtopic.php? … 43#p332343
To by też moglo posłużyć za szkielet kompilacji
https://github.com/Wallystech/openwrt_DR5018
Ale mam zacmienie jak patrze na te pliki i nie moge się tam plikow dts doszukać.
Payti napisał/a:@IceG skompilowałem testowo przy pomocy QSDK-12.2.x.xxx.xxx build z NSS dla Redmi AX3000 na IPQ5018 (z dostępnego .dts'a), wkompilowane jest NSS FW.12.2-156, gdzieś tam znalazłem, że jest ono najlepsze dla starszych IPQ5018 (wiadomo MESH'a nie będzie, ale reszta tak). Jest na kernelu 5.4.213, w obraz .bin wkompilowało się co trzeba jeśli chodzi o NSS'a.
Jak masz ochotę podrzucić .dts/.dtsi oraz deklarację DEVICE do Makefile od Xunisona mogę Ci na próbę także taki build z NSS skompilować na testy ...
Ogolnie wszystko jest dostepne na githubie, problem w tym ze ktos tu juz chyba kompilowal takiego skladaka bez pomyslnego efektu. Zapewne trzeba dostosowac dts pod wymagania starszego kernela, bo to co teraz jest to moja prowizorka na aktualne wydanie ktora o dziwo przypadkiem dziala.
Payti napisał/a:Zgadza się, ale może Ci co mają takie źródła dla Arcadyan, Xunisona i innych się podzielą nimi ...
Cos czuje ze predzej doczekamy sie komputerow kwantowych i super modeli LLM ktore to odblokuja, niz jakiegos zrodla, czy podpowiedzi.
Payti napisał/a:Z tego co widzę na tej samej kompilacji bazuje Arcadyan AW1000 z IPQ807x, można by się powzorować z przeniesieniem NSS'a
dla Xunisona, pliki NSS dla IPQ5018 jak widać są dostępne..
Juz widze jak sie ktos za to bierze.. tu jest tyle pakietow, tyle zaleznosci ze glowa mala. Ktos z wiedza o tym srodowisku musialby wpasc w temat, a na to sie nie zanosi. Wszyscy poszli w mocniejsze routery i rozpracowane pakiety, bo tak latwiej i szybciej.
lukasz3134 napisał/a:Mi migneło jeszcze jedno repo na githubie, ale to było już na kernelu 4.4. Tak w ogóle ciekawostka, w nazwie pliku oryginalnego firmware jest brax,fa532. To się odnosi też do innego chińskiego routera na bazie ipq5018.
Tu nie pamietam ale jest 4.4 lub 5.4. Tego brax,fa532 tez sie nie dostanie, niby wszystkie fw oparte na OpenWrt ale wiadomo zrodla tylko dla korpo. Mialem pisac do tych gosci z tamtego projektu ale po tym jak ktos na forum OpenWrt walczyl z jakims podobnym modelem z tej firmy to zrezygnowalem.
lukasz3134 napisał/a:Tylko że to i tak jest pod konkretny model routera, więc nawet jakby mieć źródła od Xunisona i wrzucić je do tego repo to i tak by nie zadziałało.
Tylko podalem ze cos w necie jest.. chyba jedyne dostepne, innych nie kojarze.
Pisalem o tym wczesniej
https://github.com/Wallystech/openwrt_DR5018
Szkoda ze nie udostepnili pelnych zrodel, tak to by mozna sie czyms wzorowac. Inna sprawa ze tu chyba jest mocno starszy kernel.
Teraz patrze i cos z nss jest wrzucone..
https://github.com/Wallystech/openwrt_D … sr/include
mvincm napisał/a:Poproszę serdecznie!
OK, w takim razie w niedzielę będzie nowy obraz.
Cezary napisał/a:Chcę zrobić małą rewolucję. Do tej pory do niektórych obrazów wkładałem luci-app-disks-info. Natomiast teraz włożył bym luci-app-mini-disk-manager o którym było tu już wspominane. Ktoś używa jednego lub drugiego i ma jakieś zastrzeżenia?
Tak z czystej ciekawości, który Cezary pakiet ostatecznie się zadomowił?
Będę chciał na niedzielę zrobić aktualizacje moich pakietów / repozytorium. Zmiany w pakietach są kosmetyczne (mniejszy rozmiar ikon, nowe języki, drobne funkcjonalności). Udostępniać z tymi pakietami nowy obraz, ktoś będzie zainteresowany? Na wzrost wydajności nie ma co liczyć, cała zabawa to tylko podniesienie wersji pakietów.
lukasz3134 napisał/a:Najbardziej frustrujące jest to, że sprzęt do testowania jest, ale nie ma kontaktu z gościem który się na tym zna. Na forum openwrt w ogóle nie wchodzi, możesz mu wysyłać dziesiątki wiadomości ale i tak do nich nawet nie zagląda. W moim obrazie z nss widzę że rdzeń NSS się podnosi, firmware nss się ładuję, radia wifi są rozpoznawane, ale ethernet mi nie działa i wifi tak samo. I nie mam pojęcia, który sterownik wszystko psuję...
Ciekawe czy w koncu komus uda sie to normalnie uruchomic. Chwalenie sie ze NSS dziala tylko na mocniejszych sprzetach nie podbudowuje.
thexerxis napisał/a:Mam tez zakupiony modem RM520Q chetnie go przetestuje jak sie sprawuje z Twoim softem IceG - rozumiem ze rozbieram xunisona i go poprostu przepinam? Agregacja i wszystko powinno z automatu zadzialac?
Nie potwierdze ze wszystko bedzie dzialac z automatu, kwestia tego jak masz ustawiony modem. W obrazie nie ma wszystkich sterownikow wiec modem pozniej trzeba skonfigurowac pod stery w obrazie.
lukasz3134 napisał/a:Rożnica jaką zaobserwowałem to, przy naszych sterownikach quectela bez nss zuzycie cpu to praktycznie prawie 100% na obu rdzeniach przy speedteście. Na oryginalnym sofcie, to jest ok 65-75 procent, bo tam też swoje robi nss, ale i tak nie doszedłem do 500mbps.
To ja juz nic nie rozumiem.. to w koncu bez NSS na sterownikach Quectela jest obciazenie rdzeni pod korek czy nie? czyli te stery z QModem nic nie daly?
Bardzo malo prawdopodobne, jak wczesniej nikt tego oficjalnie nie zrobil to dlaczego teraz by mialo byc inaczej? Najpierw Panowie musza stworzyc / dopracowac sterownik IPQ5018 DWMAC (nie wiem na jakim to jest etapie). Gosc z tematu wspomagal sie Claude Code przy portowaniu, wiec raz Ktos z wiedza musialby sie za to zabrac, dwa Claude za friko nie pomaga.
Fajnie by bylo, ale czy dojdzie do az takiego zbiegu okolicznosci..
thexerxis napisał/a:No nic, bede musial wgrac firmware od IceG i przetestowac te predkosci, martwi mnie ze duzo osob pisze ze osiaga gorsze predkosci niz ten oryginalny chinski soft
Jak masz internet od Pomaranczowych to jest szansa na znosne predkosci.
Tez mnie to boli ze tak to dziala, nie ukrywam liczylem na lepsze wyniki, niestety bez prawilnej sprzetowej akceleracji jest ciezko o dobre predkosci. O ile na nss nie mam wplywu to fajnie by bylo chociaz wyrownac predkosci dla ipv4 & ipv6.
nicefile napisał/a:@IceG
Czy testowałeś może wydajność sieci
iperf3 --bidir -P 2 -t 60 -c server
jeśli w 'br-lan' dołączysz jedynie wan ?
U mnie na scr50axe okazało się ze port wan ma przepustowość większą o prawie 100% od portów na switchu
testowałem "pull/22381" i tak mi wyszło. W PR mój komentarz dotyczy SoC na standardowym zegarze.
Nie testowalem pod tym katem, bardziej skupilem sie na ogolnym dzialaniu.
Ok, dziękuję za info. Ciekawe co to z tego finalnie wyjdzie.
Szkoda że ten nieszczęsny co-procesor sieciowy tak zamknęli i się marnuje pod czystym OpenWrt.
No nic.. pozostaje czekać, niech Panowie działają.
lukasz3134 napisał/a:4IceG, chciałbym cię uprzedzić, że niedługo może być spory problem jeśli kompilujesz swoje obrazy na Snapshot. Przygotowuję się przejście na kernel 6.18 dla ipq50.
@lukasz3134 Możesz mi podać źródło tej informacji, ponieważ ten wątek https://github.com/openwrt/openwrt/issues/21030 nic ciekawego nie pokazuje.
lukasz3134 napisał/a:4IceG, chciałbym cię uprzedzić, że niedługo może być spory problem jeśli kompilujesz swoje obrazy na Snapshot. Przygotowuję się przejście na kernel 6.18 dla ipq50x, i nastąpi to już niedługo, a na tym kernelu nie chcą się kompilować sterowniki quectel mhi. Pozwoliłem sobię napisać jako ostrzeżenie.
Przeciez to bylo do przewidzenia ze tak sie stanie, wiec nie ma co tu robic afery. Mozna by napisac rozwoj / postep.
Bardziej mnie martwi czemu sa tak slabe predkosci na tych sterownikach dla IPv4 okolice 130 Mbps jak u siebie na Play testowalem (przy slabym sygnale) to zgroza.. pewnie jakbym przelaczyl na usb i uruchomil na usb 2.0 modem mialbym wiecej.. porazka straszna, wcale sie nie dziwie ze jest znikome zainteresowanie obrazem.
Testowalem stare sterowniki mhi_q i one powodowaly obciazenie cpu0 pod korek. Teraz dojdz co tutaj jest pomerdane i psuje cala radoche.
Na plus.. Dodali wsparcie dla uzytych w moim obrazie latek od ledow, wiec mocno prowizorycznie ale mogliby dodac oficjalnie router (nie czekajac na oficjalne dorobienie wsparcia dla diody wan, stery od modemu to jeszcze inny bajzel ale na usb by modem dzialal).
adreskontaktowy napisał/a:Sorki za Nicka.
Z pakietami od Ciebie raz miałem problem, a dokładniej z kluczami do repo.
Przy przejściu na 25.12 pewnie też trzeba będzie podmienić?
Postawię 25.12 najpierw na lokalnym AX3000T,a potem na zdalnym ZTE dopiero.
Co do nicka.. literowka ludzka rzecz wiec spokojnie 
.
Co do repo to tak, klucz bedzie do pobrania. Wszystko jest opisane, jakie polecenia wykonac aby dzialalo, wiec nie ma co sie obawiac repo apk.
adreskontaktowy napisał/a:Ja się dalej boję, że coś nie będzie działać, szczególnie modem LTE, PPPoE lub WireGuard.
Szczególnie obawiam się update'u na MT268D, który stoi zdalnie na LTE Orange i musiałbym to zrobić przez WireGuard stojącym na skandywanwskim Mikrusie.
Do tego muszę to robić z zachowaniem konfiguracji, a potem postawić szybko watchodaga z paczki Ice4G, a apk nie używałem jeszcze.
Ewidentnie mam za trudny nick, pewnie za dlugi ze tyle z nim ludzie maja klopotow Jakby tego bylo malo.. to troche sie pakiety pozmienialy w moim repo dla apk w tym tez wariacja watchdoga.
Kaizen napisał/a:Na fabrycznym sofcie nie ma zauważalnej różnicy między IPv6 a v4. Na sofcie IceG na IPv6 śmiga bardzo podobnie jak na fabrycznym - a na IPv4 ponad dwa razy wolniej. Mam bardzo podobne wyniki co bacz7. IPv6 sprawdzałem na Orange - ktoś jeszcze daje IPv6 na 5g? IPv4 sprawdzałem na Orange i t-mobile.
Najgorsze jest to ze na ten moment nie mam na to rozwiazania i trzeba by przeprowadzic jakies sledztwo wszak nie kazdy ma neta z Orange i troche slabo ze tak to teraz dziala.
Znalezione posty: 1 do 25 z 1,435
Strony 1 2 3 … 58 Następna