P2P GO operating channel width

Hi Johannes, Jouni,

I was wondering how to configure the bandwidth of the operating channel in P2P-GO scenario. In nl80211.c I do see the use of .set_ap_chanwidth() callback. Reading the spec it seems the operating channel is exchanged during GO negotiation, but I do not see any reference about the bandwidth. It does exchange the operating class and I found some info in p2p_supplicant.c (see below). I am just not sure how this is configured to the driver, ie. what nl80211 commands will be used.

Gr. AvS --8<------------------------------------------------------------

static struct p2p_oper_class_map op_class[] = {
	{ HOSTAPD_MODE_IEEE80211G, 81, 1, 13, 1, BW20 },
#if 0 /* Do not enable HT40 on 2 GHz for now */
	{ HOSTAPD_MODE_IEEE80211G, 83, 1, 9, 1, BW40PLUS },
	{ HOSTAPD_MODE_IEEE80211G, 84, 5, 13, 1, BW40MINUS },
#endif
	{ HOSTAPD_MODE_IEEE80211A, 115, 36, 48, 4, BW20 },
	{ HOSTAPD_MODE_IEEE80211A, 124, 149, 161, 4, BW20 },
	{ HOSTAPD_MODE_IEEE80211A, 116, 36, 44, 8, BW40PLUS },
	{ HOSTAPD_MODE_IEEE80211A, 117, 40, 48, 8, BW40MINUS },
	{ HOSTAPD_MODE_IEEE80211A, 126, 149, 157, 8, BW40PLUS },
	{ HOSTAPD_MODE_IEEE80211A, 127, 153, 161, 8, BW40MINUS },
	{ HOSTAPD_MODE_IEEE80211A, 128, 36, 161, 4, BW80 },
	{ -1, 0, 0, 0, 0, BW20 }
};

In theory, operating class could be used to negotiate channel bandwidth during GO Negotiation. In practice, though, most implementations do not do this. Instead, the device that becomes the GO can just decide to enable 40 MHz (or 80/80+80/160 MHz for VHT) on its own regardless of which operating class was used. This should still be done in a way that the primary channel ends up being where indicating during GO Negotiation to allow the P2P Client to find the GO more easily.

Jouni Malinen                                            PGP id EFC895FA