BOOTP defekt mit LCOS 10.12.0082

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von backslash »

Hi Bernie137,

ich glaube du wirfst siaddr und option 66 zusammen - die gehören aber nicht zusammen...

siaddr enthalt die IP-Adresse des nächsten Servers oder 0.0.0.0 und der Name de Datei steht im Fled fname des DHCP-Headers. Statt siaddr zu setzen kann auch im Feld sname des DHCP-Headers der DNS-Name des TFTP-Servers angegeben werden

die Option 66 enhält den DNS-Namen des TFTP-Servers, wenn das sname-Feld im DHCP-Header für Option-Overload verwendet wird
die Option 67 enhält den Filenamen, wenn das fname-Feld im DHCP-Header für Option-Overload verwendet wird

Nun sollte man der Einfachheit mal davon ausgehen können, daß es einem DHCP-Client, der Option 66/67 unterstützt, egal ist, ob der den DNS-Namen des TFTP-Servers und den Filename im sname/fname Feld des DHCP-Headers sieht oder aber als explizite Option. Wenn du dann Option 66/67 als "additional options" einträgst, kannst du dann *allen* Clients das *selbe* Image zuweisen. Aber nur, wenn der DHCP-Client in der Lage is, eine DNS-Auflösunmg zu machen...

Ist er nicht in der Lage eine DNS-Auflösung zu machen, so kommt das Feld siaddr zum Zug, das vom LANCOM gefüllt wird, wenn es über die einen Eintrag in der Alias-Liste findet. Dieser kann entweder über einen Eintrag in der Hostliste angesteuert werden oder aber der Client fordert das Image im DHCDISCOVER/DHCPREQUEST im fname Feld des DHCP-Headers an.

nun zu den Szenarien:

Zu Szenario 2:
Die Option 66 wird als SIAdr an den Client "TEST" durchgereicht, es wird das Image "PXE" gebootet.
hier wird mitnichten eine Option 66 als siaddr weitergerichet... Hier wird das Feld siaddr auf die Adresse des Image-Servers in der Alias-Liste gesetzt. Das ist ein kleiner aber wichtiger Unterschied


Zu Szenario 3:

versuch doch mal

Code: Alles auswählen

/setup/dhcp/additional-options

Option-Number    Network-name      Option-Type      Option-Value                             
===================================------------------------------------
66               INTRANET          string           tftp-server.intern
67               INTRANET          String           boot\x86\wdsnbp.com
und unter

Code: Alles auswählen

/Setup/DNS/DNS-List

Host-name                                                         Rtg-tag  IP-Address       IPV6-Address
===========================================================================--------------------------------------------------------
tftp-server.intern                                                0        192.168.172.100  ::
vielleicht führt das ja schon zum gewünschten Ergebnis - zumindest solange du den Clients das LANCOM als DNS-Server zuweist...

Die Alias-Liste kannst du dabei auch leer lassen, denn sie wird eh ignoriert, da du keinen Eintrag in der Host-Liste hast, der auf sie verweist. Zudem hast du die Optionen 66 und 67 manuell konfiguriert, die so ausgerollt werden...

zu Szenario 4:

auch hier müßte erstmal der TFTP-Server in der Option 66 als DNS-Name konfiguriert und in der DNS-Liste aufgelöst werden (wie in Szenario 3). Was dann passiert, hängt dann aber vermutlich von der Implementation aller eingesetzten Clients ab... Wenn sie siaddr/fname den Optionen 66/67 verziehen, dann könnte das tatsächlich funktionieren. Wenn nicht, dann booten auch die explizit aufgeführten Clients das über die Optionen 66/67 zugewiesene Image - oder gar nicht, weil sie verwirrt sind...

Hier bestünde also höchstens ein Handlungsbedarf darin, die Optionen 66/67 nicht auszurollen, wenn es für den Client einen Eintrag in der Hostliste gibt, oder wenn der Client selbst ein Image anfordert...

Gruß
Backslash
Benutzeravatar
Bernie137
Beiträge: 1700
Registriert: 17 Apr 2013, 21:50
Wohnort: zw. Chemnitz und Annaberg-Buchholz

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von Bernie137 »

Hallo Backslash,

vielen Dank für Deine ausführliche Antwort. Das hat mir geholfen, die Sache besser zu verstehen. Wenn ich auch vorab sagen muss, es ist immer noch ungelöst. Es nützt nichts, mit einem DNS Namen zu arbeiten - es bleibt bei dem Problem. Allerdings konnte ich nun das Verhalten genauer untersuchen und poste jetzt zwei Wireshark DHCP Offer Mitschnitte. Bitte nicht verwirren lassen durch die IP-Adressen, es handelt sich um unterschiedliche Standorte!

1. MS-DHCP
Im MS-DHCP ist die Option 66 (TFTP-Server gesetzt) gleichzeitig setzt Microsoft aber auch den Wert Next Server ebenfalls auf den Wert der Option 66. Damit funktioniert das gewünschte Prozedere, unbekannten Clients ein Image zu verpassen. (Zusatzinfo: Entferne ich die Option 66, setzt dieser DHCP Server seine eigene IP-Adresse bei Next Server ein.)
MS-DHCP.jpg
2. Lancom-DHCP
Im Lancom DHCP ist die Option 66 wie folgt eingetragen:
Option-Number Network-name Option-Type Option-Value
===================================------------------------------------
66 INTRANET String 192.168.172.100
67 INTRANET String boot\x86\wdsnbp.com
Der LANCOM DHCP setzt die Option 66 richtig, verzichtet aber darauf den Wert bei Next Server anzugeben. Dort steht nur 0.0.0.0 und damit geht das gewünschte Verhalten leider nicht.
LANCOM-DHCP.jpg
ich glaube du wirfst siaddr und option 66 zusammen - die gehören aber nicht zusammen...
Da hast Du sicherlich recht. Aber was soll ich darauf antworten? Ja und Nein. Genau das machen andere Hersteller auch. Ein Blick bei google verdeutlicht das Problem... https://www.google.de/search?q=pxe+boot ... jNs_gWdkZM

Jetzt kann man darüber streiten, ob bei Setzen der Option 66 gleichzeitig der Wert Next Server damit konfiguriert werden muss oder nicht, dass wird sicherlich eine RFC besagen. Fakt ist, nur mit dem Wert Next Server (SiAddr) funktioniert es.

Ich habe aber bisher nichts gefunden, mit welcher DHCP Option ich den Wert "Next Server" explizit setzen könnte. Hast Du da einen Tipp für mich?

Gruß Bernie
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Man lernt nie aus.
Benutzeravatar
Bernie137
Beiträge: 1700
Registriert: 17 Apr 2013, 21:50
Wohnort: zw. Chemnitz und Annaberg-Buchholz

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von Bernie137 »

Noch ein Nachtrag zu beiden Bildern:
Sowohl beim MS-DHCP als auch beim LANCOM-DHCP ist ebenfalls die Option 67 auf "boot\x86\pexboot.com" gesetzt. Was mir nun aber an den beiden Bildern auffällt ist ein weiterer Unterschied. Beim MS-DHCP wird dadurch ebenfalls der Wert "Boot file name:" (5 Zeilen unterhalb der Next Server IP) gesetzt, was der Lancom DHCP auch nicht tut.

Inzwischen denke ich, das der MS-DHCP und andere DHCP, bei Setzen der Option 66 ebenfalls den Wert bei "Next Server IP" und die Option 67 ebenfalls bei "Boot file name" mit eintragen. Diese Funktionsweise macht der LANCOM DHCP so nicht. Welches Verhalten nun RFC konform ist, weis ich nicht und eine Diskussion darüber bringt mir auch keine Lösung. Aber, wenn die Tabelle

Code: Alles auswählen

/setup/dhcp/hosts

MAC-Address   Network-name      IP-Address       Hostname                         Image-alias
================================-------------------------------------------------------------
0000000000000  INTRANET          0.0.0.0   TEST                             PXE     
eine "allgemeine" MAC Adresse tollerieren würde, wäre die Problemstellung vielleicht auch gelöst??? Konkrete MAC Adressen in der Tabelle sollten aber Vorrang haben.

Gruß Bernie
Man lernt nie aus.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von backslash »

Hi Bernie137,

auch wenn du das sicherlich nichtr so hören willst: Die Option 66 enthält nunmal laut RFC den Hostnamen des TFTP-Servers. Das heißt aber auch, daß in der siaddr *keine* Adresse stehen *kann*, wenn die Option 66 gesetzt ist - denn der Client muß den Namen erst in eine IP-Adresse auflösen... Es mag ja sein, daß Microsoft und andere Hersteller dazu übergegangen sind, die Option 66 selbst aufzulösen und die aufgelöste Adress ins siaddr-Feld zu packen, nur um kaputte DHCP-Clients doch bedienen zu können - aber das ist m.E. nach ein Workarraound, denn sie könnten die Option 66 wieder aus dem Paket rausnehmen. Das macht die ganze Option überflüssig... Statt Worarrounds für kaputte Clients in DHCP-Servern zu erwarten, solltest du (und alle anderen Betroffenen) eher die Hersteller der jeweiligen Netzwerkkarten, PCs und Co in die Verantwortung nehmen, wenn sie kein Image laden können, ohne daß die siaddr gesetzt ist.

BTW: Dein Vorschlag mit der "any-Adresse" funktioniert aber auch wieder nur, wenn du eine Monokultur hast - oder eben doch alle Clients einzeln konfigurierst, die nicht der Monokultur angehören... Dann sehe ich fast schon keinen Vorteil mehr darin, ein paar Clients nicht zu konfigurieren...

Gruß
Backslash
Benutzeravatar
Björn
Beiträge: 65
Registriert: 14 Sep 2010, 12:32
Kontaktdaten:

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von Björn »

backslash hat geschrieben: BTW: Dein Vorschlag mit der "any-Adresse" funktioniert aber auch wieder nur, wenn du eine Monokultur hast - oder eben doch alle Clients einzeln konfigurierst, die nicht der Monokultur angehören... Dann sehe ich fast schon keinen Vorteil mehr darin, ein paar Clients nicht zu konfigurieren...
"any" wäre zumindest für mich auch eine Erleichterung. Dann kann ich eine ganze Debian VM sparen, die nur DHCP macht (+ den Charme von VRRP).
Die Monokultur lässt sich auch einfach in einem physisch oder virtuell getrenntem Netz wegsperren.

>"ein paar Clients" sind in meinem Fall ~60 Anlagen die auch ohne unseren Support Acronis booten müssen. Wenn Eppendorf Rechner austauscht sind uns die neuen MAC-Adressen nicht bekannt.

Gruß Björn
Benutzeravatar
Bernie137
Beiträge: 1700
Registriert: 17 Apr 2013, 21:50
Wohnort: zw. Chemnitz und Annaberg-Buchholz

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von Bernie137 »

Hi backslash,
backslash hat geschrieben:auch wenn du das sicherlich nichtr so hören willst: Die Option 66 enthält nunmal laut RFC den Hostnamen des TFTP-Servers.
Gut ok, dann ist Euer KB-Eintrag aber falsch, das vorletzte Bild: https://www2.lancom.de/kb.nsf/1275/769A ... enDocument
backslash hat geschrieben:Statt Worarrounds für kaputte Clients in DHCP-Servern zu erwarten
Ich erwarte keinen Workaround. Schau Dir bitte folgenden Wireshark Trace an. Er ist vom LANCOM, es sind keinerlei Optionen 66 oder 67 gesetzt. Nur die Tabelle /setup/dhcp/hosts enthält einen konkreten Eintrag zu dieser Client MAC Adresse. Alles funktioniert wunderbar. Dieses Verhalten ist also ohnehin schon im LANCOM implementiert und ich hätte es gerne auch für unbekannte Clients, für beliebige MAC Adressen. Dein Argument der Monokultur ist kein Argument. Damit man die "angebliche" Monokultur erhält, muss man überhaupt erst einmal explizit diesen Eintrag für beliebige Clients erstellen (können). Und wer sagt denn, dass neben dem Eintrag für beliebige MAC-Adressen nicht auch welche für konkrete MAC-Adressen in der Tabelle /setup/dhcp/hosts existieren und funktionieren dürfen.
LANCOM-BootP.jpg
Gruß Bernie
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Man lernt nie aus.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von backslash »

Hi Bernie137
Ich erwarte keinen Workaround.

doch, das tust du schon.. du erwartest, daß der DHCP-Server, wenn du Option 66 setzt, den Hostnamen in eine IP-Adresse auflöst und als siaddr einsetzt, so wie es in deinem MS-Trace zu sehen ist - dort ist aber auch zu sehen, daß der MS-Server die Option 66 nicht ins sname Feld übernommen hat. Erstaunlicherweise steht aber im fname Feld etwas - vermutlich das gleiche, wie in der Option 67 (die du leider nicht ausgeklappt hast). Da stellt sich nun die Frage, wie hast du den MS-Server wirklich konfiguriert. An der Optionen 66/67 kann es eigentlich nicht liegen, denn wenn er scheinber eine übernimmt (67 -> fname), wieso dann nicht die andere (66 -> sname)? Und wenn er letzteres schon nicht getan hat, wieso sollte er dann die Option 66 in die sipaddr übernehmen...
Schau Dir bitte folgenden Wireshark Trace an. Er ist vom LANCOM, es sind keinerlei Optionen 66 oder 67 gesetzt.
richtig. Da hast du auch einen Eintrag in der Host-Tabelle gemacht und das Image zugewiesen. Niemand hat bestritten, daß das LANCOM ein Boot.-Image zuweisen kann. Hier geht es letztendlich darum, daß
  • Netzwerkkarten- und/oder Rechnerhersteller ddie Zuweisung des Images falsch imlenemntiert haben: sie ignorieren in Option 66 und brauchen die IP-Adresse im siaddr Feld. Vermutlich ignorieren sie auch die Option 67 - deine Traces vom MS-DHCP lassen daruaf keine Rückschlüsse zu, wohl aber Ergebnisse deiner Google-Suche...
  • es im LANCOM keinen "any" Eintrag in der Host-Liste gibt - dER ist aber auch nicht mal so eben nebenbei nachgerüstet...
Gruß
Backslash
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von alf29 »

Moin,

ich weiß nicht, ob ich den ganzen Sachverhalt zu 100% verstehe, aber da ich nun einmal die Tabelle mit den Additional Options verbrochen habe, gebe ich auch meinen Senf dazu:

Der Code, der hinter dieser Tabelle macht genau das, was der Name aussagt - sie hängt die dort konfigurierten Optionen an Antworten vom DHCP-Server an, nicht mehr und nicht weniger. Darüber hinaus ist sie "dumm": Sie hat keinerlei eingebautes Wissen darüber, was Option x oder y bedeutet und daß es irgendwelche Querbeziehungen von einer bestimmten Option zu anderen Optionen oder Feldern im Header einer BOOTP/DHCP-Message geben könnte, und sie kann auch keine Felder im Header setzen. Sie ist dafür eingebaut worden, weitere Optionen setzen zu können, die "orthogonal" zu denen sind, die der DHCP-Server selber setzt, und die zu exotisch sind und bei zu wenigen Kunden gebraucht werden, als daß man dafür eigene Menüpunkte vorsehen wollte. Wenn man darüber versucht, so eine Art Default für Optionen oder Felder zu konstruieren, für die der DHCP-Server aus dem einen oder anderen Grund keinen Default hat, dann kommt irgendetwas heraus, für das ich im Einzelfall nicht garantieren möchte.

Unabhängig ob das bisher diskutierte nun legal ist oder nicht, wäre ich auch strikt dagegen, solche impliziten Abhängigkeiten in diese Tabelle einzubauen, a la "wenn Option x gesetzt, dann setze auch Feld y im Header darauf, aber nur, wenn's bisher leer ist". Solche impliziten Abhängigkeiten gehen früher oder später immer bei einem anderen Kunden nach hinten los. Wenn, dann müßte man in irgendeiner Form Werte bzw. Overrides für die Felder im Header vorsehen. Das wäre aber ein Feature-Wunsch...

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
mz80chvo
Beiträge: 1
Registriert: 03 Nov 2017, 20:44

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von mz80chvo »

Die ursprüngliche Vermutung dieses Threads bestand ja darin, dass mit dem aktuellen LCOS 10.12 BOOTP defekt ist. Ich habe dieses Phänomen auch festgestellt und zwar völlig unabhängig von zusätzlichen DHCP-Optionen o.ä.

Im Einzelnen:

1.) Ich verwende die BOOTP-Funktionalität von LCOS zum Booten von Linux schon seit etlichen Jahren völlig problemlos. Anfangs noch ein Lancom 1621 mit LCOS 7.82. Einfach die entsprechenden Rechner als Station für BOOTP eintragen und ein zuvor definiertes Bootimage zugeordnet. Die Imagedateien liegen auf einer NAS-Station, die nebenher einen TFTP-Dienst laufen hat. Die Clients haben i.d.R. ein ROM mit dem Intel Boot Agent, aber auch Etherboot habe ich schon ausprobiert. Das ganze in Verbindung mit PXELINUX lief völlig geschmeidig, irgendwelche zusätzlichen DHCP-Optionen waren nie erforderlich.

2.) Das ganze lief auch unverändert auf einem aktuellen Lancom 883 mit LCOS 9.24.0212RU4.

3.) Nach einem Update auf 10.12.0084SU1 funktionierte der Bootvorgang jedoch nicht mehr. Die Fehlermeldung des Intel Boot Agents besagte, dass vom TFTP-Server unzulässige TFTP-Operationen gemeldet wurden.

4.) Das kam mir merkwürdig vor, da ich weder an den Clients noch am TFTP-Server irgendwelche Änderungen vorgenommen hatte. Habe deshalb die Netzwerkverkehr in der Bootphase mit Wireshark mitgeschnitten. Und tatsächlich habe ich zwischen LCOS 9.24 und LCOS 10.12 einen signifikanten Unterschied gefunden, der hier im Forum auch schon angesprochen wurde:

LCOS 9.24 meldet im Feld "Next server IP address" die IP-Adresse des TFTP-Server zurück, ich beim entsprechenden Boot-Image-Alias in LCOS definiert hatte (z.B. 192.168.16.251).

LCOS 10.12 meldet im selben Feld jedoch die IP-Adresse des Routers selbst (z.B 192.168.16.254) zurück. Ganz egal, welche IP-Adresse ich im Boot-Image-Alias hinterlegt habe. Die Fehlermeldung des Intel Boot Agents kam also von dem in LCOS integrierten TFTP-Dienst, der jedoch mit der Bootanfrage meiner Clients natürlich nichts anfangen kann.

Das Verhalten von LCOS 10.12 hat sich an dieser Stelle also gegenüber älteren Versionen geändert. Meiner Meinung nach ist LCOS 10.12 hier fehlerhaft.

Ich habe jedenfalls dank Firm Safe wieder LCOS 9.24 in meinem Lancom 883 aktiviert. Prompt funktioniert auch der BOOTP mit PXELINUX wieder einwandfrei.
dMatschek
Beiträge: 39
Registriert: 24 Apr 2017, 11:44

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von dMatschek »

Kann mir jemand Infos geben, wie sich das Stand heute weiterentwicklet hat? Ich glaube ich hänge in einem aktuellen Projekt genau hier dran fest.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von backslash »

Hi dMatsche,

es hat sich nichts geändert - und wird sich auch nicht, solange kein Großkunde genügend (> n-1000) Geräte nur kauft, wenn sich das ändert...
Aber solche Kunden habe i.A. eine eigene Infrastruktur, in der sie den DHCP-Server des LANCOMs gar nicht nutzen...

Gruß
Backslash
dMatschek
Beiträge: 39
Registriert: 24 Apr 2017, 11:44

Re: BOOTP defekt mit LCOS 10.12.0082

Beitrag von dMatschek »

Besten Dank für die schnelle Klarstellung Backslash!

VG,
Matschek
Antworten