Damaged frames¶
tshark 4.6.8 and the engine on damaged recordings, 2026-11-03¶
A frame damaged after the radio's FCS check, on its way over USB or in the Pi, reaches tshark as it is. The sensor has shown two such frames in its recordings, both left out: a beacon with Bad FCS on capB (2026-10-30) and a frame of protocol version 3 from a radio on USB 2 under load (sensor-link.md). A tshark that crashed or hung on one would end the radio's capture, which the live plan restarts, and fail the session on a second end within 10 s (LivePlan.restartWindow); the replay would run into the same frame.
editcap -E <p> --seed <n> changes each byte of a recording's records with the probability p, the radiotap header and the MAC header included; a frame of about 130 bytes is damaged somewhere at p = 0.0001 about once in a hundred. Each damaged pcap went through the decoder's two passes on stdin, as in a session: the field list (TsharkField.arguments) and the JSON of the management frames (ManagementDecoder.arguments), with a limit of 600 s each.
The two passes¶
Three seeds per probability; every run ended with exit status 0, within seconds, every line with the field list's columns and the four fields Frame requires, every JSON packet with its frame number. Frames without a type are those the decoder skips as no 802.11.
| Recording (capA) | Frames | p | Frames without a type | JSON packets |
|---|---|---|---|---|
testlab-wifi7-one-link |
55,009 | 0.0001 | 23–31 | 11,453–11,459 |
| 0.001 | 298–338 | 11,409–11,434 | ||
| 0.01 | 3,090–3,123 | 11,019–11,058 | ||
| 0.05 | 13,503–13,656 | 9,635–9,645 | ||
testlab-co-channel |
189,374 | 0.001 | 1,165–1,205 | 10,657–10,665 |
| 0.01 | 11,689–12,100 | 10,938–11,047 | ||
| 0.05 | 51,892–51,960 | 11,853–12,003 | ||
testlab-mlo-reconnect |
95,712 | 0.001 | 497–511 | 10,265–10,277 |
| 0.01 | 5,137–5,248 | 10,127–10,169 | ||
| 0.05 | 23,368–23,463 | 9,507–9,577 | ||
u7-phone-ft-roam |
14,031 | 0.001 | 79–89 | 1,401–1,413 |
| 0.01 | 797–813 | 1,395–1,411 | ||
| 0.05 | 3,545–3,655 | 1,320–1,333 |
The replay¶
linkside-cli replay on copies of four sessions with both captures damaged, 43 runs: testlab-wifi7-one-link, testlab-co-channel, u7-phone-ft-roam and ap45-phone-reauth-asleep, at p from 0.00001 to 0.05, two or three seeds each. Every run ended without an error, within 18 s.
The engine takes a damaged frame that still reads as 802.11 at its word. Against the clean replay, at the two lowest probabilities, three seeds each:
| p | Outcome (the side) | What changed |
|---|---|---|
| 0.00001 | the clean one in 12 of 12 | one uplink-loss finding came in (u7-phone-ft-roam), which became the reason of the undecided outcome; the other 11 as clean |
| 0.0001 | the clean one in 12 of 12 | uplink-loss came in twice (testlab-wifi7-one-link, u7-phone-ft-roam); in testlab-co-channel beacons with a damaged BSSID grew the BSS table from 9 BSSs to 26–32, congestion named five to seven other APs on the client's channel where the clean replay named none, and BA success read up to a point lower (99.0 to 99.2 % against 100.0 %) |
At 0.001 and above the findings filled with damage: at 0.001 testlab-wifi7-one-link gained ap-disconnect-all from a broadcast deauthentication with reason 8708.
What a busy USB link damages, and how often, is not measured: item 108 counts the frames without a type, with Bad FCS and the BSSs heard in one frame only, per port.