Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1425019 > unrolled thread

Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces Rafał Miłecki <zajec5@gmail.com> - 2016-06-17 14:40 +0200
    Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces Arend van Spriel <arend.vanspriel@broadcom.com> - 2016-06-17 21:10 +0200
      Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces Rafał Miłecki <zajec5@gmail.com> - 2016-06-17 22:50 +0200

#1425019 — Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces

On 1 June 2016 at 21:00, Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> On 01-06-16 16:36, Rafał Miłecki wrote:
>> We already support adding extra (AP) interfaces so it also makes an
>> obvious sense to allow deleting them.
>>
>> Adding a new interface is implemented by sending request to firmware for
>> creating a new BSS and waiting for a proper event. Ideally deleting
>> interface should be handled in a similar way. There should be a request
>> to firmware for deleting BSS and firmware should respond with an event.
>>
>> Unfortunately it doesn't seem to work with recent firmwares. They never
>> seem to delete BSS and never send BRCMF_E_IF_DEL. As a workaround this
>> patch deletes Linux interface while keeping a track of BSSes present in
>> a firmware. If there is request for adding a new interface this code is
>> capable of reusing existing BSS-es.
>
> It is not so much an issue of recent firmware. Actually, on recent
> firmware 7.x.y.z and higher there are other command to create *and*
> delete additional interfaces. On the other hand we aim to support a
> large number of devices going back to bcm4329 so we have to come up with
> a scheme to use the new commands or fallback to old api. Let's hope we
> can reuse much of this effort you put in.

You gave me a complex puzzle there :D It took me a while to find out
what API you meant.

Finally I found an interesting wlioctl.h in SDK 9.10.178.27 that gave
me some clue. I got this SDK from ASUS RT-AC1200G+ open souce tarball.
There are 2 interesting structs:

typedef struct wl_interface_create {
        uint16 ver; /* version of this struct */
        uint32  flags; /* flags that defines the operation */
        struct ether_addr   mac_addr; /* Optional Mac address */
        uint32  wlc_index; /* Optional wlc index */
} wl_interface_create_t;

typedef struct wl_interface_info {
        uint16 ver; /* version of this struct */
        struct ether_addr    mac_addr; /* MAC address of the interface */
        char ifname[BCM_MSG_IFNAME_MAX]; /* name of interface */
        uint8 bsscfgidx; /* source bsscfg index */
} wl_interface_info_t;

I couldn't find any corresponding WLC_* in wlioctl_defs.h, so I guess
I should use WLC_SET_VAR (or WLC_SET_VAR as you prefer) with some
string. Any tip what would it be? Something like
"wl_interface_create"? Can you reveal such a small secret?

Also can you share any tip on removing interface? I don't see any
struct for that. Is that handled by some special value in
"wl_interface_create_t" or by separated string used with WLC_SET_VAR?

[toc] | [next] | [standalone]

#1425387

On 17-06-16 14:30, Rafał Miłecki wrote:
> On 1 June 2016 at 21:00, Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
>> On 01-06-16 16:36, Rafał Miłecki wrote:
>>> We already support adding extra (AP) interfaces so it also makes an
>>> obvious sense to allow deleting them.
>>>
>>> Adding a new interface is implemented by sending request to firmware for
>>> creating a new BSS and waiting for a proper event. Ideally deleting
>>> interface should be handled in a similar way. There should be a request
>>> to firmware for deleting BSS and firmware should respond with an event.
>>>
>>> Unfortunately it doesn't seem to work with recent firmwares. They never
>>> seem to delete BSS and never send BRCMF_E_IF_DEL. As a workaround this
>>> patch deletes Linux interface while keeping a track of BSSes present in
>>> a firmware. If there is request for adding a new interface this code is
>>> capable of reusing existing BSS-es.
>>
>> It is not so much an issue of recent firmware. Actually, on recent
>> firmware 7.x.y.z and higher there are other command to create *and*
>> delete additional interfaces. On the other hand we aim to support a
>> large number of devices going back to bcm4329 so we have to come up with
>> a scheme to use the new commands or fallback to old api. Let's hope we
>> can reuse much of this effort you put in.
> 
> You gave me a complex puzzle there :D It took me a while to find out
> what API you meant.

Actually, the puzzle was supposed to be for me, but I like your
curiosity and persistence in digging up the (partial) info.

> Finally I found an interesting wlioctl.h in SDK 9.10.178.27 that gave
> me some clue. I got this SDK from ASUS RT-AC1200G+ open souce tarball.
> There are 2 interesting structs:
> 
> typedef struct wl_interface_create {
>         uint16 ver; /* version of this struct */
>         uint32  flags; /* flags that defines the operation */
>         struct ether_addr   mac_addr; /* Optional Mac address */
>         uint32  wlc_index; /* Optional wlc index */
> } wl_interface_create_t;
> 
> typedef struct wl_interface_info {
>         uint16 ver; /* version of this struct */
>         struct ether_addr    mac_addr; /* MAC address of the interface */
>         char ifname[BCM_MSG_IFNAME_MAX]; /* name of interface */
>         uint8 bsscfgidx; /* source bsscfg index */
> } wl_interface_info_t;
> 
> I couldn't find any corresponding WLC_* in wlioctl_defs.h, so I guess
> I should use WLC_SET_VAR (or WLC_SET_VAR as you prefer) with some

(huh)? anyway the api indeed uses what we call an iovar, ie.
string-based ioctl.

> string. Any tip what would it be? Something like
> "wl_interface_create"? Can you reveal such a small secret?

It is "interface_create" and "interface_remove".

Regards,
Arend

[toc] | [prev] | [next] | [standalone]

#1425462

On 17 June 2016 at 21:00, Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> On 17-06-16 14:30, Rafał Miłecki wrote:
>> On 1 June 2016 at 21:00, Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
>>> On 01-06-16 16:36, Rafał Miłecki wrote:
>>>> We already support adding extra (AP) interfaces so it also makes an
>>>> obvious sense to allow deleting them.
>>>>
>>>> Adding a new interface is implemented by sending request to firmware for
>>>> creating a new BSS and waiting for a proper event. Ideally deleting
>>>> interface should be handled in a similar way. There should be a request
>>>> to firmware for deleting BSS and firmware should respond with an event.
>>>>
>>>> Unfortunately it doesn't seem to work with recent firmwares. They never
>>>> seem to delete BSS and never send BRCMF_E_IF_DEL. As a workaround this
>>>> patch deletes Linux interface while keeping a track of BSSes present in
>>>> a firmware. If there is request for adding a new interface this code is
>>>> capable of reusing existing BSS-es.
>>>
>>> It is not so much an issue of recent firmware. Actually, on recent
>>> firmware 7.x.y.z and higher there are other command to create *and*
>>> delete additional interfaces. On the other hand we aim to support a
>>> large number of devices going back to bcm4329 so we have to come up with
>>> a scheme to use the new commands or fallback to old api. Let's hope we
>>> can reuse much of this effort you put in.
>>
>> You gave me a complex puzzle there :D It took me a while to find out
>> what API you meant.
>
> Actually, the puzzle was supposed to be for me, but I like your
> curiosity and persistence in digging up the (partial) info.
>
>> Finally I found an interesting wlioctl.h in SDK 9.10.178.27 that gave
>> me some clue. I got this SDK from ASUS RT-AC1200G+ open souce tarball.
>> There are 2 interesting structs:
>>
>> typedef struct wl_interface_create {
>>         uint16 ver; /* version of this struct */
>>         uint32  flags; /* flags that defines the operation */
>>         struct ether_addr   mac_addr; /* Optional Mac address */
>>         uint32  wlc_index; /* Optional wlc index */
>> } wl_interface_create_t;
>>
>> typedef struct wl_interface_info {
>>         uint16 ver; /* version of this struct */
>>         struct ether_addr    mac_addr; /* MAC address of the interface */
>>         char ifname[BCM_MSG_IFNAME_MAX]; /* name of interface */
>>         uint8 bsscfgidx; /* source bsscfg index */
>> } wl_interface_info_t;
>>
>> I couldn't find any corresponding WLC_* in wlioctl_defs.h, so I guess
>> I should use WLC_SET_VAR (or WLC_SET_VAR as you prefer) with some
>
> (huh)? anyway the api indeed uses what we call an iovar, ie.
> string-based ioctl.

That's what I meant, sorry for wrong naming :)


>> string. Any tip what would it be? Something like
>> "wl_interface_create"? Can you reveal such a small secret?
>
> It is "interface_create" and "interface_remove".

It (almost) works, thanks! I just hit some bug in brcmfmac in handling
events. It can be exposed by deleting 2 interfaces quickly, one by
one, it seems. I'll debug this.

-- 
Rafał

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web