I could again capture a case where some (false) 16 byte MTU frames were received - attached.

Loop 24435 2023-01-04T14:25:57 last+4s total:28h36m
.....
+ ./sctestself -b -n 4 -l 999 -t 2 -v cmperr,logmsg -F refilldata,leastdots,allowintloopb,stoponerror -X 192.168.5.221:4001 -d 24 can0
CAN selftest can0 Wrong-RX16(rxcnt=0):000#
Wrong-RX16(rxcnt=1):000#
Wrong-RX16(rxcnt=2):000#
Wrong-RX16(rxcnt=3):000#
idx    0 tx:2A5#00 00 DB 83 C7 C6 D2 22 D0 F1 81 25 26 15 EF 1F 1C 6F 91 BC 00 DC EF 74
         rx:000#
idx    1 tx:2A5#00 01 B2 FA 3F 38 59 F9 13 11 4D EE 94 14 B4 67 36 84 58 B7 A9 7F CC 99
         rx:000#
idx    2 tx:2A5#00 02 9E E9 08 2F A5 08 0C 95 7C BE 8F BB F7 E8 B5 0A F9 02 F8 8E 16 AC
         rx:000#
idx    3 tx:2A5#00 03 F5 4D 30 4D 04 DA CC D1 73 6B BA 7B 9A 5F 84 A6 F4 00 65 83 BC 5C
         rx:000#
.c (0) fail
0: RX16 (004/003)  000#
0: RX16 (004/002)  000#
0: TX72 (003/002)  2A5#00 03 F5 4D 30 4D 04 DA CC D1 73 6B BA 7B 9A 5F 84 A6 F4 00 65 83 BC 5C
0: RX16 (003/001)  000#
0: TX72 (002/001)  2A5#00 02 9E E9 08 2F A5 08 0C 95 7C BE 8F BB F7 E8 B5 0A F9 02 F8 8E 16 AC
0: RX16 (002/000)  000#
0: TX72 (001/000)  2A5#00 01 B2 FA 3F 38 59 F9 13 11 4D EE 94 14 B4 67 36 84 58 B7 A9 7F CC 99
0: TX72 (000/000)  2A5#00 00 DB 83 C7 C6 D2 22 D0 F1 81 25 26 15 EF 1F 1C 6F 91 BC 00 DC EF 74
External logger data:
(54:40.690.506      +0.089) RX B -      2A5  [24]  00 03 F5 4D 30 4D 04 DA  CC D1 73 6B BA 7B 9A 5F  84 A6 F4 00 65 83 BC 5C  
(54:40.690.417      +3.307) RX B -      2A5  [24]  00 02 9E E9 08 2F A5 08  0C 95 7C BE 8F BB F7 E8  B5 0A F9 02 F8 8E 16 AC       **** suspicious delay
(54:40.687.110      +0.088) RX B -      2A5  [24]  00 01 B2 FA 3F 38 59 F9  13 11 4D EE 94 14 B4 67  36 84 58 B7 A9 7F CC 99  
(54:40.687.022     +26.681) RX B -      2A5  [24]  00 00 DB 83 C7 C6 D2 22  D0 F1 81 25 26 15 EF 1F  1C 6F 91 BC 00 DC EF 74    **** plausible delay
(54:40.660.341      +0.071) RX B -      2A5  [16]  00 03 95 89 EA 22 98 62  36 77 C2 F9 69 99 0D 32  
(54:40.660.270      +0.417) RX B -      2A5  [16]  00 02 CF 52 6C 29 E2 86  73 10 3E 93 D4 72 30 05  
(54:40.659.853      +0.071) RX B -      2A5  [16]  00 01 8D 0E 77 13 DF 60  C3 F1 D7 14 C9 8B CC 04  
(54:40.659.782      +0.460) RX B -      2A5  [16]  00 00 5A 90 19 49 2D B8  20 C4 34 9D 31 23 59 E5  
(54:40.659.322      +0.070) RX B -      2A5  [16]  00 03 86 D1 E9 AF 12 76  51 D7 B4 B8 3B 43 85 68  
(54:40.659.252      +0.420) RX B -      2A5  [16]  00 02 EF 9D 9F D6 97 7B  7D 6C EF BB B4 6A B5 92

My sctestself received four 000# frames and quits. There are more such frames in the candump. None of them
were received by the external logger and neither in my own send-log.
It seems this happens when the sctestself does it's first test loop - which I also have seen in a second
case. The 26.681 ms delay seems to be normal as the program is started by the outer test loop. 
The +3.307 ms delay however is not normally seen when sctestself does it's first loop, not even 
if I drop caches after each sctestself run.

Can sctestself do something wrong to cause it?

-- Stefan