You can find many people asking how to get their laptop/desktop to use 802.11n when for some reason it insists on still using 802.11g with a wifi access point that supports 802.11n.

I.e. they want to use a faster variant of 802.11 than their machine is currently using.

I want to do the opposite - I have an AP using mixed mode and all my clients currently connect using the fastest variant, i.e. 802.11n - but now I want to force some of them to use a slower variant.

I want to do this on a per client basis rather than forcing the AP to stop supporting n for all clients.

My impression is that this is not easily doable on any of the client platforms that are relevant to me (Mac, Windows and Linux) so hence this question.

Why do I want to do this? I have odd embedded devices that operate in monitor mode and look out for UDP traffic between clients and AP (i.e. the clients do not communicate directly with the devices via the AP) and the devices only supports b and g.

So clients that need to interact with these devices need to be connected to the AP using one of the variants the devices understand, i.e. b or g.

This odd setup means that clients don't have to be configured to know the addresses of the embedded devices (obviously the embedded devices would need to be configured to to know the AP's passphrase if security is being used and if they wanted to decrypt the traffic). Note: the AP actually ignores the UDP packets altogether - their sole purpose is to transmit information that the embedded devices can see.

If the UDP packets were sent to the embedded devices then there would be no problem. The UDP traffic would go from my clients to the AP via 802.11n and would then be retransmitted by the AP to the devices using 802.11g. So what we gain in not needing know the addresses of the devices we lose in flexibility in regard to using any variant of 802.11 that the AP supports.

One could argue that the devices could have achieved the same thing using e.g. information encoded in wifi probes that would avoid this issue but I have to live with the current situation.

Thanks - and apologies for asking a question that covers multiple OSes, I appreciate that people may only be able to answer for a given OS they know well.

  • Such configuration normally exists in the router/AP dashboard or that of the wireless adapter, and not even found in every one. Frankly, your question is much too general.
    – harrymc
    Sep 29, 2013 at 18:11

3 Answers 3


The simple approach to getting what you appear to want is another access point. Let one do n and the other do b/g, or let one do b/g/n and the other only do b/g - and connect the "specific devices you need to have communicate this way" to the b/g (only) one.

While you appear to be seeking an answer involving subtle system tweaks on client computers, in practice the price of another access point is going to be far less than the time&hassle to try and do that - and I'm not all that sure it's even possible in the direction you are trying to do it from (ie, what the access point offers is variable - while the OSs I know well don't appear to have any straightforward options to downgrade their access other than downgrading them to hardware that can only do b/g) - which might be another approach, but will still cost you more, I think. That is, you could disable the internal wireless and plug in a USB b/g only device.

In some specific cases you might be able to replace the driver for a built-in b/g/n with a non-n driver that supports b/g on the hardware, but I doubt that's remotely seamless and/or reliable in a general sense, and I don't even have an example of that - it's just a thought that comes to mind.

  • While I'm not the manufacturer of the device in question I am concerned with how they can be deployed on 3rd party networks, not just ones under my own control. So asking every 3rd party that uses these devices to buy/configure/manage a second AP looks like a less than optimal solution (though it's beginning to look like the only solution). When I first started looking into this I assumed choosing the 802.11 protocol version would probably be possible via some control panel option, or at least configurable via the command line. But that assumption isn't holding up :( Sep 30, 2013 at 21:42
  • I make no apology for cutting to the art of the possible - it's a solution that will work, and I'm pretty sure there isn't the sort of solution you are seeking. Buying used access points, it's a pretty cheap solution these days. If you are involved as a reseller of "whatever these things are" you could bundle a b/g access point with the whatever. Of course, the manufacturer could also get up to 2009 standards, which they obviously have not done for the last 4 years. And that was just the date of the "final" standard - "draft n" devices were out for quite some time before that.
    – Ecnerwal
    Oct 3, 2013 at 2:15
  • @GeorgeHawkins: +1 The 2 APs idea is the only possible solution that will solve it for every existing computer/adapter combination. Be happy that you got one feasible solution for your impossible demand.
    – harrymc
    Oct 3, 2013 at 20:04
  • @Ecnerwal - 802.11n support wouldn't be enough in itself - for one reason MIMO. Normally an AP tailors transmissions to the capabilities of the receiving device, however this kind of monitor mode spying requires the spy to have at least as many MIMO capable antennas as the AP - unlikely for a small embedded device. The idea behind this device probably sounded good once but just can't scale well to 11n. Oct 8, 2013 at 8:48

Linux absolutely does support this, in two different ways. For certain cards 802.11n can be specifcally disabled -- the module has an option "11n_disable" for mine. You can also use iwconfig to force a bit rate -- force any b or g compatible speed and it's running b or g, for example "iwconfig wlan0 rate 11" forces 11mbps operation.

The third method, if these packets are not actually going anywhere and just the content is sniffed, can you use a broadcast or multicast address? To make sure all devices on the network can detect the broadcast and multicast packets, these packets are treated seperately and transmitted at "basic rates". 802.11, 802.11b, and 802.11g devices these "basic rates" are usually 1 and 2mbps. Newer 802.11g and 802.11n devices the "basic rates" are usually 1, 2, 5.5, and 11mbps. So, this traffic would then always be visible to these 802.11g devices. Regular traffic still runs at the best speed the card, AP, and radio conditions support.

  • Thanks @user153822 - I'll look into this on my Linux box. Do you have a reference for broadcast and multicast packets being transmitted at "basic rates"? My impression is that in infrastructure mode everything goes via the AP. It seems obvious the AP would need to retransmit broadcast packets in a universally understandable fashion but shouldn't need to for multicast (where it knows who, if anyone, is listening). The sending approach must work for, among other things, iOS which only exposes a high level n/w interface without exposing access to clearly mode independent things like probes. Sep 10, 2014 at 13:24
  • 11n_disable is specific to the Intel wifi module iwlwifi. As a note to others you can determine your wifi module name with basename $(readlink /sys/class/net/wlan0/device/driver) and then list the options for that module name with modinfo <name>. Other wifi modules don't have such a simple way to disable n and none seem to support simply selecting one or more specific modes, e.g. just g and n but not a. See also unix.stackexchange.com/q/7817 Sep 10, 2014 at 13:49

In Windows, if this is possible for both your wireless adapter and the driver installed, it would likely be accessible within Device Manager. Expand the Network Adapters section and right click on the wireless adapter, then click properties. Under the advanced tab, you should see something like this (my example is a wired Ethernet adapter). Look at every property and see if you can change the radio type there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .