Reproducing PROFINET in the Lab: Discovery, AR Establishment, and Cyclic RT Boundaries

Description and use

A reproducible PROFINET lab was built using Linux namespaces and the p-net stack, enabling detailed study of discovery, application‑relation, and cyclic RT traffic, and revealing limitations of the open‑source implementation.

Problem

Reproducing PROFINET behavior in a controlled lab environment to understand observable protocol surfaces and identify limits of open‑source implementations.

Outcome

Established a repeatable PROFINET lab that captures discovery, application‑relation, and cyclic RT traffic. Identified limitations in the open‑source stack (e.g., station‑name write protection) and documented the boundary where packet construction no longer guarantees endpoint behavior.

Workflow

• Set up Linux network namespaces for controller and device
• Deploy p-net stack in device namespace
• Capture DCP and LLDP discovery traffic
• Verify station name, vendor ID, IP config, and LLDP topology
• Attempt station‑name update to test write protection
• Capture DCE/RPC over UDP 34964 for AR/IOCR/AlarmCR blocks
• Analyze request/response UUIDs, opnums, and association
• Capture cyclic RT frames with EtherType 0x8892
• Document packet fields, timing, and endpoint behavior
• Review security implications of discovered surfaces

Evidence

The first phase established the identity and Layer 2 visibility of the device under test.

Source

The device continued reporting: rt-labs-dev. The update did not take effect.

Source

The packet capture showed a controller-to-device request followed by a device-to-controller response.

Source