gitproxy/RTLPlayground
1
0
Fork 0
mirror of https://github.com/logicog/RTLPlayground.git synced 2026-09-02 15:02:51 +08:00
Code Issues Packages Projects Releases Wiki Activity

doc: separate the trap action from CPU-port delivery

Browse Source 
The wording read as a claim about the CPU interface in general, which is
wrong and misleading: the 8051 sits behind an ordinary port of the internal
switch and is an ordinary member of a forwarding mask - which is exactly
what this implementation relies on.

Say what is actually broken instead: the trap action, a separate mechanism
whose destination is an external CPU port these boards do not populate.
Record the measurements behind it, including the widened CPU_PMSK and both
external-CPU destinations, and add the ACL trap result - a rule matching the
group intercepts frames but does not deliver them either, which is a second,
independent path to the same conclusion.

Reported-by: vDorst
This commit is contained in:
d00f
2026-08-18 23:28:37 +02:00
committed by d00f
parent be520d6716
commit 4b5bf09c83
1 changed files with 17 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/stp.md
+17 -4
View File
@@ -38,10 +38,23 @@ stp on
BPDUs are addressed to `01:80:C2:00:00:00`, a reserved link-local group. The
ASIC's Reserved-Multicast action for that address decides what happens to the
frame. The "trap to CPU" action does **not** reach the internal 8051 on this
hardware — its trap destination is an external CPU attached to a physical port
(`cpuTag_externalCpuPort_set` in the vendor SDK), which these boards do not
have. Delivery therefore uses the *forward* action, constrained to the CPU port
frame.
Forwarding to the CPU port works normally — the 8051 sits behind an ordinary
port of the internal switch and is an ordinary member of a forwarding mask.
What does not work is the *trap* action, which is a separate mechanism: its
destination is an external CPU attached to a physical port
(`cpuTag_externalCpuPort_set`, `EXT_CPU_CTRL` in the vendor SDK), which these
boards do not populate. Measured on a SWTGW218AS: with the RMA action set to
trap, zero frames arrive at the 8051, including with `CPU_PMSK` widened and the
external-CPU destination pointed at both `0xF` and `9`; with the *forward*
action plus the L2 entry below, they arrive. The ACL trap behaves the same way,
measured on the neighbouring reserved group `01:80:C2:00:00:02`: a rule matching
it intercepts the frames — the LACP receive counters stop advancing while the
rule is enabled and resume the moment it is disabled — but they never reach the
8051, with `FWD_INT_TRAP` and with `REDIRECT` aimed at the CPU port alike.
Delivery therefore uses the *forward* action, constrained to the CPU port
by a static L2 multicast entry (`port_l2mc_set()`), one per VLAN in use:
* while STP runs, the entry's member mask is the CPU port only — BPDUs reach