[PATCHv4 2/7] FT: schedule wpa_ft_rrb_rx through eloop in intra-process communication
j at w1.fi
Sat Apr 1 04:53:40 PDT 2017
On Thu, Mar 23, 2017 at 12:57:18PM +0100, Michael Braun wrote:
> 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.
> Currently, 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 wifi request until a 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 conrete bug this is currently triggering but came
> across it while thinking of FT RRB AP-AP sequence numbering.
> It 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 socket. Additionally, this ensures that the tests model AP-AP
> communication more closely to real world.
> Solution: queue these packets through eloop.
Jouni Malinen PGP id EFC895FA
More information about the Hostap