fragattacks: README: clarify ping-frag-sep tests

README.md

@@ -315,13 +315,16 @@ CVEs as a way to easily refer to each type of discovered implementation flaw.
 
 - `ping-frag-sep`: This tests sends a fragmented Wi-Fi frame that is seperated by an unrelated frame.
   That is, it sends the first fragment, then a (normal) unrelated Wi-Fi frame, and finally the second fragment.
-  In case this test fails, the mixed key attack and cache attack will likely also fail (since they require
+  In case this test fails, the (default) mixed key attack and cache attack will likely also fail (since they require
-  sending other frames between two fragments). The only purpose of this test is to better understand the
+  sending other frames between two fragments). This test will also fail in case the reciever checks whether fragments
-  behaviour of a device and to learn why other tests might be failing.
+  have consecutive packet numbers (see the next test `ping-frag-sep --pn-per-qos`).
 
 - `ping-frag-sep --pn-per-qos`: Same as above, but adding the `--pn-per-qos` parameter assures both fragments
-  have a consecutive Packet Number (PN). This is something that a reciever should be verifying in order to be
+  of the ping request have a consecutive Packet Number (PN). This is something that a reciever _should_ be
-  secure. Unfortunately, many implementations don't verify whether PNs are consecutive.
+  verifying in order to be secure. Unfortunately, before the disclosure of our results, many implementations
+  don't verify whether PNs are consecutive. This test might fail in case the reciever doesn't track the latest
+  received packet counter per QoS TID, in which case you can ignore other tests that contain the `--pn-per-qos`
+  parameter.
 
 <a id="id-test-amsdu"></a>
 ## 7.3. A-MSDU attack tests (§3 -- CVE-2020-24588)

research/fragattack.py

@@ -65,9 +65,13 @@ def prepare_tests(opt):
 
 	elif opt.testname == "ping-frag-sep":
 		# Check if we can send frames in between fragments. The seperator by default uses a different
-		# QoS TID. The second fragment must use an incremental PN compared to the first fragment.
+		# QoS TID. The second fragment of the ping request will NOT have an incremental PN compared
-		# So this also tests if the receivers uses a per-QoS receive replay counter. By overriding
+		# to the first fragment. So this test fails if the receivers checks for consecutive PNs. By adding
-		# the TID you can check whether fragments are cached for multiple sequence numbers in one TID.
+		# `--pn-per-qos` both ping fragments will use consecutive PNs, but this will only be accepted if
+		# the receiver checks PNs for each QoS TID separately.
+		# By overriding the TID to 2 you can check whether fragments are cached for multiple sequence numbers
+		# in one TID (since all fragments use the same TID but the ping fragments use a different sequence
+		# number compared to the seperator).
 		tid = 1 if stractions == None else int(stractions)
 		separator = Dot11(type="Data", subtype=8, SC=(33 << 4) | 0)/Dot11QoS(TID=tid)/LLC()/SNAP()
 		test = PingTest(REQ_ICMP,