A PROFINET lab in Linux namespaces separates what the capture proves from what the device did

Four components, two addressing schemes. DCP provides Layer 2 discovery and configuration functions, and LLDP contributes neighboring-device and topology information ^[5]. Acyclic application-relation traffic runs over DCE/RPC on UDP port 34964, carrying the structures associated with AR and IOCR configuration ^[6]. Cyclic Real-Time communication uses PROFINET's EtherType 0x8892 and puts process data directly onto Ethernet ^[7]. Tesla reports the DCP traffic on that same EtherType ^[8], so a capture filtered on `ether proto 0x8892` returns discovery and process data in one stream ^[17].

Discovery identifies a device without establishing a cyclic I/O relationship, and AR-related traffic has meaning only within a controller/device relationship ^[9]. A cyclic RT frame can have a recognizable layout and still depend on endpoint state and implementation behavior for acceptance ^[9]. The available open-source stack did not fully expose that controller/device behavior ^[4].

Tesla kept three kinds of evidence apart: what the captures established, what the application printed, and what a security conclusion could then claim ^[10]. On the last of those, he wrote that "a captured crafted frame proves that the frame reached the capture point. It does not tell me whether the target accepted it, rejected it, ignored it, or processed it in some other way" ^[11]. He added: "That sounds obvious, but it becomes easy to lose track of when a script reports a successful send and the capture looks exactly like the frame that was intended" ^[12].

A DCP Identify query from the controller side returned station name `rt-labs-dev`, vendor ID 0x0493, device ID 0x0002, and IP address 192.168.1.20 ^[13]. Those are the values the p-net device answered with inside a namespace. A fingerprinting rule keyed on them identifies that sample device; for it to identify plant hardware, the identity fields would have to come from plant hardware. The same condition governs the netload and malformed-input work: a namespace pair reproduces the framing, and firmware decides what to do with it.

Of the five phases, four involved direct laboratory experimentation and the fifth was a specification-driven review connecting the observations to PROFINET's historical Security Class model and newer secure application mechanisms ^[3]. The fifth produced no packets ^[18]. The security-mechanism conclusions rest on reading documents, which is a legitimate way to write that section and a different kind of evidence from a capture. The unglamorous part took the longest: Tesla reports spending considerable time on namespaces, virtual interfaces, routing, and the behavior of the open-source implementation before any of it worked ^[15].

The stated goal was to build a reproducible PROFINET laboratory, examine its observable protocol surfaces, and document the point where packet construction, implementation output, and verified endpoint behavior stop answering the same question ^[14]. The text as published breaks off during the discovery phase, before the DCE/RPC and cyclic RT captures appear ^[16].