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 #1340 (closed enhancement: fixed)

Opened 12 years ago

Last modified 12 years ago

[patch] Reverse engineering support commands

Reported by: mtaylor Assigned to: mtaylor
Priority: minor Milestone: version 0.9.5
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:


This patch adds iwpriv support for the following commands:

# Read a register (used for reverse engineering)
iwpriv athN readreg  <address in hex or decimal>

# Write to a register (used for reverse engineering, privileged ioctl)
iwpriv athN writereg <address in hex or decimal> <value in hex or decimal>

# Dump delta (since last mark / snapshot of ar5k registers)
iwpriv athN dumpregs 1

# Mark (snapshot of interesting ar5k registers)
iwpriv athN dumpregs 2 

# Dump all interesting ar5k registers
iwpriv athN dumpregs 0


  1. This is a work in progress, intended to help people reverse engineering or trying to figure out what is going on in the driver.
  2. The dump/mark/delta commands can cause crashes on some cards because some addresses aren't mapped.
  3. It does not exclude all the redundant addresses (due to the way memory mapping is implemented, this is normal).
  4. I'll fill in the list of exclusions so that the list of dumped values is more reasonable soon.
  5. There is a potential security issue with this patch in the current form. I'll restrict the address range to the PCI device, assuming that is necessary.


madwifi-0.9.3-reverse-engineering-cmds.diff (33.8 kB) - added by mtaylor on 05/23/07 23:49:29.
Reverse engineering ioctls

Change History

05/23/07 23:49:29 changed by mtaylor

  • attachment madwifi-0.9.3-reverse-engineering-cmds.diff added.

Reverse engineering ioctls

05/23/07 23:51:21 changed by mtaylor

FYI: This patch was based upon trunk with the patch I have in ticket #113 for regulatory testing. The ioctl names/numbers will not match up if you apply the patch directly to trunk. Grab that patch first if you need to.

(follow-up: ↓ 3 ) 05/24/07 01:30:41 changed by mentor

Hmmm, I wonder if we should start a debug branch, or something.

(in reply to: ↑ 2 ) 05/24/07 09:55:10 changed by mrenzmann

Replying to mentor:

Hmmm, I wonder if we should start a debug branch, or something.

I'd say: no. Debug stuff should be optional, but in the release driver (thus: trunk).

(follow-up: ↓ 5 ) 05/24/07 23:03:28 changed by mtaylor

The problem with adding debug ioctls to iwpriv is that the things are numbered in sequence with hard-coded sequences. I have no idea what happens if you conditionally disable some, but I'm willing to try it out.

Do you think we should put preprocessor conditionals around this code ?

(in reply to: ↑ 4 ) 05/25/07 06:30:13 changed by mrenzmann

Replying to mtaylor:

Do you think we should put preprocessor conditionals around this code ?

Yes, that should be possible, similar to how we control support for fast frames and stuff.

05/25/07 21:58:28 changed by mtaylor

I'll add the conditionals, make support, etc. and then check this in.

05/29/07 21:09:41 changed by mtaylor

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

This was committed in r2388 with more complete register name mapping. I also changed the default to only attempt to access known-good addresses during dumpregs iwpriv calls to avoid crashes on some combinations of hardware/software and made dumpregs only support AR5212/AR5213 at the moment, to avoid inadvertent crashing of older/newer chip families.

05/30/07 06:17:41 changed by mrenzmann

  • milestone changed from version 0.9.x - progressive release candidate phase to version 0.9.4.

02/11/08 06:18:49 changed by mrenzmann

  • milestone changed from version 0.9.4 to version 0.9.5.