Integrierter TFTP-Server lässt dnsmasq abstürzen

[WeAreTheBorg]

Hallo,

ich habe gerade mein neues Atom-Mainboard mit OpenBSD aufgesetzt. Es läuft auch alles soweit ganz wunderbar bis auf ein größeres Problem: wenn ich den in dnsmasq integrierten TFTP-Server aktiviere, dann bringt mir dnsmasq einen Segmentation fault. Ich möchte gerne den integrierten Server benutzen, weil ich dnsmasq als komplettes Netzwerk-Rundum-Sorglos-Paket schätze Ich habe schon Google und die Forensuche bemüht, aber habe leider bis jetzt keine Lösung gefunden.

DHCP und DNS funktioniert einwandfrei, aber sobald ich einen Rechner über PXE booten will, ist dnsmasq weg. Ich habe OpenBSD 4.5 frisch aufgesetzt (mit bsd, bsd.rd, bsd.mp, base45.tgz, etc45.tgz und man45.tgz), dann habe ich dnsmasq (ftp://openbsd.ftp.fu-berlin.de/pub/OpenBSD/4.5/packages/amd64/dnsmasq-2.45.tgz) mit pkg_add installiert und meine frühere dnsmasq.conf nach /etc kopiert und leicht angepasst.

interface=em0
bind-interfaces
resolv-file=/tmp/ppp.resolv.conf
domain-needed
bogus-priv
filterwin2k
local=/homenet.xyz/
expand-hosts
domain=homenet.xyz
dhcp-authoritative
dhcp-range=192.168.148.11,192.168.148.40,255.255.255.0,12h # DHCP 11 - 40
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/tftpboot

Da dnsmasq ohne irgendwelche Log-Fehler abschmiert, habe ich es mal im Debug-Modus gestartet:

root:151# /usr/local/sbin/dnsmasq -d                                                                 
dnsmasq: started, version 2.45 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt BSD-bridge no-ISC-leasefile no-DBus no-I18N TFTP
dnsmasq: DHCP, IP range 192.168.148.11 -- 192.168.148.40, lease time 12h
dnsmasq: TFTP root is /tftpboot 
dnsmasq: restricting maximum simultaneous TFTP transfers to 49
dnsmasq: using local addresses only for domain homenet.xyz
dnsmasq: reading /tmp/ppp.resolv.conf
dnsmasq: using nameserver 217.0.43.177#53
dnsmasq: using nameserver 217.0.43.161#53
dnsmasq: using local addresses only for domain homenet.xyz
dnsmasq: read /etc/hosts - 2 addresses
dnsmasq: DHCPDISCOVER(em0) 00:1a:4d:50:80:bb 
dnsmasq: DHCPOFFER(em0) 192.168.148.56 00:1a:4d:50:80:bb 
dnsmasq: DHCPREQUEST(em0) 192.168.148.56 00:1a:4d:50:80:bb 
dnsmasq: DHCPACK(em0) 192.168.148.56 00:1a:4d:50:80:bb
Segmentation fault (core dumped)

Wie man sieht, startet dnsmasq ganz normal, dann kommt erst die DHCP-Anfrage der Netzwerkkarte beim PXE-Boot (was noch erfolgreich ist), aber wenn der Client dann auf den TFTP-Server zugreifen und das Bootimage (pxelinux.0) herunterladen will, kommt ein Segmentation fault.

/tftpboot existiert, Zugriffsrechte 755, außerdem hat meine Konfiguration mit einem selbst kompilierten dnsmasq auf meiner FritzBox, auf einem DD-WRT-Router und unter pfSense-1.2.3_rc1 (welches anscheinend auf FreeBSD basiert) ohne Probleme funktioniert. Außerdem hatte ich bei meinem ersten OpenBSD-Router-Test vor einiger Zeit mit OpenBSD 4.4 schon genau dasselbe Problem dnsmasq wurde offensichtlich auch nicht aktualisiert von 4.4 auf 4.5, da beide noch 2.45 benutzen. FreeBSD verwendet bereits 2.47. Ich habe auch mal das Makefile und die Patches in den ports durchgeschaut. Da wird was in tftp.c reingepatcht, aber was genau der Patch bewirkt, übersteigt meine C-Kenntnisse

Hat jemand eine Idee, woran es liegen könnte? Oder hat evtl. jemand dnsmasq mit integriertem tftp am Laufen? Evtl. habe ich ja auch was übersehen, das kann auch sein.

Vielen Dank schon mal im voraus!

 

[rMarkus]

Hallo,

wenn man dem dnsmasq mit gdb zu Leibe rückt, dann kann man den Grund das SIGSEGV näher einkreisen.

gdb dnsmasq

(gdb) run

Dann die Dinge mit dem DNSMASQ machen, die ihn zum Absturz bringen, und danach folgendes in der gdb-Console eingeben:

(gdb) back

Das zeigt dann den Backtrace/Stacktrace an, d.h. welches Programm welches Unterprogramm zuvor aufgerufen hat, bevor es zu dem Problem kam.

Wenn man das weiß, kann man sich den Code ansehen, und das evtl. genauer im gdb verfolgen.

PS: dnsmasq muss mit "-g" gebaut werden, falls das nocht nicht der Fall ist

 

[WeAreTheBorg]

Hallo,

danke für deine Antwort. Mein Problem dabei ist, dass das System von einem USB-Stick auf einer 1GB-Partition läuft, d.h. ich habe leider keinen Platz für comp45.tgz (/usr hat insgesamt 592MB, 178MB belegt, 384MB frei). Wenn ich die 348MB von comp45.tgz da reininstalliere, ist /usr voll...
Ich habe trotzdem das Archiv mal auf meinem Rechner ausgepackt und habe nur das gdb-binary kopiert, in der Hoffnung, dass alle erforderlichen libraries schon in base45.tgz vorhanden sind. Ich konnte dann gdb auch ausführen, jedoch sind die Ausgaben (zumindest für mich) nicht sehr aussagekräftig:

root:180# ./gdb --args dnsmasq -d
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd4.5"...(no debugging symbols found)

(gdb) run
Starting program: /usr/local/sbin/dnsmasq -d
dnsmasq: started, version 2.45 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt BSD-bridge no-ISC-leasefile no-DBus no-I18N TFTP
dnsmasq: DHCP, IP range 192.168.148.11 -- 192.168.148.40, lease time 12h
dnsmasq: TFTP root is /tftpboot 
dnsmasq: restricting maximum simultaneous TFTP transfers to 49
dnsmasq: using local addresses only for domain homenet.xyz
dnsmasq: reading /tmp/ppp.resolv.conf
dnsmasq: using nameserver 217.0.43.177#53
dnsmasq: using nameserver 217.0.43.161#53
dnsmasq: using local addresses only for domain homenet.xyz
dnsmasq: read /etc/hosts - 2 addresses
dnsmasq: DHCPDISCOVER(em0) 00:1a:4d:50:80:bb 
dnsmasq: DHCPOFFER(em0) 192.168.148.56 00:1a:4d:50:80:bb 
dnsmasq: DHCPREQUEST(em0) 192.168.148.56 00:1a:4d:50:80:bb 
dnsmasq: DHCPACK(em0) 192.168.148.56 00:1a:4d:50:80:bb 

Program received signal SIGSEGV, Segmentation fault.
0x000000020d5fb9f8 in strcpy (to=0x0, from=0x210268000 "/tftpboot/pxelinux.0")
    at /usr/src/lib/libc/string/strcpy.c:48
48      /usr/src/lib/libc/string/strcpy.c: No such file or directory.
        in /usr/src/lib/libc/string/strcpy.c
(gdb) back
#0  0x000000020d5fb9f8 in strcpy (to=0x0, from=0x210268000 "/tftpboot/pxelinux.0")
    at /usr/src/lib/libc/string/strcpy.c:48
#1  0x0000000000419170 in ?? ()
#2  0x0000000000418df3 in ?? ()
#3  0x0000000000410f4f in ?? ()
#4  0x000000000040fc6b in ?? ()
#5  0x0000000000402bac in ?? ()
#6  0x0000000000000002 in ?? ()
#7  0x00007f7ffffbd720 in ?? ()
#8  0x00007f7ffffbd738 in ?? ()
#9  0x0000000000000000 in ?? ()

Ob dnsmasq mit -g kompiliert wurde, weiss ich nicht. Ich habe halt das im ersten Post erwähnte Binärpaket installiert. Selbst kompilieren kann ich auch nichts, da wie gesagt aus Platzproblemen comp45.tgz und damit der Compiler fehlt. Außerdem bin ich noch nicht wirklich fit mit solchen Aktionen, da ich noch absoluter Neuling bzgl. *BSD bin

 

[WeAreTheBorg]

Update

So hier mal ein kleines Update: ich habe die OpenBSD-Installation nochmal in einer VM vorgenommen, mit einer 10GB-Platte. Dabei habe ich dann alles mitinstalliert. Ich habe auch die sourcen und die ports runtergeladen (alles von dem FTP-Server aus meinem ersten Post). Die sourcen habe ich nach /usr/src entpackt und ports nach /usr/ports.

Ich habe darauf geachtet, so wenig wie nur irgend möglich am System zu ändern. Meine Schritte im einzelnen:

1. OpenBSD amd64 installiert
2. PKG_PATH auf den FTP gesetzt
3. pkg_add dnsmasq
4. dnsmasq.conf nach /etc kopiert
5. /tftpboot kopiert
6. sourcen und ports entpackt

Dann habe ich dnsmasq neu kompiliert:

cd /usr/ports/net/dnsmasq
make -DDEBUG # ist das korrekt? Wie man -g angibt, weiss ich leider nicht...

Danach habe ich das neue binary nach /root kopiert und von dort mit gdb ausgeführt. Jetzt stehen in der Ausgabe von gdb wenigstens sinnvolle Werte (die mir aber immer noch nichts sagen ).

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd4.5"...
(no debugging symbols found)

(gdb) Starting program: /root/dnsmasq -d
dnsmasq: started, version 2.45 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt BSD-bridge no-ISC-leasefile no-DBus no-I18N TFTP
dnsmasq: DHCP, IP range 192.168.148.11 -- 192.168.148.40, lease time 12h
dnsmasq: TFTP root is /tftpboot 
dnsmasq: restricting maximum simultaneous TFTP transfers to 49
dnsmasq: using local addresses only for domain homenet.xyz
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 192.168.148.5#53
dnsmasq: using local addresses only for domain homenet.xyz
dnsmasq: read /etc/hosts - 2 addresses
dnsmasq: DHCPDISCOVER(em0) 08:00:27:61:03:dd 
dnsmasq: DHCPOFFER(em0) 192.168.148.35 08:00:27:61:03:dd 
dnsmasq: DHCPREQUEST(em0) 192.168.148.35 08:00:27:61:03:dd 
dnsmasq: DHCPACK(em0) 192.168.148.35 08:00:27:61:03:dd 

Program received signal SIGSEGV, Segmentation fault.
0x0000000202b329f8 in strcpy (to=0x0, from=0x20d62f000 "/tftpboot/pxelinux.0")
    at /usr/src/lib/libc/string/strcpy.c:48
48		for (; (*to = *from) != '\0'; ++from, ++to);
(gdb) #0  0x0000000202b329f8 in strcpy (to=0x0, 
    from=0x20d62f000 "/tftpboot/pxelinux.0")
    at /usr/src/lib/libc/string/strcpy.c:48
#1  0x0000000000419170 in check_tftp_fileperm ()
#2  0x0000000000418df3 in tftp_request ()
#3  0x0000000000410f4f in check_dns_listeners ()
#4  0x000000000040fc6b in main ()

Kann damit nun evtl. jemand was anfangen? Mit ist noch etwas aufgefallen, was nicht sein sollte. Bevor ich den obigen Test gemacht habe, hatte ich vergessen, den Inhalt von /tftpboot zu kopieren (das Verzeichnis war also leer). Anstatt nun einfach dem Client beim Versuch, pxelinux.0 zu laden, ein "File not found" zu schicken, ist dnsmasq wieder abgestürzt, aber nicht mit einem Segmentation fault, sondern mit einem Bus error. Falls es gewünscht wird, kann ich den Output auch noch hier reinstellen.

 

[WeAreTheBorg]

Problem gelöst

Hallo,

ich habe das Problem mittlerweile anders gelöst. Ich brauche PXE-Boot unbedingt, daher konnte ich mich nicht so lange mit der Fehlersuche aufhalten. Ich habe einfach in meiner VM-Zweitinstallation das aktuelle dnsmasq kompiliert, und diese Version funktioniert ohne Probleme. Falls noch jemand dnsmasq benutzen will und dasselbe Problem hat, schreibe ich hier mal die unternommenen Schritte rein:

wget http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.49.tar.gz
tar xfz dnsmasq-2.49.tar.gz
cd dnsmasq-2.49
make -DIPv6 -DGNU-getopt -DBSD-bridge -Dno-DBus -Dno-I18N -DTFTP
cp src/dnsmasq /usr/local/sbin/

Danach habe ich enable-tftp und tftp-root in /etc/dnsmasq.conf richtig gesetzt, und seitdem funktioniert dnsmasq mit DHCP, DNS und TFTP bei mir. PXE-Boot ist wirklich rasend schnell vom Atom-Board

Ich hoffe, dass ich evtl. jemandem mit demselben Problem helfen konnte. Es wäre natürlich trotz allem schön, wenn die offizielle dnsmasq-Version nicht so einen groben Fehler hätte.

Viele Grüße & Vielen Dank an alle, die sich diesen Thread durchgelesen haben

 

[kili]

cd /usr/ports/net/dnsmasq
make -DDEBUG # ist das korrekt? Wie man -g angibt, weiss ich leider nicht...

Korrekt ist:

env DEBUG=-g make install

(in Bourneshell-kompatiblen Shells wie der ksh kann man sich das env sparen, ausserdem ist evtl. ein make update und/oder make repackage, ggf. mit manuellem pkg_add -r noetig, weil dnsmasq ja jetzt schon bei Dir installiert und das Paket schon fertig unter /usr/ports/packages liegt)

Und da optimierter Code manchmal verschaerftes Haareraufen beim Debuggen erfordert, kann man auch noch ein -O0 spendieren:

 env DEBUG=-g\ -O0 make install

Wenn man es mit einem Heisenbug zu tun hat, der durch -O0 ausgeschaltet wird, hat man natuerlich die Arschkarte gezogen.

Danach habe ich das neue binary nach /root kopiert und von dort mit gdb ausgeführt. Jetzt stehen in der Ausgabe von gdb wenigstens sinnvolle Werte (die mir aber immer noch nichts sagen ).

...
Program received signal SIGSEGV, Segmentation fault.
0x0000000202b329f8 in strcpy (to=0x0, from=0x20d62f000 "/tftpboot/pxelinux.0")
    at /usr/src/lib/libc/string/strcpy.c:48
48		for (; (*to = *from) != '\0'; ++from, ++to);
(gdb) #0  0x0000000202b329f8 in strcpy (to=0x0, 
    from=0x20d62f000 "/tftpboot/pxelinux.0")
    at /usr/src/lib/libc/string/strcpy.c:48
#1  0x0000000000419170 in check_tftp_fileperm ()
#2  0x0000000000418df3 in tftp_request ()
#3  0x0000000000410f4f in check_dns_listeners ()
#4  0x000000000040fc6b in main ()

Kann damit nun evtl. jemand was anfangen?

Mal sehen... Da Du nicht mit DEBUG=-g gebaut hast, fehlen zwar die Zeilennummern, aber die betreffende Funktion verwendet nur ein einer Stelle strcpy(3), und zwar in tftp.c, Zeile 343. Da steht ein

strcpy(file->filename, namebuff);

Und laut gdb ist das erste Argument von strcyp(3), hier also file->filename NULL. file selbst wird in Zeile 332 alloziert, mittels

file = whine_malloc(struct tfrp_file) + strlen(namebuff) + 1)

(den Errorcheck habe ich mal weggelassen)

whine_malloc ist nur ein Wrapper um malloc(3), der im Fehlerfall noch eine Message syslogged, also harmlos. Die etwas merkwuerdige Groesse, die da alloziert wird, laesst vermuten, dass der Speicher fuer file->filename hinten an file (ein struct tftp_file) angepappt werden soll. file wird aber folgendermassen initialisiert:

file->fd = fd;
file->size = statbuf.st_size;
file->dev = statbuf.st_dev;
file->inode = statbuf.st_ino;
file->refcount = 1;

Und dann kommt das unsaegliche

strcpy(file->filename, namebuff);

Was der Autor hier vor dem strcpy(3) noch spendieren moechte, ist ein

file->filename = (char *) file + sizeof(struct tftp_file);

Du kannst mal folgendes ausprobieren:

1. Als root ein ln -s J /etc/malloc.conf spendieren (siehe malloc(3)) und dabei zusehen, wie dnsmasq diesesmal nicht mit strcpy(0, ...) sondern mit strcpy(0xd0d0d0d0d0d0d0d0, ...) stirbt. Anschliessend /etc/malloc.conf wieder loeschen.
2. Die oben genannte Zeile einbauen, neu bauen und nochmal testen, also in etwa:
   

   $ cd /usr/ports/net/dnsmasq
   $ make clean
   $ make patch
   $ vi +342 w-dnsmasq-2.45p0/dnsmasq-2.45/src/tftp.c
   (hier vor dem strcpy(3) die genannte Zeile einfuegen)
   $ make update-patches
   (hier erst mit q aus dem pager gehen, dann mit :q aus dem automatisch gestarteten vi).
   $ DEBUG=-g\ -O0 make repackage
   $ make update
   (wenn es nicht automatisch geupdatet wird, manuell mit pkg_add -r updaten)
   [/LIST]
   
   Ich habe mir den Code jetzt nicht genauer angesehen, aber der tftp-Teil duerfte noch nie bei irgendjemanden funktioniert haben.
   
   [quote]Mit ist noch etwas aufgefallen, was nicht sein sollte. Bevor ich den obigen Test gemacht habe, hatte ich vergessen, den Inhalt von /tftpboot zu kopieren (das Verzeichnis war also leer). Anstatt nun einfach dem Client beim Versuch, pxelinux.0 zu laden, ein "File not found" zu schicken, ist dnsmasq wieder abgestürzt, aber nicht mit einem Segmentation fault, sondern mit einem Bus error. Falls es gewünscht wird, kann ich den Output auch noch hier reinstellen.[/QUOTE]
   
   Scheint ja wirklich ein Qualitaetsprograemmchen zu sein. Ganz grosses Damentennis ;-)

 

[kili]

ich habe das Problem mittlerweile anders gelöst. Ich brauche PXE-Boot unbedingt, daher konnte ich mich nicht so lange mit der Fehlersuche aufhalten. Ich habe einfach in meiner VM-Zweitinstallation das aktuelle dnsmasq kompiliert, und diese Version funktioniert ohne Probleme.

Besser waere es, den Port zu aktualisieren und an rui@ zu schicken. Werde ich vielleicht heute Nachmittag mal machen.

Ich hoffe, dass ich evtl. jemandem mit demselben Problem helfen konnte. Es wäre natürlich trotz allem schön, wenn die offizielle dnsmasq-Version nicht so einen groben Fehler hätte.

Ich verstehe nicht, warum die neue Version bei Dir funktioniert, denn sie enthaelt immer noch den gleichen Fehler, wie ich ihn eben beschrieben hatte (file->filename wird nicht initialisiert).

 

[WeAreTheBorg]

Hallo,

Ich verstehe nicht, warum die neue Version bei Dir funktioniert, denn sie enthaelt immer noch den gleichen Fehler, wie ich ihn eben beschrieben hatte (file->filename wird nicht initialisiert).

ich kann auch nicht genau sagen, warum die neue Version geht. Ich habe nur die Schritte unternommen, die ich oben angegeben habe. dnsmasq läuft seit gestern auch problemlos.

Scheint ja wirklich ein Qualitaetsprograemmchen zu sein. Ganz grosses Damentennis ;-)

Also ich hab dnsmasq mit dieser Konfiguration bereits unter verschiedenen Linux-Distributionen, der FritzBox- und DD-WRT-Firmware und FreeBSD benutzt, und überall hat es von Anfang an funktioniert. Dieses Problem ist mir zum ersten Mal bei OpenBSD begegnet...

Besser waere es, den Port zu aktualisieren

Das halte ich in der Tat auch für die beste Idee. Mit 2.46 wurden neue interessante Features eingeführt, die ich gerne testen möchte (die ganzen pxe-*-Optionen). Viele andere spezielle Router-Distributionen updaten dnsmasq leider nicht mehr über 2.45 hinaus, weil der Support für ISC-leasefiles upstream entfernt wurde und die diese Funktion benötigen. Da aber unter OpenBSD sowieso no-ISC-leasefile gesetzt ist, sollte das kein Problem darstellen.

 

[WeAreTheBorg]

Hallo,

mir ist noch was eingefallen, was ich testen könnte. Also hab ich meine VM nochmal angeworfen und dieses Mal dnsmasq-2.45 von Hand kompiliert (ohne ports):

tar xfz /usr/ports/dnsmasq-2.45.tar.gz
make -DIPv6 -DGNU-getopt -DBSD-bridge -Dno-ISC-leasefile -Dno-DBus -Dno-I18N -DTFTP
cp src/dnsmasq /usr/local/sbin/dnsmasq-2.45

Jetzt habe ich in /usr/local/sbin:
dnsmasq (das originale vom FTP aus packages/amd64)
dnsmasq.debug (das mit Hilfe von ports kompilierte binary mit debug-Code)
dnsmasq-2.45 (das gerade von Hand gebaute)
dnsmasq-2.49 (das aktuelle gestern von Hand gebaute)

Ich habe alle vier nochmal durchprobiert:
- die von Hand kompilierten Versionen ohne Patches funktionieren ohne Probleme beim PXE-Boot
- die binaries vom FTP und das aus den ports erstellte debug-package segfaulten beim PXE-Boot

Daher ist anzunehmen, dass das Problem an einem der vier Patches liegen muss, die ports auf den Quelltext anwendet... welcher es ist, kann ich leider ob mangelnder C-Kenntnisse (im Studium lernt man leider nur noch Java...) nicht sagen

 

[kili]

Also ich hab dnsmasq mit dieser Konfiguration bereits unter verschiedenen Linux-Distributionen, der FritzBox- und DD-WRT-Firmware und FreeBSD benutzt, und überall hat es von Anfang an funktioniert. Dieses Problem ist mir zum ersten Mal bei OpenBSD begegnet...

Der betroffene Code in check_tftp_fileperm() ist definitiv fehlerhaft. Auch in der Version 2.49. Hier ist noch mal ein kleines Beispielprograemmchen, das in etwa das gleiche macht:

#include <stdlib.h>
#include <string.h>

struct tftp_file {
        int bla, blubbs;
        char foo;
        char *filename;
};

int main(void) {
        struct tftp_file *file;
        char *namebuff = "gogo gaga trallafiti";
        if (!(file = malloc(sizeof(struct tftp_file) + strlen(namebuff) + 1)))
                return 1;
        file->bla = 0;
        file->blubbs = 0;
        file->foo = 'x';
        printf("%p\n", file->filename);
        strcpy(file->filename, namebuff);
        return 0;
}

Ruhig mal bauen und laufen lassen, auch mit MALLOC_OPTIONS=J im Environment oder dem Symlink /etc/malloc.conf->J in Stellung. Das gibt reproduzierbar SIGSEGV oder SIGBUS, weil file->filename nicht korrekt initialisiert wird. Dieser Code kann unmoeglich auf irgendeinem Betriebssystem funktionieren.

Ich kann das Problem mit dnsmasq-2.49 hier munter reproduzieren, solange tftp-secure im Configfile gesetzt ist. Wenn es nicht gesetzt ist, kracht as an einer anderen Stelle, die ebenfalls ziemlich gruseligen Code enthaelt.


(Port updaten)

Das halte ich in der Tat auch für die beste Idee.

Ich inzwischen nicht mehr. Nach dem, was ich gesehen habe, sollte dnsmasq besser aus dem Portstree geloescht werden.

Edith: tolle Wurst, das Ding ist tatsaechlich im Portstree kaputtgepatched, wie WeAreTheBorg festgestellt hat. Vielleicht sollte ich auch mal selbst genauer auf die Patches sehen ;-)

 

[kili]

Daher ist anzunehmen, dass das Problem an einem der vier Patches liegen muss, die ports auf den Quelltext anwendet... welcher es ist, kann ich leider ob mangelnder C-Kenntnisse (im Studium lernt man leider nur noch Java...) nicht sagen

Treffer. patch-src_tftp_c macht aus Arrays mit undeklarierter Laenge Pointer. Und das macht's dann kaputt. Ich muss mal rausfinden, wieso der Patch ueberhaupt da ist.

Nichtsdestotrotz macht das Programm auch an anderen (ungepatchten) Stellen keinen besonders sauberen Eindruck.

 

[kili]

Treffer. patch-src_tftp_c macht aus Arrays mit undeklarierter Laenge Pointer. Und das macht's dann kaputt. Ich muss mal rausfinden, wieso der Patch ueberhaupt da ist.

*Vermutlich* irgendwas fuer die Architekturen, auf denen noch gcc-2 verwendet wird.

Ich werfe mal ein diff in den Ring...

 

[soul_rebel]

Sei froh, dass dnsmasq überhaupt geht. Bei mir geht nämlich der dnsmasq-dhcp-server unter OpenBSD garnicht
Und die ralink-Karte geht nur auf der Aux-Antenne (Reichweite ca 130cm) und die atheros-Karte hatte immermal timeouts, wo ich den Router neustarten mus
Und send-pr schickt die PRs irgendwie in ein schwarzes Loch, der Router macht mich echt fertig

 

[kili]

Sei froh, dass dnsmasq überhaupt geht. Bei mir geht nämlich der dnsmasq-dhcp-server unter OpenBSD garnicht

"geht garnicht" ist 'ne tolle Fehlermeldung.

Und die ralink-Karte geht nur auf der Aux-Antenne (Reichweite ca 130cm) und die atheros-Karte hatte immermal timeouts, wo ich den Router neustarten mus
Und send-pr schickt die PRs irgendwie in ein schwarzes Loch, der Router macht mich echt fertig

Du meinst sendbug, send-pr gibt's nicht. Aber egal. Wenn das Ding nicht funktioniert, dann hast Du immer noch die Moeglichkeit, direkt an misc@, ports@ oder bugs@ zu schreiben, je nachdem , was gerade kaputt ist und in welcher Form.

 

[soul_rebel]

"geht garnicht" ist 'ne tolle Fehlermeldung.

Jo, ist sowieso nicht so die feine Art, anderer Menschen threads mit seinen Problemen vollzumüllen, I know.
Ich hatte auch schon extra Threads, die leider auch planlos blieben. [1] [2]

Du meinst sendbug, send-pr gibt's nicht. Aber egal. Wenn das Ding nicht funktioniert, dann hast Du immer noch die Moeglichkeit, direkt an misc@, ports@ oder bugs@ zu schreiben, je nachdem , was gerade kaputt ist und in welcher Form.

Ja, habe ich auch drüber nachgedacht, meine letzen Mails wurden aber damals auch nicht beantwortet. Wie auch immer, ich will ja nicht nur nerven. Ich werde demnächst nochmal versuchen bugs zu submitten. Oder ich nehme FreeBSD, wobei das meines wissens zumindest im WLAN-Bereich die Treiber von OpenBSD portiert. Außerdem gibts da kein Traffic-Shaping mit GENERIC und ich wollte doch OpenBSD

Whatever, ignore the rant...

[1] http://www.bsdforen.de/showthread.php?t=22879
[2] http://www.bsdforen.de/showthread.php?t=23037