Jouni Malinen wrote :
>
> On Fri, Mar 24, 2006 at 10:57:22AM -0500, Dan Williams wrote:
>
> > <hidden> this is something that ieee80211 does that's completely wrong.
> > Drivers need to report the _exact_ ESSID from the air in their scan
> > results. It's up to the user space app to deal with ESSID length of 0.
>
> I agree that "<hidden>" should not be used, but this is bit more complex
> than just reporting zero-length SSID.
The Wireless Extension API has the notion of "absent" ESSID as
opposed to zero-length ESSID. Maybe we could use that ?
The patch would look like (totally untested) :
--- net/ieee80211/ieee80211_wx.c 2006-03-24 10:43:04.000000000 -0500
+++ net/ieee80211/ieee80211_wx.c 2006-03-24 10:53:27.000000000 -0500
@@ -64,8 +64,8 @@
iwe.cmd = SIOCGIWESSID;
iwe.u.data.flags = 1;
if (network->flags & NETWORK_EMPTY_ESSID) {
- iwe.u.data.length = sizeof("<hidden>");
- start = iwe_stream_add_point(start, stop, &iwe, "<hidden>");
+ iwe.u.data.flags = 1; /* Hidden ESSID */
+ iwe.u.data.length = 0;
+ start = iwe_stream_add_point(start, stop, &iwe, "");
} else {
iwe.u.data.length = min(network->ssid_len, (u8) 32);
start = iwe_stream_add_point(start, stop, &iwe, network->ssid);
If you want, I can change the source of iwlist.c to mention
'hidden' explicitely.
The other suggestions all look good to me...
> By the way, can we try to start
> getting rid of calling this ESSID; it's SSID and ESSID never made it to
> the IEEE 802.11 standard.
I've seen time where people said SSID when referring to the
BSSID, so I just wanted the terminology to be without ambiguity.
James Ketrenos wrote :
>
> Since the scan results are supposed to report networks found; the first
> agreement we need to make between user space and the kernel is how we
> define a 'network', and how do we determine when a network has been
> updated?
[...]
> Currently ieee80211 does not differentiate between probe responses and
> beacons for collecting network data. To "fix" the problem we have now,
> ieee80211 needs to be changed to be able to distinguish between probe
> respones and beacons, and update all networks that match channel and MAC
> when a beacon is received (regardless of SSID) and update a specific
> network if the frame is a probe response.
The problem of trying to keep probe response for longer period
of time is that they may no longer be valid. As you roam around,
things need to timeout/expire because they are no longer reachable.
But, before going into deep technical discussions, we may want
to remind us what is the goal of this API. The goal is to present the
user a list of potential networks that can be used by him, in the case
he doesn't want to associate with a specific network. Not all
associations need it, it's a convenience feature for finding open
networks.
The network that don't send beacon do so to cloak themselves,
i.e. they don't want random joe to access them. If they don't want to
advertise themselves, the user don't really need to know about them,
therefore it's acceptable to not show them in a scan result.
If the user know about this network via other means, he can
still associate with it by entering manually the ESSID. And you you
really want to know the exhaustive list of networks around, please use
kismet.
The only thing debatable is about the current associated
network, in case it's cloaked. This network has already been
discovered (we are associated with it), therefore the user does not
really require to see it in scan results, however it would be nice for
completness.
> Ideally user space should just register to receive all beacons and probe
> responses from the network device and do all the parsing and network
> management
We may get there one day, but it will take time. That would be
the most simple and efficient API. Note that some old hardware would
not allow that.
Have fun...
Jean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
