softmac: semantics of SIOCSIWFREQ

softmac: semantics of SIOCSIWFREQ

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

[breaking out to a new thread so discussion on this doesn't get too
hidden, CC Jean since he designed this]

> - Is SIOCSIWFREQ allowed while associated?

No idea.

> - If the flag IW_FREQ_FIXED is set, should all activitity
>   including scanning only be allowed on this frequency? (Actually
>   a better would even be to work with channel/frequency sets.
>   These sets would make a lot of sense for parallel scanning
>   whith more than one device.)

Yeah, but that's impossible to code on top of the current wext
structures I'd say.

> - Is there any use of the control, if the frequency is not fixed?

Good question :)

> SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
> included in the softmac. If I would have a rough idea, what the
> semantics should be, I would even volunteer to implement it.

Yes, they definitely could/should be moved into softmac, but when
writing softmac I had no real incentive to do it because I didn't want
to dig up the info for all the above points :)

I was thinking of adding all the 'what is this ioctl supposed to do'
things we came up with to the softmac or netdev wiki. Would that be
good/useful, or should we just put it into that driver writers guide?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: softmac: semantics of SIOCSIWFREQ

[Ulrich Kunitz]

On Sun, 16 Apr 2006, Johannes Berg wrote:

> > - If the flag IW_FREQ_FIXED is set, should all activitity
> >   including scanning only be allowed on this frequency? (Actually
> >   a better would even be to work with channel/frequency sets.
> >   These sets would make a lot of sense for parallel scanning
> >   whith more than one device.)
> 
> Yeah, but that's impossible to code on top of the current wext
> structures I'd say.

I could be done via an iwpriv. Actually the Personal Telco people,
would like to use WLAN devices in parallel to do WAR driving. At
least I would like to support the fixed channel semantics.

> > SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
> > included in the softmac. If I would have a rough idea, what the
> > semantics should be, I would even volunteer to implement it.
> 
> I was thinking of adding all the 'what is this ioctl supposed to do'
> things we came up with to the softmac or netdev wiki. Would that be
> good/useful, or should we just put it into that driver writers guide?

Regarding the wireless extension ioctls, I think the best would be
to add kerneldoc comments.

Uli

-- 
Ulrich Kunitz - kune@deine-taler.de

Re: softmac: semantics of SIOCSIWFREQ

[Jean Tourrilhes]

On Sun, Apr 16, 2006 at 02:34:48PM +0200, Johannes Berg wrote:
> [breaking out to a new thread so discussion on this doesn't get too
> hidden, CC Jean since he designed this]
> 
> > - Is SIOCSIWFREQ allowed while associated?
> 
> No idea.

	Usually no, but...
	If you are in managed mode, SIOCSIWFREQ usually should return
an error, because it is not allowed.
	If you are in ad-hoc mode, SIOCSIWFREQ is used if a IBSS needs
to be created. After scanning is done, if you did not find any
network, you will create your own, and you will use the frequency that
was set. You should never return an error.
	If you are in Master mode... Well, this case is obvious ;-)

> > - If the flag IW_FREQ_FIXED is set, should all activitity
> >   including scanning only be allowed on this frequency? (Actually
> >   a better would even be to work with channel/frequency sets.
> >   These sets would make a lot of sense for parallel scanning
> >   whith more than one device.)
> 
> Yeah, but that's impossible to code on top of the current wext
> structures I'd say.

	The struct iw_scan_req has all the goodies you need to control
scanning.
	The IW_FREQ_FIXED is mostly use for SIOCGIWFREQ, when
getting. It tells you if the frequency was set by the user or
automatically picked as the result of scanning.
	I don't think any driver/hardware has the ability to set the
frequency to auto, so IW_FREQ_FIXED is the default.

> > - Is there any use of the control, if the frequency is not fixed?
> 
> Good question :)

	In managed mode, no.

> > SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
> > included in the softmac. If I would have a rough idea, what the
> > semantics should be, I would even volunteer to implement it.
> 
> Yes, they definitely could/should be moved into softmac, but when
> writing softmac I had no real incentive to do it because I didn't want
> to dig up the info for all the above points :)

	It's because softmac only implements managed mode.

> I was thinking of adding all the 'what is this ioctl supposed to do'
> things we came up with to the softmac or netdev wiki. Would that be
> good/useful, or should we just put it into that driver writers guide?

	I've heard the call, I'll try to find some time for that.

> johannes

	Jean

Re: softmac: semantics of SIOCSIWFREQ

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Mon, 2006-04-17 at 09:37 -0700, Jean Tourrilhes wrote:

> 	Usually no, but...
> 	If you are in managed mode, SIOCSIWFREQ usually should return
> an error, because it is not allowed.

Ok.

> 	If you are in ad-hoc mode, SIOCSIWFREQ is used if a IBSS needs
> to be created. After scanning is done, if you did not find any
> network, you will create your own, and you will use the frequency that
> was set. You should never return an error.

Right. Well it should return an error if it is 'associated' in ad-hoc
mode too, no?


> 	The struct iw_scan_req has all the goodies you need to control
> scanning.

Right, so that's just a matter of using a different call to say where to
scan. Gotcha. IOW -- those people that want wardriving should use kismet
or whatever and properly control the driver via the iw_scan_req.

> 	The IW_FREQ_FIXED is mostly use for SIOCGIWFREQ, when
> getting. It tells you if the frequency was set by the user or
> automatically picked as the result of scanning.

Ah, but in which case is it set by the user? And is that 'fixed' then?

> 	I don't think any driver/hardware has the ability to set the
> frequency to auto, so IW_FREQ_FIXED is the default.

What would 'auto' be?

> 	It's because softmac only implements managed mode.

We might do some sort of ad-hoc client-only with Pete's patch, but we'll
never do master or wds I think.

> 	I've heard the call, I'll try to find some time for that.

Oh I was more thinking that I myself could add it somewhere after all
our discussion. If you do that, even better, but with the things we have
discussed already I can definitely help out.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: softmac: semantics of SIOCSIWFREQ

[Jean Tourrilhes]

On Mon, Apr 17, 2006 at 08:48:10PM +0200, Johannes Berg wrote:
> On Mon, 2006-04-17 at 09:37 -0700, Jean Tourrilhes wrote:
> 
> > 	Usually no, but...
> > 	If you are in managed mode, SIOCSIWFREQ usually should return
> > an error, because it is not allowed.
> 
> Ok.
> 
> > 	If you are in ad-hoc mode, SIOCSIWFREQ is used if a IBSS needs
> > to be created. After scanning is done, if you did not find any
> > network, you will create your own, and you will use the frequency that
> > was set. You should never return an error.
> 
> Right. Well it should return an error if it is 'associated' in ad-hoc
> mode too, no?

	Nope, you want to store it for later reuse.
	Let suppose the following sequence :
		iwconfig eth0 mode ad-hoc essid another-ibss
		sleep(2)
		iwconfig eth0 freq 2.42G essid a-new-ibss
	You don't want the second call to fail.

> > 	The struct iw_scan_req has all the goodies you need to control
> > scanning.
> 
> Right, so that's just a matter of using a different call to say where to
> scan. Gotcha. IOW -- those people that want wardriving should use kismet
> or whatever and properly control the driver via the iw_scan_req.

	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).

> > 	The IW_FREQ_FIXED is mostly use for SIOCGIWFREQ, when
> > getting. It tells you if the frequency was set by the user or
> > automatically picked as the result of scanning.
> 
> Ah, but in which case is it set by the user? And is that 'fixed' then?

	It's easier to explain with bitrate. If the user does not set
the bitrate, or set it to 'auto', it's never 'fixed'. If the user set
explicitely a bitrate, it's 'fixed'.
	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.

> > 	I don't think any driver/hardware has the ability to set the
> > frequency to auto, so IW_FREQ_FIXED is the default.
> 
> What would 'auto' be?

	Well, in auto, I would expect the node to look either at the
scan result and/or noise level on the various frequency to decide where
to create the IBSS (ad-hoc) or BSS (master).

> > 	It's because softmac only implements managed mode.
> 
> We might do some sort of ad-hoc client-only with Pete's patch, but we'll
> never do master or wds I think.
> 
> > 	I've heard the call, I'll try to find some time for that.
> 
> Oh I was more thinking that I myself could add it somewhere after all
> our discussion. If you do that, even better, but with the things we have
> discussed already I can definitely help out.
> 
> johannes

	Have fun...

	Jean

Re: softmac: semantics of SIOCSIWFREQ

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

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.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: softmac: semantics of SIOCSIWFREQ

[Jean Tourrilhes]

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

Re: softmac: semantics of SIOCSIWFREQ

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Mon, 2006-04-17 at 13:01 -0700, Jean Tourrilhes wrote:

> 	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.

I don't really see the point of this either.

> 	Or if you have another meaningful use of the flag in ad-hoc
> mode, just shout.

I don't have any meaningful use for it in ad-hoc mode at all :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [RFC PATCH] softmac: (v2) send WEXT assoc/disassoc events to userspace

[Larry Finger]

Dan Williams wrote:
> Completely untested, not entirely sure it compiles.  For whatever
> reason, softmac is sending custom events to userspace already, but it
> should _really_ be sending the right WEXT events instead.  Comments?  If
> this looks good, please apply it.
> 
> Signed-off-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> 

V2 compiles cleanly. It still doesn't authenticate with my WRT54G V5, but that must be another problem.

Larry

Re: [RFC PATCH] softmac: (v2) send WEXT assoc/disassoc events to userspace

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Thu, 2006-03-09 at 15:41 -0500, Dan Williams wrote:

> Can you grab a debug log from wpa_supplicant?  Run wpa_supplicant with
> the args "-ddd", and _don't_ run it as a daemon.  Mail the output to me
> if you don't want it to go to everyone on the cc list (might include
> SSIDs and such).  That should allow us to figure out exactly where
> wpa_supplicant and/or the driver are having issues.

Did this ever happen? I'm currently trying to collect all the pending
patches

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [RFC PATCH] softmac: (v2) send WEXT assoc/disassoc events to userspace

[Hans Fugal]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

With the patch, wpa_supplicant is able to work properly for WEP and
plaintext as tested with my bcm4306 (iBook), and the latest git.

However, and this may not be related, I still must issue an 

    ip link set up eth1

after loading the bcm43xx module but before starting wpa_supplicant or
it will not work. 

-- 
Hans Fugal ; http://hans.fugal.net
 
There's nothing remarkable about it. All one has to do is hit the 
right keys at the right time and the instrument plays itself.
    -- Johann Sebastian Bach

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC PATCH] softmac: (v2) send WEXT assoc/disassoc events to userspace

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Thu, 2006-04-13 at 19:05 -0600, Hans Fugal wrote:
> With the patch, wpa_supplicant is able to work properly for WEP and
> plaintext as tested with my bcm4306 (iBook), and the latest git.

Thanks, great. I have network-manager up and running too now (finally!)

> However, and this may not be related, I still must issue an 
> 
>     ip link set up eth1
> 
> after loading the bcm43xx module but before starting wpa_supplicant or
> it will not work. 

Right, that is expected behaviour right now until we come up with how to
handle this properly.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

softmac: semantics of SIOCSIWFREQ

[Ulrich Kunitz]

Hi,

I'm just reviewing the zd1211 code and I'm wondering about the
semantics of SIOCSIWFREQ and actually, what is good for. It looks
like that softmac's set_channel can be called at any time and will
ignore any settings of SIOCSIWFREQ even it is has been given the
flag IW_FREQ_FIXED. 

Following questions come to mind:

- Is SIOCSIWFREQ allowed while associated?
- If the flag IW_FREQ_FIXED is set, should all activitity
  including scanning only be allowed on this frequency? (Actually
  a better would even be to work with channel/frequency sets.
  These sets would make a lot of sense for parallel scanning
  whith more than one device.)
- Is there any use of the control, if the frequency is not fixed?

SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
included in the softmac. If I would have a rough idea, what the
semantics should be, I would even volunteer to implement it. 

Uli

-- 
Ulrich Kunitz - kune@deine-taler.de