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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
