Bridge 3-address WLAN clients through discovered OW helpers

[TurkeyMan]

Why this should exist

A three-address 802.11 station cannot transmit bridged Ethernet frames whose source MAC belongs to a client behind it. Native four-address/WDS operation remains preferable when the driver and AP support it, but that is not generally available. IP-layer ARP-NAT/relayd approximations also do not preserve arbitrary Ethernet traffic.

This proposes an OpenWatt-native fallback: discover a nearby OW bridge, tunnel only traffic affected by the station limitation, and let the helper participate in the existing bridge learning machinery.

Design

• A three-address WLAN member solicits OW bridge helpers per VLAN when it first sees a foreign-source frame.
• The station selects the first nonce-matching offer and unicasts subsequent assisted frames to that helper using the existing OW Ethernet codec.
• The helper decapsulates at the bridge's existing attachment point, so ordinary source learning installs the return path.
• Return multicast and unknown-unicast traffic is replicated as OW unicast to registered assisted stations. It is deliberately not sent as OW broadcast: with multiple helpers that creates a helper-to-helper decapsulation and re-encapsulation loop.
• There is no dynamic managed bridge object or synthetic port. The helper is thin state attached to the bridge, and ordinary learned-unicast forwarding is unchanged.
• OW parsing remains in the existing OW ingress path. The ordinary bridge hot path adds only empty-state checks when STA assistance is unused.

Review verdict

The capability is worth pursuing, but this draft is not merge-ready. It establishes the mechanism and is useful for reviewing whether the protocol belongs in OpenWatt before hardening it.

Merge blockers

• Path L2 MTU: a full-size inner Ethernet frame requires roughly 1533 bytes untagged or 1537 bytes with a VLAN tag on the outer link. Enlarging the local packet buffer does not prove the entire helper path can carry that frame. We need a defined MTU policy: constrain helper placement, probe and attenuate where meaningful, or add fragmentation/reassembly.
• Lease and failover lifecycle: discovery retries allow a station to choose a replacement helper, but helper peer state and related bridge learning currently have no explicit expiry. The protocol needs a small claim/lease or keepalive model with coherent cleanup.
• Topology tests: cover two simultaneous helpers, VLAN separation, ARP/DHCP multicast, unknown unicast, helper failure/reselection, and maximum-sized frames.
• Trust model: any OW bridge on the same L2 can offer assistance and become a forwarding point. This must either be explicitly limited to a trusted OW domain or bound to an authentication/authorization mechanism.
• Native four-address capability: the current WLAN capability hook defaults to three-address behavior and has no driver override yet. Drivers that support native four-address mode must bypass assistance.

Validation

• Rebased on current master.
• CONFIG=unittest FEATURES=switch compiles successfully against the uRT revision pinned by master.
• The resulting unit-test executable stops at the existing src/manager/console/command.d:524 assertion before router tests execute; this PR therefore does not claim a passing unit-test run.