Ticket #173 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

when changing mac of dwl-g520, interface no longer receives packets

Reported by: BlackestOfBlack Assigned to:
Priority: minor Milestone: version 1.0.0 - first stable release
Component: madwifi: driver Version: trunk
Keywords: mac address change trunk Cc: wish@sb.net
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

This is weird and did not occur with previous versions of madwifi I was using (20050707). I currently have the cvs 20051123. An example goes like this: 

wlanconfig ath1 create wlandev wifi0 wlanmode sta
iwconfig ath1 key 999999999 (actual key here)
iwconfig ath1 ap FF:FF:FF:FF:FF:FF (actual AP mac here)
iwconfig ath1 channel 6
iwconfig ath1 essid ESSID (actual AP ESSID here)
iwconfig ath1 rate auto
ifconfig ath1 192.168.1.50 up

ping 192.168.1.254 (results okay)

ifconfig ath1 down
ifconfig ath1 hw ether 44:44:44:44:44:44 (different address)
ifconfig ath1 up

ping 192.168.1.254 (does not receive reply)

ifconfig ath1 down
ifconfig ath1 hw ethere FF:FF:FF:FF:FF:FF (original card mac here)
ifconfig ath1 up

ping 192.168.1.254 (results okay)

I have tried this with a bunch of APs that do not use mac filtering. No problem before.

Any ideas or is this known or broken?

BlackestOfBlack?

Attachments

athmac.log.gz (6.1 kB) - added by ivor on 02/06/06 13:01:55.
athdebug log

Change History

11/24/05 10:49:30 changed by mrenzmann

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

12/30/05 21:50:50 changed by anonymous

I get the same results but I'd try disconnecting from the ap first and reconnecting after setting the new mac address. then try setting the ip and pinging. This is what I tried and it still fails. I think this may be why my bridging is failing as well.

I'm using snapshot madwifi-ng-r1370-20051230 a D-Link DWL-AG660 with the AR5212 Atheros chipset on FC4 with kernel 2.6.14-1.1653_FC4

12/30/05 21:53:18 changed by jeff_sadowski@yahoo.com

could this be related to the hal? I also posted the last report

12/31/05 08:34:24 changed by jeff_sadowski@yahoo.com

I think I found the answer I was looking through the docs and this seams to have worked for me "iwpriv ath0 authmode 0"

01/03/06 12:31:36 changed by svens

  • status changed from new to assigned.
  • owner set to svens.

01/03/06 15:30:03 changed by mrenzmann

While digging through the ticket notifications that came through during the last days, it happened that I was looking at #271 right before I came to this one. The problem described there eventually also applies to this issue. I asked svens to check that.

01/04/06 01:49:34 changed by jeff_sadowski@yahoo.com

"iwpriv ath0 authmode 0" was just one of the fluke workings that I get now and then. interesting how sometimes it works and sometimes it doesn't. I still cannot send packets with a different mac address.

01/09/06 06:09:09 changed by jeff_sadowski@yahoo.com

I've been thinking would this be related to creating an ap with a different mac? can people that create an ap with a different mac communicate with devices that try to connect to them?

01/12/06 00:40:36 changed by jeff_sadowski@yahoo.com

I think part of the problem might be that the wifi0 device has a non standard mac address and the link encap is UNSPEC and that when you change the hw address on ath0 it doesn't change it on wifi0.

02/06/06 13:01:55 changed by ivor

  • attachment athmac.log.gz added.

athdebug log

02/06/06 13:09:24 changed by ivor

  • patch_attached changed.

Not sure if this is the same issue as this or the same as the now clsoed bug 323, but with the latest driver I'm unable to associate with a particular AP after changing MAC address, although this used to work with the old non -ng driver. Athdebug log of association attempt attached.

02/07/06 17:49:58 changed by ivor

ignore that, got it working! :)

03/05/06 19:19:05 changed by jeff_sadowski@yahoo.com

Ok now when I change the mac address of wifi0 then recreate the station device node it connects with that new mac address. This will allow for connecting with any mac address you desire. I'm not sure why it doesn't work with just changing the mac of the station device node. I have some more experimenting to do.

So here is how you would do what I guess you want to do BlackestOfBlack?

wlanconfig ath1 create wlandev wifi0 wlanmode sta iwconfig ath1 key 999999999 (actual key here) iwconfig ath1 ap FF:FF:FF:FF:FF:FF (actual AP mac here) iwconfig ath1 channel 6 iwconfig ath1 essid ESSID (actual AP ESSID here) iwconfig ath1 rate auto ifconfig ath1 192.168.1.50 up

ping 192.168.1.254 (results okay)

wlanconfig ath1 destroy ifconfig wifi0 hw ether 44:44:44:44:44:44 (different address) wlanconfig ath1 create wlandev wifi0 wlanmode sta iwconfig ath1 key 999999999 (actual key here) iwconfig ath1 ap FF:FF:FF:FF:FF:FF (actual AP mac here) iwconfig ath1 channel 6 iwconfig ath1 essid ESSID (actual AP ESSID here) iwconfig ath1 rate auto ifconfig ath1 192.168.1.50 up

ping 192.168.1.254 (results okay)

and I think that resolves this issue mostly.

03/05/06 19:23:35 changed by anonymous

Redid because of formating issues Ok now when I change the mac address of wifi0 then recreate the station device node it connects with that new mac address. This will allow for connecting with any mac address you desire. I'm not sure why it doesn't work with just changing the mac of the station device node. I have some more experimenting to do.

So here is how you would do what I guess you want to do BlackestOfBlack??

<pre> wlanconfig ath1 create wlandev wifi0 wlanmode sta iwconfig ath1 key 999999999 (actual key here) iwconfig ath1 ap FF:FF:FF:FF:FF:FF (actual AP mac here) iwconfig ath1 channel 6 iwconfig ath1 essid ESSID (actual AP ESSID here) iwconfig ath1 rate auto ifconfig ath1 192.168.1.50 up

ping 192.168.1.254 (results okay) wlanconfig ath1 destroy ifconfig wifi0 hw ether 44:44:44:44:44:44 (different address) wlanconfig ath1 create wlandev wifi0 wlanmode sta iwconfig ath1 key 999999999 (actual key here) iwconfig ath1 ap FF:FF:FF:FF:FF:FF (actual AP mac here) iwconfig ath1 channel 6 iwconfig ath1 essid ESSID (actual AP ESSID here) iwconfig ath1 rate auto ifconfig ath1 192.168.1.50 up </pre> ping 192.168.1.254 (results okay) and I think that resolves this issue mostly.

03/05/06 19:25:01 changed by anonymous

test [code] format test /code

03/05/06 19:30:48 changed by anonymous

Last try with formating

Ok now when I change the mac address of wifi0 then recreate the station device node it connects with that new mac address. This will allow for connecting with any mac address you desire. I'm not sure why it doesn't work with just changing the mac of the station device node. I have some more experimenting to do.

So here is how you would do what I guess you want to do BlackestOfBlack?


wlanconfig ath1 create wlandev wifi0 wlanmode sta
iwconfig ath1 key 999999999 (actual key here)
iwconfig ath1 essid ESSID (actual AP ESSID here)
ifconfig ath1 192.168.1.50 up

ping 192.168.1.254 (results okay)

wlanconfig ath1 destroy
ifconfig wifi0 hw ether 44:44:44:44:44:44 (different address)
wlanconfig ath1 create wlandev wifi0 wlanmode sta
iwconfig ath1 essid ESSID (actual AP ESSID here)
ifconfig ath1 192.168.1.50 up

ping 192.168.1.254 (results okay)

and I think that resolves this issue mostly.

10/15/06 21:44:47 changed by mrenzmann

  • status changed from assigned to new.
  • owner deleted.

Changing assignment. Anyone up to look at this issue?

02/25/07 07:24:50 changed by entity

I'm getting this bug too, however, the workaround for this does not work for me. I use: wlanconfig ath0 destroy ifconfig wifi0 hw ether 44:44:44:44:44:44 (different address) SIOCSIFHWADDR: Invalid argument

I'm also using a d-link dwl-g520.

02/26/07 02:51:00 changed by mentor

  • patch_attached set to 1.

This issue may have been fixed in r2156. Please test.

02/26/07 02:51:30 changed by mentor

  • patch_attached deleted.

02/26/07 08:42:10 changed by entity

After updating to svn r2156, I am able to change the mac address of wifi0 with the macchanger program, and afterwards recreate the ath0 interface.
Doing "ifconfig wifi0 hw ether 00:01:02:03:04:05" does not work and gives "SIOCSIFHWADDR: Invalid argument".
macchanger on wifi0 works but, for some reason doing:

wlanconfig ath0 destroy
macchanger -r wifi0
wlanconfig ath0 create wlandev wifi0 wlanmode sta

...Returns the string "ath0", but looking in ifconfig -a shows that it actually created ath1 instead of ath0. Everything works other than that though, I am able to associate fine using wpasupplicant and get an ip over dhcp afterwards using ath1 instead of ath0.

wpa_supplicant -Bw -qq -Dmadwifi -iath1 -c/etc/wpa_supplicant.conf
dhclient3 ath1


Another strange thing is when using macchanger to manually set a predefined (not random) mac for wifi0, it gives an error (spelling included):

macchanger -m=00:01:02:03:04:05 wifi0
Current MAC: 44:44:44:44:44:44 (unknown)
ERROR: Incorrect format: MAC lenght is 17. =00:01:02:03:04:05(18)

Otherwise working, but strange behavior, and am unable to set mac to a non-random value.

02/27/07 05:33:36 changed by mentor

  • status changed from new to closed.
  • resolution set to fixed.

That response from ifconfig is expected, as wifi0 does not implement a standard ethernet HW type.

The wrong response from wlanconfig is odd; but there have been some patches to this code recently to correct such situations. I shall look at that problem again.

For macchanger you need to use the format: 

-m MA:CA:DD:RE:SS:00
or
--mac=MA:CA:DD:RE:SS:00

I believe this bug to be fixed now, and will mark the ticket suitably. Post agian if you have additional problems.

02/27/07 15:02:33 changed by anonymous

One possible reason 'ath1' is created after changing the MAC address is because of udev persistent interface naming. Look in /etc/udev/rules.d.

In addition to using 'macchanger' to set the MAC address the 'ip' command also works:

'ip link set wifi0 address xx:xx:xx:xx:xx:xx'.

03/04/07 02:34:32 changed by entity

Thanks for mentioning udev, I wouldn't have known that it was responsible for ath1 being created. I've found the rule that causes it I believe in /etc/udev/rules.d/25-iftab.rules . 

# This file causes network devices to be assigned consistent names.
# See udev(8) for syntax.

SUBSYSTEM=="net", ACTION=="add", DRIVER=="?*", \
                                PROGRAM="iftab_helper %k", NAME="$result"


I can see that in my /etc/iftab, ath0 is tied to it's default mac address with an entry like: 

ath0 mac DE:FA:UL:TM:AC:00 arp 1

I can see in udevmonitor that when I run the command with ath0 having the default mac address, ath0 is created, but with a different mac, a device ath0 is detected but udev creates ath1 instead.

03/09/07 00:45:26 changed by Menoz

Somebody nows how to modify /etc/udev/rules.d/25-iftab.rules or /etc/iftab in order to create ath0 (and not ath*) with any random mac address?

(follow-up: ↓ 26 ) 04/29/08 12:22:56 changed by Dark EGI

Yee-hee! now I know :) It is so because udev already have a record ath0 with your original MAC.

I succeed by hands: Debian 4.0 r2. cd /etc/udev/rules.d/ there is a z25_persistent_net.rules file kill lines with unneeded athX interface names.

udev makes a record ath0 with your real mac.

And to be able to use ath0 - you can prevent madfiwi driver of interface autocreating. echo "options ath_pci autocreate=none" > /etc/modprobe.d/madwifi

(in reply to: ↑ 25 ) 04/29/08 15:10:17 changed by BlackestOfBlack

This system does seem to work, an issue this old is solved. Thank you for all of the work.

BlackestOfBlack?