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 #323 (closed defect: duplicate)

Opened 14 years ago

Last modified 13 years ago

[patch] fix, change mac address of the vap

Reported by: jirif Assigned to: mrenzmann
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: 802.11 stack Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

This patch fixing(adding) changing mac address of the vap, as is described here:

http://madwifi.org/wiki/UserDocs/ChangeMacAddress

BTW: the patch alow to change the mac address when the vap is in running state.

Signed-off-by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>

Attachments

changemac2.diff (390 bytes) - added by jirif on 01/19/06 14:32:19.
This is correct patch

Change History

01/19/06 12:22:42 changed by jirif

It should fix ticket:173

01/19/06 12:28:29 changed by jirif

BTW2: to get it work correctly you must have installed patch from ticket:312

01/19/06 12:51:22 changed by jirif

BTW3: it working in 80211 layer, but not with hardware. The hardware wont accept packets with another BSS.

So iam sorry for confusion, please close this ticket.

Jiri

01/19/06 14:32:19 changed by jirif

  • attachment changemac2.diff added.

This is correct patch

01/19/06 14:42:01 changed by jirif

I have found the correct solution:

http://madwifi.org/attachment/ticket/323/changemac2.diff

The mac address can be changed only at the master device, because the hardware do not support multiple bss. But in current code is problem that breaking posiblity change the mac address. The problem is than ifconfig hw not supporting ARPHRD_IEEE80211 device class. The way should be update ifconfig userspace tools or simply remove line from the driver setting the master device in to ARPHRD_IEEE80211 class. Using the master device as ARPHRD_ETHER class device should not have any beside effects. If this patch will be accepted, http://madwifi.org/wiki/UserDocs/ChangeMacAddress document should be updated with corrected informations.

Signed-off-by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>

01/22/06 10:14:27 changed by mrenzmann

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

Are both patches needed to get this fixed, or is just the second one needed?

01/23/06 11:09:32 changed by jirif

changemac.diff is incorrect (forget it), the correct one is second changemac2.diff, with included comment. original ticket comment is wrong too.

Iam sorry for confusion.

Jiri

01/27/06 13:09:54 changed by kelmo

Hmm, used this patch, and after faking the mac of a sta, it can no longer acquire its dhcp lease like usual. If i revert the mac change, everything is fine again.

01/30/06 12:34:14 changed by ivor

Just to add another datapoint, the patch doesn't work for me either. With madwifi-ng I can't associate with an AP that I need to have a spoofed MAC address. With the patch I can change the vap mac address sucessfully, but associations still fail. I can't check what MAC is being 'seen' by an AP until tonight, what information can I get to help debug this?

02/01/06 06:42:43 changed by kelmo

  • patch_attached set to 1.

02/01/06 09:48:58 changed by jirif

Again:

changemac.diff is incorrect (forget it), the correct one is second changemac2.diff, with included comment. original ticket comment is wrong too.

1./ vap mac address cannot be changed (read my comments)

2./ The mac address can be changed only at the master device (read my comment for changemac2.diff) before creating the vap

I have testet: ap mode, sta mode , wdsmode and all working fine (Wistron CM9)

Jiri

02/01/06 10:02:22 changed by mrenzmann

I removed changemac.diff now to avoid confusion. Thanks again for clarification, patch is about to be committed soon.

02/01/06 11:13:22 changed by kelmo

#173 may be related

02/02/06 02:18:37 changed by ivor

Jiri, Yes I did read your comment.:) perhaps I misunderstood the terms. Correct I did not apply changemac.diff, but changemac2.diff and the patch from 312. I changed the mac address of the wifi0 device (I thought that was the vap or have I got the terms backwards?) I'll retest against the AP tomorrow and report back. Thanks,

02/03/06 12:52:11 changed by mrenzmann

Thanks, Jiri. Patch committed in r1435.

Can someone please take care of adjusting UserDocs/ChangeMacAddress?

02/04/06 12:09:45 changed by jirif

Adjusted, with few corrections for macchanger:

http://madwifi.org/wiki/UserDocs/ChangeMacAddress?version=6

Jiri

02/04/06 20:08:54 changed by mrenzmann

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

Thanks Jiri.

04/06/06 20:16:32 changed by jirif

  • status changed from closed to reopened.
  • resolution deleted.

LOL changeset 1497 reverting this patch an the mac change feature became unavailable again !

04/07/06 01:56:27 changed by kelmo

Hmm, this was indeed overlooked when discussing the commit of r1497. Is identifying the placeholder devices as ARPHRD_ETHER really the correct way to allow mac changing?

04/07/06 04:25:17 changed by eaton.lists@gmail.com

Just pulled down fresh source, now I'm seeing this error from dhclient:

wifi0: unknown hardware address type 801
wifi0: unknown hardware address type 801

Not a big problem, since I can still get an IP. But I think this is another side-effect of r1497.

04/18/06 12:43:46 changed by kelmo

This really should be done at the VAP level if possible, making the parent device appear as an ETHER capable interface is misleading. AFAIK, hostap has the ability to change the mac of interfaces without making the parent device appear as something which it is not.

04/20/06 14:43:34 changed by kelmo

  • milestone changed from version 0.9.0 - move to new codebase to version 0.9.x - progressive release candidate phase.

06/26/06 14:09:54 changed by christian_perone@yahoo.com.br

The patch is in the current snapshot or not ????????

06/26/06 14:16:54 changed by mrenzmann

As stated in the comments above, r1497 reverted the patch and a final solution has not yet been found. That's the reason why the release notes mentions this ticket in the "known issues" section and state that changing the MAC address is not properly working at this time.

06/26/06 14:24:54 changed by christian_perone@yahoo.com.br

Sorry for buggin, I have been look at source and still remains.

07/25/06 18:30:53 changed by anonymous

This is a reconstruction:

# modprobe ath_pci autocreate=none # ifconfig wifi0 down # macchanger --mac=00:11:22:33:44:55 wifi0

This is what I am running:

linux-2.6.11.4 (non preemptive configuration) madwifi version (svn r1692) GNU MAC changer 1.5.0

The resulting oops with trace:

CPU: 0 EIP: 0060:[<d0a74efe>] Tainted: P VLI EFLAGS: 00010296 (2.6.11.4) EIP is at zz0b69b07c+0x5e/0xa8 [ath_hal] eax: 00000000 ebx: c4cc0000 ecx: c5c93e02 edx: 00000000 esi: 00000000 edi: c4cc0000 ebp: c4cc0000 esp: c5c93df0 ds: 007b es: 007b ss: 0068 Process macchanger (pid: 21602, threadinfo=c5c92000 task=c6180020) Stack: c4cc0000 c4cc0000 d0a758e9 c4cc0000 00000000 c4cc0000 00000000 c4cc0000

d0a7084c c4cc0000 c4cc02c8 00000001 c010255a c4cc0000 00000000 00000000 c4cc0000 c6f8e220 c6f8e000 00000000 0000007b 0000007b ffffff00 00000000

Call Trace:

[<d0a758e9>] zz0016d872+0x15/0x1ac [ath_hal] [<d0a7084c>] zz0002dbd2+0xf4/0xd30 [ath_hal] [<c010255a>] common_interrupt+0x1a/0x20 [<d0a4773f>] ath_reset+0x5f/0x1c0 [ath_pci] [<d0a511f3>] ath_set_mac_address+0x73/0x100 [ath_pci] [<c020bfb9>] dev_ifsioc+0xd9/0x360 [<c020c440>] dev_ioctl+0x200/0x280 [<c0241ea7>] inet_ioctl+0x67/0x80 [<c0202a23>] sock_ioctl+0xa3/0x220 [<c014ff45>] do_ioctl+0x45/0x60 [<c01500f5>] vfs_ioctl+0x55/0x1a0 [<c015026b>] sys_ioctl+0x2b/0x60 [<c0102337>] syscall_call+0x7/0xb

Code: 00 00 00 00 00 00 83 c4 18 5b c3 89 f6 56 53 8b 74 24 10 8b 5c 24 0c ba 00 00 00 00 90 8d 04 92 8d 04 42 66 8b 84 c3 34 2a 00 00 <66> 3b 06 75 05 89 d0 +eb 3c 90 8d 04 92 8d 04 42 8d 8c c3 30 2a

07/25/06 18:34:01 changed by anonymous

This is a reconstruction:

        # modprobe ath_pci autocreate=none
        # ifconfig wifi0 down
        # macchanger --mac=00:11:22:33:44:55 wifi0

This is what I am running:

        linux-2.6.11.4  (non preemptive configuration)
        madwifi version (svn r1692)
        GNU MAC changer 1.5.0

The resulting oops with trace:

CPU:    0
EIP:    0060:[<d0a74efe>]    Tainted: P      VLI
EFLAGS: 00010296   (2.6.11.4)
EIP is at zz0b69b07c+0x5e/0xa8 [ath_hal]
eax: 00000000   ebx: c4cc0000   ecx: c5c93e02   edx: 00000000
esi: 00000000   edi: c4cc0000   ebp: c4cc0000   esp: c5c93df0
ds: 007b   es: 007b   ss: 0068
Process macchanger (pid: 21602, threadinfo=c5c92000 task=c6180020)
Stack: c4cc0000 c4cc0000 d0a758e9 c4cc0000 00000000 c4cc0000 00000000 c4cc0000
       d0a7084c c4cc0000 c4cc02c8 00000001 c010255a c4cc0000 00000000 00000000
       c4cc0000 c6f8e220 c6f8e000 00000000 0000007b 0000007b ffffff00 00000000
Call Trace:
 [<d0a758e9>] zz0016d872+0x15/0x1ac [ath_hal]
 [<d0a7084c>] zz0002dbd2+0xf4/0xd30 [ath_hal]
 [<c010255a>] common_interrupt+0x1a/0x20
 [<d0a4773f>] ath_reset+0x5f/0x1c0 [ath_pci]
 [<d0a511f3>] ath_set_mac_address+0x73/0x100 [ath_pci]
 [<c020bfb9>] dev_ifsioc+0xd9/0x360
 [<c020c440>] dev_ioctl+0x200/0x280
 [<c0241ea7>] inet_ioctl+0x67/0x80
 [<c0202a23>] sock_ioctl+0xa3/0x220
 [<c014ff45>] do_ioctl+0x45/0x60
 [<c01500f5>] vfs_ioctl+0x55/0x1a0
 [<c015026b>] sys_ioctl+0x2b/0x60
 [<c0102337>] syscall_call+0x7/0xb
Code: 00 00 00 00 00 00 83 c4 18 5b c3 89 f6 56 53 8b 74 24 10 8b 5c 24 0c ba 00 00 00 00 90 8d 04 92 8d 04 42 66 8b 84 c3 34 2a 00 00 <66> 3b 06 75 05 89 d0
+eb 3c 90 8d 04 92 8d 04 42 8d 8c c3 30 2a

07/26/06 13:09:42 changed by anonymous

See related ticket: Ticket #716 (defect)?

08/01/06 15:46:59 changed by jirif

I reverted r1497 and get oops too. BUT when i using this sequence (without r1497) to change the MAC:

        ifconfig wifi0 up
        ifconfig wifi0 down
        ifconfig wifi0 hw ether 00:11:22:33:44:55

all working fine :) It seems something in the HAL is screwed because in the code is no logical reason for an oops, and it worked fine with with one of the oldest HALs. Someone should try it with macchanger, but do first that UP/DOWN hack.

08/21/06 16:58:20 changed by anonymous

that does NOT work here at all (r1705 on mips32) i get oops all the time. ath_pci is loaded with autocreate=none, then ifconfig wifi0 up / down / hw ether => segfault + oops (same if a sta vap is created then deleted before the operation) I can provide the oops message if necessary

08/21/06 17:56:29 changed by mrenzmann

Yes, that (oops dumps) would be helpful. Please make sure you enclose each dump in curly brackets, so that they show up correctly in your comment (double-check that by previewing your comment before posting - thanks).

09/01/06 01:28:32 changed by anonymous

I am running 0.9.2 here, macchanger doens't hang in here unless it's run from tty. If I run it from init script, it hanges like described above. This is really weird and confusing. This is what I am doing:

wlanconfig ath0 destroy ifconfig wifi0 down macchanger --mac=xx:xx:.... ifconfig wifi0 up wlanconfig ath0 creat wlandev wifi0 wlanmode station.

As I said, this works after logging into tty or x.org, but not as a rc.local script for example.

Note, I am using madwifi from archlinux package.

09/01/06 01:39:01 changed by cromo

sorry for the formatting, somehow it got broken.

09/02/06 03:01:30 changed by cromo

Just noticed a typo, I meant "(...) doesn't hang in here unless _if_ it's run from tty (console)".

09/18/06 12:55:29 changed by cromo

What I also noticed is that macchanger crashes when hald is not running. This probably explains why it crashes on booting (when run from rc.local) but doesn't when run from tty: hald probably is not running fully yet when rc.local is executed on init.

02/13/07 22:23:43 changed by kurth@informatik.hu-berlin.de

Using the latest driver version changing the mac address still does not work (either with ifconfig or macchanger). Is there eventually a solution for this issue, or at least a dirty hack?

02/17/07 16:13:45 changed by mentor

  • status changed from reopened to closed.
  • resolution set to duplicate.

Not the correct solution. Duplicate; see #173

02/24/07 05:03:36 changed by proski

The oops has been closed in r2156