DHCP-Problem

Beitrag von **Nadine69** » Montag 7. Januar 2002, 15:25

Hi@all

Nachdem ich die ganze Geschichte unter Windoofs bequem im Griff habe (Dank dem Tool von Field), möchte ich auch von Linux aus flashen.
Dabei stoße ich auf das Problem, daß ich den DHCP-Server nicht gestartet bekomme (es ist der selbst-kompilierte 3.0).
Er bringt folgende Fehlermeldung:

/etc/dhcpd.conf line 4: semicolon expected.
fixed-adress 192.
^
Configuration file errors encountered -- exiting

Meine /etc/dhcpd.conf sieht folgendermaßen aus:

# /etc/dhcpd.conf
subnet 192.168.1.0 netmask 255.255.255.0 {
}
host dbox-xxx {
fixed-adress 192.168.1.66 ;
hardware ethernet 00:50:9c:xx:xx:xx ;
allow bootp ;
server-name "192.168.1.111" ;
filename "/home/xxx/dbox2/tftpboot/ppcboot" ;
}

Meiner Meinung nach müsste das doch laufen. Hat jemand 'ne Idee?

Nadine

Beitrag von **Nadine69** » Montag 7. Januar 2002, 15:28

Ich sehe gerade, ich war im falschen Forum.
Kann das mal einer der Mods ins HOWTO-Forum verschieben?

Beitrag von **fx2** » Montag 7. Januar 2002, 17:57

benutze :
fixed-address <hostname_dbox>;

mit direkter IP-eingabe gings bei mir auch nicht.
den hostnamen musst du natürlich noch in /etc/hosts mit entspr. IP eintragen.

Beitrag von **Nadine69** » Montag 7. Januar 2002, 18:26

Dann bekomme ich ein:

/etc/dhcpd.conf line 4: semicolon expected.
fixed-adress dbox-xxx;
^
Configuration file errors encountered -- exiting

Beitrag von **Busman** » Montag 7. Januar 2002, 19:16

Hi,
benutze einfach anstatt
fixed-adress
doch
fixed-address mit doppel-D

CU

Beitrag von **chrissi** » Dienstag 8. Januar 2002, 00:25

subnet 192.168.1.0 netmask 255.255.255.0 {
# die geschweift klammer hier weg
host dbox {
fixed-address 192.168.1.66;
hardware ethernet 00:50:9c:2a:be:e0;
allow bootp;
server-name "192.168.1.111";
filename "/ppcboot";
}
}
^ Das semikolon war bei Dir oben. die host ... geschichte gehört in die Geschweiften klammeren einer subnet definition. (siehe man dhcpd, oder im rpm ist unter /usr/share/doc/dhcp.... eine gute bespielconfig).

Der dateiname von filename ist relativ zu sehen, den pfad gibst du per tftp vor (wobei das nur so ist, wenn der tftpd mit -s gestartet wird). siehe man tftpd

Hier noch ein Beispiel für /etc/xinetd.d/tftp:

service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -l -s /d/
disable = no
}

(danach /etc/rc.d/init.d/xinetd restart ausführen)

wenn deine linux-maschine am internet hängt, solltest Du Dir bei man xinetd.conf mal das only_from näher ansehen.

ich habe hier nur /d genommen, da ich probleme mit längeren Pfaden hatte. Das hier ist bei mir in produktion.

unter /d musste ich noch ein verzeichnis tftpboot anlegen, hier liegen bei mir kernel-cdk und die logos drin. Aber das liegt nur daran, da ich tftp mit "-s" starte. Aber wenn schon ein dienst als root läuft, dann doch bitte chroot'ed.

Ciao Chris

Hallo Chris,

Ich habe die Netzkonfig nach Deinen Angaben geändert (wenn auch die Pfadangaben bei der SuSE etwas anders sind).
Jetzt laufe ich auf folgenden Fehler:

BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Got BOOTP reply from Server IP 192.168.1.111, My IP 192.168.1.66
debug: Sending TFTP-request for file /ppcboot
debug: Sending TFTP-request for file /ppcboot
debug: Sending TFTP-request for file /ppcboot
debug: Sending TFTP-request for file /ppcboot
debug: Sending TFTP-request for file /ppcboot
debug: Sending TFTP-request for file /ppcboot
debug:
TFTP failed, giving up...
boot net failed

Flash-FS bootstrap loader (v1.5)

Found Flash-FS superblock version 3.1

An dieser Stelle fängt die Box dann an aus dem Flah zu booten.

So sieht die /etc/dhcpd.conf jetzt aus:

ddns-update-style none; #ohne diesen Eintrag startet DHCP nicht
subnet 192.168.1.0 netmask 255.255.255.0 {
host dbox-xxx {
fixed-address 192.168.1.66;
hardware ethernet 00:50:9C:2A:BE:E0;
allow bootp;
server-name "192.168.1.111";
filename "/ppcboot";
}
}

Der relevante Auszug aus der /etc/xinetd.conf:

service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -l -s /home/xxx/dbox2/tftpboot/
disable = no
}

Gruß Nadine

joh.. die box bekommt das angeforderte file nicht:

> TFTP failed, giving up...

da du den tftp ja mit -l gestartet hast, was steht denn in

/var/log/messages ?

das sollte so aussehen:
Jan 9 21:34:59 lgs dhcpd: BOOTREQUEST from 00:50:xx:xx:xx:xx via eth0
Jan 9 21:34:59 lgs dhcpd: BOOTREPLY for 192.168.206.211 to sagem (00:50:xx:xx:xx:xx) via eth0
Jan 9 20:34:59 lgs tftpd[12054]: sending /ppcboot

poste doch mal, was bei Dir kommt.

wie schon oben gesagt.. ich hatte probleme mit langen pfadnamen. probier auf jeden fall mal (auch wenn es ein verstoss gegen die unix-datei-struktur ist ;-) ) das auf die root (/) mit einem kurzen pfadnamen anzulegen.

Ciao chris

Hallo Chris,

danke erstmal für die schnelle Antwort.
Offensichtlich ist noch die tftp-Konfiguration krumm.
Auch beim Versuch einen kurzen Pfad zu benutzen (/tftpboot direkt unter root) bekomme ich in der /var/log/messages folgendes:

Jan 10 18:34:14 linux-server dhcpd: BOOTREQUEST from 00:50:9c:2a:be:e0 via eth0
Jan 10 18:34:14 linux-server dhcpd: BOOTREPLY for 192.168.1.66 to dbox-xxx (00:50:9c:2a:be:e0) via eth0
Jan 10 18:34:14 linux-server in.tftpd[1651]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1652]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1653]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1654]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1655]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1656]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1657]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1658]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1659]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server in.tftpd[1660]: Usage: in.tftpd [-vc][-m mappings][-u user][-t timeout][-r option...] [-s] [directory ...]
Jan 10 18:34:14 linux-server xinetd[1633]: tftp service was deactivated because of looping

Ganz klar also, daß der tftp-Deamon noch ein Problem hat.
Ich werde mich nochmal durch die ManPage wühlen.

Bis später Nadine

Hi,

der hat keine option -l wie es scheint.

Versuchs mal so:

server_args = -s /home/xxx/dbox2/tftpboot/

Ciao Christian

Beitrag von **Nadine69** » Samstag 12. Januar 2002, 10:25

Danke, Christian, ich habe auch bemerkt, daß in der ManPage zu in.tftpd keine Option -l erwähnt wird.
Nachdem ich diese Option rausgenommen habe, stoße ich nun aber auf ein mir unerklärliches Berechtigungsproblem:

Jan 11 21:46:42 linux-server dhcpd: BOOTREQUEST from 00:50:9c:2a:be:e0 via eth0
Jan 11 21:46:42 linux-server dhcpd: BOOTREPLY for 192.168.1.66 to dbox-xxx (00:50:9c:2a:be:e0) via eth0
Jan 11 20:46:42 linux-server in.tftpd[1071]: tftpd: read(ack): Connection refused
Jan 11 20:46:44 linux-server in.tftpd[1072]: tftpd: read(ack): Connection refused
Jan 11 20:46:46 linux-server in.tftpd[1073]: tftpd: read(ack): Connection refused
Jan 11 20:46:48 linux-server in.tftpd[1074]: tftpd: read(ack): Connection refused
Jan 11 20:46:51 linux-server in.tftpd[1075]: tftpd: read(ack): Connection refused
Jan 11 20:46:53 linux-server in.tftpd[1076]: tftpd: read(ack): Connection refused

Ich habe auf die entsprechenden Dateien und Verzeichnisse bereits die Berechtigung 777 gelegt.
Desweiteren habe ich den User nobody (der ja von tftp verwendet wird) in der /etc/ftpusers kommentiert, obwohl ich eigentlich nicht glaube, daß diese Datei für tftp relevant ist.

Hast Du vielleicht auch dazu noch 'ne Idee???

Gruß Nadine

Beitrag von **chrissi** » Samstag 12. Januar 2002, 11:02

hi,

also wenn ich genaus das bei google reinhaue, bekomme ich das:

http://www.ltsp.org/pipermail/discuss/2 ... 04409.html

hmm vielleicht hast Du ja ein glibc problem.. würde aber erstmal einen neuen tftp holen und ausprobieren...

ABER: so richtig glaube ich das nicht... kannst du mir mal ein paar fragen beantworten:

1. welche distribution, welcher kernel läuft bei Dir.
2. benutzt Du ipchains oder iptables (2.2.x= ipchains , 2.4.x ipchains oder iptables)...
wenn bei lsmod irgendwas mit ipchains rauskommt dann schick mir doch mal den output von "ipchains -L -n"
wenn da was mit iptables rauskommt, dann bitte den output von "iptables -L -n"
3. hast du irgendeine dieser (pseudo) firewall funktionen an? (erkennst Du daran, das bei iptables/ipchains -L -n was unter INPUT/FORWARD/OUTPUT rauskommt) Falls ja, dann tuh dir den gefallen, zieh das Ding vom internet ab, und gib ein "iptables -F" bzw. ipchains -F ein. wenn es dann geht, pass die Firewall so an, das tftp (und alles was dazu gehört)von intern erlaubt ist.
4) was steht in /etc/hosts.deny /etc/hosts.allow

ich habe keinen source zu tftpd gefunden. Aber unter http://www.freshmeat.net das hier gefunden:

http://www.ohse.de/uwe/software/utftpd.html

unter http://elfikom.physik.uni-oldenburg.de/ ... -gate.html bei eingabe von tftpd solltest Du die original sourcen finden ;-)

und da habe ich das noch gesehen: (COOL ;-) :
http://fringe.davesource.com/Fringe/Com ... es/TCP-IP/

BITTE nehmt das doch in das howto auf!!!

Ciao Chris

PS: bin ab morgen eine Woche im Urlaub

Beitrag von **Nadine69** » Samstag 12. Januar 2002, 11:38

Hi Chris,

danke erstmal für die prompte Antwort, Du scheinst ja wohl ständig online zu sein ;-)

Zu Deinen Fragen:
1. Es ist 'ne SuSE 7.3 mit Kernel 2.4.10
2. linux-server:~ # iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
3. offensichtlich muß wohl eine dieser (pseudo) firewall funktionen laufen, ohne daß ich bisher davon wußte.
Auch nach einem iptables -F sieht der iptables -L -n output unverändert aus und beim Versuch die Box zu booten bekomme ich den bekannten Fehler.

Ich bin jetzt noch dabei einen tftp-server von ftp://ftp.dei.uc.pt/.raid0/linux/ftp.re ... odule/TFTP zu saugen.
Vielleicht hilft's ja.

Bis später Nadine

Beitrag von **Nadine69** » Samstag 12. Januar 2002, 12:59

So nachdem ich nun iptables deinstalliert habe und den anderen TFTP-Server (utftp) benutze sieht der Fehler folgendermaßen aus:

Jan 12 12:50:05 linux-server dhcpd: BOOTREQUEST from 00:50:9c:2a:be:e0 via eth0
Jan 12 12:50:05 linux-server dhcpd: BOOTREPLY for 192.168.1.66 to dbox-xxx (00:50:9c:2a:be:e0) via eth0
Jan 12 12:50:05 linux-server utftpd[7997]: connect from 0.0.0.0
Jan 12 12:50:05 linux-server utftpd[7997]: peer requests /ppcboot, conversion octet
Jan 12 12:50:05 linux-server utftpd[7997]: denied read access to /ppcboot

Die Verzeichnis- und Dateiberechtigungen stehen auf 777.

Nadine

Beitrag von **chrissi** » Samstag 12. Januar 2002, 14:09

hi,
> linux-server:~ # iptables -L -n
> Chain INPUT (policy ACCEPT)
> target prot opt source destination

> Chain FORWARD (policy ACCEPT)
> target prot opt source destination

> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination

dann ist da auch nix, was das blocken könnte ;-)

die frage ist da noch, läuft der tftpd den du jetzt hast mit chroot?

Falls ja: /ppcboot sollte richtig sein
falls nein: musst du als pfad den kompletten pfad angeben.

ciao christian

Beitrag von **Nadine69** » Samstag 12. Januar 2002, 18:59

Hi Chris,

Hatte jetzt noch'n bischen was anderes zu tun (man hat ja auch noch Familie ;-)).
Der utftp-Deamon verfügt laut ManPage über beide Optionen.

-C, --global-chroot DIR
utftpd shall change its working directory to DIR, and invoke chroot(".") magic
after that. This will be

before the configuration file is read.

-d, --global-chdir DIR
utftpd shall change its working directory to DIR. This is

after a global
chroot (see the -C option above).

Ich habe auch beide Optionen jeweils mit und ohne komplette Pfadangabe in der /etc/dhcpd.conf ausprobiert. Es ist jedes Mal das gleiche Ergebnis.
Macht es Sinn, sich nach noch einem anderen tftp-Server umzusehen???

Falls wir nichts mehr voneinander hören, wünsche ich Dir einen schönen Urlaub!

Gruß Nadine

Beitrag von **chrissi** » Samstag 12. Januar 2002, 19:32

ja, ich denke schon

ich schick Dir mal das src-rpm von dem, der bei redhat 7.2 dabei ist. (per mail)

Beitrag von **chrissi** » Samstag 12. Januar 2002, 19:35

hi ist unter

ftp://ftp.de.uu.net/pub/linux/redhat/re ... 14.src.rpm

Beitrag von **Nadine69** » Samstag 12. Januar 2002, 20:23

Danke für den Link, werde ich gleich ausprobieren.
Was mir aber bei dem utftp-Deamon aufgefallen ist:

Jan 12 19:10:38 linux-server utftpd[20443]: connect from 0.0.0.0
Jan 12 19:10:38 linux-server utftpd[20443]: peer requests /ppcboot, conversion octet
Jan 12 19:10:38 linux-server utftpd[20443]: denied read access to /ppcboot

Wieso eigentlich connect fron 0.0.0.0 ??? Hat da vielleicht der dhcp-Deamon das Problem???

Bis dann Nadine

Beitrag von **chrissi** » Samstag 12. Januar 2002, 20:43

das könnte sein

Beitrag von **chrissi** » Samstag 12. Januar 2002, 20:45

ich kann bei mir sehen, woher die anfrage kommt.

aber wenn da eine Anfrage reinkommt, dann sollte ja der dhcp-server schon seinen job positiv erledigt haben

Beitrag von **Nadine69** » Samstag 12. Januar 2002, 20:53

Wieso dann aber from 0.0.0.0? Müsste da nicht die vom dhcp vergebene IP stehen?
Mit dem rpm-File komme ich auch nicht weiter.
Nach rpm -i bla-bla.rpm tut der Rechner zwar was, ich finde aber das Ergebnis dessen, was er getan hat nicht.

Nadine (die hofft nicht zu sehr zu nerven ;-))

Beitrag von **Nadine69** » Montag 14. Januar 2002, 14:31

So, jetzt habe ich das ganze mal (aus Mangel an anderen Ideen) auf einem anderen Rechner installiert.
Was soll ich sagen, dort löppt das auf Anhieb mit Ausnahme eines nfs-Fehlers (wohl noch die falsche Freigabe).
Ich denke das ursprüngliche Problem des ersten Rechners könnte eine 10/100-er Netzwerkkarte sein ???

Bis später Nadine