It is awkward that this command is hidden deep inside PrivateFrameworks, but at least it works.
Once you are disconnected from the network, simply type the following (replace 00:11:22:33:44:55 with the MAC address of your choice):

To change the ethernet MAC address, type:
ifconfig en0 lladdr 00:11:22:33:44:55

OR

To change the wifi MAC address, type:
ifconfig en1 lladdr 00:11:22:33:44:55

To confirm that the MAC address has been changed, type ifconfig en0 for ethernet, or ifconfig en1 for wifi.

These steps worked perfectly on a 2009 core 2 duo MacBook Pro running Snow Leopard.

This was a great way to explain something that is deeply complex. Bravo!

Thanks again.

I tried everything listed here and nothing works.

Firstly there are two types of Radio chipsets being manufactured today.
Hardware based and Software based.

This distinction is very important to note as managing the bulk of 802.11 traffic on your machine can be done in either software (depending on your wireless chipset) or hardware (again chipset dependent). When I say software I mean the OSX kernel may be responsible for some of the interface and traffic management and sometimes only in certain situations. Its a very complex issue to explain without launching in to the 802.11 standard in depth. I’ll try to summarize below:

The 802.11 standard is complicated. Very complicated. Just consider for a moment that 802.11 is a layer two protocol that has its own built-in-retransmission and fragmentation support (not even mentioning the optional power-savings mode). Pushing all this complexity down into layer two has created some design issues that have never come up before in commodity networking hardware-namely, where to draw the line between hardware and driver and where to draw the line between driver and OS proper. Where these lines are drawn has very real impact on what you can persuade a chipset to do that it might not otherwise do. (ie: change your mac address or spoof a packet for injection etc)

When your operating system wants to send an Ethernet packet, the kernel forms a simple 14-byte Ethernet header, prepends it to the layer three packet (IP in most cases) and hands it off to the Ethernet hardware to put it on the wire. In the worst case scenario, the Ethernet card causes a collision (or two), backs off randomly, and transmits until it succeeds.

Now what happens when your operating system wants to send out an 802.11 data packet? Well, the kernel might create the 802.11 header itself, pass it off to the card along with the payload, and forget about it. But what happens then? A lot. There are 126 pages of state transition diagrams inside the 1999 revision of the 802.11 standard describing exactly what should happen if you’re curious, but here are a few highlights.

First, the card/driver needs to ensure that the media is not physically busy at the time the sender wishes to transmit. This is the easy part and is called a clear channel assessment in the standard.

Second, the card/driver also is responsible for keeping track of various other state information related to media access control. One example is to make sure that it doesn’t step over another client’s Clear To Send (CTS) window. Once the card has decided it’s okay to transmit, it needs to switch the radio into transmit mode (recall the cards are half-duplex) and send the packet. Immediately after transmission, the card switches back into receive mode. If the card/driver does not receive an acknowledgment (ACK), then it needs to back off and retransmit. There are other factors it must consider as well (Request To Send (RTS) thresholds, fragmentation, and so on) but this should get the point across.

The question remains, however: who is responsible for all that overhead related to media access control, the driver (software) or the chipset (hardware)? If the answer is software, then you might be able to bypass as much of the protocol as you would like and transmit arbitrarily crafted packets (forged deauthentication packets, for example). If the answer is hardware, you are generally at the mercy of the chipset as to what you may or may not transmit(this includes having the ability to do a simple mac address change). If all you want to do is get a card into monitor mode, this may not be such a big deal. As soon as you want to start injecting packets (and many new techniques that take advantage of this are surfacing), it becomes very important. If the chipset itself (hardware) is responsible for generating control or management packets, it might not let you send them yourself.

In summary then. When you tell an Ethernet card to send a packet, you are telling it to send the packet. It’s not going to examine the packet to see if it likes what you are trying to send, and it’s not going to wait around very long to transmit. When you tell a wireless card to transmit, you are suggesting it start transmitting at its soonest possible convenience, assuming it agrees with your payload.
This extends to any form of interface management as well. When you tell your ethernet card to change its mac address you’re merely suggesting it. If it feels like it, depending on what kind of radio chipset is in your macbook pro and who’s responsible for interface management and other low end functionality, you will either be successful at changing your mac address or you won’t. Its down to the type of radio chipset in your macbook pro and the driver/hardware management boundary.

With your wired ethernet card these problems don’t exist. It is managed entirely in software through the osx driver. When you tell it to change its mac address you are ‘TELLING’ it. Its not a suggestion. It must conform. Its a trivial matter to change wired mac address and an entirely different matter altogther on the wifi side.

This explains why you keep getting varying results that make little sense and have no pattern. Its got nothing to do with your version of osx and everything to do with your radio chipset.

I hope that clears it up somewhat.

mysteriös