linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* AP mode with Broadcom 4330
@ 2017-07-28 14:15 Russell King - ARM Linux
  2017-07-28 17:49 ` Russell King - ARM Linux
  0 siblings, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-07-28 14:15 UTC (permalink / raw)
  To: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list

Hi,

I've been struggling yesterday and today trying to configure AP mode
with the Broadcom 4330 on a SolidRun Hummingboard2, using the 2013
firmware:

Firmware version = wl0: Jan 23 2013 17:47:32 version 5.90.195.114 FWID 01-f9e7e464

People tell me that this works with SR's 3.14 kernel, but I'd prefer
to use mainline (4.13-rc2).  Whenever I try to configure AP mode via
Network Manager or hostapd (on Debian Jessie), the SSID I ask for and
the MAC address does not appear on other wifi clients.  wlan0's
MAC is 6c:ad:f8:1d:4c:d9.

However, I have recently noticed that this pops up on clients when
AP mode is enabled:

BSS 00:10:18:f1:f2:f3(on wlan0)
        TSF: 80810271 usec (0d, 00:01:20)
        freq: 2412
        beacon interval: 10 TUs
        capability: ESS (0x0001)
        signal: -15.00 dBm
        last seen: 3203 ms ago
        SSID: BRCM_TEST_SSID
        Supported rates: 1.0* 2.0* 5.5* 11.0*
        DS Parameter set: channel 1
        IBSS ATIM window: 0 TUsBSS 52:0d:10:41:e9:99(on wlan0)
        TSF: 21849896478 usec (0d, 06:04:09)
        freq: 2462
        beacon interval: 100 TUs
        capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
        signal: -80.00 dBm
        last seen: 3020 ms ago
        Information elements from Probe Response frame:
        SSID: Virgin Media
        Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
        DS Parameter set: channel 11
        Country: GB     Environment: Indoor/Outdoor
                Channels [1 - 13] @ 20 dBm
        ERP: <no flags>
        Extended supported rates: 24.0 36.0 48.0 54.0
        HT capabilities:
                Capabilities: 0x1ad
                        RX LDPC
                        HT20
                        SM Power Save disabled
                        RX HT20 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 8 usec (0x06)
                HT TX/RX MCS rate indexes supported: 0-15
        HT operation:
                 * primary channel: 11
                 * secondary channel offset: no secondary
                 * STA channel width: 20 MHz
                 * RIFS: 1
                 * HT protection: no
                 * non-GF present: 1
                 * OBSS non-GF present: 0
                 * dual beacon: 0
                 * dual CTS protection: 0
                 * STBC beacon: 0
                 * L-SIG TXOP Prot: 0
                 * PCO active: 0
                 * PCO phase: 0
        Overlapping BSS scan params:
                 * passive dwell: 20 TUs
                 * active dwell: 10 TUs
                 * channel width trigger scan interval: 300 s
                 * scan passive total per channel: 200 TUs
                 * scan active total per channel: 20 TUs
                 * BSS width channel transition delay factor: 5
                 * OBSS Scan Activity Threshold: 0.25 %
        Extended capabilities: HT Information Exchange Supported, TFS, WNM-Sleep Mode, TIM Broadcast, BSS Transition, 6
        WMM:     * Parameter version 1
                 * u-APSD
                 * BE: CW 15-1023, AIFSN 3
                 * BK: CW 15-1023, AIFSN 7
                 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
                 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
        Vendor specific: OUI 00:03:7f, data: 01 01 00 00 ff 7f
        RSN:     * Version: 1
                 * Group cipher: CCMP
                 * Pairwise ciphers: CCMP
                 * Authentication suites: IEEE 802.1X
                 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)

This is when using this hostapd configuration file:

interface=wlan0
driver=nl80211
ssid=Time
channel=1
hw_mode=g
wpa=2
wpa_passphrase=FooBarBazBat
wpa_pairwise=CCMP TKIP

Enabling tracing via /sys/kernel/debug/tracing/events/cfg80211/rdev_start_ap/enable
gives:

         hostapd-2213  [000] .... 15637.517729: rdev_start_ap: phy0, netdev:wlan0(3), AP settings - ssid: Time, band: 0, control freq: 2412, width: 0, cf1: 2412, cf2: 0, beacon interval: 100, dtim period: 2, hidden ssid: 0, wpa versions: 2, privacy: true, auth type: 8, inactivity timeout: 0

So the right SSID is being requested.  Enabling debug (4096+6) in the
brcmfmac driver gives:

brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=chanspec, len=4
brcmutil: data
00000000: 01 2b 00 00                                      .+..
brcmfmac: brcmf_cfg80211_get_tx_power Enter
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=qtxpower, len=4
brcmutil: data
00000000: 7f 00 00 00                                      ....
brcmfmac: brcmf_cfg80211_get_tx_power Exit (0x7f 31)
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=chanspec, len=4
brcmutil: data
00000000: 01 2b 00 00                                      .+..
brcmfmac: brcmf_cfg80211_get_tx_power Enter
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=qtxpower, len=4
brcmutil: data
00000000: 7f 00 00 00                                      ....
brcmfmac: brcmf_cfg80211_get_tx_power Exit (0x7f 31)
brcmfmac: brcmf_cfg80211_change_iface Enter, bsscfgidx=0, type=3
brcmfmac: brcmf_cfg80211_change_iface IF Type = AP
brcmfmac: brcmf_cfg80211_change_iface Exit
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=chanspec, len=4
brcmutil: data
00000000: 01 2b 00 00                                      .+..
brcmfmac: brcmf_cfg80211_get_tx_power Enter
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=qtxpower, len=4
brcmutil: data
00000000: 7f 00 00 00                                      ....
brcmfmac: brcmf_cfg80211_get_tx_power Exit (0x7f 31)
brcmfmac: brcmf_cfg80211_del_station Enter ff:ff:ff:ff:ff:ff
brcmfmac: brcmf_fil_cmd_data_set ifidx=0, cmd=201, len=12
brcmutil: data
00000000: 02 00 00 00 ff ff ff ff ff ff e1 ec              ............
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_cfg80211_del_station Exit
brcmfmac: brcmf_cfg80211_del_key Enter
brcmfmac: brcmf_cfg80211_del_key Enter
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=wsec_key, len=164
brcmutil: data
00000000: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030: 01 00 00 00 00 d0 27 ee 00 00 00 00 c0 82 a1 ed  ......'.........
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_cfg80211_del_key Exit
brcmfmac: brcmf_cfg80211_del_key Enter
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=wsec_key, len=164
brcmutil: data
00000000: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030: 02 00 00 00 00 d0 27 ee 00 00 00 00 c0 82 a1 ed  ......'.........
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_cfg80211_del_key Exit
brcmfmac: brcmf_cfg80211_del_key Enter
brcmfmac: chandef_to_chanspec chandef: control 2412 center 2412 width 0
brcmfmac: brcmf_cfg80211_start_ap ctrlchn=1, center=2412, bw=0, beacon_interval=100, dtim_period=2,
brcmfmac: brcmf_cfg80211_start_ap ssid=Tim(4), auth_type=8, inactivity_timeout=0
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_int_get ifidx=0, cmd=46, value=0
brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=mpc, len=4
brcmutil: data
00000000: 00 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_set_mpc MPC : 0
brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=arp_ol, len=4
brcmutil: data
00000000: 00 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=arpoe, len=4
brcmutil: data
00000000: 00 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_configure_arp_nd_offload successfully configured (0) ARP offload to 0x0
brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=ndoe, len=4
brcmutil: data
00000000: 00 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_data Failed: BCME_UNSUPPORTED (-23)
brcmfmac: brcmf_configure_arp_nd_offload failed to configure (0) ND offload err = -23
brcmfmac: brcmf_cfg80211_start_ap WPA(2) IE is found
brcmfmac: brcmf_configure_wpaie Enter
brcmfmac: brcmf_configure_wpaie RSN_AKM_PSK
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=wme_bss_disable, len=4
brcmutil: data
00000000: 01 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=auth, len=4
brcmutil: data
00000000: 00 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=wsec, len=4
brcmutil: data
00000000: 46 00 00 00                                      F...
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=wpa_auth, len=4
brcmutil: data
00000000: 80 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=76, value=100
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=78, value=2
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=3, value=1
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=apsta, len=4
brcmutil: data
00000000: 00 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=20, value=1
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=mbss, len=4
brcmutil: data
00000000: 01 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=118, value=1
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=chanspec, len=4
brcmutil: data
00000000: 01 2b 00 00                                      .+..
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=2, value=1
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_cmd_data_set ifidx=0, cmd=26, len=52
brcmutil: data
00000000: 04 00 00 00 54 69 6d 65 00 00 00 00 00 00 00 00  ....Time........
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030: 00 00 00 00                                      ....
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_add_if Enter, bsscfgidx=0, ifidx=0
brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_cfg80211_start_ap AP mode configuration complete
brcmfmac: brcmf_vif_set_mgmt_ie bsscfgidx 0, pktflag : 0x01
brcmfmac: brcmf_config_ap_mgmt_ie Applied Vndr IEs for Beacon
brcmfmac: brcmf_vif_set_mgmt_ie bsscfgidx 0, pktflag : 0x02
brcmfmac: brcmf_config_ap_mgmt_ie Applied Vndr IEs for Probe Resp[15330.653223] brcmfmac: brcmf_net_setcarrier Enter, bsscfgidx=0 carrier=1
brcmfmac: brcmf_txflowblock_if enter: bsscfgidx=0 stop=0x4 reason=4 state=0
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_cfg80211_add_key Enter
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=wsec_key, len=164
brcmutil: data
00000000: ...
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_bsscfg_data_get ifidx=0, bsscfgidx=0, name=wsec, len=4
brcmutil: data
00000000: 46 00 00 00                                      F...
brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bsscfgidx=0, name=wsec, len=4
brcmutil: data
00000000: 46 00 00 00                                      F...
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
00000000: 46 00 00 00                                      F...
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_cfg80211_add_key Exit
brcmfmac: brcmf_cfg80211_config_default_key Enter
brcmfmac: brcmf_sdio_bus_txctl Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_tx_ctrlframe Enter
brcmfmac: brcmf_sdio_bus_rxctl Enter
brcmfmac: brcmf_sdio_isr Enter
brcmfmac: brcmf_sdio_dpc Enter
brcmfmac: brcmf_sdio_readframes Enter
brcmfmac: brcmf_sdio_read_control Enter
brcmfmac: brcmf_fil_bsscfg_data_get ifidx=0, bsscfgidx=0, name=wsec, len=4
brcmutil: data
00000000: 46 00 00 00                                      F...
brcmfmac: brcmf_cfg80211_config_default_key Exit

The SSID appears to be set by "brcmf_fil_cmd_data_set ifidx=0, cmd=26,
len=52" but seems to be ignored by the firmware.

The BRCM_TEST_SSID and mac address 00:10:18:f1:f2:f3 can be found in
the SDIO firmware .bin file:

0001acf0  34 01 04 00 01 00 00 0e  34 01 04 00 42 52 43 4d  |4.......4...BRCM|
                                                                         ^^^^
0001ad00  34 01 04 00 5f 54 45 53  34 01 04 00 54 5f 53 53  |4..._TES4...T_SS|
                                                                 ^^^^    ^^^^
0001ad10  34 01 04 00 49 44 01 04  34 01 04 00 82 84 8b 96  |4...ID..4.......|
                                                                 ^^
0001ad50  34 01 04 00 ff ff ff ff  34 01 04 00 00 10 18 f1  |4.......4.......|
                                               ^^^^^^^^^^^
0001ad60  34 01 04 00 f2 f3 00 10  34 01 04 00 18 f1 f2 f3  |4.......4.......|
                      ^^^^^|^^^^^              ^^^^^^^^^^^

so this BRCM_TEST_SSID with mac address 00:10:18:f1:f2:f3 is definitely
coming from the 4330.  Given that it goes away if I down the interface
and comes back when I reconfigure AP mode, this all points towards a
firmware/driver incompatibility and a regression compared to 3.14
kernels, which work with the exact same firmware.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-07-28 14:15 AP mode with Broadcom 4330 Russell King - ARM Linux
@ 2017-07-28 17:49 ` Russell King - ARM Linux
  2017-07-28 19:50   ` Arend van Spriel
  0 siblings, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-07-28 17:49 UTC (permalink / raw)
  To: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list

On Fri, Jul 28, 2017 at 03:15:03PM +0100, Russell King - ARM Linux wrote:
> Hi,
> 
> I've been struggling yesterday and today trying to configure AP mode
> with the Broadcom 4330 on a SolidRun Hummingboard2, using the 2013
> firmware:
> 
> Firmware version = wl0: Jan 23 2013 17:47:32 version 5.90.195.114 FWID 01-f9e7e464
> 
> People tell me that this works with SR's 3.14 kernel, but I'd prefer
> to use mainline (4.13-rc2).  Whenever I try to configure AP mode via
> Network Manager or hostapd (on Debian Jessie), the SSID I ask for and
> the MAC address does not appear on other wifi clients.  wlan0's
> MAC is 6c:ad:f8:1d:4c:d9.

I've just found the cause of this.  What it comes down to is this commit:

commit a44aa4001a86d46f936ca449e5d6c268446bfae2
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Wed Dec 3 21:05:33 2014 +0100

    brcmfmac: add multiple BSS support.

    This patch adds support for multiple BSS interfaces (AP). In
    total three AP configurations can be created. In order to use
    multiple BSS firmware needs to support it.

    Reviewed-by: Arend Van Spriel <arend@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

which adds this hunk to brcmf_cfg80211_start_ap()

        if (dev_role == NL80211_IFTYPE_AP) {
+               if ((brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS)) && (!mbss))
+                       brcmf_fil_iovar_int_set(ifp, "mbss", 1);
+

What this is saying is: "if the device supports MBSS, and MBSS was not
requested (from ifp->vif->mbss), then *ENABLE* MBSS."  That's clearly
nonsense.

Replacing that "(!mbss)" with "mbss" results in AP mode working on the
4330.  However, I suspect:

		if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
			brcmf_fil_iovar_int_set(ifp, "mbss", mbss);

actually makes much more sense.

Given that this is direct firmware interaction, I can't say which is
correct - all I can say is that mainline kernels are currently broken.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-07-28 17:49 ` Russell King - ARM Linux
@ 2017-07-28 19:50   ` Arend van Spriel
  2017-07-31 12:59     ` Russell King - ARM Linux
  2017-08-14 23:30     ` Russell King - ARM Linux
  0 siblings, 2 replies; 13+ messages in thread
From: Arend van Spriel @ 2017-07-28 19:50 UTC (permalink / raw)
  To: Russell King - ARM Linux, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list

On 28-07-17 19:49, Russell King - ARM Linux wrote:
> On Fri, Jul 28, 2017 at 03:15:03PM +0100, Russell King - ARM Linux wrote:
>> Hi,
>>
>> I've been struggling yesterday and today trying to configure AP mode
>> with the Broadcom 4330 on a SolidRun Hummingboard2, using the 2013
>> firmware:
>>
>> Firmware version = wl0: Jan 23 2013 17:47:32 version 5.90.195.114 FWID 01-f9e7e464
>>
>> People tell me that this works with SR's 3.14 kernel, but I'd prefer
>> to use mainline (4.13-rc2).  Whenever I try to configure AP mode via
>> Network Manager or hostapd (on Debian Jessie), the SSID I ask for and
>> the MAC address does not appear on other wifi clients.  wlan0's
>> MAC is 6c:ad:f8:1d:4c:d9.
> 
> I've just found the cause of this.  What it comes down to is this commit:

Hi Russell,

I noticed in your log that mbss was set to 1 so I was going to look at
that, but you clearly beat me to it ;-)

> commit a44aa4001a86d46f936ca449e5d6c268446bfae2
> Author: Hante Meuleman <meuleman@broadcom.com>
> Date:   Wed Dec 3 21:05:33 2014 +0100
> 
>     brcmfmac: add multiple BSS support.
> 
>     This patch adds support for multiple BSS interfaces (AP). In
>     total three AP configurations can be created. In order to use
>     multiple BSS firmware needs to support it.
> 
>     Reviewed-by: Arend Van Spriel <arend@broadcom.com>
>     Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
>     Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
>     Signed-off-by: Arend van Spriel <arend@broadcom.com>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> which adds this hunk to brcmf_cfg80211_start_ap()
> 
>         if (dev_role == NL80211_IFTYPE_AP) {
> +               if ((brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS)) && (!mbss))
> +                       brcmf_fil_iovar_int_set(ifp, "mbss", 1);
> +
> 
> What this is saying is: "if the device supports MBSS, and MBSS was not
> requested (from ifp->vif->mbss), then *ENABLE* MBSS."  That's clearly
> nonsense.

I was going to agree with you, but having second thoughts. There are
actually two use-cases that need to be handled properly. The regular AP
case and the MBSS case. In case of MBSS the initial AP interface will
have mbss set to false and subsequent AP interfaces will have mbss set
to true, but in firmware this has to be configured inverted. That is
what the code above is doing. However, this indeed breaks the regular AP
case for firmwares that abuse that setting for testing purposes (no idea
why that is in a released firmware).

> Replacing that "(!mbss)" with "mbss" results in AP mode working on the
> 4330.  However, I suspect:
> 
> 		if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
> 			brcmf_fil_iovar_int_set(ifp, "mbss", mbss);
> 
> actually makes much more sense.
> 
> Given that this is direct firmware interaction, I can't say which is
> correct - all I can say is that mainline kernels are currently broken.

Indeed. I have to come up with a proper fix for both scenarios. Thanks
for the report.

Regards,
Arend

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-07-28 19:50   ` Arend van Spriel
@ 2017-07-31 12:59     ` Russell King - ARM Linux
  2017-07-31 20:28       ` Arend van Spriel
  2017-08-14 23:30     ` Russell King - ARM Linux
  1 sibling, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-07-31 12:59 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote:
> I was going to agree with you, but having second thoughts. There are
> actually two use-cases that need to be handled properly. The regular AP
> case and the MBSS case. In case of MBSS the initial AP interface will
> have mbss set to false and subsequent AP interfaces will have mbss set
> to true, but in firmware this has to be configured inverted. That is
> what the code above is doing. However, this indeed breaks the regular AP
> case for firmwares that abuse that setting for testing purposes (no idea
> why that is in a released firmware).

Maybe detect the BCRM_TEST_SSID string in the firmware file (as it's
broken up amongst other data, it's not trivial) and disable mbss for
such firmware?  Alternatively, maybe blacklist mbss for some firmware
versions?

Do the firmware versions that include this "abuse" actually have
functional mbss?

There's also the obvious question: which firmware is recommended for
the 4330?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-07-31 12:59     ` Russell King - ARM Linux
@ 2017-07-31 20:28       ` Arend van Spriel
  2017-11-14 23:07         ` Russell King - ARM Linux
  0 siblings, 1 reply; 13+ messages in thread
From: Arend van Spriel @ 2017-07-31 20:28 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

On 31-07-17 14:59, Russell King - ARM Linux wrote:
> On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote:
>> I was going to agree with you, but having second thoughts. There are
>> actually two use-cases that need to be handled properly. The regular AP
>> case and the MBSS case. In case of MBSS the initial AP interface will
>> have mbss set to false and subsequent AP interfaces will have mbss set
>> to true, but in firmware this has to be configured inverted. That is
>> what the code above is doing. However, this indeed breaks the regular AP
>> case for firmwares that abuse that setting for testing purposes (no idea
>> why that is in a released firmware).
> 
> Maybe detect the BCRM_TEST_SSID string in the firmware file (as it's
> broken up amongst other data, it's not trivial) and disable mbss for
> such firmware?  Alternatively, maybe blacklist mbss for some firmware
> versions?

Well. It seem 43362 chip also had this and we disabled mbss for that
chipset. So we may do that for 4330 as well.

> Do the firmware versions that include this "abuse" actually have
> functional mbss?

Digging through our internal bug database I found a remark that
BRCM_TEST_SSID showing up means mbss is not functional.

> There's also the obvious question: which firmware is recommended for
> the 4330?

We tend to rely on what is released to AOSP as our team does not have
the bandwidth to go through the release process. I checked and it is
still the same so matches what is in linux-firmware.

Regards,
Arend

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-07-28 19:50   ` Arend van Spriel
  2017-07-31 12:59     ` Russell King - ARM Linux
@ 2017-08-14 23:30     ` Russell King - ARM Linux
  2017-08-15  6:25       ` rosenp
  1 sibling, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-08-14 23:30 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote:
> On 28-07-17 19:49, Russell King - ARM Linux wrote:
> > Replacing that "(!mbss)" with "mbss" results in AP mode working on the
> > 4330.  However, I suspect:
> > 
> > 		if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
> > 			brcmf_fil_iovar_int_set(ifp, "mbss", mbss);
> > 
> > actually makes much more sense.
> > 
> > Given that this is direct firmware interaction, I can't say which is
> > correct - all I can say is that mainline kernels are currently broken.
> 
> Indeed. I have to come up with a proper fix for both scenarios. Thanks
> for the report.

I'm now on 4.13-rc4, and running with my patch.  I've configured AP mode:

Interface wlan0
	ifindex 3
	wdev 0x1
	addr 6c:ad:f8:1d:4c:d9
	ssid Time
	type AP
	wiphy 0
	channel 5 (2432 MHz), width: 20 MHz, center1: 2432 MHz

using NetworkManager with a WPA2 key.  However, a Realtek RTL8192EU
client is trying to connect to it, but is unable:

[ 1750.497436] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
[ 1750.530929] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
[ 1750.738795] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 2/3)
[ 1750.946780] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 3/3)
[ 1751.154764] wlan0: authentication with 6c:ad:f8:1d:4c:d9 timed out

The antennas are definitely within range (finger to thumb distance)
and the Realtek can definitely see the BCM4330 in AP mode.  I don't
see the interrupts for the SDIO interface increment while the client
tries to connect.

The WPA2 password is definitely the same on both ends.

Any ideas how to debug this?

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-08-14 23:30     ` Russell King - ARM Linux
@ 2017-08-15  6:25       ` rosenp
  2017-08-15  8:22         ` Russell King - ARM Linux
  0 siblings, 1 reply; 13+ messages in thread
From: rosenp @ 2017-08-15  6:25 UTC (permalink / raw)
  To: Russell King - ARM Linux, Arend van Spriel
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

If using rtlwifi, you could try using rtl8xxxu and see if you get
similar results. ¯\_(ツ)_/¯

On Tue, 2017-08-15 at 00:30 +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote:
> > On 28-07-17 19:49, Russell King - ARM Linux wrote:
> > > Replacing that "(!mbss)" with "mbss" results in AP mode working
> > > on the
> > > 4330.  However, I suspect:
> > > 
> > > 		if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
> > > 			brcmf_fil_iovar_int_set(ifp, "mbss", mbss);
> > > 
> > > actually makes much more sense.
> > > 
> > > Given that this is direct firmware interaction, I can't say which
> > > is
> > > correct - all I can say is that mainline kernels are currently
> > > broken.
> > 
> > Indeed. I have to come up with a proper fix for both scenarios.
> > Thanks
> > for the report.
> 
> I'm now on 4.13-rc4, and running with my patch.  I've configured AP
> mode:
> 
> Interface wlan0
> 	ifindex 3
> 	wdev 0x1
> 	addr 6c:ad:f8:1d:4c:d9
> 	ssid Time
> 	type AP
> 	wiphy 0
> 	channel 5 (2432 MHz), width: 20 MHz, center1: 2432 MHz
> 
> using NetworkManager with a WPA2 key.  However, a Realtek RTL8192EU
> client is trying to connect to it, but is unable:
> 
> [ 1750.497436] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
> [ 1750.530929] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
> [ 1750.738795] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 2/3)
> [ 1750.946780] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 3/3)
> [ 1751.154764] wlan0: authentication with 6c:ad:f8:1d:4c:d9 timed out
> 
> The antennas are definitely within range (finger to thumb distance)
> and the Realtek can definitely see the BCM4330 in AP mode.  I don't
> see the interrupts for the SDIO interface increment while the client
> tries to connect.
> 
> The WPA2 password is definitely the same on both ends.
> 
> Any ideas how to debug this?
> 
> Thanks.
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-08-15  6:25       ` rosenp
@ 2017-08-15  8:22         ` Russell King - ARM Linux
  2017-08-15  9:42           ` Arend van Spriel
  0 siblings, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-08-15  8:22 UTC (permalink / raw)
  To: rosenp
  Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list

On Mon, Aug 14, 2017 at 11:25:03PM -0700, rosenp@gmail.com wrote:
> If using rtlwifi, you could try using rtl8xxxu and see if you get
> similar results. ¯\_(ツ)_/¯

I'm using rtl8xxxu.  I don't think rtlwifi supports the 8192eu - it
certainly does not list the device id:
Bus 001 Device 002: ID 0bda:818b Realtek Semiconductor Corp.

As an extra data point, trying to associate to the 4330 with an Intel
client gives:

[8821752.691490] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
[8821752.693448] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
[8821752.696230] wlan0: authenticated
[8821752.697493] wlan0: associate with 6c:ad:f8:1d:4c:d9 (try 1/3)
[8821752.700816] wlan0: RX AssocResp from 6c:ad:f8:1d:4c:d9 (capab=0x411 status=0 aid=1)
[8821752.704407] wlan0: associated
[8821755.814844] wlan0: deauthenticated from 6c:ad:f8:1d:4c:d9 (Reason: 2=PREV_AUTH_NOT_VALID)

which gets slightly further but ultimately still fails.

> On Tue, 2017-08-15 at 00:30 +0100, Russell King - ARM Linux wrote:
> > On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote:
> > > On 28-07-17 19:49, Russell King - ARM Linux wrote:
> > > > Replacing that "(!mbss)" with "mbss" results in AP mode working
> > > > on the
> > > > 4330.  However, I suspect:
> > > > 
> > > > 		if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
> > > > 			brcmf_fil_iovar_int_set(ifp, "mbss", mbss);
> > > > 
> > > > actually makes much more sense.
> > > > 
> > > > Given that this is direct firmware interaction, I can't say which
> > > > is
> > > > correct - all I can say is that mainline kernels are currently
> > > > broken.
> > > 
> > > Indeed. I have to come up with a proper fix for both scenarios.
> > > Thanks
> > > for the report.
> > 
> > I'm now on 4.13-rc4, and running with my patch.  I've configured AP
> > mode:
> > 
> > Interface wlan0
> > 	ifindex 3
> > 	wdev 0x1
> > 	addr 6c:ad:f8:1d:4c:d9
> > 	ssid Time
> > 	type AP
> > 	wiphy 0
> > 	channel 5 (2432 MHz), width: 20 MHz, center1: 2432 MHz
> > 
> > using NetworkManager with a WPA2 key.  However, a Realtek RTL8192EU
> > client is trying to connect to it, but is unable:
> > 
> > [ 1750.497436] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
> > [ 1750.530929] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
> > [ 1750.738795] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 2/3)
> > [ 1750.946780] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 3/3)
> > [ 1751.154764] wlan0: authentication with 6c:ad:f8:1d:4c:d9 timed out
> > 
> > The antennas are definitely within range (finger to thumb distance)
> > and the Realtek can definitely see the BCM4330 in AP mode.  I don't
> > see the interrupts for the SDIO interface increment while the client
> > tries to connect.
> > 
> > The WPA2 password is definitely the same on both ends.
> > 
> > Any ideas how to debug this?
> > 
> > Thanks.
> > 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-08-15  8:22         ` Russell King - ARM Linux
@ 2017-08-15  9:42           ` Arend van Spriel
  2017-08-15  9:58             ` Russell King - ARM Linux
  0 siblings, 1 reply; 13+ messages in thread
From: Arend van Spriel @ 2017-08-15  9:42 UTC (permalink / raw)
  To: Russell King - ARM Linux, rosenp
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

On 15-08-17 10:22, Russell King - ARM Linux wrote:
> On Mon, Aug 14, 2017 at 11:25:03PM -0700, rosenp@gmail.com wrote:
>> If using rtlwifi, you could try using rtl8xxxu and see if you get
>> similar results. ¯\_(ツ)_/¯
> 
> I'm using rtl8xxxu.  I don't think rtlwifi supports the 8192eu - it
> certainly does not list the device id:
> Bus 001 Device 002: ID 0bda:818b Realtek Semiconductor Corp.
> 
> As an extra data point, trying to associate to the 4330 with an Intel
> client gives:
> 
> [8821752.691490] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
> [8821752.693448] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
> [8821752.696230] wlan0: authenticated
> [8821752.697493] wlan0: associate with 6c:ad:f8:1d:4c:d9 (try 1/3)
> [8821752.700816] wlan0: RX AssocResp from 6c:ad:f8:1d:4c:d9 (capab=0x411 status=0 aid=1)
> [8821752.704407] wlan0: associated
> [8821755.814844] wlan0: deauthenticated from 6c:ad:f8:1d:4c:d9 (Reason: 2=PREV_AUTH_NOT_VALID)
> 
> which gets slightly further but ultimately still fails.

Hi Russell,

On vacation this week, but it is raining over here so have some moments 
to kill. Here a couple of things to try:

1) try without encryption.
2) does hostapd log show anything interesting.
3) can you use the Intel client to make a sniff.

I can check what could trigger the firmware after 3 sec. to deauth. Just 
not sure if I will get to that this week. Could be failing EAPOL handshake.

Regards,
Arend

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-08-15  9:42           ` Arend van Spriel
@ 2017-08-15  9:58             ` Russell King - ARM Linux
  2017-08-15 10:29               ` Russell King - ARM Linux
  0 siblings, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-08-15  9:58 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: rosenp, linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

On Tue, Aug 15, 2017 at 11:42:12AM +0200, Arend van Spriel wrote:
> On 15-08-17 10:22, Russell King - ARM Linux wrote:
> >On Mon, Aug 14, 2017 at 11:25:03PM -0700, rosenp@gmail.com wrote:
> >>If using rtlwifi, you could try using rtl8xxxu and see if you get
> >>similar results. ¯\_(ツ)_/¯
> >
> >I'm using rtl8xxxu.  I don't think rtlwifi supports the 8192eu - it
> >certainly does not list the device id:
> >Bus 001 Device 002: ID 0bda:818b Realtek Semiconductor Corp.
> >
> >As an extra data point, trying to associate to the 4330 with an Intel
> >client gives:
> >
> >[8821752.691490] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
> >[8821752.693448] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
> >[8821752.696230] wlan0: authenticated
> >[8821752.697493] wlan0: associate with 6c:ad:f8:1d:4c:d9 (try 1/3)
> >[8821752.700816] wlan0: RX AssocResp from 6c:ad:f8:1d:4c:d9 (capab=0x411 status=0 aid=1)
> >[8821752.704407] wlan0: associated
> >[8821755.814844] wlan0: deauthenticated from 6c:ad:f8:1d:4c:d9 (Reason: 2=PREV_AUTH_NOT_VALID)
> >
> >which gets slightly further but ultimately still fails.
> 
> Hi Russell,
> 
> On vacation this week, but it is raining over here so have some moments to
> kill. Here a couple of things to try:
> 
> 1) try without encryption.
> 2) does hostapd log show anything interesting.
> 3) can you use the Intel client to make a sniff.
> 
> I can check what could trigger the firmware after 3 sec. to deauth. Just not
> sure if I will get to that this week. Could be failing EAPOL handshake.

Sorry for the confusion - the problem with iwlwifi turned out to be a
lack of /dev/random entropy, causing hostapd to forcefully deauth the
client - that was hidden when running hostapd from systemd and is only
visible if you run hostapd manually.

(I have other problems there - manually starting hostapd works every
time, but when started using systemctl start hostapd, systemctl status
hostapd always reports that it's started but exited and it definitely
isn't running... I'm just hitting one problem after another here with
wireless, I'm quite sure this tech hates me!)

However, I'm still having problems with the Realtek not getting further
than _allegedly_ sending the auth frames - I'm not convinced that the
driver is actually sending anything yet.  I can't see anything suggesting
it is from iwlwifi in monitor mode, and enabling all the debug for the
rtl8xxxu driver doesn't give the slightest hint that this driver is
doing anything remotely useful to transmit these frames.  For instance:

[41742.979480] usb 1-1: rtl8xxxu_read32(0440)  = 0x0000000f, len 4
[41742.985826] usb 1-1: rtl8xxxu_write32(0440) = 0x0000000f
[41742.994470] usb 1-1: rtl8xxxu_write8(0480) = 0x04
[41742.999430] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
[41743.206163] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 2/3)
[41743.414148] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 3/3)
[41743.622138] wlan0: authentication with 6c:ad:f8:1d:4c:d9 timed out
[41743.629100] usb 1-1: rtl8xxxu_write8(0618) = 0x00
[41743.636490] usb 1-1: rtl8xxxu_write8(0619) = 0x00
[41743.641573] usb 1-1: rtl8xxxu_write8(061a) = 0x00

How can it send auth packets without writing to any registers (this is
with all debug options set in /sys/module/rtl8xxxu/parameters/debug !)

So, I don't think the 4330 has a problem, I think it's all down to
the Realtek driver being buggy.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-08-15  9:58             ` Russell King - ARM Linux
@ 2017-08-15 10:29               ` Russell King - ARM Linux
  0 siblings, 0 replies; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-08-15 10:29 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: rosenp, linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

On Tue, Aug 15, 2017 at 10:58:42AM +0100, Russell King - ARM Linux wrote:
> Sorry for the confusion - the problem with iwlwifi turned out to be a
> lack of /dev/random entropy, causing hostapd to forcefully deauth the
> client - that was hidden when running hostapd from systemd and is only
> visible if you run hostapd manually.
> 
> (I have other problems there - manually starting hostapd works every
> time, but when started using systemctl start hostapd, systemctl status
> hostapd always reports that it's started but exited and it definitely
> isn't running... I'm just hitting one problem after another here with
> wireless, I'm quite sure this tech hates me!)
> 
> However, I'm still having problems with the Realtek not getting further
> than _allegedly_ sending the auth frames - I'm not convinced that the
> driver is actually sending anything yet.  I can't see anything suggesting
> it is from iwlwifi in monitor mode, and enabling all the debug for the
> rtl8xxxu driver doesn't give the slightest hint that this driver is
> doing anything remotely useful to transmit these frames.  For instance:
> 
> [41742.979480] usb 1-1: rtl8xxxu_read32(0440)  = 0x0000000f, len 4
> [41742.985826] usb 1-1: rtl8xxxu_write32(0440) = 0x0000000f
> [41742.994470] usb 1-1: rtl8xxxu_write8(0480) = 0x04
> [41742.999430] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
> [41743.206163] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 2/3)
> [41743.414148] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 3/3)
> [41743.622138] wlan0: authentication with 6c:ad:f8:1d:4c:d9 timed out
> [41743.629100] usb 1-1: rtl8xxxu_write8(0618) = 0x00
> [41743.636490] usb 1-1: rtl8xxxu_write8(0619) = 0x00
> [41743.641573] usb 1-1: rtl8xxxu_write8(061a) = 0x00
> 
> How can it send auth packets without writing to any registers (this is
> with all debug options set in /sys/module/rtl8xxxu/parameters/debug !)
> 
> So, I don't think the 4330 has a problem, I think it's all down to
> the Realtek driver being buggy.

And things get even weirder - if I reboot, rtl8xxxu fails to associate:

[   38.377649] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
[   38.410252] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
[   38.616678] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 2/3)
[   38.824660] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 3/3)
[   39.032645] wlan0: authentication with 6c:ad:f8:1d:4c:d9 timed out

if I then rmmod the rtl8xxxu module and reinsert the exact same module:

[   49.914724] wlan0: authenticate with 6c:ad:f8:1d:4c:d9
[   49.935765] wlan0: send auth to 6c:ad:f8:1d:4c:d9 (try 1/3)
[   49.943182] wlan0: authenticated
[   49.956116] wlan0: associate with 6c:ad:f8:1d:4c:d9 (try 1/3)
[   49.971504] wlan0: RX AssocResp from 6c:ad:f8:1d:4c:d9 (capab=0x411 status=0 aid=2)
[   49.985466] usb 1-1: rtl8xxxu_bss_info_changed: HT supported
[   49.997918] wlan0: associated

This looks like a rtl8xxxu driver / core mac80211 bug, so I'll take it
to the rtl8xxx folk now.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-07-31 20:28       ` Arend van Spriel
@ 2017-11-14 23:07         ` Russell King - ARM Linux
  2017-11-15  8:47           ` Arend van Spriel
  0 siblings, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2017-11-14 23:07 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

Arend,

Did this bug ever get fixed, or are 4330's still ending up advertising
BCRM_TEST_SSID when they're put into AP mode with mainline kernels?

It would be good to know whether I can drop my patch for this from my
kernel tree and still have working AP mode.

Thanks.

On Mon, Jul 31, 2017 at 10:28:50PM +0200, Arend van Spriel wrote:
> On 31-07-17 14:59, Russell King - ARM Linux wrote:
> > On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote:
> >> I was going to agree with you, but having second thoughts. There are
> >> actually two use-cases that need to be handled properly. The regular AP
> >> case and the MBSS case. In case of MBSS the initial AP interface will
> >> have mbss set to false and subsequent AP interfaces will have mbss set
> >> to true, but in firmware this has to be configured inverted. That is
> >> what the code above is doing. However, this indeed breaks the regular AP
> >> case for firmwares that abuse that setting for testing purposes (no idea
> >> why that is in a released firmware).
> > 
> > Maybe detect the BCRM_TEST_SSID string in the firmware file (as it's
> > broken up amongst other data, it's not trivial) and disable mbss for
> > such firmware?  Alternatively, maybe blacklist mbss for some firmware
> > versions?
> 
> Well. It seem 43362 chip also had this and we disabled mbss for that
> chipset. So we may do that for 4330 as well.
> 
> > Do the firmware versions that include this "abuse" actually have
> > functional mbss?
> 
> Digging through our internal bug database I found a remark that
> BRCM_TEST_SSID showing up means mbss is not functional.
> 
> > There's also the obvious question: which firmware is recommended for
> > the 4330?
> 
> We tend to rely on what is released to AOSP as our team does not have
> the bandwidth to go through the release process. I checked and it is
> still the same so matches what is in linux-firmware.
> 
> Regards,
> Arend

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: AP mode with Broadcom 4330
  2017-11-14 23:07         ` Russell King - ARM Linux
@ 2017-11-15  8:47           ` Arend van Spriel
  0 siblings, 0 replies; 13+ messages in thread
From: Arend van Spriel @ 2017-11-15  8:47 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list

On 11/15/2017 12:07 AM, Russell King - ARM Linux wrote:
> Arend,
>
> Did this bug ever get fixed, or are 4330's still ending up advertising
> BCRM_TEST_SSID when they're put into AP mode with mainline kernels?
>
> It would be good to know whether I can drop my patch for this from my
> kernel tree and still have working AP mode.

Hi Russell,

For now keep it as this thread got dusty on my end. Sorry about that. I 
can submit a patch for brcmfmac disabling mbss, which may be what you 
are carrying in your kernel tree right now. As 4330 is out there for a 
while I guess it is good to make it a stable patch.

Regards,
Arend

> Thanks.
>
> On Mon, Jul 31, 2017 at 10:28:50PM +0200, Arend van Spriel wrote:
>> On 31-07-17 14:59, Russell King - ARM Linux wrote:
>>> On Fri, Jul 28, 2017 at 09:50:21PM +0200, Arend van Spriel wrote:
>>>> I was going to agree with you, but having second thoughts. There are
>>>> actually two use-cases that need to be handled properly. The regular AP
>>>> case and the MBSS case. In case of MBSS the initial AP interface will
>>>> have mbss set to false and subsequent AP interfaces will have mbss set
>>>> to true, but in firmware this has to be configured inverted. That is
>>>> what the code above is doing. However, this indeed breaks the regular AP
>>>> case for firmwares that abuse that setting for testing purposes (no idea
>>>> why that is in a released firmware).
>>>
>>> Maybe detect the BCRM_TEST_SSID string in the firmware file (as it's
>>> broken up amongst other data, it's not trivial) and disable mbss for
>>> such firmware?  Alternatively, maybe blacklist mbss for some firmware
>>> versions?
>>
>> Well. It seem 43362 chip also had this and we disabled mbss for that
>> chipset. So we may do that for 4330 as well.
>>
>>> Do the firmware versions that include this "abuse" actually have
>>> functional mbss?
>>
>> Digging through our internal bug database I found a remark that
>> BRCM_TEST_SSID showing up means mbss is not functional.
>>
>>> There's also the obvious question: which firmware is recommended for
>>> the 4330?
>>
>> We tend to rely on what is released to AOSP as our team does not have
>> the bandwidth to go through the release process. I checked and it is
>> still the same so matches what is in linux-firmware.
>>
>> Regards,
>> Arend
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2017-11-15  8:47 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-28 14:15 AP mode with Broadcom 4330 Russell King - ARM Linux
2017-07-28 17:49 ` Russell King - ARM Linux
2017-07-28 19:50   ` Arend van Spriel
2017-07-31 12:59     ` Russell King - ARM Linux
2017-07-31 20:28       ` Arend van Spriel
2017-11-14 23:07         ` Russell King - ARM Linux
2017-11-15  8:47           ` Arend van Spriel
2017-08-14 23:30     ` Russell King - ARM Linux
2017-08-15  6:25       ` rosenp
2017-08-15  8:22         ` Russell King - ARM Linux
2017-08-15  9:42           ` Arend van Spriel
2017-08-15  9:58             ` Russell King - ARM Linux
2017-08-15 10:29               ` Russell King - ARM Linux

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).