{
	"id": "ec6df7eb-c44a-4b89-9f9e-636637416d11",
	"created_at": "2026-04-06T00:16:30.360404Z",
	"updated_at": "2026-04-10T13:11:54.403037Z",
	"deleted_at": null,
	"sha1_hash": "4f9de8f94e6832d57f47502530f37f84a96b0611",
	"title": "WakeOnLAN · Wiki · Wireshark Foundation / Wireshark · GitLab",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 133811,
	"plain_text": "WakeOnLAN · Wiki · Wireshark Foundation / Wireshark · GitLab\r\nPublished: 2024-01-11 · Archived: 2026-04-05 18:21:11 UTC\r\nSkip to main content\r\nWakeOnLAN\r\nWakeOnLAN (WOL)\r\nWakeOnLAN is the protocol name given to the so-called Magic Packet technology, developed by AMD and\r\nHewlett Packard for remotely waking up a remote host that may have been automatically powered-down because\r\nof its power management features. Although power management allows companies and individuals to cut power\r\nusage costs, it presents a problem for IT departments especially in being able to quickly and efficiently remotely\r\nmanage PC's, especially during off-hours operation when those PC's are most likely to be in a suspended or\r\nstandby state, assuming power management features are enabled.\r\nHistory\r\nFor a history of WakeOnLAN and Magic Packet technology, refer to either this wikipedia article, or read this\r\nAMD white paper.\r\nProtocol dependencies\r\nEthernet: According to AMD's white paper, WakeOnLAN depends only on Ethernet. However, the paper\r\nalso indicates that the Magic Packet can reside anywhere within the payload. This means that we would\r\nhave to search every Ethernet frame for the Magic Packet. In my opinion, doing so would degrade\r\nWireshark performance, especially since most traffic will not contain a Magic Packet. Therefore, the\r\nWakeOnLAN dissector has been implemented to dissect only the actual implementations of the Magic\r\nPacket. As of this writing, the author is only aware of 2 implementations, one being ether-wake which uses\r\nEthertype 0x0842, which is unfortunately not yet a registered Ethertype, and the other implementation\r\nbeing over UDP.\r\nUDP: Several tools mentioned in the above Wikipedia article implement the Magic Packet over UDP.\r\nPacket Format\r\nA physical WakeOnLAN (Magic Packet) will look like this:\r\nSynchronization Stream Target MAC Password (optional)\r\n6 96 0, 4 or 6\r\nhttps://gitlab.com/wireshark/wireshark/-/wikis/WakeOnLAN\r\nPage 1 of 3\n\nThe Synchronization Stream is defined as 6 bytes of FFh.\r\nThe Target MAC block contains 16 duplications of the IEEE address of the target, with no breaks or interruptions.\r\nThe Password field is optional, but if present, contains either 4 bytes or 6 bytes. The WakeOnLAN dissector was\r\nimplemented to dissect the password, if present, according to the command-line format that ether-wake uses,\r\ntherefore, if a 4-byte password is present, it will be dissected as an IPv4 address and if a 6-byte password is\r\npresent, it will be dissected as an Ethernet address.\r\nExample traffic\r\nHere is a screenshot of some WakeOnLAN traffic:\r\nWireshark\r\nThe WOL dissector is fully functional for Ethertype 0x0842 and for UDP only. It was first included with\r\nWireshark starting with Git commit 6785ffd7 on November 6, 2007. General availability began with the 0.99.7\r\nrelease of Wireshark.\r\nPreference Settings\r\nCurrently, there are no preferences for the WOL dissector; however, in some cases you may need to ensure that the\r\nUDP \"Try heuristic sub-dissectors first\" preference is enabled in order for WOL dissection to work. When\r\nenabling this UDP preference, keep in mind that heuristics are not fool-proof, so it's possible that enabling it could\r\nadversely affect dissection of other protocols. Enable it with caution.\r\nExample capture file\r\nA simple example capture file containing WOL traffic is available on the SampleCaptures page.\r\nhttps://gitlab.com/wireshark/wireshark/-/wikis/WakeOnLAN\r\nPage 2 of 3\n\nSampleCaptures/wol.pcap\r\nDisplay Filter\r\nA complete list of WOL display filter fields can be found in the display filter reference\r\nExample: Show only the WOL based traffic:\r\nCapture Filter\r\nAs WOL is currently implemented, you can use the following capture filter to be reasonably assured of capturing\r\nmost WOL traffic; however, to guarantee all WOL traffic is captured, at least as far as the dissector is concerned,\r\nyou should omit the \"port 9\" qualifier in the capture filter expression:\r\n ether proto 0x0842 or udp port 9\r\nExternal links\r\nMore information about WakeOnLAN can be found on wikipedia.\r\nThe AMD white paper is also an excellent source of information.\r\nDiscussion\r\nImported from https://wiki.wireshark.org/WakeOnLAN on 2020-08-11 23:27:16 UTC\r\nSource: https://gitlab.com/wireshark/wireshark/-/wikis/WakeOnLAN\r\nhttps://gitlab.com/wireshark/wireshark/-/wikis/WakeOnLAN\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://gitlab.com/wireshark/wireshark/-/wikis/WakeOnLAN"
	],
	"report_names": [
		"WakeOnLAN"
	],
	"threat_actors": [],
	"ts_created_at": 1775434590,
	"ts_updated_at": 1775826714,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4f9de8f94e6832d57f47502530f37f84a96b0611.pdf",
		"text": "https://archive.orkl.eu/4f9de8f94e6832d57f47502530f37f84a96b0611.txt",
		"img": "https://archive.orkl.eu/4f9de8f94e6832d57f47502530f37f84a96b0611.jpg"
	}
}