[Gelöst] Wake on LAN auf der Shell
-
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 ;-)
