[Gelöst] Wake on LAN auf der Shell
-
Weiß jemand von euch, wie man auf der Shell andere Rechner aufwecken kann.
Aus der help des wol-Befehls habe ich mir den Zeile
wol -i <host-ip-adresse> <host-mac-adress></host-mac-adress></host-ip-adresse>
zusammengereimt. Der Befehl wird auch ohne Murren akzeptiert und mit
Waking up <host-mac-adresse>...</host-mac-adresse>
bestätigt, zum Leben erweckt er aber keinen meiner Rechner. :(
Der Befehl wird übrigens auch akzeptiert, wenn man die -i Option samt IP Adresse weglässt, obwohl pfSense dann gar nicht wissen kann auf welchem Interface es das Magic Paket rausschicken soll. Die Angabe des Interface selbst wie in der GUI sieht der Befehl nicht vor.
-
Ist den Wake Up on LAN im Bios der Rechner aktiviert?
Funktioniert dies von einem Rechner zum andern? -
Ja, es funktioniert auch auf der pfSense GUI.
-
Öhm, habe genau deinen Befehl (mit -i ) eben in die Shell der pfsense 2.3.1_1 x64 full eingegeben und der Rechner ist aufgewacht.
Keine Probleme hier soweitl
-
Keine Chance hier. Habe selbes Release.
Habe es eben nochmal auf der Konsole, via SSH und am Command Prompt der GUI auf 2 pfSense (im CARP) getestet, und das mit 2 verschiedenen Zielhosts. Es rührt sich damit einfach nichts! >:(
Beide Hosts starten anstandslose über die GUI Services > Wake on LAN.Dummerweise habe ich eben festgestellt, dass ich auch von einem Linux-Host mit wol keinen Rechner starten kann, also vermutlich nicht ein pfSense Problem.
Was kann dabei schief gehen? Die pfSense GUI sendet ebenso ein Magic Paket wie der wol Befehl und auf die GUI reagieren die Rechner. -
Eventuell die MAC Adresse anders übergeben als via GUI? Evtl. ist das command sensitiv gegenüber HEX Zeichen in groß/klein? (Mal als doofe Vermutung einwerf)
-
Ich würde es mal von einem Rechner probieren, der am selben Switch hängt wie der, den du starten willst. Das sehe ich im Moment als einziges greifbares Probelm.
Wenn du keine VLANs, Virtual Machine oder Wifi Gedöns im NEtz hast ;-)
@JeGr ich hab's einfach aus der Liste der statics in meinem WOL der pfsense rauskopiert und in die Konsole gepastet…
-
War auch nur so eine Idee, dass das vielleicht vorher irgendwas konvertiert wird (hatte das an anderer Stelle schonmal als Problem).
-
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:drse:00:01
Oder 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.
-
Klaro! 100% sicher dass das funzt!
PS: wetten der ist um halb sechs heim gegangen? :-D
-
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>
Damit starten die Dinger! Ich werd verrückt.
Die -i Option hätte ich nicht so verstanden, dass die Broadcast Adresse anzugeben wäre. :-\
-
Ich glaube das war auch was mir im Kopf noch falsch als ARP rumgegeistert ist. Das Magic Packet muss ja zielgerichtet werden, sprich es muss theoretisch ohne IP raus, aber bei mehreren Interfaces muss es ja richtig abbiegen und ins richtige Subnetz abzweigen. Macht irgendwie Sinn ;) Aber gewusst hätt ichs auch nicht mehr :D
-
Meine Denke dazu war, die pfSense kennt eh das zur IP gehörige Netz.
Aber wenn man sich es genau überlegt, den wol Befehl gibt es ja nicht nur auf Routern, sondern der ist recht allgemein auf Unixioden Sytemen, und die kennen natürlich nicht ein anderes Netz.Danke für Eure Hilfe!
:)Aber jetzt doch ein schönes Wochenende. Mein Bier ist schon kalt. ;)
-
Wenn static ARP aktiviert funktioniert es ja auch mit -i und der nominellen IP des hosts , den ich wecken will. Nur scheinbar nicht, wenn die pfSense die IP garnicht kennt?!?
-
Nur der Ordnung halber: Das funktioniert nun auch nach einem Neustart der pfSense.