Archiv verlassen und diese Seite im Standarddesign anzeigen : PXE Problem mit alten Rechnern
Seit ein paar Tagen bin ich auf ein merkwürdiges Problem gestossen.
Mein PXE-Server lief bisher ohne Probleme.
Allerdings hat er scheinbar ein Problem mit alten PC's, zumindest möchte er nicht richtig damit komunizieren.
Zum System:
Ubuntu 14.04
isc-dhcp-server
tftpd-hpa
So siehts aus wenn es funktioniert:
02:23:09.557950 IP xxx > xyz.domain.de.tftp: 27 RRQ "pxelinux.0" octet tsize 0
02:23:09.561812 IP xxx > xyz.domain.de.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
02:23:09.625680 IP xxx > xyz.domain.de.tftp: 79 RRQ "pxelinux.cfg/0xxxxx85-1xxf-4xxx-xxx5-a726xxxxxxx7" octet tsize 0 blksize 1408
02:23:09.634756 IP xxx > xyz.domain.de.tftp: 63 RRQ "pxelinux.cfg/01-08-00-27-XX-XX-XX" octet tsize 0 blksize 1408
02:23:09.642750 IP xxx > xyz.domain.de.tftp: 42 RRQ "vesamenu.c32" octet tsize 0 blksize 1408
02:23:09.703722 IP xxx > xyz.domain.de.tftp: 63 RRQ "pxelinux.cfg/01-08-00-27-XX-XX-XX" octet tsize 0 blksize 1408
Hier bootet er korrekt und mein Menü erscheint.
So wenn es nicht funktioniert:
02:23:23.824500 IP xxx > xyz.domain.de.tftp: 35 RRQ "pxelinux.0.^A^D^A^DM-^?M-^?M-~" octet tsize 0
02:23:23.826295 IP xxx > xyz.domain.de.tftp: 40 RRQ "pxelinux.0.^A^D^A^DM-^?M-^?M-~" octet blksize 1456
Hier funktioniert es nicht und wie man sieht bastelt er irgendwelche Zeichen hinzu "pxelinux.0.^A^D^A^DM-^?M-^?M-~" wo ich mir keinen Reim darauf machen woher er diese nimmt.
Hier funktioniert zwar noch die DHCP zuweisung der IP und auch der connect auf den TFTP wie man oben sieht aber als Fehler erhalte ich folgendes auf dem Client:
DHCP_AUSGABE ....
TFTP.
PXE-T01: File not found
PXE-E3B: TFTP Error - File not found
PXE-M0F: Exiting Intel PXE ROM.
Ich muss vielleicht dazu sagen das die Anfrage von einem DrayTek Vigor 2925 weitergeleitet wird an den Linux-Server. Ich habe auf dem Linux-Server auch 2 Subnetze. Eines welches nicht mit dem DrayTek in Verbindung steht und via DHCP vom Linux-Server verwaltet wird und eines welches auch mit in dem Netz des DrayTeks hängt wobei hier die DHCP konfiguration vom DrayTek erledigt wird und lediglich via next-server und option 67 pxelinux.0 an den tftp des linux-server verweist.
Das lustige ist das die alten Rechner im DHCP verwalteten Netz des Linux-Server starten. Im DHCP verwalteten netz des DrayTek Routers nicht (wie man oben sieht). Hier bastelt es die Zeichen hinter das Bootfile.
via "tcpdump -vv -s 1024 port bootps" erscheint das File "pxelinux.0" dort aber korrekt. Nur via "tcpdump port tftp" erkennt man dann diese komischen Zeichen hinter dem File. Wie gesagt starten andere PC's problemlos und dort erscheinen diese Zeichen auch nicht hinter dem File.
Vielleicht hat hier noch jemand die zündende Idee an was es noch liegen könnte. Ich kann mir langsam keinen Reim mehr darauf machen wie ich das Problem abstellen könnte.
Greetz ZeR0
Hier
http://rawtechnology.blogspot.de/2014/09/certain-machines-cant-boot-from-linux.html
gibts einen einen Hinweis auf " /etc/default/tftpd-hpa.map".
Damit kann wohl buggy PXEs den bootfile-namen "zurechtbiegen".
Näheres unter "man tftpd" Stichwort "FILENAME REMAPPING".
Die nötige Regexp kann sicher einer beisteuern.
Dazu wäre der kaputte Dateinamen als ASCII-Encoding hilfreich.
Wahnsinn, nach was hast du denn gegoogelt?
Ich hab mir nen Wolf gegoogelt aber auf das bin ich nicht gestossen.
Es läuft zwar noch immer nicht aber ich denke das ist der richtige Ansatz.
Sobald ich auf eine Lösung gestossen bin oder weitere Erkentnisse habe, schreibe ich sie hier.
Was ich bis jetzt sagen kann:
tail -f /var/log/syslog
enthält bei mir keinerlei ausgabe des tftp ...
so wie ich das sehe läuft der TFTP auch nicht im verbose Modus:
root 29877 0.0 0.0 15124 156 ? Ss 01:46 0:00 /usr/sbin/in.tftpd --listen --user tftp --address 0.0.0.0:69 -l -c -s /var/lib/tftpboot/
meine /etc/defaul/tftp-hpa sah so beim test mit "ps aux | grep tftpd" aus:
# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot/"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure --ipv4 --verbose --verbosity 5"
TFTP_OPTIONS="-l -c -s"
erst so hat es funktioniert: (nur fürs Protokoll)
# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot/"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -c -s -4 -v --verbosity 5"
Nun sollte er auch mit Loglevel 5 laufen:
root 30111 0.0 0.0 15124 152 ? Ss 02:06 0:00 /usr/sbin/in.tftpd --listen --user tftp --address 0.0.0.0:69 -l -c -s -4 -v --verbosity 5 /var/lib/tftpboot/
nun haben wir auch die Ausgabe im Syslog:
Oct 20 02:09:26 host in.tftpd[30132]: RRQ from 192.168.XX.XXX filename pxelinux.0.#001#004#001#004▒▒▒
Oct 20 02:09:26 xxxx in.tftpd[30132]: sending NAK (1, File not found) to 192.168.21.160
Oct 20 02:09:26 xxxx in.tftpd[30133]: RRQ from 192.168.XX.XXX filename pxelinux.0.#001#004#001#004▒▒▒
Oct 20 02:09:26 xxxx in.tftpd[30133]: sending NAK (1, File not found) to 192.168.21.160
Wieder fürs Protokoll. So sieht es bei einem Client aus bei dem PXE funktioniert:
Oct 20 02:10:45 host in.tftpd[30149]: RRQ from 192.168.XX.XXX filename pxelinux.0
Oct 20 02:10:45 xxxx in.tftpd[30149]: tftp: client does not accept options
Oct 20 02:10:45 xxxx in.tftpd[30150]: RRQ from 192.168.XX.XXX filename pxelinux.0
Oct 20 02:10:45 xxxx in.tftpd[30151]: RRQ from 192.168.XX.XXX filename pxelinux.cfg/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Oct 20 02:10:45 xxxx in.tftpd[30151]: sending NAK (1, File not found) to 192.168.XX.XXX
Oct 20 02:10:45 xxxx in.tftpd[30152]: RRQ from 192.168.XX.XXX filename pxelinux.cfg/01-08-00-27-XX-XX-XX
Oct 20 02:10:45 xxxx in.tftpd[30155]: RRQ from 192.168.XX.XXX filename vesamenu.c32
Oct 20 02:10:45 xxxx in.tftpd[30156]: RRQ from 192.168.XX.XXX filename pxelinux.cfg/01-08-00-27-XX-XX-XX
Oct 20 02:10:45 xxxx in.tftpd[30157]: RRQ from 192.168.XX.XXX filename splash.png
Die Ausgabe mit "tcpdump -ni eth0 -v -T tftp 'udp'"
02:14:50.639854 IP (tos 0x0, ttl 20, id 2, offset 0, flags [none], proto UDP (17), length 63)
192.168.XX.XXX.2070 > 192.168.XX.X.69: 35 RRQ "pxelinux.0.^A^D^A^DM-^?M-^?M-~" octet tsize 0
02:14:50.641597 IP (tos 0x0, ttl 64, id 2013, offset 0, flags [none], proto UDP (17), length 47)
192.168.XX.X.57986 > 192.168.XX.XXX.2070: 19 ERROR ENOTFOUND "File not found"
02:14:50.641941 IP (tos 0x0, ttl 20, id 3, offset 0, flags [none], proto UDP (17), length 68)
192.168.XXX.XXX.2071 > 192.168.XX.X.69: 40 RRQ "pxelinux.0.^A^D^A^DM-^?M-^?M-~" octet blksize 1456
02:14:50.643588 IP (tos 0x0, ttl 64, id 2014, offset 0, flags [none], proto UDP (17), length 47)
192.168.XX.X.43507 > 192.168.XX.XXX.2071: 19 ERROR ENOTFOUND "File not found"
Laut Ubunut Terminal mit "ISO-8859-1" ergibt die Ausgabe "tail -f /var/log/syslog" folgendes:
Oct 20 02:25:16 host in.tftpd[30326]: RRQ from 192.168.XX.XXX filename pxelinux.0.#001#004#001#004ÿÿþ
Oct 20 02:25:16 xxxx in.tftpd[30326]: sending NAK (1, File not found) to 192.168.XX.XXX
Oct 20 02:25:16 xxxx in.tftpd[30327]: RRQ from 192.168.XX.XXX filename pxelinux.0.#001#004#001#004ÿÿþ
Oct 20 02:25:16 xxxx in.tftpd[30327]: sending NAK (1, File not found) to 192.168.XX.XXX
So jetzt bräuchte ich nochmal Hilfe für die /etc/default/tftpd-hpa.map :)
Fürs Erste schon mal vielen Dank Aqualung. Das hat mir schon mehr als weitergeholfen und war die zündende Idee ;)
Greetz ZeR0
EDIT:
ASCII CODE sollte dann so aussehen:
ASCII | hex 2E | dez 46 | #001 | .
ASCII | hex 01 | dez 1 | #001 | SOH ^A
ASCII | hex 04 | dez 4 | #004 | EOT ^D
ASCII | hex 01 | dez 1 | #001 | SOH ^A
ASCII | hex 04 | dez 4 | #004 | EOT ^D
ISO-8859-1 | hex 00FF | dex 255 | ÿ | M-^? |
ISO-8859-1 | hex 00FF | dex 255 | ÿ | M-^? |
ISO-8859-1 | hex 00FE | dex 254 | þ | M-~ |
echo 'rg 0\.^A.*$ 0' > /etc/default/tftpd-hpa.map
Wörtlich: Ersetze 0.^A gefolgt von beliebigen Zeichen bis Zeilenende durch "0".
Hinweis: ^A erzeugst Du mit STRG-v dann STRG-a.
Es fehlen evtl. noch single Qoutes...
Nun wirds komisch ... :confused:
Ich habe bereits nach meinem Post selbst einige Varianten versucht aber muss dazu sagen das ich mit regex so gut wie nichts am Hut habe. Genau so gut sahen auch meine Versuche aus und es tat sich nichts ... Fehlerbild unverändert.
Jetzt gebe ich also das ein was du mir geschrieben hast ... über die noch offene Ubuntu Konsolo (steht noch auf "ISO-8859-1"!) und schaue zur sicherheit danach in die /etc/default/tftpd-hpa.map ... dort erwartet mich das:
rg 0\..*$ 0
Hmm, ok hier zeigt es was an wo das ^A stehen soll. Bei mir in der Datei sieht es leer aus ... nungut weiter im Text.
EDIT: oder auch nicht. Nach dem speichern ist es hier zwischen den Punkten nun auch leer. Denke mal das liegt an der Zeichenkodierung.
Ich konnte einen Versuch natürlich trotzdem nicht lassen und habe versucht zu booten ... widererwarten startet es nun ... selbst mit diesem einem Befehl in der tftpd-hpa.map ... das kann doch nicht sein. Zumal wenn man sich die Ausgabe dazu ansieht ?!??! :confused:
root@host:~# tcpdump port tftp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:18:01.346460 IP 192.168.XX.XXX.2070 > host.domain.de.tftp: 35 RRQ "pxelinux.0.^A^D^A^DM-^?M-^?M-~" octet tsize 0
12:18:01.348891 IP 192.168.XX.XXX.2071 > host.domain.de.tftp: 40 RRQ "pxelinux.0.^A^D^A^DM-^?M-^?M-~" octet blksize 1456
12:18:01.378456 IP 192.168.XX.XXX.49152 > host.domain.de.tftp: 79 RRQ "pxelinux.cfg/ffffffff-ffff-ffff-ffff-ffffffffffff" octet tsize 0 blksize 1408
12:18:01.380859 IP 192.168.XX.XXX.49153 > host.domain.de.tftp: 63 RRQ "pxelinux.cfg/01-00-11-09-XX-XX-XX" octet tsize 0 blksize 1408
.
.
.
12:18:01.421665 IP 192.168.XX.XXX.49165 > host.domain.de.tftp: 42 RRQ "vesamenu.c32" octet tsize 0 blksize 1408
12:18:01.493401 IP 192.168.XX.XXX.49166 > host.domain.de.tftp: 50 RRQ "pxelinux.cfg/default" octet tsize 0 blksize 1408
12:18:01.584209 IP 192.168.XX.XXX.49167 > host.domain.de.tftp: 40 RRQ "splash.png" octet tsize 0 blksize 1408
Das kann ich jetzt irgendwie nicht ganz nachvollziehen. Die Fehlerhaften Zeichen am Ende sind doch unverändert und trotzdem startet er jetzt? Die Wege der Bits und Bytes sind manchmal unergründlich ... :confused:
EDIT:
Auch andere Clients starten nun ... mit der selben Ausgabe welche noch die fehlerhaften Zeichen enthält ... aber sie starten ... warum auch immer :confused:
BetterWorld
20.10.15, 11:47
Das dürfte wohl auch ein (kleiner) Bug sein. Er "stösst" auf die Zeichen und mappt danach.
Die Darstellung in deinem Editor sagt mal gar nix. Da dürfte jeder Editor sein eigenenes Süppchen kochen.
In "vi" kannst das korrekt darstellen lassen. :set listchars um eine dir genehmes Mapping zu erstellen. Und :set list um das ganze dann gemappt anzeigen zu lassen.
Aber Hey!
Wenn es geht, ja nicht mehr hingucken,
und erst recht nicht hinlangen!
EDIT: oder auch nicht. Nach dem speichern ist es hier zwischen den Punkten nun auch leer. Denke mal das liegt an der Zeichenkodierung.
Klarheit sollte
od -t d1 /etc/default/tftpd-hpa.map
verschaffen.
Aber Hey!
Wenn es geht, ja nicht mehr hingucken,
und erst recht nicht hinlangen!
:D da hast du wohl recht aber ganz wohl ist mir auch nicht dabei wenn ich es nicht nachvollziehen kann. Es wäre schon schön wenn die Zeichen auch im Log verschwinden und er auch sichtlich korrekt arbeitet. Oder nicht? :eek:
Mit "vi" hast du recht, da wird das ^A korrekt angezeigt. Danke für den Tip. Der WinSCP-Editor scheint da wohl wirklich gänzlich ungeeignet dafür zu sein. Vielleicht kann man auch dort die Zeichenkodierung ändern aber bis jetzt bin ich noch nicht fündig geworden. Egal "vi" tuts für die kleinen Änderungen ja auch.
@Aqualung:
root@host:~# od -t d1 /etc/default/tftpd-hpa.map
0000000 114 103 32 48 92 46 1 46 42 36 32 48 10
0000015
Auch danke für diesen Tip.
Momentan sieht meine tftpd-hpa.map so aus:
rg 0\.^A.*$ 0
rg 0\.^D.*$ 0
rg 0\.ÿ.*$ 0
rg 0\.þ.*$ 0
ob die letzten Beiden Zeichen aber richtig sind. Da bin ich mir nicht sicher. Erzeugt wurden sie mit STRG + UMSCH + U -> Eingabe 00FF und 00FE.
Fehlerbild laut Log unverändert. Startet aber nach wie vor.
BetterWorld
20.10.15, 13:07
vi kann schlicht alles.
Du kannst solche Digraphen auch bequem eingeben.
Es ist und bleibt der schnellste, beste und überhaupt.
Autsch, das tut weh.
Wie würde Homer sagen ... DOH!
Ich wunder mich warum es beim TCPDUMP nichts ändert ... tja wie denn auch wenn das nur die Anfrage abfängt.
Habe nochmal verbose im tftpd-hpa eingeschalten und via "tail -f /var/log/syslog" nun folgenden Auszug erhalten:
Oct 20 18:29:35 host in.tftpd[21287]: remap: input: pxelinux.0.#001#004#001#004ÿÿþ
Oct 20 18:29:35 xxxx in.tftpd[21287]: remap: rule 0: rewrite: pxelinux.0
Oct 20 18:29:35 xxxx in.tftpd[21287]: remap: done
Oct 20 18:29:35 xxxx in.tftpd[21287]: RRQ from 192.168.XX.XXX filename pxelinux.0.#001#004#001#004ÿÿþ remapped to pxelinux.0
Oct 20 18:29:35 xxxx in.tftpd[21287]: tftp: client does not accept options
Oct 20 18:29:35 xxxx in.tftpd[21288]: remap: input: pxelinux.0.#001#004#001#004ÿÿþ
Oct 20 18:29:35 xxxx in.tftpd[21288]: remap: rule 0: rewrite: pxelinux.0
Oct 20 18:29:35 xxxx in.tftpd[21288]: remap: done
Oct 20 18:29:35 xxxx in.tftpd[21288]: RRQ from 192.168.XX.XXX filename pxelinux.0.#001#004#001#004ÿÿþ remapped to pxelinux.0
Etwas Hirn bei der Arbeit hat noch nie geschadet. :D Somit funktioniert also alles wie es soll ... zumindest fürs Erste ;)
Nochmal herzlichen Dank, ohne die Hilfe würde ich vermutlich noch immern googlen und keinen Schritt weiter sein. *THUMBS UP*
EDIT:
war ja klar das mir nachdem alles läuft das passende Tutorial für regex in die Hände fällt ;)
http://www.linuxforen.de/forums/showthread.php?278583-RegEx-Tutorial-Teil2-mit-Einf%FChrung-in-sed&p=1826445#post1826445
Vielleicht hilft es jemand anderen noch an dieser Stelle. Ich werds mir auf jedenfall auch mal zur Gemüte führen. ;)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.