softmac: semantics of SIOCSIWFREQ
Subsystems (2)
[breaking out to a new thread so discussion on this doesn't get too hidden, CC Jean since he designed this]
Quoted 1 line
- Is SIOCSIWFREQ allowed while associated?
No idea.
Quoted 5 lines
- If the flag
IW_FREQ_FIXEDis 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.
Quoted 1 line
- Is there any use of the control, if the frequency is not fixed?
Good question :)
Quoted 3 lines
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
Quoted 8 lines · Johannes Berg
Quoted 5 lines
- If the flag
IW_FREQ_FIXEDis 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.
Quoted 7 lines
Quoted 3 lines
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
Signature · 1 line
Ulrich Kunitz - [email protected]
Quoted 6 lines · Johannes Berg
[breaking out to a new thread so discussion on this doesn't get too hidden, CC Jean since he designed this]
Quoted 1 line
- 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 ;-)
Quoted 8 lines
Quoted 5 lines
- If the flag
IW_FREQ_FIXEDis 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.
Quoted 3 lines
Quoted 1 line
- Is there any use of the control, if the frequency is not fixed?
Good question :)
In managed mode, no.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 1 line
johannes
Jean
Quoted 3 lines · Jean Tourrilhes
Usually no, but...
If you are in managed mode, SIOCSIWFREQ usually should return
an error, because it is not allowed.
Ok.
Quoted 4 lines
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?
Quoted 2 lines
The struct
iw_scan_reqhas 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.
Quoted 3 lines
The
IW_FREQ_FIXEDis 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?
Quoted 2 lines
I don't think any driver/hardware has the ability to set the
frequency to auto, soIW_FREQ_FIXEDis the default.
What would 'auto' be?
Quoted 1 line
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.
Quoted 1 line
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
Quoted 8 lines · Johannes Berg
Quoted 3 lines · Jean Tourrilhes
Usually no, but...
If you are in managed mode, SIOCSIWFREQ usually should return
an error, because it is not allowed.Ok.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
The struct
iw_scan_reqhas 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).
Quoted 5 lines
Quoted 3 lines
The
IW_FREQ_FIXEDis 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.
Quoted 4 lines
Quoted 2 lines
I don't think any driver/hardware has the ability to set the
frequency to auto, soIW_FREQ_FIXEDis 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).
Quoted 5 lines
Quoted 1 line
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.
Quoted 7 lines
Quoted 1 line
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
Quoted 3 lines · Jean Tourrilhes
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 :)
Quoted 4 lines
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
Quoted 8 lines · Johannes Berg
Quoted 3 lines · Jean Tourrilhes
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 :)
Quoted 8 lines
Quoted 4 lines
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.
Quoted 1 line
johannes
Jean
Quoted 5 lines · Jean Tourrilhes
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.
Quoted 2 lines
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