vielen Dank für das Debuggin MIT Lösung: tolle Sache
Dass der Fehler von den „alten Hasen“ die linbo 4 seit etlichen Monaten
produktiv einsetzten, nicht gefunden wurde, kann ich auch erklären: wir
nutzen alle immer nur Kleinbuchstaben bei den Hosts.
Ich weiß nicht mehr, was das ausgelößt hat, aber das war auch imemr mal
eine Empfehlung.
In die Doku und in die WebUI hat es diese Empfehlung bisher aber nicht
geschafft.
Es sollte unterbunden werden.
Gleichzeitig sollte es aber linbo trotzdem richtig machen.
Damit haben wir ja die Lösung gefunden, in der Richtung hatte ich auch das Problem vermutet. Wie schon gesagt, früher wurde nicht über nslookup der Name aufgelöst, das kam mit der 7.1 hinzu.
Ich finde nicht, dass das dauerhaft in der Doku stehen sollte. Wenn es kein Problem gibt sollte es auch nicht dokumentiert werden, das ist nur ein Workaround zu einem Problem, das es gar nicht geben sollte.
Leider zu früh gefreut. O.g. Lösung funktioniert auch nicht zuverlässig.
wakeonlan -i mit ipdresse funktioniert nur, wenn die firewall (hier: Opensense) den entsprechenden PC noch in der ARP Tabelle hat. (Schnittstellen->Diagnose->ARP Tabelle). Wenn der PC aber aus ist, verschwindet der PC nach ein paar Stunden jedoch automatisch aus der ARP Tabelle der firewall. Opensense weiß dann wohl nicht ins welches Netz das wakeonlan-paket gehört und verwirft es. Somit funktioniert dann auch wakeonlan -i mit ipdresse NICHT mehr. Natürlich auch linbo-remote nicht mehr
Wir haben weiter nach Lösungen gesucht:
Nun kann man ja auch bei wakeonlan -i eine Brodcastadresse angeben. Z.B. wakeonlan -i 10.101.255.255. Sollte normalerweise funktionieren, da die Firewall anhand Ihrer Schnittstellen das passende Netz herrausfinden könnte. Macht Opensense aber nicht. Auch das Brodcast-wakeonlan-Paket verwirft sie.
Lösung wäre hier, das man in der ARP-Tabelle von Opensense die Netze mit den entsprechenden Brodcastadressen neustartfest einträgt. Das sieht aber die WebGUI von Opensense nicht vor. Somit muss man das über die Konsole machen: Login mit root → 8 drücken → shell → cd /usr/local/etc/rc.syshook.d/start/ → dann dort für jedes Netz eine Datei (z.B. 99-broadcast-vlan101) erzeugen (Brodcastadresse entsprechend anpassen)
#!/bin/sh
arp -S 10.101.255.255 FF:FF:FF:FF:FF:FF
Damit funktioniert wakeonlan -i 10.101.255.255 zuverlässig.
Die Frage bleibt, wie machen wir das nun bei linbo-remote? Nun linbo-remote hat ja den Parameter -u. Doch fragen wir uns, warum wakeonlan nicht immer mit der Brodcastadresse aufrufen? Wir haben da keine Nachteile gesehen und somit nun in linbo-remote statt
# use broadcast address
if [ -n "$USEBCADDR" ]; then
bcaddr=$(get_bcaddress "$hostip")
[ -n "$bcaddr" ] && WOL="$WOL -i $bcaddr"
else
[ -n "$hostip" ] && WOL="$WOL -i $hostip"
fi
komplett auf den else-zweig verzichtet:
# # use broadcast address
# if [ -n "$USEBCADDR" ]; then
bcaddr=$(get_bcaddress "$hostip")
[ -n "$bcaddr" ] && WOL="$WOL -i $bcaddr"
# else
# [ -n "$hostip" ] && WOL="$WOL -i $hostip"
# fi
Ich glaube das kann man so in git übernehmen plus den Parameter -u komplett rausimplentieren.
Oder sieht da einer Nachteile?
das von " anacronataff" beobachtete Problem sollte ja nur bei einer Segmentierung der Netze auftreten (und nur dann benötigt man „-i“ bei wakeonlan) , dürfte dann aber auch andere Router betreffen. Wenn man die Broadcastadresse verwendet, hat man auf jeden Fall bessere Chancen, dass das Paket durchkommt.
Mit der IP-Adressen funktioniert das nur dann zuverlässig, wenn im Router eine statische ARP-Tabelle für alle Rechner vorhanden ist. Das steht auch so in der Manpage.
Wakeonlan sollte also immer die Broadcastadresse verwenden, unabhängig von der Netzstruktur. Das „-u“ sollte also das Standardverhalten sein. Wenn überhaupt, dann sollte die IP-Adressen nur dann verwendet werden, wenn man es explizit angibt.
Die Funktion validip ist nicht sinnvoll für Broadcastadressen, da das letzte Oktett nicht 255 sein darf, laut Funktion. Generell sind alle 255er ausgeschlossen?
/usr/share/linuxmuster/linbo/helperfunctions.sh
# check valid ip
validip(){
(expr match "$1" '\(\([1-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)\.\([0-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)\.\([0-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)\.\([1-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)$\)') &> /dev/null || return 1
}
Die Funktion lebt von einigen Annahmen. Wenn man statt einem /24er-Netz ein /23er-Netz nutzt, dann sind .0 und .255 im letzten Oktett auch gültige IP-Adressen.
