6 messages, 3 authors, 2021-10-05 · open the first message on its own page
From: Johannes Berg <johannes@sipsolutions.net>
Date: 2021-02-12 08:39:08
On Fri, 2021-02-05 at 13:51 -0800, Abhishek Kumar wrote:
Since using DELBA frame to APs to re-establish BA session has a dependency on APs and also some APs may not honour the DELBA frame.
That's completely out of spec ... Can you say which AP this was? You could also try sending a BAR that updates the SN. johannes
From: Youghandhar Chintala <hidden>
Date: 2021-09-24 07:37:14
Hi Johannes and felix,
We have tested with DELBA experiment during post SSR, DUT packet seq
number and tx pn is resetting to 0 as expected but AP(Netgear R8000) is
not honoring the tx pn from DUT.
Whereas when we tested with DELBA experiment by making Linux android
device as SAP and DUT as STA with which we don’t see any issue. Ping got
resumed post SSR without disconnect.
Please find below logs collected during my test for reference.
192.168.0.15(AtherosC_12:af:af) ===> DUT IP and MAC
192.168.0.55(Netgear_d2:93:3d) ===> AP IP and MAC
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
474 22.186433 192.168.0.15 192.168.0.55 ICMP
44 37 Data is protected
0x000000000026 0
Echo (ping) request id=0x0d00, seq=256/1, ttl=64 (reply in 480)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
480 22.188371 192.168.0.55 192.168.0.15 ICMP
44 5 Data is protected
0x000000000011 6
Echo (ping) reply id=0x0d00, seq=256/1, ttl=64 (request in 474)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
483 22.246335 192.168.0.15 192.168.0.55 ICMP
44 38 Data is protected
0x000000000027 0
Echo (ping) request id=0x1258, seq=11/2816, ttl=64 (reply in 489)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
489 22.248127 192.168.0.55 192.168.0.15 ICMP
44 13 Data is protected
0x000000000012 0
Echo (ping) reply id=0x1258, seq=11/2816, ttl=64 (request in 483)
The above pings(with TID 0) are before SSR. As soon as DUT recovers
after SSR, DUT is sending DELBAs to AP.
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code
TID Info
546 26.129127 AtherosC_12:af:af Netgear_d2:93:3d
802.11 44 4 Data is not protected
Delete Block Ack
0x0 Action, SN=4, FN=0, Flags=........C
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code
TID Info
548 26.129977 AtherosC_12:af:af Netgear_d2:93:3d
802.11 44 5 Data is not protected
Delete Block Ack
0x6 Action, SN=5, FN=0, Flags=........C
After SSR, we started ping traffic with TID 7 and 0. ping is successful
for TID 7 and failed for TID 0.
For TID 0, ping requests tx PN is reset to 0 but it seems AP is not
reset its PN hence we see this ping failure for TID 0.
Whereas TID 7 ping success because we started it after SSR.
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
557 26.355256 192.168.0.15 192.168.0.55 ICMP
44 0 Data is protected
0x000000000001 0
Echo (ping) request id=0x1258, seq=15/3840, ttl=64 (no response found!)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
571 27.376895 192.168.0.15 192.168.0.55 ICMP
44 1 Data is protected
0x000000000002 0
Echo (ping) request id=0x1258, seq=16/4096, ttl=64 (no response found!)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
588 28.400946 192.168.0.15 192.168.0.55 ICMP
44 2 Data is protected
0x000000000003 0
Echo (ping) request id=0x1258, seq=17/4352, ttl=64 (no response found!)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
600 29.424881 192.168.0.15 192.168.0.55 ICMP
44 3 Data is protected
0x000000000004 0
Echo (ping) request id=0x1258, seq=18/4608, ttl=64 (no response found!)
Below ping packets are with TID 7
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
622 30.898249 192.168.0.15 192.168.0.55 ICMP
44 0 Data is protected
0x000000000006 7
Echo (ping) request id=0x1276, seq=1/256, ttl=64 (reply in 626)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
626 30.900015 192.168.0.55 192.168.0.15 ICMP
44 0 Data is protected
0x000000000013 7
Echo (ping) reply id=0x1276, seq=1/256, ttl=64 (request in 622)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
644 31.897456 192.168.0.15 192.168.0.55 ICMP
44 1 Data is protected
0x000000000008 7
Echo (ping) request id=0x1276, seq=2/512, ttl=64 (reply in 648)
No. Time Source Destination
Protocol Channel Sequence number Protected flag Block Ack Starting
Sequence Control (SSC) CCMP Ext. Initialization Vector Action code TID
Info
648 31.899266 192.168.0.55 192.168.0.15 ICMP
44 1 Data is protected
0x000000000014 7
Echo (ping) reply id=0x1276, seq=2/512, ttl=64 (request in 644)
Regards,
Youghandhar
On 2021-02-12 14:07, Johannes Berg wrote:On Fri, 2021-02-05 at 13:51 -0800, Abhishek Kumar wrote:quoted
Since using DELBA frame to APs to re-establish BA session has a dependency on APs and also some APs may not honor the DELBA frame.That's completely out of spec ... Can you say which AP this was? You could also try sending a BAR that updates the SN. johannes
Regards, Youghandhar -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
From: Johannes Berg <johannes@sipsolutions.net>
Date: 2021-09-24 07:39:48
On Fri, 2021-09-24 at 13:07 +0530, Youghandhar Chintala wrote:
Hi Johannes and felix, We have tested with DELBA experiment during post SSR, DUT packet seq number and tx pn is resetting to 0 as expected but AP(Netgear R8000) is not honoring the tx pn from DUT. Whereas when we tested with DELBA experiment by making Linux android device as SAP and DUT as STA with which we don’t see any issue. Ping got resumed post SSR without disconnect.
Hm. That's a lot of data, and not a lot of explanation :) I don't understand how DelBA and PN are related? johannes
From: Youghandhar Chintala <hidden>
Date: 2021-09-24 09:14:25
Hi Johannes We thought sending the delba would solve the problem as earlier thought but the actual problem is with TX PN in a secure mode. It is not because of delba that the Seq number and TX PN are reset to zero. It’s because of the HW restart, these parameters are reset to zero. Since FW/HW is the one which decides the TX PN, when it goes through SSR, all these parameters are reset. The other peer say an AP, it does not know anything about the SSR on the peer device. It expects the next TX PN to be current PN + 1. Since TX PN starts from zero after SSR, PN check at AP will fail and it will silently drop all the packets. Regards, Youghandhar On 2021-09-24 13:09, Johannes Berg wrote:
On Fri, 2021-09-24 at 13:07 +0530, Youghandhar Chintala wrote:quoted
Hi Johannes and felix, We have tested with DELBA experiment during post SSR, DUT packet seq number and tx pn is resetting to 0 as expected but AP(Netgear R8000) is not honoring the tx pn from DUT. Whereas when we tested with DELBA experiment by making Linux android device as SAP and DUT as STA with which we don’t see any issue. Ping got resumed post SSR without disconnect.Hm. That's a lot of data, and not a lot of explanation :) I don't understand how DelBA and PN are related? johannes
Regards, Youghandhar -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
From: Johannes Berg <johannes@sipsolutions.net>
Date: 2021-09-24 09:21:04
Hi,
We thought sending the delba would solve the problem as earlier thought but the actual problem is with TX PN in a secure mode. It is not because of delba that the Seq number and TX PN are reset to zero. It’s because of the HW restart, these parameters are reset to zero. Since FW/HW is the one which decides the TX PN, when it goes through SSR, all these parameters are reset.
Right, we solved this problem too - in a sense the driver reads the database (not just TX PN btw, also RX replay counters) when the firmware crashes, and sending it back after the restart. mac80211 has some hooks for that. johannes
From: Jouni Malinen <hidden>
Date: 2021-10-05 20:26:01
On Fri, Sep 24, 2021 at 11:20:50AM +0200, Johannes Berg wrote:
quoted
We thought sending the delba would solve the problem as earlier thought but the actual problem is with TX PN in a secure mode. It is not because of delba that the Seq number and TX PN are reset to zero. It’s because of the HW restart, these parameters are reset to zero. Since FW/HW is the one which decides the TX PN, when it goes through SSR, all these parameters are reset.Right, we solved this problem too - in a sense the driver reads the database (not just TX PN btw, also RX replay counters) when the firmware crashes, and sending it back after the restart. mac80211 has some hooks for that.
This might be doable for some cases where the firmware is the component assigning the PN values on TX and the firmware still being in a state where the counter used for this could be fetched after a crash or detected misbehavior. However, this does not sound like a very reliable mechanism for cases where the firmware state for this cannot be trusted or for the cases where the TX PN is actually assigned by the hardware (which would get cleared on that restart and the value might be unreadable before that restart). Trying to pull for this information periodically before the issue is detected does not sound like a very robust design either, since that would both waste resources and have a race condition with the lower layers having transmitted additional frames. Obviously it would be nice to be able to restore this type of state in all cases accurately, but that may not really be a viable approach for all designs and it would seem to make sense to provide an alternative approach to minimize the user visible impact from the rare cases of having to restart some low level components during an association. -- Jouni Malinen PGP id EFC895FA