question regarding use_monitor for nl80211 driver

[Jouni Malinen]

On Mon, Sep 29, 2014 at 04:17:37PM +0000, Izoard, CedricX wrote:
> We're facing issue with full mac driver, when creating p2p groups.
> 
> The driver reports it support ap_sme but not probe command nor tx data status, so use_monitor is set to 1 in wpa_driver_nl80211_capa.
> Then when setting up the AP for the p2p group, because of (device_ap_sme=1 and use_monitor=1) the supplicant doesn't register handler for management frame and then action frames sent to the p2p group are not processed.
> 
> On kitkat baseline, there is patch that force use_monitor to 0 if driver support WPA_DRIVER_FLAGS_OFFCHANNEL_TX (commit aec9e647dab45c87511f822f6f9468800ec6f3b1 "AOSP: nl80211 use_monitor hack")
> Since L-dessert is using upstream supplicant this patch is not present, and several tests regarding p2p service discovery or p2p presence request are failing because there is no handler to process those action frames.

In upstream, there is actually another way for clearing use_monitor,
i.e., it is not used with drivers that do not support monitor interface
(NL80211_IFTYPE_MONITOR). I have not noticed this specific case that you
describe here since the non-mac80211 drivers I've been testing with do
not actually support monitor interface..

This was added in 2011 in commit
536062f274f523f7f84f2895894bb67a03ff9320:

    nl80211: Fix use_monitor driver capability for non-mac80211 drivers
    
    Poll command may be enough for mac80211 to figure out whether monitor
    interface is to be used, but this change did not take into account
    non-mac80211 drivers that support AP mode without monitor interface.
    For example, ath6kl needs to get use_monitor disabled.

And I'm not really sure whether any full MAC driver before that worked
properly in device_ap_sme mode with nl80211-driver interface (i.e., some
hacks were needed to get things working)..


> Isn't use_monitor irrelevant if device_ap_sme is set ?
> What would be the correct way to fix this issue ?  at supplicant level or driver level ?

I'm trying to remember why this was done in the way it is currently.. I
was going to simply say that there is no point in use using monitor
interface with non-mac80211 drivers, but the current capability
determination implementation is obviously trying to do something more
than that.

The !poll_command_supported and !data_tx_status are only for mac80211
version validation. !monitor_supported covers many device_ap_sme
drivers.


device_ap_sme was added with commit
61cbe2ffd89b8a4ea7db0a3a4c0a4e066372505c:

    nl80211: Use device AP SME capability
    
    This changes the auto-detection of whether or not the device contains
    the AP SME away from monitor interface addition failing to the explicit
    attribute in nl80211. Keep the old auto-detection for a little while so
    that ath6kl isn't broken right away.

(that replaced no_monitor_iface_capab with device_ap_sme)


no_monitor_iface_capab was added with commit
866af8b6bdfed42c7628d5da149ba1962257d005:

    nl80211: Allow AP mode to be started without monitor interface
    
    This is in preparation for supporting AP mode with SME/MLME in the
    driver/firmware.

(based on monitor interface addition failing)


As a conclusion of that history, I would be tempted to say that there
does not exist even a single non-mac80211 driver that would use monitor
mode and as such, we should just do

	if (drv->device_ap_sme)
		drv->use_monitor = 0

instead of checking !monitor_supported as an additional constraint.

-- 
Jouni Malinen                                            PGP id EFC895FA