[PATCH/RFC] improve overlap detection and handling for P2P PBC
j at w1.fi
Tue Nov 29 13:20:07 EST 2011
On Tue, Nov 29, 2011 at 05:36:26PM +0100, Vitaly Wool wrote:
> I've been struggling to get my prototype P2P device to work with Samsung
> Galaxy SII. The connection establishment kept failing with WPS_FAILURE and
> it turned out to be due to overlap detected:
> 01-03 01:27:26.140 E/wpa_supplicant( 2455): WPS: Requested UUID -
> hexdump(len=16): 22 21 02 03 04 05 06 07 08 09 1a 1b 1c 1d 1e 1f
> 01-03 01:27:26.140 D/wpa_supplicant( 2455): WPS: Consider PBC session with
> 01-03 01:27:26.140 E/wpa_supplicant( 2455): WPS: UUID-E - hexdump(len=16):
> 22 21 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> 01-03 01:27:26.140 D/wpa_supplicant( 2455): WPS: New Enrollee
> 01-03 01:27:26.140 D/wpa_supplicant( 2455): WPS: 2 active PBC session(s)
> 01-03 01:27:26.140 D/wpa_supplicant( 2455): WPS: PBC overlap - deny PBC
Argh.. Is that the way this device works with a deployed software? That
is a known bug in that specific WPS implementation and I was hoping that
it would never get released in a real end user product.
This is so broken on multiple levels.. Those UUIDs are supposed to be
unique for each device (good luck with those hardcoded values being
unique) and only a single UUID can be used by the device, but this
device is using two different ones..
> So Galaxy changes UUID for PBC negotiation but the thing is, it could have
> been considered to be the same session because the MAC address is the same.
Well, yes, it could have, but this is so horribly broken that I would
like to just not allow it to use PBC.
> There is a mechanism to do so for P2P connections in wpa_supplicant but it
> doesn't work because P2P MAC address is not passed over
> to wps_registrar_skip_overlap(). This patch adds that and also fixes the
> PBC session removal after the negotiation (the current version leaves the
> session in the list if it doesn't match UUID, I suggest that we remove all
> sessions for the given MAC).
Could you please confirm that you are seeing this broken behavior with a
deployed end user product and there are large number of those deployed?
I don't think I would agree with all these changes since they break the
way PBC overlap detection is supposed to work. If this bad behavior
shows up in huge number of end user devices, it may be justifiable to
add a workaround for it, but I want to limit the scope of how far the
workaround goes in disabling overlap detection.
Jouni Malinen PGP id EFC895FA
More information about the HostAP