From: Jean Tourrilhes <jt@hpl.hp.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: netdev@vger.kernel.org, softmac-dev@vger.kernel.org,
Ulrich Kunitz <kune@deine-taler.de>
Subject: Re: softmac: semantics of SIOCSIWFREQ
Date: Mon, 17 Apr 2006 13:01:39 -0700 [thread overview]
Message-ID: <20060417200139.GA28626@bougret.hpl.hp.com> (raw)
In-Reply-To: <1145302029.4116.14.camel@localhost>
On Mon, Apr 17, 2006 at 09:27:09PM +0200, Johannes Berg wrote:
> On Mon, 2006-04-17 at 12:06 -0700, Jean Tourrilhes wrote:
>
> > Definitely. I was just pointing out that scanning behaviour is
> > not dictated by current setting of the drivers (except when the
> > hardware does it, cf. Ornoco).
>
> Yeah, I was just repeating it for Ulrich :)
>
> > For freq, it's simpler. In managed mode, it's never 'fixed',
> > because the card/driver choose the frequency. In master mode, it's
> > almost always 'fixed', because the user has to set the frequency. In
> > ad-hoc mode, it depend in the node creates or not the IBSS.
>
> But isn't that a detail the user shouldn't have to know? See, if a node
> with a higher TSF joins the IBSS, then it gets to send out the beacons
> for it, IIRC.
Who sent the beacon is different from who created the IBSS. If
you don't like this proposal, here is another one : if in ad-hoc mode
the actual IBSS freq is the same as what the user set, then set the
'fixed' flag, otherwise report the actual freq without the 'fixed'
flag.
Or if you have another meaningful use of the flag in ad-hoc
mode, just shout.
> johannes
Jean
next prev parent reply other threads:[~2006-04-17 20:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-16 12:34 softmac: semantics of SIOCSIWFREQ Johannes Berg
2006-04-16 17:17 ` Ulrich Kunitz
2006-04-17 16:37 ` Jean Tourrilhes
2006-04-17 18:48 ` Johannes Berg
2006-04-17 19:06 ` Jean Tourrilhes
2006-04-17 19:27 ` Johannes Berg
2006-04-17 20:01 ` Jean Tourrilhes [this message]
2006-04-17 20:19 ` Johannes Berg
[not found] <1141928917.26954.7.camel@localhost.localdomain>
[not found] ` <1141935893.28038.2.camel@localhost.localdomain>
2006-03-09 20:36 ` [RFC PATCH] softmac: (v2) send WEXT assoc/disassoc events to userspace Larry Finger
[not found] ` <1141936896.28038.6.camel@localhost.localdomain>
2006-04-12 23:56 ` Johannes Berg
[not found] ` <20060413001909.GB23116@falcon.fugal.net>
[not found] ` <1144887916.4187.28.camel@localhost>
[not found] ` <20060413002816.GC23116@falcon.fugal.net>
[not found] ` <1144888334.4187.32.camel@localhost>
2006-04-14 1:05 ` Hans Fugal
2006-04-15 19:25 ` Johannes Berg
2006-04-16 11:24 ` softmac: semantics of SIOCSIWFREQ Ulrich Kunitz
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=20060417200139.GA28626@bougret.hpl.hp.com \
--to=jt@hpl.hp.com \
--cc=johannes@sipsolutions.net \
--cc=kune@deine-taler.de \
--cc=netdev@vger.kernel.org \
--cc=softmac-dev@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;
as well as URLs for NNTP newsgroup(s).