Workgroup and client bridges on vehicles

A vehicle’s PLC does not roam. Its bridge does. The bridge is the Wi-Fi client that carries the vehicle’s wired devices onto the WLAN, and two of its choices decide what those devices experience: how it presents them to the network, and when it leaves one access point for the next.

Why a vehicle uses a bridge

Giving every controller and I/O chassis its own Wi-Fi radio rarely works. A jointly published industrial wireless design guide lists the reasons: too few antenna options, poor RF characteristics, placement limits, and too many radios packed into too little space. Its answer is a workgroup bridge, one radio that operates as a single wireless client of the access point. Behind it sit the HMIs, I/O, controllers and drives, on a small switch. The guide’s design carries up to 19 devices behind a single bridge¹, and it ran standard and safety I/O through bridges in its tests.

The pattern fits vehicles. PI’s PROFINET design guideline names automated guided vehicles and extensive conveying systems as good candidates for wireless.

The split matters. The radio, its antennas and its roam settings live in the bridge. The PLC and the safety controller behind it never see a scan or a handshake. They see packets stop and start. The bridge is the device you configure, and the device you test.

Three addresses are not enough

An ordinary data frame from a client to its access point names three stations: the AP as receiver, the client as transmitter, and the final destination. The client’s own address doubles as the source. The Linux kernel reads it exactly that way: without a fourth address, a frame’s source is address 2, the transmitter².

That leaves no field for a device behind the bridge. A wired switch would simply forward that device’s frame. A Wi-Fi client cannot: RFC 4389³ notes that classic bridging needs promiscuous mode, and that a wireless client cannot put its wireless interface into it.

Bridges get around this in three ways.

One device. The simplest bridge carries a single wired client, one MAC address. The design guide set that mode aside for that reason.

Address translation. The bridge sends everything under its own MAC address and answers address lookups for the devices behind it. RFC 4389 describes IPv4 ARP proxying as the long-standing fix, and its IPv6 proxy substitutes its own link-layer address inside the payload of every packet that carries one.

Four addresses, or registration. A four-address frame carries the original source and final destination beside the two radios. In Linux, both the client and the AP need to transmit 4-address frames⁴, and the Linux access point daemon turns this on with its 4-address station mode⁵. Vendor bridges add a registration step. In the design guide, the bridge learns its wired clients’ MAC addresses and reports them to the access point. One vendor’s 2025 configuration note⁶ says its bridge sends those reports to the controller in IAPP messages.

What translation breaks

Translation works for IPv4 unicast because ARP gives the bridge something to answer. Beyond that, a device behind the bridge gets only what the bridge was built to handle.

Layer 2 protocols. PROFINET cyclic I/O runs directly on layer 2 with Ethertype 0x8892, without TCP/IP⁷. Each PROFINET device is addressed by its own MAC address, and its name is tied to that address through DCP. A bridge that puts its own MAC address on every frame hides the address that model depends on. OpenWrt’s relay mode, for example, handles IPv4 only⁸.
Broadcast and multicast. The same relay mode includes DHCP and broadcast relaying, and its documentation notes that link-local discovery such as mDNS is generally not routable. Anything else is up to the bridge.
Duplicate address detection. RFC 4389 lists as a requirement that a device moving between segments keeps its address without the proxy’s cache making it look like a duplicate. Ask how a translating bridge meets that.

If the vehicle carries PROFINET, or anything else that lives below IP, rule out translation first.

Four addresses are not a guarantee

802.11 frames have room for a fourth address. How makers use it is another matter. The Linux wireless documentation calls WDS a non-standard extension, often implemented differently in drivers and vendor firmware, and incompatible between them. It says Linux’s own 4-address mode is not compatible with other WDS implementations either. Its advice is the same hardware and software on every device.

IEEE added a standard way to use 802.11 links as transit links within 802.1Q bridged networks⁹: 802.11ak, General Link, published June 14, 2018¹⁰. Whether a given bridge and access point implement it is a question for both vendors. No source found for this page shows two makers’ four-address bridging working together. Test the exact pair, at the firmware you will run, before it goes on a vehicle.

Four addresses also bring Ethernet’s rules onto the radio. An AP that receives a broadcast from a four-address client must not send it back to that client, and loop suppression may mean blocking individual client links at the AP. Those points come from a presentation to an IETF working group by a former IEEE 802.11 task group chair, offered as the presenter’s own view.

The bridge decides when to roam

The network can suggest a target. The client decides, and on a vehicle the client is the bridge. One vendor’s roaming primer says it plainly: the client always decides when and where to roam, and the algorithm is vendor specific.

In the design guide, a roaming bridge looks for a new access point on poor RSSI, excessive interference, too many lost beacons, or a high frame-loss percentage. It roams before it loses its current association. By default it scans every channel in the band. A scan list narrows that, and putting every roaming AP on one channel gives the fastest roam. That choice also stacks every cell on one channel, which co-channel contention weighs. The roam threshold is a signal level in dBm, to be tuned to the RF and to test results.

Those settings are the roam. Record them, and test them on the route. Shortening or hiding the roam covers which fast-roaming methods to ask a bridge for, and the client roaming matrix shows what common client platforms support.

Multicast and implicit I/O through a bridge

EtherNet/IP carries I/O and safety data in implicit messages, which use UDP and can be unicast or multicast. Over a radio the difference is large. The design guide warns that multicast frames are not acknowledged and not repeated if lost, and says to use only unicast connections for wireless I/O. It lists unicast support from ControlLogix firmware v18 for standard I/O and v20 for safety I/O, and CIP Sync as multicast only as of v24.

Some access points convert multicast to unicast for each client. hostapd’s option sends each station its own copy, with the destination replaced by the station’s MAC address, and warns that this may break expectations at the receiver. Behind a bridge, that station address is the bridge’s own. Ask the bridge vendor what it does with such a frame. Multicast and DTIM with implicit I/O covers the failure.

After the roam: the devices behind it

A roam moves the bridge and everything behind it. The wired network has to learn the new path for every one of those addresses.

When a client is authorized, a Linux access point broadcasts a Layer 2 Update frame¹¹ to update forwarding tables in the switches. It carries the client’s own address. The devices behind a bridge are not in it. How the network learns their new location, and how long that takes, is the subject of wired MAC table convergence after a roam.

One bridge or two

One bridge is one radio, one roam decision and one point of failure. A second bridge on another channel or band can keep a link up while the first one roams. That is the make-before-break idea on the roaming options page.

It also gives the wired devices two paths to the same network. The four-address presentation notes that bridging protocols such as spanning tree work best when each client link looks point-to-point, and that loop suppression may mean blocking individual links. A design with two bridges has to decide, on purpose, whether one path waits or both carry traffic and duplicates are discarded. Redundant radio paths covers the options.

What to ask a vendor

How the bridge presents wired devices: single client, address translation, four-address frames, or registration. Which of those works with your access points, by model and firmware.
How many wired devices it supports behind one radio.
Whether it passes non-IP Layer 2 frames, such as PROFINET, and multicast, unchanged.
What triggers a roam, which thresholds you can set, and how its scan list works.
Which fast-roaming methods it supports for your key type, and whether any of them need the same maker’s access points.
What it does after a roam to announce the devices behind it.
Whether two can run on one vehicle, and how that design avoids loops and duplicate frames.

Your PLC never roams. Its bridge does, and every setting that decides the gap lives in the bridge.