オンボードNICのWoL出力が接続され、ブートではなくシステムリセット(私の意見ではNMI経由)が発生する独自のハードウェアがあります。
これは、PDUやIPMIの交換コストを発生させることなくリモート再起動を容易にするために行われたようです。
しかし、OSがロードされるとWoL機能が抑制されるようです。 memtest 86はこれを抑制しませんが、Linuxは抑制することがわかりました。頑張ったethtool -s wol a/u/m/b/a/g/s
私は正しい道を行っていますか? OSの実行中にWoLを目覚めたままにする方法は?
/ # lspci -nn | grep -i net
01:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
/ # ethtool -i
ethtool -i eth0
driver: e1000e
version: 2.3.2-k
firmware-version: 2.1-0
bus-info: 0000:01:00.0
/ # uname -a
Linux (none) 3.19.0 #1 SMP Mon Oct 19 15:48:25 CDT 2015 x86_64 GNU/Linux
/ #
ターゲットカーネルは、最新のCentOS、Ubuntu、Debian、Windows、Proxmox(Debian)、およびVMwareです。
私はWoLをオペレーティングシステム「外部」で実行したいと思います。必要に応じて、OSがこれを無効にできることに同意しますが、デフォルトではそうではありません。 WoLが単にBIOSでアクティブになり、ハードウェアでサポートされている場合、OSは何をしても一貫して動作します。
答え1
Intelは現在、NICチップのデータシートを見るために登録したいと思っていますが、Googleはここで82574シリーズのデータシートを見つけました。https://docs.rs-online.com/96e8/0900766b81384733.pdf
私が知っている限り、データシートにはWake-on-LANパケットを待っている間にカードが正常に送受信できるかどうかは実際には示されていません。ただし、データシートでは、着信パケットにフィルタを適用する方法について説明します。これらのフィルタは通常の着信トラフィックを妨げる可能性がありますか?
私の最初の推測は、WoL機能が中断される正確な時間は、PCI(e)バスがリセットされたとき、またはNICドライバがロードされたときです。 WoLが停止しないという事実はmemtest86
後者かもしれないことを示唆しています。それでは(おそらく役に立たない)答えがあるでしょう。NICドライバのロード防止また、WoL-as-reset機能が提供されますが、システムへのネットワーク接続も必要な場合は、別のNICが必要です。 :-(
Linuxe1000e
ドライバは実際にWoL機能のみを有効にしているようです。ドライバーが閉じたとき。私にとっては、WoLを有効にすると、どのような方法でもNICの一般的な機能を妨げる可能性があることを示しています。