Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #254 (closed defect: worksforme)

Opened 13 years ago

Last modified 12 years ago

iwconfig ath* mode x / iwpriv ath* mode x failure.

Reported by: Assigned to: dyqith
Priority: minor Milestone: version 1.0.0 - first stable release
Component: madwifi: driver Version: trunk
Keywords: mode Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

got 2 atheros devices. both working quite well with _old_ (very) driver.

ath_hal: (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
ath_rate_sample: 1.2
Build date: Nov 10 2005

With the newest -ng- driver i cannot change mode using iwpriv or iwconfig anymore. the first card becomes 11b and the second 11g. chant change anymore.

Change History

12/27/05 14:18:31 changed by mrenzmann

  • description changed.

What revision of madwifi-ng are you using? What error messages do you get back (if any)?

01/06/06 00:13:45 changed by

  • cc set to

I noticed that if the interfaces are not "up", the commands do nothing. So, maybe try doing a "ifconfig ath0 up" then change the mode using "iwpriv ath0 mode 3" for 11g. I'm also not sure if "iwconfig ath0 mode master" will do anything anymore since all the functionality of creating virtual devs are done by the wlanconfig tool.

01/06/06 08:38:25 changed by mrenzmann

You're right about iwconfig ath0 mode master. For now this isn't valid anymore, since the mode is determined once when a VAP is created and can't be changed later. That probably will change in the future, though, we have an open ticket for this idea somewhere...

01/10/06 00:41:00 changed by Stijn Tintel <>

It seems that changing modes (A, B or G) isn't done the same way as with madwifi-old. You can't use the numbers 1, 2 or 3 as an argument to "iwpriv athX mode Y" anymore, instead you have to use "11a", "11b" or "11g", like this:

iwpriv ath0 mode 11g

Imo, this is less confusing then using numbers, so if it's up to me it stays this way - though the wiki needs some updating then.

01/10/06 00:54:53 changed by Stijn Tintel <>

It seems that using numbers as an argument to "iwpriv athX mode Y" does not give an error when the interface is down, but it also does not change the mode. And, using 11* as an argument (as I mentioned above) only works when the interface is up.

01/10/06 06:30:17 changed by mrenzmann

  • priority changed from critical to minor.
  • milestone set to version 1.0.0 - first stable release.

We could allow both, and promote the use of the text strings rather than the plain numbers. Users which know the "old way" (plain numbers) then could still use this if they prefer.

01/11/06 07:33:14 changed by

I looked through the code and tried the numbers and 11a,11b,11g, and they function the same way. i.e. when the interface is down, it doesn't change the modes

Only when the interface is up, then it changes.

01/16/06 01:42:45 changed by

From what I've seen going through the code and experimenting the mode changes don't take effect until a scan is initiated. The changes to mode do remain "pending" however, and will take effect as soon as a scan starts. So for the most part changing the mode while the interface is down will not result in any immediate visible change, but as soon as the interface is brought up (and it starts a scan) it will come up in the last mode specified when it was down.

04/07/06 07:27:49 changed by dyqith

  • patch_attached changed.

I'm wondering what we're going to try to fix with this ticket.

I think we can try to update all the user ioctl's to be more consistent (i.e. issuing a command will update the dev. driver state when the interface is up, and not wait, etc)

What do people think about this ?

04/28/06 05:38:24 changed by dyqith

  • owner set to dyqith.

04/28/06 05:38:33 changed by dyqith

  • status changed from new to assigned.

07/17/07 13:31:44 changed by mtaylor

  • status changed from assigned to closed.
  • resolution set to worksforme.

This ticket has not been updated in over twelve months and is being marked as "works for me" automatically.

If the ticket is still applies to the head revision of trunk, please re-open the ticket and provide any additional details needed and progress on the problem to date. Thanks.