beim der remote-Pflege von Clients stehe ich vor folgendem Problem:
Ich wecke einen Client mit linbo-remote … klappt. Das mit (dhcpretry ist noch im test)
Ich fahre den Client aus linbo raus ODER aus Ubuntu raus runter … klappt.
Ich will den Client wieder wecken … KLAPPT NICHT!
…
Ich warte 30-40 min und probiere es wieder … siehe da, es klappt wieder …
das Verhalten habe ich auch schon bemerkt. Wenn ich remote z.B. Änderungen
an der Software vornehme, dann wähle ich reboot/Neustart, dann kommt der
Rechner wieder in den Linbo-Bildschirm und ich kann per linbo-remote weiter
arbeiten.
ok - dann scheint es also nicht an meinen Switchen zu liegen …
Leider darf ich an die nicht ran - es hätte also sein können,
dass die nach WOL-Paketen auf einem Port "Verdauungsstörungen"
haben, weil sie das als “Angriff” interpretieren und da zeitweilig dicht machen …
So was ähnliches hatte ich schon, als ich Rechner getauscht habe. Da hat die
geänderte MAC den Port stillgelegt …
mein Problem ist, dass ICH den Nachweis führen muss,
dass evtl. was mit dem Netz falsch konfiguriert ist.
Schuld ist ja immer Linux und nie die Infrastruktur … wissen
wir doch, dass es diese Probleme mit Windows NIE geben würde …
wakeonlan setzt schon viel früher an. Da ist noch kein Betriebssystem aktiv, also kann das Betriebssystem - welches auch immer - nicht schuld sein.
Machs doch umgekehrt. Häng einen Windows Rechner dran und fahr den runter und mit wakeonlan wieder hoch. Wenn das nonstop funktioniert liegt der Verdacht nahe dass es am Betriebssystem liegt.
Meiner Erfahrung ist die.
Starte ich alle Rechner in einen Raum per wakeonlan, dann kommen nicht alle Rechner hoch (ich schätze mal 80 % - 90 % starten). Wiederhole ich den Vorgang mehrmals, dann werden es immer weniger die auf wakeonlan reagieren. Dabei ist es egal ob ich die Rechner aus Windows, oder aus Ubuntu herunter fahre.
Ich führe das auf die mehr oder weniger gute Implementierung von wakeonlan auf der Netzwerkkarte zurück.