wie kann ich einzig vom TFTP-Server aus prüfen, ob dieser Server im LAN
als PXE-Server bereitsteht? Geht das überhaupt?
Hintergrund: in einem von mir aus der Ferne betreuten LAN habe ich
(sicherheitshalber) nur Zugriff auf den (Linux-)Server, nicht aber auf
die vielen (Windows-)Clients. Diese Clients sollen jetzt per PXE booten
- bei meinem Vergleichs-System hier zuhause funktioniert das
wunderschön. Dort: Fehlermeldung, dass irgendwas mit PXE nicht
funktioniere.
Sieht so aus, als ob der Client grundsätzlich PXE-Boot machen kann, der
Server aber (noch) nicht die richtige Antwort gibt. Und da möchte ich
aus der Ferne testen ...
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Helmut Hullen <Hel...@hullen.de> wrote:
> wie kann ich einzig vom TFTP-Server aus prüfen, ob dieser Server im
> LAN als PXE-Server bereitsteht? Geht das überhaupt?
[...]
> Sieht so aus, als ob der Client grundsätzlich PXE-Boot machen kann,
> der Server aber (noch) nicht die richtige Antwort gibt. Und da
> möchte ich aus der Ferne testen ...
Da eine mögliche Fehlerquelle ein Paketfilter auf dem Server oder den
Clients wäre, wird es sehr schwierig, alle möglichen Fehlerquellen
auszuschließen, wenn Du nur Verbindungsversuche vom Server auf den
Server machen kannst.
Globalgalaktisch muss die Antwort auf "geht das überhaupt" deshalb
"nein" heißen.
Gruß
Christian
--
....Christian.Garbs.....................................http://www.cgarbs.de
He who Laughs, Lasts.
Du meintest am 26.08.10:
>> wie kann ich einzig vom TFTP-Server aus prüfen, ob dieser Server im
>> LAN als PXE-Server bereitsteht? Geht das überhaupt?
> [...]
>> Sieht so aus, als ob der Client grundsätzlich PXE-Boot machen kann,
>> der Server aber (noch) nicht die richtige Antwort gibt. Und da
>> möchte ich aus der Ferne testen ...
> Da eine mögliche Fehlerquelle ein Paketfilter auf dem Server oder den
> Clients wäre, wird es sehr schwierig, alle möglichen Fehlerquellen
> auszuschließen, wenn Du nur Verbindungsversuche vom Server auf den
> Server machen kannst.
Ich bin ja bescheiden - mir würde schon reichen, wenn ich vom Server aus
eine Antwort auf einen PXE-Versuch bekäme. Denn dann bestünde Hoffnung,
dass auch ein Client eine Antwort bekommen kann.
Helmut Hullen <Hel...@hullen.de> wrote:
> Ich bin ja bescheiden - mir würde schon reichen, wenn ich vom Server aus
> eine Antwort auf einen PXE-Versuch bekäme. Denn dann bestünde Hoffnung,
> dass auch ein Client eine Antwort bekommen kann.
Ob der TFTP-Server laeuft und die dateien zugreifbar sind, kannst du doch
einfach mit dem simplen Kommando "tftp" testen.
Wenn du weisst, welche Datei per TFTP geladen werden soll, einfach mit
~ $ tftp <serverip>
tftp> mode binary
tftp> get <dateiname>
Moegliche Fehlerquellen waeren z.B. noch, dass die IP-Adresse beim Netzwerk-
boot nicht an den Client uebermittelt wird, dass die Netzmaske falsch ist
oder Routing-Information fehlt (so dass der TFTP-Server nicht erreicht werden
kann), dass eine falsche IP-Adresse des TFTP-Servers oder ein falscher Name
des Boot-Images uebermittelt wird, ...
Ohne Unterstuetzung "vor Ort" von jemandem, der fuer dich ggfs. die Diagnose
uebernimmt, hast du wohl eher schlechte Karten (denn auf einen Mitschnitt
saemtlichen Netzwerktraffics und Analyse des Traffics wirst du wohl Probleme
haben, den Fehler sauber zu diagnostizieren ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Du meintest am 26.08.10:
>> Ich bin ja bescheiden - mir würde schon reichen, wenn ich vom Server
>> aus eine Antwort auf einen PXE-Versuch bekäme. Denn dann bestünde
>> Hoffnung, dass auch ein Client eine Antwort bekommen kann.
> Ob der TFTP-Server laeuft und die dateien zugreifbar sind, kannst du
> doch einfach mit dem simplen Kommando "tftp" testen.
Habe ich den Wald vor lauter Bäumen nicht gesehen? Ich war sehr darauf
fixiert, dass der Dienst per "inetd" gerufen wird ...
> Wenn du weisst, welche Datei per TFTP geladen werden soll, einfach
> mit
> ~ $ tftp <serverip>
> tftp> mode binary
> tftp> get <dateiname>
Und zur Übersicht vorweg "?" oder "help" ... funktioniert.
> Moegliche Fehlerquellen waeren z.B. noch, dass die IP-Adresse beim
> Netzwerk-boot nicht an den Client uebermittelt wird,
Das könnte bei dem muckelnden Server das Hauptproblem gewesen sein; der
DHCP-Dämon hatte die Arbeit eingestellt, nachdem der dortige Kollege in
der "dhcpd.conf" u.a. anstelle des englischen Worts "address" die
halbdeutsche Version "adress" eingetragen hatte.
dhcpd -d -f
liefert dann etwas verwirrende Fehlermeldungen.
> Ohne Unterstuetzung "vor Ort" von jemandem, der fuer dich ggfs. die
> Diagnose uebernimmt, hast du wohl eher schlechte Karten (denn auf
> einen Mitschnitt saemtlichen Netzwerktraffics und Analyse des
> Traffics wirst du wohl Probleme haben, den Fehler sauber zu
> diagnostizieren ...).
In einer Stunde weiss ich mehr ... der Kollege vor Ort wird mal wieder
einen Client anwerfen.