FT: Schedule wpa_ft_rrb_rx() through eloop in intra-process communication
With AP-AP communication, when hapd0 sends a packet, hapd1 can receive it immediately and send a response. But hapd0 will only read and process the response after it has returned from the sending context, that is entered eloop again. So one does not need to consider the RX function of the reply to run for the request sending hapd before the send calling function has returned. Previously, with intra-process communication, the packet is not scheduled through eloop. Thus the RX handler of the reply might be run while the sending context of the original request has not returned. This might become problematic, e.g., when deferring a management frame processing until an RRB response is received and then have the request restarted and finished before the original request handling has been stopped. I'm not aware of any concrete bug this is currently triggering but came across it while thinking of FT RRB AP-AP sequence numbering. I think the non-eloop scheduling approach might be error-prone and thus propose to model it more closely to the way the message would be received from a socket. Additionally, this ensures that the tests model AP-AP communication more closely to real world. Solution: queue these packets through eloop. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>master
parent
4696773676
commit
c5fee1604b
Loading…
Reference in New Issue