Change Details

An earlier commit relaxed the TA/RA rules around control frames to fix other issues, however it now results in control frames not specifically from a known node / to us to be handled in the control path. Specifically, rtwn(4) RTL8812/RTL8821 NICs are currently passing BARs from the AP TA to any destination to us; which is tripping up BAW tracking and causing traffic hangs. This is a WIP commit meant for more discussion: * I am currently only validating the RA and not the TA because some control frames do not have a TA, and * I'm not sure if this is the right spot to do this, or whether it should be done earlier in the input path, where vap->iv_recv_ctl() is called.

An earlier commit relaxed the TA/RA rules around control frames to fix other issues, however it now results in control frames not specifically from a known node / to us to be handled in the control path. Specifically, rtwn(4) RTL8812/RTL8821 NICs are currently passing BARs from the AP TA to any destination to us; which is tripping up BAW tracking and causing traffic hangs.

An earlier commit relaxed the TA/RA rules around control frames to fix other issues, however it now results in control frames not specifically from a known node / to us to be handled in the control path. Specifically, rtwn(4) RTL8812/RTL8821 NICs are currently passing BARs from the AP TA to any destination to us; which is tripping up BAW tracking and causing traffic hangs. This is a WIP commit meant for more discussion: * I am currently only validating the RA and not the TA because some control frames do not have a TA, and * I'm not sure if this is the right spot to do this, or whether it should be done earlier in the input path, where vap->iv_recv_ctl() is called.