Kernel bauen

[MReimer]

Als ist es tatsächlich möglich einen Kernel selber zu bauen (obwohl das Wiki da noch unklare Infos gibt)? Wenn ja: Ist es ohne größere Probleme machbar netfilter und somit iptables zu aktivieren?

 

[olistudent]

Wenn du einen Kernel für Linux kompilieren kannst,
sollte dich das vor keine größeren Probleme stellen.
Wobei ich bis jetzt den Verdacht habe, dass AVM die Pakete vor dem netfilter-hook abgreift.
Es gab ja mal das Problem mit den 2er dboxen und da ist der multid auch abgestürtzt, wenn man das Paket gedroppt hat...

MfG Oliver

 

[MReimer]

Ich habe noch nicht allzuviel Zeit mit dem Thema "Kernel kompilieren" verbracht. Wäre hilfreich wenn das vorher jemand mit mehr Erfahrung getestet hätte (Bedarf an netfilter scheint ja da zu sein da ich nicht als einziger frage und auch schon in anderen Themen gefragt wurde).

 

[olistudent]

Da musst du pfeffer fragen.
Der hat/hatte iptables in seinem Image...

MfG Oliver

 

[supamicha]

hallo oli,

kannst du das mksquashfs mit lzma bitte hier online stellen ?

micha

 

[olistudent]

Ja, mach ich.
Sobald ich es wieder habe...
Dazu brauchst du aber einen passenden Kernel!

MfG Oliver

 

[danisahne]

Ich hab iptables laufen, hab aber noch nicht so viel damit rumgetestet. Wann stürzt multid ab?

In der INPUT Chain hab ich schonmal ein wenig gefiltert und das klappte auch.

 

[olistudent]

Mit aktuellen Images sollte das nicht mehr passieren.
War nur ein Beispiel.

MfG Oliver

 

[owb]

ich hab grad selbst einmal probiert einen eigenen Kernel zu erstellen.
Einen Compiler habe ich mir mit folgendem Script erstellt: crosstool (gcc-3.3.2-glibc-2.3.2)
Allerdings ist auch hier das resultierende Image deutlich groesser als das Original. Ich habe auch nichts an der Konfiguration geaendert.

Wow, da muss ich mich wohl korrigieren.
Man muss im Makefile lediglich das -Os ergaenzen und der resultierende Kernel ist bis aufs byte gleich gross!
Jetzt bin ich mal gespannt ob das mit ipv6 noch klappt. Das Modul laed jedenfalls schonmal.

 

[danisahne]

Danke für die Info. Dann wäre das auch mal endlich geklärt. Hast du auch Byte-weise verglichen bzw. mit einer Hashfunktion? D.h. ist der resultierende Kernel exakt der selbe?
Bei mir läuft er mit -O2 und lzma. Ohne lzma ist er 30KB zu groß, mit lzma ist massig Platz im Kernel

Damit braucht man zum reproduzieren des Kernels:
* gcc-3.3.2
* glibc-2.3.2
* -Os

Auch getestet (squashfs mit mksquashfs-lzma):
* gcc-3.3.2
* glibc-2.3.2
* lzma patch
* -O2

Was wurde sonst noch erfolgreich getestet?

 

[owb]

Hast du auch Byte-weise verglichen bzw. mit einer Hashfunktion? D.h. ist der resultierende Kernel exakt der selbe?

Nein, genauer habe ich nicht verglichen.
Hash wuerde auch nichts bringen da ja Daten und Namen vom Kompilerlauf anders sein duerften als im Original.
Dazu muesste man wohl ein binaeres diff nutzen.

Lzma habe ich zumindest mit den buildsachen von AVM (make-kernel.sh) nicht hinbekommen.
(7zip rein kopiert und im Makefile "./" ergaenzt, Option im Kernel auf "y" gesetzt)
Aber ich denke das mag daran liegen das die buildscripte nicht darauf ausgelegt sind.

Leider funktioniert ipv6 nicht ganz so wie ich mir das vorgestellt habe....
Kommunikation mit dem Lan funktioniert.
Aber anscheinend hat der Kernel aufgrund von AVMs bastelei keine Moeglichkeit einen Tunnel (sit, protocol 41) aufzubauen. Jedenfalls gehen keine Daten nach aussen raus und die Konfiguration der lokalen IP des Tunnels ist auch nicht ganz eindeutig....
Schade eigentlich.

Falls jemand selbst einmal testen Moechte kann ich ihm ja den Kernel, das Modul und ein passendes "ip" zur Konfiguration zusenden.

 

[danisahne]

Ich benutze nur das Unterverzeichnis 'GPL'. Dort mußt du die 7Z Option in die Config.4mb reinschreiben, da mit dieser bei jedem make die Kerneloptionen überschrieben werden (glaube so war das). Ich nehm eigene Skripte um das kernel.image wieder zusammenzubasteln.

Hash wuerde auch nichts bringen da ja Daten und Namen vom Kompilerlauf anders sein duerften als im Original.
Dazu muesste man wohl ein binaeres diff nutzen.

Achso, einleuchtend. Kenn mich nicht so ganz mit den Innereien eines Compilers aus.

Mfg,
Daniel

 

[owb]

Ich benutze nur das Unterverzeichnis 'GPL'. Dort mußt du die 7Z Option in die Config.4mb reinschreiben, da mit dieser bei jedem make die Kerneloptionen überschrieben werden (glaube so war das). Ich nehm eigene Skripte um das kernel.image wieder zusammenzubasteln.

Klasse, wenigstens das klappt bei mir jetzt auch.
Die Option hatte ich beim letzten Test dort natuerlich auch gesetzt. Allerdings habe ich die Option fuer gzip nicht rausgeworfen (weiss nicht obs daran lag). Ausserdem war in dem Patch der hier gepostet wurde in der inflate.c eine Zeile anders wleche ich jetzt auch uebernommen hab (vielleicht wars auch das).

 

[olistudent]

Hi.
Mit der original Zeile hab ich's nicht zum Laufen gekriegt.
Da ist vor dem Decompress immer ein Fehler gekommen.
Dann hab ich noch lzma aus dem openwrt probiert und das ging auch nicht...

MfG Oliver

 

[owb]

Leider funktioniert ipv6 nicht ganz so wie ich mir das vorgestellt habe....
Kommunikation mit dem Lan funktioniert.
Aber anscheinend hat der Kernel aufgrund von AVMs bastelei keine Moeglichkeit einen Tunnel (sit, protocol 41) aufzubauen. Jedenfalls gehen keine Daten nach aussen raus und die Konfiguration der lokalen IP des Tunnels ist auch nicht ganz eindeutig....

Nur als Ergaenzung: mittlerweile funktioniert es doch. Fehler war einfach dass ich vergessen habe das Forwarding fuer ipv6 zu aktivieren.
Die konfiguration der lokalen IP scheint fast egal zu sein. Es hat sowohl mit der Lan ip als auch mit der IP vom dsl device funktioniert.

 

[danisahne]

Hallo,

habe eben versucht, meinen lzma Kernel in die .03.85er Firmware einzubauen. Danach bootet die Box alle 5 Sekunden neu... den Rest kennt ihr ja. Neue Kernelsourcen sind nicht online. Mir ist aufgefallen, dass die Blockgröße des squashfs nun 65536 ist (vorher 16384). Kann es sein, dass da etwas mit dem squashfs schief läuft? Wenn den Kernel der Firmware nicht anrühre, dann funktioniert meine gemoddete Firmware noch (wenn ich zusätzlich dazugemoddete Daemonen weglasse, weil lzma und damit der Platz fehlt).

Mfg,
Daniel

 

[danisahne]

Hallo,

ich hab die neue Firmware .03.85 mit den AVM Sourcen vom Juni zum Laufen gebracht. Grund war die maximale Blockgröße von squashfs in den Kerneloptionen. Der Parameter muss auf 0x10000 (also 65536) hochgestellt werden. Mir ist dann aber gleich aufgefallen, dass der orignal Kernel der neuen Firmware ein wenig größer ist als mein selbstgebastelter. Schließlich merkte ich, dass kein dsld Daemon mehr lief. Die Ausgabe vom dsld möcht ich euch nicht vorenthalten:

~ # dsld -d
2002-09-08 14:03:03 dsld: csock: using poll
Sep  8 14:03:03 dsld[872]: csock: using poll
2002-09-08 14:03:04 dsld: startup (Sep 30 2005 12:51:59)
Sep  8 14:03:04 dsld[872]: startup (Sep 30 2005 12:51:59)
~ # Sep  8 14:03:04 dsld[874]: DSL Mac xx:xx:xx:xx:xx:xx
Sep  8 14:03:04 dsld[874]: VOIP Mac xx:xx:xx:xx:xx:xx
Sep  8 14:03:04 dsld[874]: Can't open /dev/kdsld - No such file or directory (2)
Sep  8 14:03:04 dsld[874]: warning: nothing to do, BUG ?
Sep  8 14:03:04 voipd[395]: connstatus 3 -> 0
Sep  8 14:03:05 dsld[874]: BUDGET led: off
Sep  8 14:03:05 dsld[874]: warning: nothing to do, BUG ?
Sep  8 14:03:05 cltmgr[319]: box_led_update_status
Sep  8 14:03:05 cltmgr[319]: got led event 18
Sep  8 14:03:05 voipd[395]: connstatus 0 -> 3
Sep  8 14:03:06 dsld[874]: warning: nothing to do, BUG ?
Sep  8 14:03:07 dsld[874]: ioctl(KDSLD_UNSETUP): failed - Bad file descriptor (9)
Sep  8 14:03:07 dsld[874]: ioctl(KDSLD_TS_DESTROY): failed - Bad file descriptor (9)
Sep  8 14:03:07 dsld[874]: StatisticExit
Sep  8 14:03:07 dsld[874]: StatisticFlushToFlash

Das, was meiner Meinung nach wichtig ist, hab ich fett gemacht: Can't open /dev/kdsld - No such file or directory. Da hat AVM anscheinend wieder am Kernel rumgearbeitet. Keine schlechte Idee, mal wieder den Support zu fragen, wann die neuen Kernel Sourcen online sind.

Gruß,
Daniel

 

[owb]

Mir ist dann aber gleich aufgefallen, dass der orignal Kernel der neuen Firmware ein wenig größer ist als mein selbstgebastelter.

ca. 8k

Das, was meiner Meinung nach wichtig ist, hab ich fett gemacht: Can't open /dev/kdsld - No such file or directory. Da hat AVM anscheinend wieder am Kernel rumgearbeitet. Keine schlechte Idee, mal wieder den Support zu fragen, wann die neuen Kernel Sourcen online sind.

Hast du nur den Kernel ausgetauscht und die module der Firmware dazu gepackt?
Hast du einmal nachgesehen ob alle Module geladen werden?

Sollten beide Punkte zutreffen wuerde ich fast schwarz sehen wollen dass die Quellen dann keinen lauffaehigen Kernel mehr hergeben werden.
Sieht fast danach aus als haette AVM eines ihrer Module in den Kernel gepackt und dafuer werden die sicher keine Quellen hergeben (auch wenn ich mir garnicht sicher bin ob das zulaessig ist....)

Naja, was solls - ich hab die neue Firmware mal ausgetestet und konnte eh nichts gross neues feststellen. Abgesehen davon dass die Funktionen auf dem ISDN Port viel umfangreicher sind. Aber darauf kann ich dann auch verzichten....

 

[danisahne]

Hi owb,

ich habe nur das ram_zimage.bin ersetzt. War das Device /dev/kdsld im alten Kernel schon vorhanden? Hab jetzt bis zum nächsten Wochenende leider keine Fritzbox parat.

Auch in dem erfolgreich gebauten Kernel für die .03.71er Firmware sind glaube schon nicht Quell-offene Teile enthalten, die statisch gegen den Kernel gelinkt werden. Ob diese Teile GPL sind, da scheiden sich so weit ich weiß die Geister, aber der Rest der Linux Sourcen sind GPL und damit ist AVM verpflichtet sie rauszurücken. Fragt sich nur, wie lange das dauern wird. Ich habe den Support schon angeschrieben. Wenn das vielleicht der ein oder andere von euch auch macht...

Mfg,
Daniel

 

[owb]

ich habe nur das ram_zimage.bin ersetzt. War das Device /dev/kdsld im alten Kernel schon vorhanden? Hab jetzt bis zum nächsten Wochenende leider keine Fritzbox parat.l

Das device ist auf keinen Fall in einem normalen Kernel vorhanden.
Es kann daher nur von einer AVM eigenen Aenderung am Kernel oder von einem AVM eigenen Modul kommen.

Hier ist zum Glueck letzteres der Fall.
Dem Modul "kdsldmod" fehlte das Symbol "br2684_ioctl_hook". Das entsprechende Modul ist zwar im Kernel vorhanden allerdings scheint AVM dort etwas gedreht zu haben so dass das Symbol auch bei "einkompiliertem" Modul exportiert wird.

Bei mir funktioniert es jetzt wenn ich im "net/atm/common.c" die Zeile 69 so aendere:

#if defined(CONFIG_ATM_BR2684) || defined(CONFIG_ATM_BR2684_MODULE)

Auch in dem erfolgreich gebauten Kernel für die .03.71er Firmware sind glaube schon nicht Quell-offene Teile enthalten, die statisch gegen den Kernel gelinkt werden.

Das ist schon richtig. Die Quellen enthalten nur "offene" Teile. Aber dort ist es auch der Fall das die geschlossenen Teile nicht direkt im Kernel landen wo ich mir ziemlich sicher bin dass das auch nicht zulaessig waehre.
Als zu ladendes Modul ist das nicht so problematisch.