Ich versuche, einen PC ohne CD-Laufwerk und ohne USB-Boot-Optionen per Netzwerk zu booten (im BIOS verfügbar, erkennt USB jedoch nicht, ist vielleicht irgendwie kaputt).
Hier ist jedenfalls das Protokoll von TFTP32:
Rcvd DHCP Discover Msg for IP 0.0.0.0, Mac 00:1F:D0:8D:8B:09 [06/12 13:06:48.916]
DHCP: proposed address 192.168.2.1 [06/12 13:06:48.917]
Rcvd DHCP Rqst Msg for IP 0.0.0.0, Mac 00:1F:D0:8D:8B:09 [06/12 13:06:51.113]
Previously allocated address 192.168.2.1 acked [06/12 13:06:51.113]
Connection received from 192.168.2.1 on port 2070 [06/12 13:06:51.125]
Read request for file <netboot\pxelinux.0>. Mode octet [06/12 13:06:51.126]
Using local port 53708 [06/12 13:06:51.127]
Connection received from 192.168.2.1 on port 2071 [06/12 13:06:53.125]
Read request for file <netboot\pxelinux.0>. Mode octet [06/12 13:06:53.126]
Using local port 53709 [06/12 13:06:53.127]
Connection received from 192.168.2.1 on port 2072 [06/12 13:06:57.136]
Read request for file <netboot\pxelinux.0>. Mode octet [06/12 13:06:57.137]
Using local port 53710 [06/12 13:06:57.137]
Connection received from 192.168.2.1 on port 2073 [06/12 13:07:03.122]
Read request for file <netboot\pxelinux.0>. Mode octet [06/12 13:07:03.123]
Using local port 53711 [06/12 13:07:03.124]
TIMEOUT waiting for Ack block #1 [06/12 13:07:06.129]
TIMEOUT waiting for Ack block #1 [06/12 13:07:08.129]
Connection received from 192.168.2.1 on port 2074 [06/12 13:07:11.086]
Read request for file <netboot\pxelinux.0>. Mode octet [06/12 13:07:11.087]
Using local port 53717 [06/12 13:07:11.088]
TIMEOUT waiting for Ack block #1 [06/12 13:07:12.139]
TIMEOUT waiting for Ack block #1 [06/12 13:07:18.126]
TIMEOUT waiting for Ack block #1 [06/12 13:07:26.090]
Auch wenn ich den Computer anpinge, erhalte ich:
Pinging 192.168.2.1 with 32 bytes of data:
Reply from 10.20.21.188: Destination net unreachable.
Reply from 10.20.21.188: Destination net unreachable.
Reply from 10.20.21.188: Destination net unreachable.
Reply from 10.20.21.188: Destination net unreachable.
Ping statistics for 192.168.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
PS C:\Windows\system32>
Ich wäre Ihnen sehr dankbar, wenn jemand eine Idee hätte, wie ich das beheben könnte.
Grüße
BEARBEITEN_>
Weitere Informationen, die hilfreich sein könnten
Ich verwende kein Crossover-Kabel. Die Netzwerkkarte meines Server-Rechners ist allerdings eine Gigabit-Netzwerkkarte. Ich bin mir jedoch nicht sicher, ob ich trotzdem ein Crossover-Kabel benötige. Die beiden PCs sind nur über einen Fast-Ethernet-Switch verbunden.
Das letzte Ziel des Netboots ist die Installation von Debian auf dem Client-Computer. Ich betreibe derzeit einen Apache-Server, habe aber noch nicht herausgefunden, was die nächsten Schritte sein werden. Ich boote pxelinux.0 (ich bin mir noch nicht ganz sicher, was es eigentlich ist, ich habe es aus der Debian-Tar.gz-Datei, die ich gemäß der Anleitung aus dem Internet heruntergeladen habe.Hier).
Antwort1
Sie haben definitiv ein Problem mit den IP-Subnetzen. Mit einer Maschine auf 10.20.21.x und der anderen auf 192.168.2.x befinden Sie sich in völlig unterschiedlichen Netzwerktypen. Sie sollten wahrscheinlich mit einem Netzwerkadministrator oder jemandem sprechen, der sich mit Netzwerken auskennt. Beide Maschinen müssen sich im selben Netzwerk und im selben Subnetz befinden, es sei denn, Sie haben den Switch Ihres TFTP-Servers für das andere Subnetz geöffnet.
Antwort2
Ich hatte vor einiger Zeit dasselbe Problem mit „Timeout beim Warten auf Bestätigung“ mit tftpd32. Was das Problem für mich behoben hat, war die vorübergehende Deaktivierung meiner Firewall auf dem Windows-Computer. Nachdem die Kommunikation ohne Störungen durch die Firewall möglich war, wurde meine Übertragung durchgeführt. Wie in einemanderer BlogSie sollten außerdem sicherstellen, dass Sie in den Optionen auf der Registerkarte „TFTP-Server“ alles richtig konfiguriert haben (z. B. PXE-Kompatibilität), dass das Subnetz für den DHCP-Server mit dem Subnetz der Schnittstelle übereinstimmt, an die Sie den Computer anschließen, und dass sich während der Arbeit hieran kein anderer DHCP-Server in Ihrem Netzwerk befindet.
Das Ausschalten Ihrer Firewall kann gefährlich sein. Seien Sie also vorsichtig und vergessen Sie nicht, sie wieder zu aktivieren!
AKTUALISIEREN:
Nachdem ich das jetzt noch einmal gelesen und darüber nachgedacht habe, scheint es definitiv ein Problem mit Ihrer IP-Adressierung zu sein. Aus der Ping-Ausgabe geht hervor, dass Ihr Windows-Computer die IP 10.20.21.188 hat und der Computer, auf dem Sie bereitstellen möchten, von tftp32 die IP-Adresse 192.168.2.1 erhält. Da sie sich in unterschiedlichen Netzwerken befinden, können sie mit Ihrem beschriebenen Setup nicht miteinander kommunizieren. Damit dies funktioniert, müssen Sie entweder den DHCP-Pool in tftp32 bearbeiten oder die IP Ihres Computers in eine statische Adresse im richtigen Netzwerk ändern, damit sie mit dem DHCP-Pool übereinstimmt.
Antwort3
Ich hatte das gleiche Problem mit der Fehlermeldung „TIMEOUT beim Warten auf Bestätigungsblock Nr. 1“, wenn ein Client versuchte, eine Datei von meinem TFTPD-Server abzurufen.
Ich habe zunächst versucht, den TFTP-UDP-Port 69 in der Server-Firewall zu aktivieren, aber das hat nicht geholfen.
Schließlich stellte sich heraus, dass die Ursache des Problems auf der Client- und nicht auf der Server-Seite lag!
Der Grund dafür ist, dass TFTP die Daten über einen dynamisch zugewiesenen UDP-Port an den Client zurücksendet.
Es ist notwendig, eine Regel in derKlientFirewall, die es der Client-TFTP-Anwendung ermöglicht, Daten auf jedem UDP-Port zu empfangen. Auf Windows-Clients ist das C:\Windows\System32\tftp.exe.
Antwort4
Sparen Sie Zeit und vermeiden Sie DHCP-Probleme in PXE-Umgebungen. Nutzen Sie Ihre bereits vorhandene DHCP-Infrastruktur und richten Sie Ihren PXE-Server (d. h.Serva) InProxyDHCPModus. Auf diese Weise müssen Sie sich nicht mit unterschiedlichen Subnetz-IP-Fehlern wie dem, den Sie jetzt erleben, herumschlagen und Sie müssen Ihre aktuelle DHCP-Serverkonfiguration nicht ändern.