ds-0.2.9_26-14.2

Status
Für weitere Antworten geschlossen.
Hi Alexander,

bei beiden Fedora-Installationen ist wget in Version GNU Wget 1.10.2 (Red Hat modified) installiert. Beide Systeme sind patch-mäßig auf neuestem Stand.

gelinkt bei Fedora Core 6 (64-bit Installation) gegen:
Code:
        libssl.so.6 => /lib64/libssl.so.6 (0x0000003cb0c00000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0000003f2cc00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003f21000000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x0000003f22800000)
        librt.so.1 => /lib64/librt.so.1 (0x0000003f26000000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003f20800000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003cafc00000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003cb0800000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003f2c400000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000003cb0400000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003f1f800000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f21400000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003cb0000000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003f2b800000)

gelinkt bei Fedora Core 4 (32-bit Installation) gegen:
Code:
        linux-gate.so.1 =>  (0x00471000)
        libssl.so.5 => /lib/libssl.so.5 (0x0062b000)
        libcrypto.so.5 => /lib/libcrypto.so.5 (0x006ff000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00813000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0068b000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00626000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00665000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00611000)
        libdl.so.2 => /lib/libdl.so.2 (0x00b09000)
        libz.so.1 => /usr/lib/libz.so.1 (0x005e8000)
        librt.so.1 => /lib/librt.so.1 (0x00a54000)
        libc.so.6 => /lib/libc.so.6 (0x00490000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0080e000)
        /lib/ld-linux.so.2 (0x00472000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x005fd000)
 
hm, mir ist grad nochwas aufgefallen, hat jetzt aber wahrscheinlich direkt nix mit dem ds-mod zu tun, eher wie avm die dsl-verbindung behandelt. Früher konnte ich mit "ip adress" meine aktuelle externe IP sehen, das funktioniert nicht mehr. Seit wann das so ist weiß ich nicht. Gibts da noch eine andere Möglichkeit (außer mit externen Scripts oder Diensten wie myip.com)?
 
@kriegaex: Danke für deine ausführliche Erklärung über Dateisystem. Jetzt wird mir einiges klar.
kriegaex schrieb:
...eine genaue Fehlermeldung und ein angehängtes Log mit Verbosity Level 2 vom make auch geholfen...
Nein ist nicht nötig. "Zu groß" wird das Image insgesamt, was dazu in einzelnem und wie beiträgt, kann man zwar mit etwas Umstand erfahren, es bringt aber nichts. Da muss ich wirklich die Pakete abwählen.

Und hier habe ich eine Bitte an dich, packe bitte in dein Intro auf der ersten Seite diesen Link zu wiki

http://wiki.ip-phone-forum.de/software:ds-mod:pakete:start

mit einer dringenden Empfehlung sich den Inhalt dieser Seite vor "make menuconfig" zu studieren. Mittlerweile verliere ich schon den Überblick über alle Pakete (und ich bin schon mehr als ein Jahr hier), was kann man dann von einem Newbee erwarten.

Ich bitte auch die Autoren der neuen Pakete, ihre Pakete entsprechend auf dieser WIKI-Seite einzutragen (falls noch nicht geschehen). "telefon" sollte dort übrigens längst ein "obsolete" bekommen. Nicht schlecht wäre, wenn man daneben noch ungefähre Angaben zu Paketgröße geben würde. Ich weiß, es ist abhängig von Bibliotheken, Kompilieroptionen usw., aber in der Art 10...20kB würde vielen hier die Auswahl erleichtern.

kriegaex schrieb:
Dateisystem-Blockgröße von 64 KB
Das ist mein Hauptproblem. Daran hatte ich gar nicht gedacht. Und du hast Recht
kriegaex schrieb:
...sind es gerade mal 16,8 KB
eben gerade sie haben mir zufälligerweise damals bei 7050 gereicht um diese 64KB-Grenze zu überspringen. Diesmal hatte ich Pech.
kriegaex schrieb:
Gestrippte Binaries machen gleich viel mehr aus
Ja schon, aber Pakete erhalten nicht nur Binaries, so dass ich es so nicht pauschalisieren würde. Damals mit 7050 hat das deaktivieren der Clientfunktion im Dropbear nichts gebracht, löschen der Brandings dagegen schon.

MfG

Hermann
 
Wiki-Link eingefügt

Okay, ich habe also einen Wiki-Link eingefügt, wenn auch nicht Deinen, der sowieso ungültig war, sondern den zur Hauptseite. In der Thread-Liste dieses Forums steht zwar seit Ewigkeiten ein Wichtig: [Wiki] Dokumentation des danisahne-mod von danisahne, aber egal, war ja keine Arbeit.
 
"make" nach "make clean"

Es gibt eine Fehlermeldung, die beim ersten "make" oder "make precompiled" nach einem "make clean" oder "make distclean" ausgegeben wird. Wenn man danach den Aufruf wiederholt, läuft "make" oder "make precompiled".

Die Meldung lautet (abgeschrieben):
Code:
...
AR   util-linux/built-in.o
LINK busybox_unstripped
make[1]: Leaving directory `/home/bofh..../source/busybox-host/busybox-1.4.1'
cp source/busybox-host/busybox-1.4.1/busybox tools/busybox
ln: ,,tools/makedevs": Datei existiert
make: *** [tools/busybox] Fehler 1
MfG
Hermann
 
Danke für die Info. Nach make clean kann das sein, denn da wird nur das clean der Tools-Busybox aufgerufen, der Makedevs-Link wird nicht entfernt. Bei make distclean aber schon, da sollte das nicht passieren. Ich korrigiere das.

Update: gefixt und eingecheckt (alter Fehler).
 
Zuletzt bearbeitet:
Hab heute ohne Probleme (und super schnell) mit FriBoLi 0.4 den Mod -14.2 compiliert und geflasht. Läuft super (siehe Signatur)!

Vielen Dank an alle Mitwirkenden!! :rock:
 
download Probleme wegen Proxy?

Ich sitz hier hinter einem Proxy der Anfragen auf Port 8080 erwartet.
Bei "make precompiled" erhalte ich:
Code:
/ds-0.2.9_26-14.2> make precompiled
wget -P dl http://dsmod.wirsind.info/precompiled/kernel-toolchain-dsmod-0.1.tar.lzma || \
        wget -P dl http://friboli.3dfxatwork.de/kernel-toolchain-dsmod-0.1.tar.lzma
--17:35:09--  http://dsmod.wirsind.info/precompiled/kernel-toolchain-dsmod-0.1.tar.lzma
           => `dl/kernel-toolchain-dsmod-0.1.tar.lzma'
Auflösen des Hostnamen »dsmod.wirsind.info«.... 85.214.27.242
Verbindungsaufbau zu dsmod.wirsind.info|85.214.27.242|:80... fehlgeschlagen: Keine Route zum Zielrechner.
--17:35:09--  http://friboli.3dfxatwork.de/kernel-toolchain-dsmod-0.1.tar.lzma
           => `dl/kernel-toolchain-dsmod-0.1.tar.lzma'
Auflösen des Hostnamen »friboli.3dfxatwork.de«.... 85.214.49.66
Verbindungsaufbau zu friboli.3dfxatwork.de|85.214.49.66|:80... fehlgeschlagen: Keine Route zum Zielrechner.
make: *** [dl/kernel-toolchain-dsmod-0.1.tar.lzma] Fehler 1

Liegt das an dem Proxy? Surfen kann ich, da der Proxy im Browser eingestellt ist, benutze Suse10.2.
 
Na klar, wget fragt standardmäßig über Port 80. Muß mal nachschauen, wie man das Busybox-wget dazu kriegt, einen Proxy zu benutzen. Es gibt zwar einen Schalter dafür...
Code:
-Y      use proxy ('on' or 'off')
... aber welche Umgebungsvariablen man setzen muß, damit er ihn auch benutzt, steht nicht in der Doku. Man kann es mit denen vom "großen" wget auf Standardsystemen probieren, schau mal in die Manpage. Ich gucke inzwischen mal kurz in den Quellcode und editiere diese Nachricht anschließend.

Edit: Denkfehler: Du bist ja am Build-System, nicht auf der Box. Also hast Du ja das normale wget. (Oh Mann!) Macht nix, war trotzdem mal interessant nachzuschauen. Ebenfalls http_proxy bzw. ftp_proxy. Authentikation an Proxy und Server wird ebenfalls unterstützt, wenn das in busybox-menuconfig angekreuzt wird. Und es ist angekreuzt im DS-Mod.
 
Zuletzt bearbeitet:
bigfrog schrieb:
Ich sitz hier hinter einem Proxy der Anfragen auf Port 8080 erwartet.
Dann musst Du vor make etc. den Proxy setzen. z.B. so:

Code:
export http_proxy=http://meinproxy.meinedomain.de:8080/

Dirk
 
Achtung: Iptables wird *immer* in die Firmware eingebaut

Leicht modifiziertes Zitat aus meinem jüngsten Update unter "Probleme" bei Posting #1:

:!: Wichtig: Bei make precompiled wird immer das Iptables-Binary gebaut und - schlimmer - beim Firmware-Bauen auch immer eingebaut. Gerade bei kleineren Boxen wie 5050/7050 kann das die entscheidenden KBs ausmachen, ob die FW zu groß ist oder nicht. (uralt, ist jetzt erst aufgefallen, in Bearbeitung)

Temporärer(!) Workaround: in fwmod die Zeile
Code:
"$TAR" -cf - -C "${KERNEL_REP_DIR}/root" --exclude=lib --exclude=usr/lib \
suchen und
Code:
--exclude=usr/sbin/iptables
einfügen (vor dem abschließenden Backslash!).

Danke an dsteinkopf, der mich darauf aufmerksam gemacht hat. Ich denke, es wird ein globales Setting für Iptables geben müssen, das dem ein Ende bereitet. Denn wenn die Bibliotheken nicht in der FW sind (das läuft korrekt), wozu dann das Binary?
 
Hallo,

bei mir startet der syslogd nicht. In /var/log/mod.log steht "...Starting syslogd...failed...".
Ich habe mir rc.syslogd mal in die ramdisk kopiert und mit "set -x" versehen:

Der Fehler ist, dass zwischen der Option "-C" und dem Parameter kein Leerzeichen stehen darf (Zeile 37 bei mir).

Habs ausprobiert: Nach Änderung der Datei ./packages/syslogd-cgi-0.2/root/etc/init.d/rc.syslogd und Neubauen der Firmware gehts wieder. (War das der richtige Weg?)

Dirk
 
iptables geht nicht

Nochwas:
Die Frage nach iptables kam ja schon ein paar Mal, aber ich kann mich nicht an eine positive Antwort erinnern. Ich habe das Problem etwas eingekreist:

"insmod /lib/modules/2.6.13.1-ar7/kernel/net/ipv4/netfilter/ip_tables.ko" liefert einen Fehler. Die wesentliche Meldung im dmesg ist dabei

ip_tables: Unknown symbol request_module

Dabei scheint mir "request_module" eine relativ "basic" Funktion des Kernels zu sein.

Kann da jemand was zu sagen?


Dirk
 
Sorry, jetzt sehe ich, dass es doch schon mal eine Antwort von olistudent gab:
olistudent schrieb:
@fant
Entweder nimmst du den selbst gebauten Kernel. Oder du musst die Module neu bauen. Und zwar musst du im kernel-menuconfig die Option für das automatische Laden von Modulen deaktivieren (CONFIG_KMOD=y).

Allerdings verstehe ich das nicht:
Warum geht das nicht von selbst? Ist das ein Bug im ds-mod?
Warum muss ich den Kernel neu bauen?
Was heißt "oder du musst die Module neu bauen" - sind sie das nicht durch make precompiled?

Totale Verwirrung.


Dirk
 
Neuen User auf der Box erstellen

Hi,


ich habe mal versucht, einen eigenen User auf die Box zu bringen. Dazu habe ich mal in das script /usr/bin/modpasswd geschaut. Ich habe dann mit 'modpasswd load' die passwd und die shadow nach /var/tmp geholt, habe je eine Zeile eingebaut:
bodo:x:2:1:bodo:/mod/home/bodo:/bin/sh
bodo:*:12332:0:99999:7:::
Dann habe ich diese mit 'modpasswd save' zurück geschrieben. Ich habe ein Verzeichnis angelegt '/mod/home/bodo' und die Eigentumsverhältnisse angepasst mit 'chmod -R bodo.users /mod/home/bodo'. Zum Schluss habe ich mit 'modpasswd bodo' ein Kennwort vergeben. Am Schluss habe ich die Box völlig neu gestartet und nachgesehen, was davon noch da ist. Es ist zu meinem Erstaunen alles noch da. Ich habe noch nicht so ganz raus, wann etwas einen Neustart überlebt.

Wenn ich versuche, mich per ssh mit dem neuen User anzumelden, dann kommt die Passwort-Abfrage immer wieder, aber keine shell. Ich habe es vom Computer und von der Box (als root) mit ssh auf localhost versucht. Ich habe nachgesehen, ssh mit passwort ist bei dropbear zugelassen. Leider habe ich kein logfile gefunden. syslog habe ich nicht installiert (sollte ich vielleicht mal machen :D). Hat jemand eine Idee?:noidea:


Gruß
Kai
 
Zuletzt bearbeitet:
@dsteinkopf: Bei mir startet der Syslogd und hat in der genannten Zeile auch ein Leerzeichen. Kannst Du bitte nochmal überprüfen, ob Du da evtl. manuell etwas geändert haben könntest? Am besten schaust Du mal ins Download-Paket unter dl/syslogd-cgi-0.2-dsmod.tar.bz2.

Zu Iptables: Was Oliver in dem anderen Post (den ich erst mal suchen mußte) meinte, war, daß Du die Module nochmal neu bauen sollst, nachdem Du CONFIG_KMOD deaktiviert hast.
 
@dsteinkopf
Danke, das herunterladen hinter dem Proxy funktioniert!
Kannst du mir erläutern was die Zeile "macht"? Oder wo ich das nachlesen kann?

Gruß
bigfrog
 
Code:
export http_proxy=http://meinproxy.meinedomain.de:8080

Schrittweise:
  • export sorgt dafür, daß die Umgebungsvariable http_proxy dem aufgerufenen Prozeß (wget) bekannt ist.
  • Wget weiß, daß in genau dieser Variablen drin steht, wie der Proxy heißt (meinproxy.meinedomain.de) und auf welchem sog. Port (8080) er auf eingehende Client-Verbindungen wartet.

Ansonsten: man wget
 
Nochmal dazu:

dsteinkopf schrieb:
Der Fehler ist, dass zwischen der Option "-C" und dem Parameter kein Leerzeichen stehen darf (Zeile 37 bei mir).

Nachdem wir das Mißverständnis privat geklärt haben (nicht kein Leerzeichen ist der Fehler, sondern daß da eines war), habe ich das gefixt. Zitat aus Posting #1 unter "Probleme":

Syslogd läuft nicht, wenn Ringpuffergröße explizit gesetzt wird. (alter Fehler, behoben, kommt im Patch 14.2-p1)
Selbst fixen: in packages/syslogd-cgi-0.2/root/etc/init.d/rc.syslogd suchen nach -C $SYSLOGD_BUFFER_MAXSIZE und Leerzeichen dazwischen entfernen
 
Status
Für weitere Antworten geschlossen.

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,159
Beiträge
2,247,074
Mitglieder
373,678
Neuestes Mitglied
brainkennedy
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.