Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Tarnyagin <abi.dmitryt@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] cfg80211: merge in beacon ies of hidden bss.
Date: Thu, 03 Nov 2011 10:39:01 +0100	[thread overview]
Message-ID: <1320313141.3950.35.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <CAMG6FYhgeNg3CbDZg7GkJkq1ArJ=5n+bD=zPx=6ZFe7-Kj4Jmw@mail.gmail.com> (sfid-20111103_101806_675539_162704BA)

Hi Dmitry,

> >> +     if (!ie1 && !ie2)
> >> +             return 0;
> > I don't think it's valid to leave out the SSID IE, so I'd rather not
> > have that test here. It might interact badly with other uses (mesh?)
> >
> ie1 and ie2 could not NULL at the same time, otherwise the bss
> would be found in the first search attempt. However, I would prefer
> to have some water-proof check here. WARN_ON? BUG_ON?

Maybe a warning? But I don't see why it'll just fall through to the next
line and return -1 if one of them is missing.

> >> +             if (ie2[i + 2])
> >> +                     return -1;
> > I don't understand this loop. Why check that ie2 is zeroed, but check
> > only to the minlen of ie1, ie2?
> >
> Check that ie2 is zeroed is a check for hidden SSID.
> Check only to minlent to be in-line with cmp_ies().
> 
> >> +     return ie2[1] - ie1[1];
> > I'd error out much earlier if the length is different instead of
> > comparing to the minlen first.
> >
> Key comparator must use same algorithm in any rb-tree search function
> (order is important), otherwise ordering of items in the tree is broken
> and search gives incorrect results.
> This code uses same order as cmp_ies() does.

Oh. Good point. Add a comment?

> >> @@ -494,6 +578,13 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
> >>       spin_lock_bh(&dev->bss_lock);
> >>
> >>       found = rb_find_bss(dev, res);
> >> +     if (!found) {
> >> +             struct cfg80211_internal_bss *hidden;
> >> +
> >> +             hidden = rb_find_hidden_bss(dev, res);
> >> +             if (hidden)
> >> +                     merge_hidden_ies(res, hidden);
> >> +     }
> > I was going to complain that I don't understand why this works -- but
> > then I think now I do. If you move the code down into the else branch
> > it'll be much easier to follow.
> >
> Ok.
> 
> Thank you for review!

Eliad pointed out another thing: It is possible to have multiple SSIDs
hidden behind a single hidden SSID. Therefore, this should update all of
those BSS structs. Also, I'm a tad confused about the matching code
here, this code path executes for both received beacons and probe
responses, but probe responses would typically have found the BSS
already? But what if we only have a beacon and then receive a probe
response? Or vice versa? Some comments would be good outlining how that
works.

johannes


  reply	other threads:[~2011-11-03  9:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-02 18:19 [PATCH] cfg80211: merge in beacon ies of hidden bss Dmitry Tarnyagin
2011-11-03  8:55 ` Johannes Berg
2011-11-03  9:17   ` Dmitry Tarnyagin
2011-11-03  9:39     ` Johannes Berg [this message]
2011-11-03 10:03       ` Dmitry Tarnyagin
2011-11-03 10:13         ` Johannes Berg
2011-11-03 15:14 ` Eliad Peller
2011-11-03 21:12   ` Dmitry Tarnyagin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1320313141.3950.35.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=abi.dmitryt@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox