Overview
Waking a remote panel PC, IPC, or workstation from a SIMATIC S7-300 PLC requires the controller to emit a Wake-on-LAN (WOL) "magic packet" addressed to the target's MAC address. The S7-300 CPU's integrated PROFINET interface does not implement raw MAC-layer ISO transport connections, so the recommended path is to add a CP 343-1 communications processor and configure a NetPro ISO transport or UDP connection. This article documents the exact byte structure of the magic packet, the Siemens part numbers that matter, the protocol choice between ISO transport and UDP, the STEP 7 configuration steps, sample SCL/STL code that builds and transmits the frame, and a field-tested troubleshooting matrix.
The WOL use case is fully covered by AMD's Magic Packet Technology specification, and the panel PC (for example a Siemens SIMATIC iPC277E) only needs the WOL option enabled in its BIOS/UEFI and a powered standby state on the network interface.
Prerequisites
- SIMATIC S7-300 CPU, any variant from 312 to 319, FW ≥ 2.6 if the integrated PN port is used for UDP.
- CP 343-1 communications processor inserted in the S7-300 rack. Recommended MLFB:
6GK7343-1EX30-0XE0(full protocol set, ISO transport, ISO-on-TCP, TCP, UDP, S7 communication). Acceptable substitutes:6GK7343-1EX21-0XE0(legacy firmware) or6GK7343-1GX30-0XE0(Advanced). - STEP 7 V5.5 SP4 or higher, or STEP 7 Professional (TIA Portal) V13 SP1+ for newer CP 343-1 GSD/GSDML entries.
- SIMATIC NET PC software if the target PC must act as ISO transport server (otherwise use the UDP path).
- Wireshark on a mirrored port or on the target PC to capture the magic packet during commissioning.
- Target PC with WOL enabled in BIOS/UEFI, "Wake on Magic Packet" set on the NIC driver, and link/activity LED active in standby.
Wake-on-LAN Magic Packet Structure
Per AMD's Magic Packet specification, the wake frame is a fixed byte stream with no IP/UDP header required when it is injected as a raw Ethernet frame. The structure is reproduced in the table below.
| Offset | Length (bytes) | Value | Description |
|---|---|---|---|
| 0 | 6 | FF FF FF FF FF FF |
Synchronization stream (preamble) |
| 6 | 96 | Target MAC × 16 | 16 unaltered repetitions of the destination MAC |
| 102 | 0 (or 4/6) | Password (optional) | Most modern NICs ignore this field |
The fixed payload is therefore 102 bytes. When the packet is sent as a UDP datagram, the UDP/IP stack adds its own headers. The destination IP for a limited broadcast is 255.255.255.255; for a directed subnet broadcast use <net>.255. The destination UDP port is conventionally 7 (echo) or 9 (discard); most WOL agents accept either, and many allow any port.
For raw Ethernet injection, the Ethertype is 0x0842 and the destination MAC is FF:FF:FF:FF:FF:FF. The S7-300 cannot emit raw Ethernet frames directly, which is why the application must ride on top of UDP through a CP 343-1 or the integrated PN port.
0xFF. Tools that pad the field with 0x00 or interleave a 7E flag (HDLC) will not be recognized by the NIC's WOL state machine.CP 343-1 Hardware Variants
| MLFB | Designation | ISO Transport | UDP | Notes |
|---|---|---|---|---|
6GK7343-1CX10-0XE0 |
CP 343-1 Lean | No | Yes (limited) | Use only for the UDP broadcast path; no MAC-level ISO. |
6GK7343-1EX30-0XE0 |
CP 343-1 | Yes | Yes | Recommended for the ISO transport WRITE path. FW ≥ V3.0. |
6GK7343-1EX21-0XE0 |
CP 343-1 (legacy) | Yes | Yes | FW V1.x; verify entry ID 26171811 for protocol matrix. |
6GK7343-1GX30-0XE0 |
CP 343-1 Advanced | Yes | Yes | Adds IP routing and security. Required if the PC is on a different subnet. |
6GK7343-1HX00-0XE0 |
CP 343-1 IT | Yes | Yes | Adds web/FTP server. Heavier than the Lean but more protocol-capable. |
For S7-300 PN CPUs (for example 6ES7315-2EH14-0AB0 FW 3.2 or 6ES7317-2EK14-0AB0 FW 3.2), the integrated PROFINET X2 port can emit the magic packet directly through FB65/FB67 open communication, eliminating the CP 343-1 hardware. This is the path most often chosen in modern retrofits because it avoids a slot in the central rack.
Protocol Selection: ISO Transport vs UDP
| Criterion | ISO Transport WRITE | UDP broadcast (TUSEND) |
|---|---|---|
| Frame carrier | ISO 8073 TPDU, MAC-level | UDP/IP, port 7 or 9 |
| Target endpoint | MAC + TSAP (PC must run an ISO transport listener) | MAC (built into the NIC's WOL state machine) |
| PC software required | Yes (S7-Link, RFC 1006 listener, or custom .NET code) | No (driver + BIOS option only) |
| Routable across subnets | No (MAC-bound) | Yes with directed broadcast or magic helper |
| Block on PLC | AG_SEND (FC5) / AG_RECV (FC6) | TCON (FB65) + TUSEND (FB67) |
| NetPro connection type | "ISO Transport Connection" | "UDP connection" |
| CPU support | CP 343-1 only (CPU PN port cannot terminate ISO transport to MAC) | CP 343-1 or PN CPU integrated port |
Recommendation: use the UDP path on a CP 343-1 or on the CPU's PN port unless the target PC must implement a Siemens-compatible ISO transport server. ISO transport is included here because it is the explicit suggestion raised in the support thread, and because a minority of installations still rely on a custom C# RFC 1006 server on the PC side.
Configuring the NetPro ISO Transport Connection
- Open the S7 project in STEP 7 and launch NetPro.
- Right-click the CP 343-1 in the rack and select Insert New Connection.
- Choose ISO Transport Connection as the type. The local partner (CP 343-1) is the active endpoint; the remote partner is the PC's NIC and is passive.
- Enter the PC's MAC address as the MAC address field. Do not enter an IP address; the connection is MAC-bound.
- Assign a TSAP pair: local TSAP e.g.
10.00and remote TSAP e.g.20.00. The PC listener must bind to20.00. - Confirm and let STEP 7 generate the connection DB (System Data Blocks). The connection ID is recorded here and is required by AG_SEND.
- Download the hardware configuration including the NetPro connection to the S7-300.
For the UDP path, repeat the steps above but choose UDP connection. Set the remote IP to 255.255.255.255 and the remote port to 9. The TSAP fields are replaced by the IP and port pair in this case.
Building the Magic Packet in a Data Block
Reserve a data block (for example DB100) of at least 102 bytes. The example below uses SCL for clarity; the same byte pattern can be generated with STL, LAD, or FBD.
DATA_BLOCK DB100
STRUCT
SyncStream : ARRAY[0..5] OF BYTE; // 0xFF x 6
MacRepetition : ARRAY[0..95] OF BYTE; // 16x target MAC
LengthField : INT; // = 102
END_STRUCT;
END_DATA_BLOCK
FUNCTION_BLOCK FB_WOL_Builder
VAR_INPUT
TargetMAC : ARRAY[0..5] OF BYTE; // e.g. 01-02-03-04-05-06
Build : BOOL; // rising edge triggers rebuild
END_VAR
VAR
i : INT;
j : INT;
END_VAR
BEGIN
IF Build THEN
FOR i := 0 TO 5 DO
DB100.SyncStream[i] := 16#FF;
END_FOR;
FOR i := 0 TO 15 DO
FOR j := 0 TO 5 DO
DB100.MacRepetition[i*6 + j] := TargetMAC[j];
END_FOR;
END_FOR;
DB100.LengthField := 102;
END_IF;
END_FUNCTION_BLOCK
If you prefer a direct fill (no loop overhead) use a pointer-driven FC that writes the 6-byte MAC 16 times into the destination area, or use the BLKMOV (SFC20) system function to copy the MAC 16 times after the 0xFF header has been written once. The same DB feeds either AG_SEND (ISO transport WRITE) or TUSEND (UDP).
Sending the Packet via ISO Transport WRITE
Use AG_SEND (FC5) from the SIMATIC_NET_CP library. The block references the connection ID generated by NetPro.
// Call parameters for AG_SEND (FC5)
CALL FC5 // AG_SEND
ACT := TRUE, // send trigger (rising edge)
ID := W#16#0001, // connection ID from NetPro (decimal 1 in this example)
LADDR := W#16#0100, // logical base address of CP 343-1 (here 256 decimal)
SEND := P#DB100.DBX0.0 BYTE 102, // pointer to the 102-byte magic packet
LEN := 102, // length of payload
DONE := DoneFlag, // one-shot done
ERROR := ErrFlag, // error bit
STATUS := StatusWord; // CP 343-1 status
The receiving PC must run an ISO transport server bound to the same TSAP as configured in NetPro. Typical implementations are SIMATIC NET S7-LAN, the S7 driver from MHJ-Software, or a custom RFC 1006 stack. The server reads 102 bytes and discards them; the side effect is that the frame crosses the wire and the target NIC's WOL state machine receives it.
FF:FF:FF:FF:FF:FF at the MAC layer if the OS NDIS filter already claims broadcast frames. A third-party RFC 1006 listener running in raw socket mode is the only practical way. This is why most projects use the UDP path instead.Sending the Packet via PN CPU UDP Broadcast (T-Blocks)
When the application uses a CPU 315-2 PN/DP, CPU 317-2 PN/DP, or CPU 319-3 PN/DP, the integrated PROFINET interface can send the 102-byte payload as a UDP datagram to a limited broadcast address. The blocks live in the Standard Library > Communication Blocks folder.
DATA_BLOCK DB_UDP_Params
STRUCT
TconPar : TCON_PAR; // UDT 65 - connection parameters
TUSendPar : TUSEND_PAR; // UDT 67 - send parameters
END_STRUCT;
END_DATA_BLOCK
FUNCTION_BLOCK FB_WOL_Sender
VAR
TCON_Inst : TCON; // FB65
TUSEND_Inst : TUSEND; // FB67
Connect : BOOL;
SendTrig : BOOL;
ConnDone : BOOL;
ConnErr : WORD;
ConnStatus : WORD;
SendDone : BOOL;
SendErr : WORD;
SendStatus : WORD;
END_VAR
BEGIN
// One-time connection parameters
DB_UDP_Params.TconPar.BlockLength := 64;
DB_UDP_Params.TconPar.Protocol := B#16#11; // UDP = 0x11
DB_UDP_Params.TconPar.LocalPort := 0; // any local port
DB_UDP_Params.TconPar.RemotePort := 9; // WOL discard port
DB_UDP_Params.TconPar.RemoteAddress := '255.255.255.255';
DB_UDP_Params.TconPar.ActiveEstablished := TRUE;
DB_UDP_Params.TconPar.ConnectionType := B#16#0B; // 0x0B = UDP broadcast
IF Connect AND NOT ConnDone THEN
TCON_Inst(REQ := TRUE,
ID := 1,
DB := DB_UDP_Params,
DONE := ConnDone,
ERROR := ConnErr,
STATUS:= ConnStatus);
END_IF;
IF SendTrig AND ConnDone THEN
TUSEND_Inst(REQ := TRUE,
ID := 1,
LEN := 102,
DATA:= P#DB100.DBX0.0 BYTE 102,
DONE:= SendDone,
ERROR := SendErr,
STATUS:= SendStatus);
END_IF;
END_FUNCTION_BLOCK
The same T-block pattern works on a CP 343-1 with a configured UDP connection, although the connection parameters are slightly different. In STEP 7 V5.5 the UDT 65/67/68 fields are populated by the NetPro wizard once the UDP connection is created.
Verification
- Power down the target PC to standby, leaving the network cable connected. Verify that the link LED remains lit.
- Connect a Wireshark capture on a mirrored port of the switch that carries the magic packet. Set the filter to
udp port 9 || ethertype 0x0842. - Trigger the
BuildandSendbits in the S7-300. Expect to see a UDP datagram from the CP 343-1 (or CPU PN port) to255.255.255.255:9containing exactly 102 bytes. The first six bytes must beFF FF FF FF FF FFand the next 96 bytes must be 16 repetitions of the target MAC. - Watch the target NIC's activity LED. A single short flash (3-15 ms) confirms the WOL state machine consumed the frame.
- The PC should power on within 1-5 seconds depending on BIOS POST duration.
- Re-run five times consecutively to confirm the S7-300 is not suffering from residual retries or DONE/ERROR flag latching.
Topology
Troubleshooting Matrix
| Symptom | Most likely cause | Diagnostic | Remedy |
|---|---|---|---|
| AG_SEND/TUSEND reports ERROR=1 and STATUS=8183 | Connection not loaded or wrong connection ID | Open NetPro and confirm the ID matches | Re-download the S7 program with NetPro; verify ID passed to the block |
| STATUS=8185 / 80B0 | CP 343-1 has not established the ISO transport connection | Check CP diagnostic buffer with STEP 7 > CP diagnostics | Verify PC listener is running and the remote TSAP matches |
| No frame visible in Wireshark on the mirror port | Switch is not mirroring the source port | Check the SPAN/mirror configuration | Reconfigure monitor session; some managed switches mirror only egress |
| Frame is visible but PC does not wake | WOL not enabled in BIOS/UEFI or driver | Check BIOS setting "Wake on LAN / PCIe"; check NIC advanced > Wake on Magic Packet | Enable both; reboot for BIOS change |
| Frame is visible but PC wakes then immediately sleeps | SecureBoot/UEFI rejects Magic Packet or driver filter strips it | Look at NIC advanced properties > "Wake on Magic Packet from power off state only" | Disable driver pattern filtering; set NIC to accept all magic packet formats |
| PC wakes only when PLC is on the same VLAN/subnet | Limited broadcast 255.255.255.255 is not forwarded by router |
Inspect routing on the Layer-3 device | Use directed subnet broadcast or a UDP unicast helper |
Magic packet contains 0x00 in the first 6 bytes |
DB is not initialized before AG_SEND is called | Read DB100 in STEP 7 online | Force a Build pulse on cold restart, or use a non-zero default value in the DB |
| AG_SEND DONE is never set | Job pending in the CP from a previous call | Check the CP diagnostics > "Open jobs" counter | Reset the CP with the AG_CNTRL block (FC10) before re-triggering |
Field-Proven Tips
- Always use a static IP on the CP 343-1's Ethernet interface. DHCP leases can change between PLC restarts and break the NetPro connection ID lookup.
- Issue the Build pulse at startup, then a periodic refresh every 10 minutes so a power-loss event cannot leave the DB in an unknown state.
- For the UDP path, set the CP's "Keep-alive" time to at least 60 s. If the PLC sits idle, some managed switches will age out the MAC entry and the broadcast will not leave the switch.
- On the iPC277E specifically, the WOL option is buried under BIOS > Power Management > Wake on LAN from S5. Set this to Power On, not Last State.
- When capturing with Wireshark, set the capture filter to
ether proto 0x0842 or (udp port 9 and greater 100)to suppress unrelated traffic but still capture the full payload.
FAQ
Why must I use a CP 343-1 instead of the CPU's integrated Ethernet port for ISO transport?
The integrated PROFINET interface of an S7-300 PN CPU supports TCP, ISO-on-TCP, UDP, S7, and PROFINET, but it cannot terminate a raw ISO transport connection that targets a MAC address. The CP 343-1 (6GK7343-1EX30-0XE0 or -1GX30-0XE0) is required for that protocol class. For WOL, however, the PN CPU can emit the magic packet via UDP without any CP.
Can the S7-300 CPU send a magic packet without any CP installed?
Yes, if the CPU is a PN variant (CPU 31x-2 PN/DP, FW ≥ 2.6). Configure the integrated PROFINET port with a static IP, create a UDP connection in NetPro pointing to 255.255.255.255:9, and use TCON (FB65) and TUSEND (FB67) to send the 102-byte payload.
What is the exact byte sequence of a Wake-on-LAN magic packet?
Six bytes of 0xFF (synchronization stream) followed by 16 unaltered copies of the target's 6-byte MAC address, for a total of 102 bytes. Most NICs accept this payload regardless of the UDP source or destination port, with port 7 or 9 being conventional.
Which UDP port should be used for Wake-on-LAN, 7 or 9?
Either port is accepted by all common NIC WOL agents. Port 9 (discard) is preferred because it avoids generating echo traffic if the target OS is running. The Magic Packet specification itself does not bind the protocol to a specific port.
Does Wake-on-LAN work through routers and VLAN boundaries?
A limited broadcast (255.255.255.255) is not forwarded by any IP router, so a magic packet only reaches the local subnet. To cross a router, use a directed subnet broadcast (e.g. 192.168.10.255) plus an IP helper-address on the router, or use a magic-packet-relay tool on a host inside the target subnet. Switches forward the UDP broadcast as long as the source MAC entry has not aged out.
How do I confirm the S7-300 actually transmitted the magic packet?
Mirror the PLC's switch port, run Wireshark, and filter on udp port 9 and greater 101. The captured frame must be exactly 102 bytes starting with six 0xFF bytes. Alternatively, check the CP 343-1 diagnostic buffer for send-job completion and inspect the Done/Error/Status outputs of AG_SEND or TUSEND.