On Wed, 2011-08-31 at 08:20 +0200, Johannes Berg wrote:
> > Other filters that come to my mind would be by security features,
> > regardless of the SSID (eg. "give me all open security SSIDs", or "I
> > only want WPA2 capable SSIDs"). The wl12xx firmware doesn't support
> > this at the moment, but I can see some potential use-cases for this.
>
> That might be interesting. But maybe that's a filter a la my previous
> model with SSID unset and security set to open etc.? If you add that
> filter to wl12xx you'd get wakeup for every network though, so in this
> special case it might be interesting to know whether or not the device
> supports it. OTOH, if you want to connect to any open network, you'll
> need to swallow the wakeup cost anyway.
>
> > Yet another possibility is to filter out based on signal strength
> > (wl12xx supports it). For instance it may make sense for roaming, eg.
> > "give me only SSIDs with better signal than the one I'm connected to
> > right now").
>
> Wouldn't that also just be an extension? Or would this not be a
> per-network filter?
Right, we can do it as an extension.
> > These are all theoretical and at least we don't have any real
> > requirement for them at the moment. But this was more or less what I
> > was preparing for.
>
> Ok. I think the BSSID blacklist would just be a separate attribute, I
> see no reason to have a nesting for that.
Actually, we could make the filter and blacklisting very generic. We
can use the same attributes for both. The only difference would be that
the former would include anything that matches and the latter would
exclude anything that matches.
> > In any case, I think for the filtering, we can implement some kind of
> > wildcard too. We could have a bit in the filter saying that it's a
> > wildcard, so any results that start with the supplied bytes would pass
> > through.
> >
> > In this case, I think the same rule of not having SSIDs that don't fit
> > the filters would still apply. For instance, if you pass only "DIRECT-"
> > for the probe_reqs, without broadcast, it doesn't make sense to have a
> > filter that only matches "FOOBAR".
>
> True. Do we really want to add this wildcard complexity to filters
> though? Is it really worth it? OTOH, I guess you'd need it for something
> like iPass.
Yeah, it was the hotspot case that I had in mind. But since we don't
need this right now, let's leave it out. It can be added easily later
on.
> > > > I think we can still keep it like this and improve the filter list by
> > > > adding a "wildcard" attribute if you want to filter on P2P wildcards?
> > > >
> > > > Now back to "Maybe cfg80211 should apply that rule", I thought about it,
> > > > but decided to keep it hw-specific, since I don't know what other HW
> > > > will want to do. ;) But I can add it to cfg80211 if you like.
> > >
> > > Is it something you _need_ to make your firmware happy? Otherwise I
> > > think I'd rather leave it out completely :)
> >
> > Kind of, yes. Actually our firmware is "smart" in the scheduled scan
> > feature. You pass a single list of SSIDs to it with attributes such as
> > open/hidden and it will by itself decide whether to send a probe_req for
> > it or not. And it will filter for those SSIDs regardless of whether a
> > probe_req was sent. It's a bit more complicated than that, but not
> > really relevant here.
> >
> > I could probably manage without this limitation in the API, but then it
> > would be difficult to handle the max_ssids and max_filter_ssids
> > limitations (the limitation in our case actually applies to a sum of the
> > two). If we have the limitation in the API, then the filter list will
> > always be a superset of the SSID list, which makes it simpler. ;)
>
> OK :)
I'll add the check in cfg80211 then. There are probably other
combinations that don't make sense either (eg. sending an SSID in the
probes and blacklisting it).
> > > Yeah of course they don't fit but see how we have a separate policy for
> > > key attributes for example.
> >
> > Sure, I tried to look at the key attributes and reg stuff, but they
> > actually use a different nl callback. I didn't see how to use it for
> > the filter stuff, which is actually a subset of attributes for the
> > existing scan attributes. Anyway, I'll check the nl API more carefully
> > and fix this. I probably need to use nla_parse() and such.
>
> > > Oh. Ok you're thinking of this completely differently than I am. With
> > > the filtering I'm looking at (see above) the way to make this make sense
> > > is to do
> > >
> > > FILTERS={1={SSID=foo, ...}, 2={SSID=bar, ...}, ... }
> >
> > This makes sense too, but if we want to support other kinds of filters
> > (such as the ones I mentioned above), we need to have at least the type
> > of filter for each:
> >
> > FILTERS={1={type=SSID, SSID=foo},
> > 2={type=SSID, SSID=bar},
> > 3={type=RSSI, min_rssi=-70},
> > 4={type=BLACKLIST, BSSID=bssid1},
> > 5={type=BLACKLIST, BSSID=bssid2},
> > ...}
> >
> > What I was originally thinking of implementing was this:
> >
> > FILTERS={SSID={SSID_LIST={foo, bar, ...}},
> > RSSI={min_rssi},
> > BLACKLIST={BSSID_LIST={bssid1, bssid2, ...}},
> > ...}
> >
> > ...and the SSID_LIST elements could be foo={SSID="FOO", security=WPA2},
> > bar={SSID="bar", security=OPEN}, for example. Though I'm not sure this
> > is necessary (see my question earlier).
>
> I wouldn't bother nesting those though, so I'd do
>
> NETWORK_FILTER=(1=(SSID=...), ...)
> BSSID_BLACKLIST=(1=...,2=...,...)
> etc.
> That way only the network attributes that belong to a "profile" like
> SSID, security, ... are nested.
Yeah, this is okay. To make it more generic though, should we make it
like this?
MATCH={1={SSID=foo, SECURITY=open, BSSID=00:01:02:03:04:05, ...}, 2={...}}
NOT_MATCH={1={SSID=bar, ...}, 2={BSSID=00:02:03:04:05:06, ...}, ...}
Meaning that we just have MATCH/NO_MATCH and use the same set of
attributes for both? Maybe someone will want to blacklist an SSID or
other attributes too. Who wants to see APs called "Free open wifi"? :D
I also prefer using match/not_match (couldn't find a better antonym),
because "filter" is ambiguous (let-through or leave-out?).
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
