[Gelöst] Wake on LAN auf der Shell
-
Okay, weitere ca. 1000 Tests gemacht.
Groß-/klein in der MAC hatte ich versucht. Ein Test hat übrigens dann gezeigt, dass die MAC im wol Befehl nicht case-sensitive ist.
Der Linux-Host, von dem es aus nicht geklappt hat, hängt mit einem der beiden Testrechner auch am selben Switch. VLANs u. VMs habe ich aber auch im Subnetz. Soll das ein Problem darstellen?
Mittlerweile konnte ich Erfolge verbuchen. Auf dem Linux ging es dann mit dem selben Befehl (aus dem Eingabe-Cache geholt), dann ging es mit einem Testrechner auch auf der Konsole des Masters, während es per "SSH-Befehl mitschicken" am Master auf beiden funktionierte, nachdem ich den 2. Rechner einige Male per wolcmd von einem Windows-Host geweckt hatte. Die beiden Rechner liegen in verschiedenen Subnetzen und an unterschiedlichen Interfaces an der pfSense.
Später ging es dann auch auf dem anderen Rechner auf der Konsole des Masters.Klar klingt das wie wenn sich der Blödmann in der Konsole erst bei der MAC-Adresse vertippt hätte, doch ich habe die Daten tausende Male verglichen, das hat 100 Pro gepasst, und auch auf der Konsole habe ich die Befehle aus dem Cache geholt.
Es hat also den Anschein, als hätte irgendwas in meinem Netz die Magic Pakete gefressen und ist nun satt.
Solch eine Sache, die irgendwann geht, irgendwann auch nicht, ohne irgendeinen Grund für das Problem zu finden, macht mich rasend. >:( >:( >:(
Werde es morgen nochmals testen, nur via SSH, anderes interessiert mich eh nicht, und mich ggf. weiter ärgern. Aber gewiss nicht solange, morgen ist Freitag. :)
-
… die NSA ist auch nur eine Verwaltung und es dauert immer etwas, bis neue Netzwerkfeatures freigeschaltet werden :-D
-
Neuer Tag, neues Glück… Oder auch nicht. :(
Bevor ich gestern das Handtuch geworfen habe, habe ich noch beiden Firewalls restartet.
Damit stehe ich nun auch wieder ganz am Anfang des Problem, d.h. es geht via SSH wieder nichts bei beiden Probanden, und das mit derselben Befehlszeile (aus dem Cache), die gestern noch funktioniert hatte.
Auf der GUI lassen sich beide problemlos aufwecken. Nachdem ersten Aufwecken von der GUI tut es der eine auch wieder über SSH, nicht aber der andere.Ich habe keinen Dunst, was ich noch an Justage versuchen könnte, der wol Befehl bietet da nicht viel. Darum werde ich die Funktion auf andere Rechner verlegen. Nervt eben nur, dass ich so in jedem Netz einen separaten Rechner dafür benötige und das nicht zentral steuern kann.
Danke jedenfalls für die Hinweise.
Schönes WE. -
…was dann noch bleiben könnte (!) sind die NICs, mal die entsprechenden Rechner, die starten sollen, für 1-2 min ganz stromlos machen und nochmal probieren.
PS: Für WOL reicht schon ein Raspi 1... :-D
-
@virago: Blöde Idee: Mach mal nach dem Neustart, wenn es auf der Shell nicht geht mal einen ARP Table lookup wie die aussieht. Dann Befehl (der nicht geht) - nochmal gucken und dann via GUI und dann schauen (bzw. wenn der Befehl auch gut). Evtl. macht die GUI noch nen ARP Lookup vorher oder legt nen static ARP entry an?
Wie gesagt nur wild geraten, aber da WOL/MACs sehr oft ARP heißt, vielleicht mal da ansetzen.
-
…wegen stromlos: bei mir hängen alle Rechner mit WOL an schaltbaren Steckdosen. Bei der Geschichte hier fällt mir wieder ein, warum das (u.a.) so ist :-)
-
…wegen stromlos: bei mir hängen alle Rechner mit WOL an schaltbaren Steckdosen. Bei der Geschichte hier fällt mir wieder ein, warum das (u.a.) so ist :-)
;D ;D ;D
Schön. Hilft mir aber nicht weiter, die Idee mit stromlos machen. Wenn der Strom zurückkommt, starten die Rechner ohnehin von selbst. Das soll aber auch funktionieren, wenn sie am Netz bleiben.An einem laufenden Rechner scheitert es auch nicht, daher bringt mir der Pi nichts. Es sollte eben von einem LAN-Rechner zentral gesteuert werden, der kann aber nicht direkt Rechner in der DMZ aufwecken und muss dafür wieder einen laufenden DMZ-Rechner bemühen. Soweit habe ich das auch schon gelöst.
Über die Firewall wäre die Sache halt einfacher gewesen, weil die ohnehin Teil von LAN und DMZ ist.@JeGr:
Das mit dem ARP Lookup verstehe ich nicht. Wenn der Rechner seit dem Start der Firewall nicht läuft, kann der Eintrag ja gar nicht in der ARP Table stehen. Da kommt er doch erst dann rein, wenn er sich mit seiner IP gemeldet hat, und dafür müsste er erst laufen.
Auch sollte WOL gar nichts mit ARP zu tun haben, weil dafür ohnehin nur die MAC nötig ist. -
Sorry, ich kann mich echt nicht mehr entsinnen WAS genau es war, aber ich hatte schonmal sowas mit WOL bzw. Magic Packets und ARP deshalb auch "blöde Idee" einfach mal nachzuschauen ob da was zu sehen ist irgendwie. Oder ggf. die Arp Table auf dem Switch sofern du die einsehen kannst. Strohhalme und so ;)
-
Beide Rechner standen Anfangs nicht in der ARP Table der FW. WOL über SSH Test war negativ.
Beide über GUI-WOL gestartet. Den Windows Rechner gab es dann auch gleich in der ARP Table, vermutlich müssen die immer gleich nach dem Start Billy-Boss anrufen. Den Linux-Rechner musste ich erst anpingen, um einen ARP Eintrag zu bekommen.Danach die Rechner wieder runter gefahren und WOL via SSH versucht. Wieder auf beiden erfolglos.
Der Switch zeigt mir die ARP Tabelle nicht an. Aber führe ich WOL von einem anderen Rechner im Netz aus, läuft das auch über den Switch.
-
Mal mit static ARP Eintrag probieren?
-
Da müsste man mich erst überzeugen, dass die IP für WOL erforderlich tatsächlich ist.
-
meinjanur…
Und mal in das GUI script für WOL geschaut, was das so macht?
-
Ehrlich gesagt, weiß ich jetzt auch gar nicht, wo in der pfSense static ARP Einträge anzulegen wären.
Aber warum versprichst du dir davon was? Beim Versuch zuvor waren beide Rechner in der ARP Tabelle der pfSense abgelegt, und beiden habe auf den SSH-WOL Befehl nicht reagiert.
Die pfSense Scripte zu interpretieren ist für mich als Nicht-Programmierer mühsam. Das gehe ich heute nicht mehr an.
-
Static ARP geht ganz einfach im DHCP, wenn man eine feste IP zuordnet (haben meine WOL alle).
Ick habe mal (als totaler NICHTprogramierer) in das WOL script geschaut:
if (!mwexec("/usr/local/bin/wol -i {$bcip} {$mac}")) {
Da wird neben der MAC auch eine "bcip" an WOL übergeben, die bcip wird bestimmt durch:
$bcip = gen_subnet_max($ipaddr, get_interface_subnet($if));
…. nur mal so ;-)
-
Das ist einen Service Netz, da läuft kein DHCP.
Ick habe mal (als totaler NICHTprogramierer) in das WOL script geschaut:
;D
Da wird neben der MAC auch eine "bcip" an WOL übergeben, die bcip wird bestimmt durch:
Das ist interessant. Siehst du auch, wo das Script die IP daher nimmt und was es damit macht?
Im GUI WOL werden gar keine IPs angegeben, so müsste die pfSense erst einen NS Lookup machen, um an die IP zu kommen. Wenn so, erhält sie die auch, wenn sie dynamisch ist.Anm.: Auf meiner pfSense läuft auch kein DNS.
-
Die man-page von wol schrob:
-i HOST
–ipaddr=HOST
Broadcast packet to this IP address or hostname. This is important if your wol client is a multihomed host and you want to send only to one subnet (default IP address is 255.255.255.255).Also wenn man keine angibt, dann wird einfach die 255.255.255.255 mitgeschickt...
:-p
-
Ja wobei aber 255.255.255.255 wahrscheinlich eben falsch ist. Vielleicht klappts deshalb erst nachdem die Kisten einmal bekannt waren.
Da gabs auch Bezüge in Redmine für
https://redmine.pfsense.org/issues/4318
https://redmine.pfsense.org/issues/5654So wie das aussieht muss das wol command mit der BC IP des Interfaces gestartet werden. Also bspw. im Netz 10.0.0.0/24 mit wol -i 10.0.0.255 ma:ca:dr
se:00:01Oder so ähnlich ;) Beim Routen sollten nämlich komplette Broadcasts 255.255.255.255 verworfen werden, sonst würde dir ja das ganze Internet anworten ;) Ergo vermute ich, dass der Fallback hier auf 4x255 dir bei deinem Shell Command evtl den Nerv tötet ;)
-
bcip = BROADCAST IP ! Würde ich mal sagen, also die öberste IP im subnet, in dem die entsprechende MAC Adresse liegt, daher die Wahl des Interface, auf dem die entspechende MAC zu Hause ist in der GUI.
Probier mal:
wol -i <broadcastdresse des="" netzes=""><mac>in der Konsole…</mac></broadcastdresse>
-
uups, Überschneidung, aber wir sind da ja scheinbar einer Meinung @JeGr… :-D
-
Jep und ich bin gespannt ob es was bringen mag.
