[PATCHv4 2/7] FT: schedule wpa_ft_rrb_rx through eloop in intra-process communication

[Jouni Malinen]

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.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA