> Is a new version of this patch hinging only on this? We'd love to have a
> fixed-
> up one :-)
The new version covers the use cases mentioned by Jouni as the OUIs of the
vendor commands
has the format of OUI + type + subtype. For other format of vendor commands,
they will be treated
as
Hi,
> As you pointed out the use cases for having vendor elements in MBSSID
> subelements, what is
> your suggestion to identify and process the vendor elements?
Is a new version of this patch hinging only on this? We'd love to have
a fixed-up one :-)
johannes
> On Tue, Nov 14, 2017 at 02:39:31PM +, Peng Xu wrote:
> > > I'm not even sure why this is necessary anyway though, do we really
> > > think vendors will expect to be able to put vendor IEs inside the
> > > subelements and override the ones outside?
> > >
> > > Is there even any point for the
On Tue, Nov 14, 2017 at 02:39:31PM +, Peng Xu wrote:
> > I'm not even sure why this is necessary anyway though, do we really think
> > vendors will expect to be able to put vendor IEs inside the subelements and
> > override the ones outside?
> >
> > Is there even any point for the WFA ones?
>
> Right, not really.
>
> I'm not even sure why this is necessary anyway though, do we really think
> vendors will expect to be able to put vendor IEs inside the subelements and
> override the ones outside?
>
> Is there even any point for the WFA ones? It seems WMM really ought to be
> the
> >
> > This may be right for the WFA/Microsoft OUI, but not necessary anything
> > else?
> >
>
> Right, I only considered the most common cases since I did not find a
> generic way to compare two vendor elements. Any suggestion?
Right, not really.
I'm not even sure why this is necessary
> >
> > It is OUI + type + subTye.
>
> Ah, right, type/subtype.
>
> Still, this is problematic, because there's nothing that says that the vendor
> IE
> must have OUI + type + subtype, the spec only says OUI + vendor specific
> data.
>
> This may be right for the WFA/Microsoft OUI, but not
On Tue, 2017-11-14 at 14:20 +, Peng Xu wrote:
> >
> > > + if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) {
> > > + if (!memcmp(tmp_old + 2, tmp + 2, 5)) {
> > > + /* same vendor ie, copy from new ie
> >
> > */
> > > +
>
> > + if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) {
> > + if (!memcmp(tmp_old + 2, tmp + 2, 5)) {
> > + /* same vendor ie, copy from new ie
> */
> > + memcpy(pos, tmp, tmp[1] + 2);
>
> + if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) {
> + if (!memcmp(tmp_old + 2, tmp + 2, 5)) {
> + /* same vendor ie, copy from new ie */
> + memcpy(pos, tmp, tmp[1] + 2);
> +
Hi,
Thanks for working on this.
> +u8 *gen_new_bssid(const u8 *bssid, u8 max_bssid, u8 mbssid_index, gfp_t gfp)
I looks like this should be static? I'm also pretty sure you leak the
result, I guess you shouldn't allocate memory here. Just passing in a
pointer to a buffer (that could be on the
11 matches
Mail list logo
