Temat "Wyższość Tomato nad OpenWRT", który sobie pierwotnie wybrałem to raczej litania a nie artykuł na konkurs, chociaż mam nadzieje, że kiedyś go zrealizuje Dużo pracy i brak czasu zmusiło mnie do zmiany tematu na prostszy, chociaż pomocny i nigdzie dokładnie nie opisany. Wiele osób codziennie pyta mnie o informacje odnośnie kompilacji własnego openwrt. Dało mi to myślenia, że taki artykuł jest potrzebny. Poznanie tej wiedzy zajęło mi prawie miesiąc (a obsego dużo cierpliwości - wielkie dzięki obsy). Podzielę się tą wiedzą z innymi.
Kto nie chciałby poszczycić się własną dystrybucją oprogramowania na router? Dostosować soft do swoich potrzeb. Wkompilować w niego to co się chce a wywalić to co danej jednostce jest zbędne. Zaspokoić potrzeby wszystkich się nie da, więc taka wiedza odnośnie kompilacji własnego openwrt jest naprawdę potrzebna i właśnie tego będzie dotyczył ten tutorial.
Zanim zaczniemy...
Wyjaśnię tu jeszcze po krótce zasadę działania systemu plików w openwrt. Nie prawdą jest, że openwrt jest systemem typu RW a przynajmniej nie tak do końca. Alternatywy typu tomato lub ddwrt mają system plików read-only a z wolnej przestrzeni pamięci flash można zrobić sobie zapisywalny system plików jffs. W openwrt nie ma jffs. Został on przeznaczony właśnie na potrzeby zapisywalnego systemu plików. Soft wgrywany jest do rom (system read-only) a jego część konfiguracyjna kopiowana jest do jffs i "kombinowana" za pomocą pivota. Kombinacja romu i jffsa daje nam zapisywalny system plików. I tu mała uwaga. system zajmuje miejsce podwójnie. Przyjmijmy, że wkompilowaliśmy w nasz obraz na stale transmission. Instaluje sie on do romu. Gdy modyfikujemy jakiś jego plik, zapisuje się on na jffs a w romie pozostaje nietknięty. Powiedzmy, że chcemy transmission zastąpić rtorrentem. Usuwamy go przez opkg i... usuwa nam się tylko z jffsa, w romie nadal zostaje gdyż rom jest tylko do odczytu. W przypadku aktualizacji jest jeszcze gorzej, gdyż nowa wersja zainstaluje nam sie na jffs natomiast w rom nadal jest stara wersja. Miejsca zajmowane jest więc podwójnie w pamięci flash routera. Myśl tą rozwinę w dalszej cześci artykułu. Tyle tytułem wstępu, zabieramy się do roboty
I. Przygotowanie środowiska programistycznego - SDK
Potrzebujemy linuxa. Najlepiej nadaje się do tego ubuntu lub debian. Jeżeli nie posiadamy osobnego komputera możemy posłużyć się wirtualną maszyną. Od razu uczulę by zagospodarować sobie przynajmniej 10-15GB wolnej przestrzeni Z czasem przekonacie się czemu.
Instalacji linuxa nie będę tu opisywał. Instalacja jest prosta i zakładam, że każdy kto chce zacząć przygodę z kompilacją openwrt ma jakieś pojęcie o linuxie i instalacja systemu nie jest dla niego problemem.
Cały opis będę wzorował na Debianie a kompilował będę trunka pod tplinka wr1043nd.
Po instalacji linuxa należy doinstalować parę potrzebnych paczek:
Tworzymy w katalogu domowym katalog np openwrt i ściągamy do niego źródła trunka:
Cytat
cd /home
mkdir openwrt
cd openwrt
svn co svn://svn.openwrt.org/openwrt/trunk/
cd trunk
Pobrane źródła zawierają podstawowy zestaw pakietów. Aby ściągnąć pozostałe pakiety dostępne w repozytorium (tzw. feeds) należy przejść do katalogu ze źródłami a następnie pobrać listę dostępnych pakietów oraz zainstalować je poleceniami:
Cytat
./scripts/feeds update -a
./scripts/feeds install -a
Ponieważ jest to wersja rozwojowa, która codziennie się zmienia (timeline można znaleźć na https://dev.openwrt.org/timeline), należy przed każdą kompilacją sprawdzić czy nie wyszła nowsza wersja trunka. Służy do tego polecenie (musimy być w katalogu ze źródłami):
Cytat
svn up
Przy okazji sprawdzajmy też czy nie wyszła nowsza wersja feeds`ów.
Mamy już gotowe podstawowe środowisko. Zabieramy się za konfigurację i kompilację naszego openwrt.
II. Konfiguracja openwrt
!UWAGA Nie zaleca się wykonywać kompilacji na koncie z prawami roota. Jeżeli jednak chcemy uparcie działać na koncie z prawami roota musimy do pliku tmp/.prereq-build dopisać
Cytat
FORCE=1
Będąc w katalogu ze źródłami wydajemy komendę
Cytat
make menuconfig
by wejść w menu konfiguracji kompilacji.
Rys. Standartowe menu konfiguracji opewnrt
Wybieramy odpowiedni dla naszego routera Target System, Target profile oraz Target Images. W ten sposób zaznaczą nam się też podstawowe pakiety potrzebne dla danego urządzenia. Pozostaje nam dobór dodatkowych pakietów i modułów wg naszego uznania.
Opcje możemy zaznaczyć (*) lub (M). (*) oznacza skompilowanie pakietu/modułu jako paczkę ipk i wkompilowanie jej do obrazu wynikowego. (M) skompiluje jako paczkę ipk, którą później można doinstalować przy pomocy opkg. Uczulam przed kompilacją wszystkiego do obrazu. To co ulega zmianie np (transmission) nie warto kompilować na stałe (*), tylko właśnie jako moduł (M). Pisałem o tym na początku. Zaznaczenie danej opcji spowoduje też zaznaczenie innych pakietów zgodnie z zależnościami. Możemy więc natrafić też na pakiety oznaczone jako (---), którego nie da się odznaczyć. Oznacza to, że ten pakiet jest zależny od innego (jest potrzebny by inny pakiet zadziałał). By móc odznaczyć taki pakiet musimy najpierw znaleźć i odznaczyć pakiet, który go potrzebuje/blokuje. Po wybraniu wszystkich pakietów i funkcjonalności, które chcemy, wychodzimy z menu a na pytanie czy zapisać konfigurację odpowiadamy twierdząco. Konfiguracja zostanie zapisana jako plik .config
Jeżeli posiadamy już wstępny plik z konfiguracją pod swój router np. pobrany od innego developera lub ze strony openwrt możemy go umieścić w katalogu ze źródłami pod nazwą .config. Uprości nam to kompilację własnej dystrybucji, gdyż nie zaczynamy od zera a jedynie musimy dostosować konfigurację do własnych potrzeb.
III. Kompilacja openwrt
Gdy mamy już gotową konfigurację możemy przystąpić do kompilacji.
Jeżeli jest nasza kolejna kompilacja musimy najpierw wyczyścić środowisko z poprzedniej kompilacji komendą:
Cytat
make clean
Trzeba pamiętać by czyszczenie wykonywać każdorazowo przed kompilacją.
Właściwą kompilację wywołujemy komendą
Cytat
make
Jeżeli posiadamy procesor wielordzeniowy możemy wykonać kompilację z określoną ilością rdzeni procesora poprzez dodanie parametru -jx, gdzie x to liczba rdzeni jakie mają być wykorzystane w kompilacji. Jeżeli nie podamy tego parametru, do kompilacji zostanie wykorzystana moc jednego rdzenia a dokładniej mówiąc wszystkie rdzenie ale suma ich wykorzystania da 100% (wg linuxa jeden rdzen 100%, 2 rdzenie 200%, 4 rdzenie 400% itd). Chcąc więc wykonać kompilację z pełną mocą obliczeniową naszego procesora należy podać ten paramentr. Przykładowo dla dwurdzeniowego procesora będzie to:
Cytat
make -j2
Możemy włączyć też opcję debuggowania dodając na końcu parametr V=99. Uczulam by właśnie tak wykonywać kompilację, gdyż ewentualne niepowodzenie w kompilacji pozwoli nam zdiagnozować i poprawić problem. Pełna komenda powinna więc wyglądać następująco:
Cytat
make -j2 V=99
Kompilacja jest czasochłonna. Na jednym rdzeniu może wynieść nawet 2h. Na 4 rdzeniach ok 40min. Za pierwszym razem należy doliczyć czas potrzebny na ściągniecie źródeł kernela, iptables i wszystkich zaznaczonych pakietów (już wiecie czemu mówiłem by zagospodarować sporą ilość wolnego miejsca B)).
Po pomyślnie zakończonej kompilacji otrzymamy gotowy obraz w katalogu ./bin/(wybrana_architektura)/. Przykładowo dla Tplinka 1043ND będzie to
W katalogu ./bin/packages bedziemy mieli zaś wszystkie paczki ipk z zaznaczonych pakietów i modułów (nieważne czy zaznaczaliśmy je jako * czy M).
IV Kompilacja pojedyńczego pakietu
Czasami istnieje potrzeba skompilowania pojedynczego pakietu (np wyszła nowsza wersja używanego przez nas pakietu lub potrzebujemy pakiet którego wcześniej nie skompilowaliśmy). Nie ma wtedy potrzeby kompilować wszystkiego. Wystarczy skompilować tylko dany pakiet.
Taki pakiet musi być w menu zaznaczony przynajmniej jako M lub *.
Następnie jeżeli jest to pakiet główny z svn wydajemy polecenie (dla przykładu będzie będzie to wireless-tools)
Cytat
make package/wireless-tools-compile V=99
czyli make package/(nazwa_pakietu)-compile i V=99 by włączyć debuggowanie.
Jeżeli jest to pakiet z feeds`ów (np rtorrent) komenda będzie następująca
Cytat
make package/feeds/packages/rtorrent-compile V=99
Chcąc skompilować pakiet dla Luci lub xwrt komenda będzie następująca
Cytat
make package/feeds/luci/(pakiet)-compile V=99
lub
make package/feeds/xwrt/(pakiet)-compile V=99
Skompilowany pakiet znajdziemy w
Cytat
./bin/(architektura)/packages/
Gotowe.
V Modyfikacje - dostosowanie plików do własnych potrzeb.
A co gdy chcemy manipulować plikami np dodać do obrazu własne pliki lub wymusić konfigurację?
Można to robic na dwa sposoby. Jeden to edycja plików znajdujących się w
Cytat
./package/base-files/files
Dla przykładu chcemy zmodyfikować plik opkg.conf i dopisać tam własne repozytorium z paczkami ipk a więc wystarczy zmodyfikować plik:
Cytat
./package/base-files/files/etc/opkg.conf
i taki zmodyfikowany przez nas plik trafi to naszego wynikowego obrazu. Jednak modyfikując w ten sposób pliki narażamy się na parę problemów:
- co gdy ten pakiet zostanie zmieniony przez upgrade svn?
- po pewnym czasie pogubimy się, które pliki są oryginalne a które przez nas modyfikowane?
- co gdy chcemy dodać własne pliki, których nie ma w base-files?
Na te pytania rozwiązaniem jest drugi sposób na własne pliki w obrazie openwrt. Wystarczy stworzyć w katalogu ze źródłami katalog files i przyjąć go jako root "/" naszego openwrt. Teraz gdy chcemy zmodyfikować przykładowy opkg.conf wystarczy go umieścić w ./files/etc/opkg.conf. Taki plik trafi do obrazu zamiast tego z base-files.
Kolejny przykład: chcemy dodać nasz skrypt do openwrt i ma się znajnować w /sbin/. A więc tworzymy plik:
Cytat
./files/sbin/skrypt.sh
Pamiętajmy o nadaniu mu atrybutu "execute", wtedy w obrazie też będzie posiadał ten atrybut.
Dzięki umiejscawianiu modyfikowanych plików w ./files zamiast w ./package/base-files/ tworzymy całe drzewo naszych plików. Wiemy dokładnie, które pliki w naszym obrazie myśmy zmodyfikowali. Jednak i to rozwiązanie ma jeden mały minus - np zmodyfikowaliśmy ważny plik systemowy a nowsza wersja trunka wprowadza całkiem nową zawartość tego pliku, my nie zwrócimy na to uwagi. Nasz plik trafi do obrazu zamiast tego z trunka. Może to powodować do skompilowania obrazu, który może uwalić nasz router.
Gdzie w takim razie najlepiej trzymać zmodyfikowane pliki? Nie ma jednoznacznej recepty. Ja wszystkie pliki staram trzymać się w ./files. Są jednak pliki, które wolę modyfikować bezpośrednio w package. Dla przykładu plik /etc/preinit modyfikowałem (poprawiałem tryb failsafe by działał w tplinku) w base-files gdyż jest to jeden z najważniejszych plików openwrt. Ewentualny upgrade tego pliku może conajwyżej unieruchomić tryb failsafe. Jednak gdybym trzymał ten plik w ./files/ a uległby on zmianie, mógłbym tak wygenerowanym obrazem uwalić router co jest bardziej problematyczne niż niedziałający tryb failsafe.
Z czasem sami zauważycie, które pliki gdzie lepiej modyfikować.
VI. Tworzenie paczek, których nie ma w svn`ie
Czasami zdarza się, że potrzebujemy program, którego nie ma w svn`ie trunka ani w feeds`ach. Co wtedy? Odpowiedź - należy go sobie samemu skompilować Temat ten sam jeszcze "szlifuję" ale rzucę wam chociaż światło na to jak taką paczkę sobie przygotować.
Całość opiera się na przygotowaniu odpowiedniego pliku Makefile. To swego rodzaju szablon, który zawiera informacje jaki pakiet chcemy skompilować, skąd kompilator ma pobrać źródła pakietu oraz jak go skonfigurować i skompilować. Nie jest to łatwa sztuka, jednak do wielu pakietów można znaleźć gotowe pliki Makefile specjalnie przygotowane pod openwrt.
Chcąc stworzyć własny pakiet przechodzimy do katalogu packages i tworzymy w nim katalog z nazwą pakietu. Nastepnie w tym katalogu tworzymy plik Makefile. Możemy też opcjonalnie utworzyć dwa katalogi:
- patches - w tym katalogu znajdować się będą patche, którymi to możemy poprawić lub dostosować źródła pakietu przed ich kompilacją.
- files - tu możemy zamieszczać nasze pliki np konfiguracje, które chcemy by znalazły się paczce.
define Package/bridge
SECTION:=base
CATEGORY:=Network
DEFAULT:=y
TITLE:=Ethernet bridging configuration utility
DESCRIPTION:=Ethernet bridging configuration utility\\\
Manage ethernet bridging; a way to connect networks together to\\\
form a larger network.
URL:=http://bridge.sourceforge.net/
endef
Zmienne:
- PKG_NAME - nazwa pakietu, widoczna również w menuconfig
- PKG_VERSION - wersja pakietu
- PKG_RELEASE - wersja pliku makefile dla tego pakietu
- PKG_SOURCE -nazwa pliku ze źródłami
- PKG_SOURCE_URL - link do pliku ze źródłami
- PKG_MD5SUM -suma kontrola do weryfikacji poprawności ściągnietych źródeł
- PKG_CAT - czym rozpakować ściągniete źródła (zcat, bzcat, unzip)
- PKG_BUILD_DEPENDS - pakiety, które muszą być zbudowane przed tym pakietem. Podobnie działa zmienna DEPENDS.
@SF - specjalny skrót informujący kompilator, że źródła znajdują się na sourceforge
Definicje:
- SECTION - typ pakietu (obecnie nieużywane)
- CATEGORY - umiejscowienie w menuconfig
- TITLE - krótka informacja o pakiecie
- DESCRIPTION - pełna informacja o pakiecie
- URL - informacja skąd pobrać oryginalne źródła
- MAINTAINER - (opcjonalne) z kim się skontaktować w sprawie pakietu
- DEPENDS - (opcjonalne) zależności - które pakiety należy budować / zainstalowanać przed tym pakietem
Package/conffiles (opcjonalne) - lista plików instalowanych przez pakiet
Build/Prepare (opcjonalne) - zestaw poleceń do rozpakowania i patchowania źródeł
Build/Compile (opcjonalne) - parametry i zmienne z jakimi pakiet ma zostaw skonfigurowany przed kompilacją.
Package/install - definiuje zestaw skompilowanych plików i ich umiejscowienie w paczce wynikowej.
Package/preinst - skrypt, który zostanie wykonywany przed instalacją pakietu
Package/postinst - skrypt, który zostanie wykonywany po instalacji pakietu
Package/prerm - skrypt, który zostanie wykonany przed usunięciem pakietu
Package/postrm - skrypt, który zostanie wykonny po usunięciu pakietu
Na dole pliku Makefile znajduje się właściwa komenda BuildPackage. To makro, które wywołuje funkcję konfiguracji i kompilacji pakietu. Podajemy w tym miejscu tylko jeden parametr - nazwę pakietu (w tym przypadku bridge). Pozostałe informacje pobierane są ze zdefiniowanych wcześnej przez nas bloków.
Po przygotowaniu pliku Makefile wchodzimy w make menuconfig, odnajdujemy stworzony przez nas pakiet i oznaczamy M lub *, a następnie kompilujemy tak jak każdy inny pojedyńczy pakiet.
Ta część tutoriala była co prawda bardzo opisowa ale chodziło mi właśnie o przekazanie wam chociaz podstawowych informacji na temat budowy pakietu ze źródeł.
HAPPY END
Tym sposobem dotarlismy do końca tutorialu. Mam nadzieję, że dzięki niemu openwrt zyska większą liczbę zwolenników i developerów. Jak widać nie jest to przysłowiowa "czarna magia" i da się ta wiedzę poskromić. Teraz już każdy w domowym zaciszu może sobie zbudować własne openwrt B)
Temat będzie sukcesywnie uaktualniany i modernizowany o nowe informacje dotyczące kompilacji openwrt.
-----------------
Pozdrawiam
shibby
Edytowany przez shibby dnia 22-01-2010 23:43
Router:Unifi Cloud Gateway Max Switch:Netgear MS510TXPP Switch:Unifi USW-Flex-Mini - szt. 2 Wi-Fi:Unifi U6-Lite - szt. 2 Proxmox VE:i5-13400T, 64GB RAM, 2x 512GB NVMe, 3x 2TB SSD, Intel X710-DA2 SFP+ VM #1:Synology SA6400 VM #2:Debian, WWW VM #3: Home Assistant OS
shibby co znaczy konkretnie "stworzyć w katalogu ze źródłami katalog files i przyjąć go jako root "/" naszego openwrt." ?
Gdzie mam stworzyć katalog "files" i co zanczy "przyjąć" gdy mam układ np.:
/../Openwrt/trunk/
./svn
./bin
./build_dir
...
...
tam gdzie masz źródła trunka robisz katalog files. Co tam umieścisz będzie wkompilowane w firmware, dokładnie tak jak tam umieściłeś. Wiec jak zrobisz files/etc/gucio to pózniej będziesz na ruterze miał katalog /etc/gucio
No właśnie mi osobno libart też się kompiluje.
Natomiast osobno robiona paczka rrdtool wywala błąd.
Pierwsze linijki gdzie widać błąd (kompilacja rrdtool):
/usr/include/freetype2/freetype/ftglyph.h:558: error: expected declaration specifiers before 'FT_EXPORT'
In file included from /home/andrzej/Openwrt/trunk/staging_dir/target-mips_uClibc-0.9.30.1/usr//include/libart-2.0/libart_lgpl/art_affine.h:24,
from /home/andrzej/Openwrt/trunk/staging_dir/target-mips_uClibc-0.9.30.1/usr//include/libart-2.0/libart_lgpl/libart.h:4,
from rrd_gfx.h:14,
from rrd_gfx.c:25:
/home/andrzej/Openwrt/trunk/staging_dir/target-mips_uClibc-0.9.30.1/usr//include/libart-2.0/libart_lgpl/art_point.h:27: error: storage class specified for parameter 'ArtPoint'
/home/andrzej/Openwrt/trunk/staging_dir/target-mips_uClibc-0.9.30.1/usr//include/libart-2.0/libart_lgpl/art_point.h:29: warning: empty declaration
In file included from /home/andrzej/Openwrt/trunk/staging_dir/target-mips_uClibc-0.9.30.1/usr//include/libart-2.0/libart_lgpl/libart.h:4,
from rrd_gfx.h:14,
from rrd_gfx.c:25:
widze ze wszystkie pakiety zalezne kompilują się a wywala na końcu przy składaniu rrdtool.
Edytowany przez Tytan69 dnia 07-02-2010 17:15
@Shibby, jeśli Ci się spodoba, dodaj do swojego artykułu bezpośrednio. Myślę, że to dobre uzupełnienie Twojej pracy.
Pochwała ImageBuildera.
Narzędzie to jest prostym mechanizmem relizującym następujące kroki:
- budowa struktury katalogów na podstawie wybranych pakietów
- nałożenie na to wybranego katalogu
- budowa obrazu wynikowego
Co nam to daje? Kolejno:
- możliwość stworzenia obrazu z wbudowanymi, potrzebnymi nam pakietami
- konfugurację na poziomie wgrywanego obrazu. Wydaje się, że to niewiele, ale tak nie jest. Poza zintegrowaniem z obrazem pliku /etc/passwd (z ustawionym hasłem) czy innymi powtarzalnymi czynnościami ja konfiguruję od razu sieć (muszę mieć podany mac-adres) co pozwala mi
wgrywać obraz spoza lanu routera i widzieć go po takiej operacji. Oczywiście nie jest to zalecany sposób flaszowania ;)
- gotowy obraz do wgrania, co oczywiste.
Czwartą korzyścią jest czas tworzenia obrazu. O ile kompilacja OpenWRT trwa długo, to przepakowanie kilkunastu czy kilkudziesięciu plików i kilka kopiowań to w najgorszym razie pół minuty. Przy częstych kombinacjach zysk jest ogromny.
Jak to zrobić?
Po pierwsze trzeba skompilować ImageBuildera na poziomie głównego menu kompilacji OpenWRT. Po skompilowaniu otrzymujemy w katalogu bin archiwum zawierające ImageBuildera a w nim komplet zaznaczonych pakietów.
Teraz trzeba to sobie gdzieś rozpakować. Potem przygotować _strukturę_ _katalogów_ z plikami do podmiany/dodania. A na końcu wywołać make z odpowiednimi parametrami.
No to przykład z utworzeniem obrazu zawierającym pakiet ntpclient i ustawionym hasłem roota.
Ponieważ zaraz podam skrypt ułatwiający całą procedurę, będę się opierał na przykładzie własnego systemu plików.
Projekt OpenWRT mam w /mnt/hd/asus/2.4/8.09. 8.09 to katalog projektu pobrany z SVN a w nim w bin leży
OpenWrt-ImageBuilder-brcm-2.4-for-Linux-i686.tar.bz2 :)
Więc zakładam katalog /mnt/hd/asus/2.4/extra
i dalej /mnt/hd/asus/2.4/extra/etc
Do tego ostatniego kopiuję plik /etc/passwd z routera (tam jest hasło, chyba że masz /etc/shadow, ale pewnie nie masz).
Dalej. Zakładam katalog /mnt/hd/asus/2.4/ibuilder i do niego rozpakowuję wspomniane wcześniej archiwum. Tutaj uwaga, bezpośrednie rozpakowanie archiwum założy jakiś taki katalog typu OpenWrt-ImageBuilder-brcm-2.4-for-Linux-i686, ale ja go zawsze skracam do ibuilder.
I mając to wszystko możemy wywołać make z katalogu ibuilder z odpowiednimi parametrami:
FILES - katalog ze strukturą katalogów, u nas FILES="/mnt/hd/asus/2.4/extra/"
PACKAGES - lista paczek do dodania do obrazu, u nas PACKAGES="ntpclient"
Gotowe wywołanie:
cd /mnt/hd/asus/2.4/ibuilder
make clean image PACKAGES="ntpclient" FILES="/mnt/hd/asus/2.4/extra/"
a potem zaglądamy do /mnt/hd/asus/2.4/ibuilder/bin ;)
Mój plik automatyzujący całą operację. Sprawdza, czy jest nowa wersja IBuildera, przydaje się po przekompilowaniu OpenWRT, na przykład jak zmienimy parametryzację BusyBoxa albo wykonamy svn up.
Jeśli jest nowszy to rozpakowuje do katalogu ibuilder (z całym tym cudowaniem z katalogami). Ostatecznie wywołuje make do tworzenia obrazu (mam przygotowany pod obsługę USB i zewnętrzny dysk). Na samym dole zaremowany gratis dla wielbicieli interfejsów graficznych.
Od tej pory już nie musimy się prosić Obsego o jakieś konkretne obrazy, możemy je zrobić samemu.
Powodzenia!
P.S. Mam kiepskie doświadczenia z załączania plików na forum, dlatego równolegle załączam link do źródła skrytpu: http://wklej.org/id/275916/
Wadą IBuildera :-) jest to ze trzeba przekompilowac wszystkie pakiety.
Pozdrawiam, Artur http://digi-led.pl Elementy elektroniczne | urz?dzenia sieciowe | us?ugi informatyczne http://openwrt.pl - Polskie Centrum OpenWrt o p e n (your) r o u t e r . p l
@Tytan troche nie jestem w temacie na jaka platforme kompilujesz openwrt ale polecam regule malych kroczkow. Sciagnij sobie trunka+feeds, zrob czysty config (nie uzywaj od kogos) i zobacz czy ci sie kompiluje wszystko dobrze. Pozniej dodawaj stopniowo to co chcesz i potrzebujesz
Router:Unifi Cloud Gateway Max Switch:Netgear MS510TXPP Switch:Unifi USW-Flex-Mini - szt. 2 Wi-Fi:Unifi U6-Lite - szt. 2 Proxmox VE:i5-13400T, 64GB RAM, 2x 512GB NVMe, 3x 2TB SSD, Intel X710-DA2 SFP+ VM #1:Synology SA6400 VM #2:Debian, WWW VM #3: Home Assistant OS
Mam na myśli ze jak uzywasz np trunka i chcesz skompilowac ImageBuilder to automatycznie zaznaczane są wszystkie pakiety!! nie ważne czy bedziesz je dodawał do swego obrazu czy nie.
Mam nadzieje ze sie nie myle :-)
Pozdrawiam, Artur http://digi-led.pl Elementy elektroniczne | urz?dzenia sieciowe | us?ugi informatyczne http://openwrt.pl - Polskie Centrum OpenWrt o p e n (your) r o u t e r . p l
W trunku i wersji stabilnej inaczej to działa. Nie jestem pewien jak w której. Ale faktycznie coś takiego jest, albo coś podobnego. Zresztą nie tylko w odniesieniu do Image Buildera ale wyjściowy zestaw zaznaczonych pakietów jest różny.
Z drugiej strony takie zaznaczanie wszystkich pakietów jest logiczne, gdyż ImageBuilder MUSI miec binarki pakietów jakie chcemy uzyć w swoich obrazach.
Pozdrawiam, Artur http://digi-led.pl Elementy elektroniczne | urz?dzenia sieciowe | us?ugi informatyczne http://openwrt.pl - Polskie Centrum OpenWrt o p e n (your) r o u t e r . p l
shibby napisał/a:
@Tytan troche nie jestem w temacie na jaka platforme kompilujesz openwrt ale polecam regule malych kroczkow. Sciagnij sobie trunka+feeds, zrob czysty config (nie uzywaj od kogos) i zobacz czy ci sie kompiluje wszystko dobrze. Pozniej dodawaj stopniowo to co chcesz i potrzebujesz
Na WRT160NL.
Zmieniam system na ubuntu bo doszełem że to wina mandrivy a szukać co jest nie tak już mam dosyć
· Łącznie użytkowników: 24,115 · Najnowszy użytkownik: Ja
Czat
Musisz się zalogować, aby opublikować wiadomość.
Maniek91PL
06-11-2024 22:37
dzięki !
maxikaaz
29-10-2024 14:27
@Maniek91PL - Administration=> Admin Access, i tam masz "Allow Wireless Access" do zaznaczenia
Maniek91PL
26-10-2024 22:07
siemka! ktoś przypomni co się ustawiało jeśli nie mogę wejść od strony wifi do tomato? od lan działa
overflow2
04-10-2024 17:34
Kupowałem Asusy n10u albo n12d1 ale nie widzę ich, chyba już nie produkują, Chodzi o coś nowego i taniego. Transfery niewielkie.
maxikaaz
04-10-2024 09:38
@overflow2 patrząc po dostępności funkcji w nowych kompilacjach, to chyba nawet WRT54G/GL jeszcze ma OpenVPN, albo jakiś odpowiednik... zależy, na jakie transfery liczysz.
overflow2
30-09-2024 20:53
Jaki aktualnie najtańszy router do tomato do openvpn?
maxikaaz
27-07-2024 15:07
@servee - na początek router do rozebrania i obejrzenia, ciężko wróżyć tak tylko po objawach
maxikaaz
27-07-2024 14:55
@servee - cały kontroler nie pada tak sobie z powodu "zbiegu okoliczności", więc prawdopodobnie gdzieś przepięcie.
servee
25-07-2024 13:33
@maxikaaz: działało, aż pewnego pięknego dnia przestało działać. W tym dniu była też burza, ale to raczej zbieg okoliczności.
maxikaaz
25-07-2024 11:38
@servee - o ile problem jest w obrębie samych wyjść (dławiki, warystory), to naprawialne, ale jeśli w samym SoC - to nienaprawialne ze względu na koszta. A co było przyczyną?
' target='_blank'>Link
Dużo pracy i brak czasu zmusiło mnie do zmiany tematu na prostszy, chociaż pomocny i nigdzie dokładnie nie opisany. Wiele osób codziennie pyta mnie o informacje odnośnie kompilacji własnego openwrt. Dało mi to myślenia, że taki artykuł jest potrzebny. Poznanie tej wiedzy zajęło mi prawie miesiąc (a obsego dużo cierpliwości - wielkie dzięki obsy). Podzielę się tą wiedzą z innymi.
