Set default P2P_MAX_CLIENT_IDLE to 20

Consider the disconnect event generated due to EAP-FAILURE(after WPS handshake) during the P2P connection.

In this disconnect context, the group idle timer will be set to 10 and assoc retry starts. If the connection doesn't go through in
the first attempt the group will be removed. This is because the authentication timeout happens at 10secs and the assoc
will be retried only after that.

I feel setting to twenty seconds will help to retry at least two times. Please see whether it is okay.

Setting authentication timeout to 5secs is also another option. But not sure whether there are some systems requiring 10secs
time.


[PATCH] Set default P2P_MAX_CLIENT_IDLE to 20

Signed-hostap: Jithu Jance <jithu@broadcom.com>
---
 wpa_supplicant/p2p_supplicant.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

On Mon, May 21, 2012 at 05:16:33AM +0000, Jithu Jance wrote:
> Consider the disconnect event generated due to EAP-FAILURE(after WPS handshake) during the P2P connection.
> 
> In this disconnect context, the group idle timer will be set to 10 and assoc retry starts. If the connection doesn't go through in
> the first attempt the group will be removed. This is because the authentication timeout happens at 10secs and the assoc
> will be retried only after that.

Do you know what is causing the authentication to take more than 10
seconds? That sounds pretty excessive for P2P use cases..

> I feel setting to twenty seconds will help to retry at least two times. Please see whether it is okay.

This is somewhat problematic since there is also the opposite
requirement of making the device notice quickly when the group goes down
and the explicit indication from GO using Deauthentication frame is not
that reliable (or correctly implemented in many deployed devices for
that matter).

> Setting authentication timeout to 5secs is also another option. But not sure whether there are some systems requiring 10secs
> time.

That could be reasonable for P2P use cases. Though, I would rather
figure out whether there would be better signals for determining that a
new attempt is needed. That authentication timeout should really be more
specific to cases where EAPOL frames do not get processed in reasonable
time frame. I would assume that the case you are thinking of here would
be something else. Or are you really seeing cases where association is
completed successfully, but 4-way handshake does not go through?

Hi Jouni,

> Do you know what is causing the authentication to take more than 10
> seconds? That sounds pretty excessive for P2P use cases..

Suppose the association fails due to timeout [Auth/Assoc frame is sent but
received no response], then I see that Authentication timeout happens only
after 10secs. So the assoc retry happens only after 10 secs in this case.By
this time, the group_idle_timeout would expire and the group is removed.

The reason for no auth resp/assoc resp could be due to absence of peer (due
to a scan on the shared virtual interface) at that point of time. So I feel
reducing the authentication timeout to 5secs would give a chance to try
Assoc one more time.

Pls correct me, If my understanding is wrong.





- Jithu Jance
*
*


On Sun, Jun 10, 2012 at 11:17 PM, Jouni Malinen <j@w1.fi> wrote:

> On Mon, May 21, 2012 at 05:16:33AM +0000, Jithu Jance wrote:
> > Consider the disconnect event generated due to EAP-FAILURE(after WPS
> handshake) during the P2P connection.
> >
> > In this disconnect context, the group idle timer will be set to 10 and
> assoc retry starts. If the connection doesn't go through in
> > the first attempt the group will be removed. This is because the
> authentication timeout happens at 10secs and the assoc
> > will be retried only after that.
>
> Do you know what is causing the authentication to take more than 10
> seconds? That sounds pretty excessive for P2P use cases..
>
> > I feel setting to twenty seconds will help to retry at least two times.
> Please see whether it is okay.
>
> This is somewhat problematic since there is also the opposite
> requirement of making the device notice quickly when the group goes down
> and the explicit indication from GO using Deauthentication frame is not
> that reliable (or correctly implemented in many deployed devices for
> that matter).
>
> > Setting authentication timeout to 5secs is also another option. But not
> sure whether there are some systems requiring 10secs
> > time.
>
> That could be reasonable for P2P use cases. Though, I would rather
> figure out whether there would be better signals for determining that a
> new attempt is needed. That authentication timeout should really be more
> specific to cases where EAPOL frames do not get processed in reasonable
> time frame. I would assume that the case you are thinking of here would
> be something else. Or are you really seeing cases where association is
> completed successfully, but 4-way handshake does not go through?
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP@lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>