Madwifi notes

From Helpful
Jump to: navigation, search
This hasn't been updated for a while, so could be outdated (particularly if it's about something that evolves constantly, such as software).

Madwifi access point

### Make sure forwarding is on
echo 1 > /proc/sys/net/ipv4/ip_forward

#First argument (defaults to ath0), the second the wlan parent

### Card setup
# If the device existed, we remove it before we try to (re)create it
(ifconfig $DEVICE 1>/dev/null 2>/dev/null) && (wlanconfig $DEVICE destroy; sleep 1)

# Create $DEVICE as AP-type VAP
wlanconfig $DEVICE create wlandev $PARENT wlanmode ap -bssid

# card, cell and WEP config. They are multiple key-value pairs
iwconfig $DEVICE essid MyStreet   channel 8   key E95BE2DACE1A01FD6E70B26FDB ; sleep 1

### And on the ethernet side, give it an IP and bring it up
ifconfig $DEVICE up
#(manually add broadcast/mask details to that line if the implied defaults won't do)

#if you have DHCP for this, you probably want to (re)start it now, for example: 
#/etc/init.d/dhcpd restart

# While debugging: show configured details
#iwconfig $DEVICE
#ifconfig $DEVICE


  • does a wlanconfig ath0 destroy if the device existed already. There are also rules to how you create more than one VAP on the same adapter, in terms of order.
  • creating the device with -bssid makes the bssid the MAC of the underlying hardware
  • I iwconfig ath0 mode master is probably redundant if you wlan it as an ap(verify)
  • I had various problems where something would be forgotten, usually the IP address or WEP key. This probably has to do with configuration timing on the wifi card, hence the sleep statements - but I can't guarantee this will always work.
  • visit some random number generator site for a key. You need 13 bytes, 26 hex characters (this is one way). (Note: This is WEP, which you can crack within minutes in the (for the hacker's) best case. I'll figure out WPA later.)

Note that an AP has to stay on one channel, so you can't use any monitor programs configured to channelhop - the VAPs may look separated, but there's only one tuner on most wireless cards.

If you want to cooperate with your system config somewhat, you should read up; every distro has a different way of handling wireless configuration. Me, I have the above in a completely separate script I have to manually run.

dhcp daemon

Make it serve on (at least or exactly) the wireless interface (here ath0), and give out a particular range (see also the division suggestion below).

At this point, connect with a client, see if you get an IP, and see if ping works. From linux, you can do a ping -A to ping very fast; it should be clear whether it's working.

In an idempotent script that restarts the dhcp server, you probably want to sleep at least three seconds, since you want network configuration to have settled. That is, if you don't configure things like subnet information, it has to come from settled hardware configuration (verify)


(mostly unrelated to wifi, I just rarely use this)

To NAT internal network on ath0 via a public-IP interface (specifically via my public IP on eth0), I do:

iptables -t nat -A POSTROUTING -o eth0 -s -j SNAT --to publicip
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


  • if cat /proc/sys/net/ipv4/ip_forward says 0 you will need to do echo 1 > /proc/sys/net/ipv4/ip_forward, or rather edit some system configuration to do so at bootup. In my case this is in /etc/sysctl.conf.
  • You may also want incoming forwards:
iptables -t nat -A PREROUTING -d publicip -p tcp -m tcp --dport 3389 -j DNAT --to-destination internalip:3389
  • When messing with iptables, I prefer to iptables-save > a file, mess with that, and iptables-restore from that file - less worry about -I, -A, table names and such things.


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

(Not really tested by me)

If you already have a private-IP network you use for your home LAN you can bridge a range onto that same subnet:

brctl addbr br0
brctl addif br0 ath0
brctl addif br0 eth1


  • Requires kernel support and 'bridge-utils' package
  • You can give the bridge an IP, but this isn't necessary.
  • Inspect bridge with
    brctl show
    , and pings.
  • If you bridge, you may want to informally split a subnet into, say:
    • 1-99 for static, wired ethernet clients,
    • 100-199 to be handed out by DHCP, and (visitors)
    • 200-254 as DHCP-assigns-by-MAC that never change (known clients)

In my case, I do have such a private network, but it is a dedicated internal connection that I don't want routing muck with, so I instead chose to use a new private network, (I also have a public IP range with one address free which I could bridge onto directly - but that sort of destroys the point of making it an AP.)