Bug 12951 (Drew) - Cannot connect with changed MAC on ath5k
Summary: Cannot connect with changed MAC on ath5k
Status: RESOLVED INSUFFICIENT_DATA
Alias: Drew
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: i386 Linux
: P1 normal
Assignee: Bob Copeland
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-27 03:12 UTC by iesousagape
Modified: 2012-10-30 16:44 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.35
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description iesousagape 2009-03-27 03:12:18 UTC
I've tested this on different Linux distros, such as Slackware 12.0, Ubuntu 8.04, and Debian 5.0.0. I am currently working with the stable version of Debian right now (5.0.0., a.k.a. Lenny).

This is what Debian shows as my wireless card: wlan0: Atheros Communications Inc. AR5413 802.11abg NIC (wireless
The brand name is Linksys WPC55AG.

Here is how I got this to work with the old madwifi driver (before ath5k was installed):

# ifconfig -a // There is lo (up), eth0 (down), wifi0 (up), and ath0 (up). wifi0 and ath0 both have the original MAC address //
# ifconfig ath0 down
# ifconfig wifi0 down
# wlanconfig wifi0 destroy
# ifconfig -a // There is lo (up), eth0 (down), and wifi0 (down). wifi0 still has the original MAC address //
# macchanger --mac 9c:0d:cb:e6:dc:7a wifi0
# wlanconfig ath0 create wlandev wifi0 wlanmode managed//
# ifconfig ath0 up
# ifconfig -a // There is lo (up), eth0 (down), wifi0 (up), and ath0 (up). Both wifi0 and ath0 have the NEW MAC address //
# iwconfig ath0 essid essidhere key hexkeyhere
# dhclient ath0 // Successfully connects to the internet //

No other method works, and I get the same problems as I am about to describe.

With the ath5k driver, the command wlanconfig is not available, which I need to destroy and create interfaces. iw does not do the same thing.

I have attempted to change my MAC without the use of wlanconfig WITH THE OLD MADWIFI DRIVER, but every method fails. Basically, I have tried about a dozen or more variations of:

# ifconfig -a // There is lo (up), eth0 (down), wifi0 (up), and ath0 (up). wifi0 and ath0 both have the original MAC address //
# ifconfig ath0 down
# ifconfig wifi0 down
# ifconfig -a // There is lo (up), eth0 (down), wifi0 (down), and ath0 (down). wifi0 and ath0 still has the original MAC address //
# macchanger --mac 9c:0d:cb:e6:dc:7a wifi0
# ifconfig ath0 up
# ifconfig -a // There is lo (up), eth0 (down), wifi0 (up), and ath0 (up). Only wifi0 has the NEW MAC address, ath0 still has the OLD MAC address //
# iwconfig ath0 essid essidhere key hexkeyhere
# dhclient ath0 // Cannot connect, No DHCPOFFERS received, No working leases in persistent database - sleeping, etc. //

and

# ifconfig -a // There is lo (up), eth0 (down), wifi0 (up), and ath0 (up). wifi0 and ath0 both have the original MAC address //
# ifconfig ath0 down
# ifconfig wifi0 down
# ifconfig -a // There is lo (up), eth0 (down), wifi0 (down), and ath0 (down). wifi0 and ath0 still has the original MAC address //
# macchanger --mac 9c:0d:cb:e6:dc:7a wifi0
# macchanger --mac 9c:0d:cb:e6:dc:7a ath0
# ifconfig ath0 up
# ifconfig -a // There is lo (up), eth0 (down), wifi0 (up), and ath0 (up). Both wifi0 and ath0 have the NEW MAC address //
# iwconfig ath0 essid essidhere key hexkeyhere
# dhclient ath0 // Cannot connect, No DHCPOFFERS received, No working leases in persistent database - sleeping, etc. //

So the MAC addresses can successfully change and be applied to the interfaces, but when the dhclient comes, it will not connect me to my router. At this point, I must either reload the driver modules, or take out my wireless card and plug it back in to reset it back to its original state with the original MAC address, and I can do dhclient again to connect to my router smoothly. If I try to change the MAC address to the original MAC, dhclient still will not connect. I have to reset the card.

Now for the ath5k driver.

ath5k has wlan0 and wmaster0, but I'm pretty sure that wmaster0 doesn't do anything after doing a little bit of research. Another reason why I'm inclined to believe wmaster0 does not actually mean it's a "master" of anything is, because if I run, for example, airmon-ng, with the madwifi driver, it shows wifi0 as the parent interface, and ath0 beneath it. If I run airmon-ng on ath5k, it only shows wlan0 and NOT wmaster0.

So, since there is no wlanconfig with ath5k, I have to utilize only ifconfig/iwconfig/macchanger. Basically all I can do is experiment with the failed attempt methods above, except switch both "wifi0" and "ath0" with "wlan0" because ath5k doesn't seem to use a "parent" interface.

So basically this would be one of my attempts (out of the many I've tried with different combinations) for example:

# ifconfig -a // There is lo (up), eth0 (down), wmaster0 (up), and wlan0 (up). wmaster0 and wlan0 both have the original MAC address //
# ifconfig wlan0 down
# ifconfig -a // There is lo (up), eth0 (down), wmaster0 (down), and wlan0 (down). wmaster0 and wlan0 still has the original MAC address //
# macchanger --mac 9c:0d:cb:e6:dc:7a wmaster0
# macchanger --mac 9c:0d:cb:e6:dc:7a wlan0
# ifconfig wlan0 up
# ifconfig -a // There is lo (up), eth0 (down), wmaster0 (up), and wlan0 (up). Both wmaster0 and wlan0 have the NEW MAC address //
# iwconfig wlan0 essid essidhere key hexkeyhere
# dhclient wlan0 // Cannot connect, No DHCPOFFERS received, No working leases in persistent database - sleeping, etc. //

In some tries I did not use wmaster0 at all, and sometimes I used both, and even just for the sake of trying, tried only wmaster0 and not wlan0. Trust me, I've done every possible combination over the past week and I'm pretty sure I haven't missed something. So I doubt that these commands will succeed.

I need something equivalent to old madwifi's "wlanconfig" command for ath5k.

Is there something for this?
Comment 1 Bob Copeland 2009-03-27 15:17:58 UTC
You do not need wlanconfig - I have done this in the past and it works, but I do not recall offhand the sequence of commands.  Will get back to you.
Comment 2 Bob Copeland 2009-04-05 15:30:25 UTC
This sequence works here.  With NM running, there are issues reconnecting -- I believe this is some sort of rekeying issue, but I haven't tracket it down.  Anyway, changing the mac itself doesn't have problems.

[root@sludge ~]# killall NetworkManager
[root@sludge ~]# ifconfig wlan0 down
[root@sludge ~]# macchanger -A wlan0
Current MAC: 00:60:96:a6:25:0c (T.s. Microtech Inc.)
Faked MAC:   00:0e:49:e5:db:17 (Forsway Scandinavia Ab)
[root@sludge ~]# ifconfig wlan0 up
[root@sludge ~]# /etc/init.d/NetworkManager start  # associates here
[root@sludge ~]# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 00:0E:49:E5:DB:17  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12991 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13908 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6243568 (5.9 MiB)  TX bytes:2280531 (2.1 MiB)

So back to your problem.  Your network is just using WEP?  I assume it works before you do anything, then after 'ifconfig wlan0 down; macchanger; ifconfig wlan0 up' sequence it does not work, correct?  Is there any information about the association process in dmesg?
Comment 3 iesousagape 2009-04-05 19:05:56 UTC
I turned off wireless protection temporarily so I don't have to enter the key every single time I do iwconfig.

No, everything works after ifconfig wlan0 down; macchanger; ifconfig wlan0 up'. It does not work only after 'dhclient wlan0'.

Anyway, I have decided to switch back to the old Madwifi for the meanwhile. With ath5k, not only do I have this issue, but I have over 50% packet loss and frequent disconnects (once every few minutes, and I have to re-associate again). The speed is also incredibly slow.

With Madwifi, the speeds are fast again, I have no disconnected once in over 2 days now, and it's very consistent. I have no idea why Madwifi is becoming obsolete and ath5k replacing it when clearly the Madwifi seems better (at least from the results)...
Comment 4 Bob Copeland 2009-04-06 12:14:14 UTC
Ok, well using wpa_supplicant (or network manager) would keep you from having to enter the key with iwconfig.  IIRC, there might also be a difference in that madwifi implicitly begins a scan at interface up time, which mac80211 drivers do not do.  wpa_supplicant thus might fix the dhclient as well.

I can use 54 mbit/s rate with ath5k now (effective throughput of ~ 18mbit/s), it may be worth trying compat-wireless to have the latest updates to the ath5k phy.  But feel free to use whichever you prefer.
Comment 5 Bob Copeland 2009-08-16 14:22:22 UTC
Marking this NEEDINFO now -- please try in latest kernel with process from Comment #2 to confirm whether it works.
Comment 6 pourrite 2009-10-07 20:19:37 UTC
I have exactly the same problem with changing MAC address under ath5k driver. 
I have tried what Bob recommand in his comment #2 but I still cannot connect to the AP.
Still looking for a solution... Any ideas ?
Comment 7 pourrite 2009-10-07 20:21:31 UTC
In addition, I can't manage to use madwifi driver.
Comment 8 iesousagape 2009-10-07 20:30:29 UTC
I've decided to wait a little while until the developers work on this driver a bit more. Until then, I've put my current atheros wireless card aside and am using one with a ral chipset.

pourrite@gmail.com, I was able to replace ath5k with madwifi on a clean Debian install, so I'm sure with any Debian-based distro it's possible. It's also probably feasible on other distros with a recent Linux kernel
Comment 9 Bob Copeland 2009-10-10 18:12:45 UTC
(In reply to comment #6)
> I have exactly the same problem with changing MAC address under ath5k driver. 
> I have tried what Bob recommand in his comment #2 but I still cannot connect
> to
> the AP.
> Still looking for a solution... Any ideas ?

What is in dmesg when you attempt to connect?
Comment 10 Bob Copeland 2009-10-10 18:13:35 UTC
WRT above, try with CONFIG_MAC80211_VERBOSE_DEBUG enabled.
Comment 11 Diego 2011-07-07 02:21:21 UTC
(In reply to comment #5)
> Marking this NEEDINFO now -- please try in latest kernel with process from
> Comment #2 to confirm whether it works.

I had exactly the same problem with ath5k (chip ar2425) in Ubuntu 10.10 with kernel 2.6.35-22-generic
I have tried the same steps with same result. After getting properly a fake MAC address, it is unable to connect to AP. I have to go back to the original MAC in order to connect.
Comment 12 Alan 2012-08-29 17:14:24 UTC
Is this still seen with modern kernels ?

Note You need to log in before you can comment on or make changes to this bug.