In my previous HOWTOs, Using Debian GNU/Linux (sarge/stable) as a wireless accesspoint with Atheros wlan adapter and Securing insecure wireless home network with IPSec, I showed how to create a simple Debian Sarge accesspoint with additional protection of IPsec encryption. In this article I will show how to set up a more advanced Debian Etch (4.0) accesspoint using hostapd and a Atheros-based wireless card in master mode. In addition, I will cover setting up Debian Etch-based clients the "Debian Way" by combination of /etc/network/interfaces and wpa_supplicant. Especially the Debian Sarge as a simple accesspoint is still useful, so I suggest opening it alongside with this HOWTO. Also, if you are paranoid about security or simply want to experiment, you can use IPSec on top of WPA - it works quite reliably. See the WEP + IPsec HOWTO for more information.
NOTE: I currently use only Atheros-based wireless cards, so in all examples the wireless card is called ath0. Substitute ath0 with the correct device name where applicable.
During the time I've used my Debian-based accesspoint I've run into several problems. Many of the problems I encountered were related to wireless networks in general, so I'll cover them here.
First of all, make sure that you don't choose a channel which is already filled with other accesspoints. If you are using Atheros-based Wireless NIC, set it to "Managed mode" with iwconfig ath0 mode Managed and issue wlanconfig ath0 list ap. This will list all accesspoints that are visible:
root@localhost:~# wlanconfig ath0 list ap SSID BSSID CHAN RATE S:N INT CAPS An accesspoint 00:10:32:1b:28:e2 1 2M 10:0 100 EP Another one 00:0e:02:72:af:31 8 54M 4:0 100 EPs WPA Atheros 00:05:a3:ea:22:f2 12 54M 31:0 100 EPSs WPA WME ATH
This listing seems not to show those accesspoints which are "hidden". It is, however, possible to detect hidden accesspoints on the same frequency (channel) indirectly. Just use the wireless network for a while and then issue iwconfig ath0:
root@localhost:~# iwconfig ath0
ath0 IEEE 802.11g ESSID:"MyAP"
Mode:Managed Frequency:2.467 GHz Access Point:
00:15:E9:30:96:E6
Bit Rate:6 Mb/s Tx-Power=18 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:4942-9443-0AE3-A328-21EA-D883-EAB1-2CC2
Security mode:restricted
Power Management:off
Link Quality=28/94 Signal level=-67 dBm Noise level=-95 dBm
Rx invalid nwid:3 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
root@localhost:~#
In this case the channel is pretty clear. If there is interference from other accesspoints you will have a high value in Rx invalid nwid. A wlan card can only receive packets that are sent on the same channel, so packets with invalid network ID represent other accesspoints on the same channel.
I stumbled upon this problem once, when I had serious problems with my wireless network. Sometimes my packet loss was 100% for long periods of time. Sometimes the connection would be just fine. When I got frustrated enough, I (once again) read the iwconfig manpage and then looked at iwconfig output. I noticed that my card had received over 14000 packets with invalid nwid. I then changed the channel and the network connection started working perfectly.
With many wireless cards you can control the transmit power. In general the longer the range, the higher transmit power you need. It might seem like a good idea to use the highest possible transmit power so that you don't have to worry about it. There are a couple of problems with this. First of all, high transmit power means that everyone - not just you - will be able to try to connect to your wireless network. It does not mean that they will or can, but they can always try.
In addition you will probably end up interfering with other people's networks on the same channel. Being in a highly saturated wlan is quite similar to being in a noisy restaurant: if you raise your voice, everyone else will have to raise theirs. If everybody would speak silently nobody would have to shout. So I recommend finding a clear channel and reducing the transmit power as much as possible. This way you won't be broadcasting your wireless network to the whole city block.
Then again, I don't expect consumer-grade wireless accesspoints to play nice here: they are all about maximum range and high throughput. It would probably be too hard for the average Joe to adjust transmit power manually, so I guess that by default they are transmitting at full power.
It is possible to make a Linux or *BSD computer a wireless accesspoint without using any dedicated software for the job. In fact, you just need to put you wireless card into master mode with iwconfig ath0 mode Master and you're basically done. Of course you need additional software and configuration, but hostapd is not strictly required.
I had my AP in basic Master mode without hostapd for quite a while. Although it worked well 95% of the time, it was not really reliable enough. Sometimes clients could not authenticate, no matter what I did. After a brief struggle I noticed that the wireless card did not always disassociate the clients that had disconnected. When the same client tried to connect again, card would refuse the connection, because it thought that a client with the same hardware (mac) address was already connected. This was rather irritating, because the only way to fix this was to restart the wireless interface on the AP.
When I bought a WPA2-capable wireless card, I finally decided to try hostapd, because it was not possible to get WPA2-encryption and authentication on a Linux AP without it. Installing hostapd was a breeze, and it has been 100% reliable. All problems I've had with my wireless setup after moving to hostapd have been on the client side. In short, I've been very impressed with it.
First step you have to do on the accesspoint is to configure the wireless hardware properly. This step is slightly different on various Linux flavors. The steps taken here should work at least on Debian and Ubuntu, but might work on some other distros.
First open up the file /etc/network/interfaces, which contains definitions for all network interfaces your computer has. Add an entry for your wireless card, or modify it if it exists:
### etherconf DEBCONF AREA. DO NOT EDIT THIS AREA OR INSERT TEXT BEFORE IT. # NOTE: We are being naughty here and disobeying debconf. Perhaps you shouldn't... # We want lo, ath0 and eth0 to start at boottime auto lo eth0 ath0 # We need the loopback device iface lo inet loopback # This is the ethernet card connected to the Internet iface eth1 inet dhcp hostname localhost ### END OF DEBCONF AREA. PLACE YOUR EDITS BELOW; THEY WILL BE PRESERVED. # It is not possible to configure the wireless interface with debconf # with enough granularity, so we'll have to do it manually iface ath0 inet static # Basic interface settings address 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 # It would be possible to set wireless parameters here directly, # but I find it easier to set them in pre-up and post-down # scripts (see "man interfaces" for more info) pre-up /etc/init.d/ath0_preup post-up /etc/init.d/ath0_postup
The important thing here is the pre-up part. Before you can bring the wireless interface up, you must have some wireless settings (channel, rate, mode etc.) already configured. This is where the pre-up -script comes into play.
Atheros-based cards use a tool called wlanconfig to create and delete wireless interfaces. This kind of functionality is needed because the madwifi drivers allow you to create multiple virtual wireless interfaces which you can configure independently. For example, you can create two different virtual wireless interfaces (for example ath0 and ath1) and configure them independently of each other. By default new Atheros virtual interfaces are not in accesspoint mode: therefore if you wish to use an interface as an accesspoint, you have to destroy it first and then recreate it in accesspoint mode. I have not yet found a clean way to force the interface to start in accesspoint mode.
NOTE: The Atheros accesspoint mode should not be mixed with Master, Managed or Ad-hoc modes, which are modes in which a configured wireless cards can be in. Below is an example of the /etc/init.d/ath0_preup script which you can use as a basis for your own:
#!/bin/bash # /etc/init.d/ath0_preup # # Destroy the virtual ath0 interface wlanconfig ath0 destroy > /dev/null 2>&1 # Re-create the virtual interface and force it in accesspoint mode wlanconfig ath0 create wlandev wifi0 wlanmode ap bssid # Bring the interface up. The actual network parameters are set # later when execution of /etc/network/interfaces continues ifconfig ath0 up # Set basic wireless parameters to our liking # # You could set essid here, but it is overwritten by the one # in hostapd.conf #iwconfig ath0 essid MyAP # Switch the interface to Master-mode so that it will # receive requests from outside, instead of doing requests # itself iwconfig ath0 mode Master # Autoselect the rate at which the interface operates instead of # using defined rate (e.g. 11M, 54M) iwconfig ath0 rate auto # Select a channel to use: make sure it's not too saturated # with other wifi traffic. See above for more information. iwconfig ath0 channel 12 # We could set the WEP key here, or disable the key if we want, # but the settings defined in hostapd.conf override this anyway #iwconfig ath0 key my-secret-key # Set the transmit power. With my card 18 is the largest possible # transmit power available. Issue "iwlist ath0 txpower" to see your # card's limits. iwconfig ath0 txpower 18 # Disable power management which _might_ cause some trouble. When # everything is working smoothly, you can switch it on. iwconfig ath0 power off
To verify that the interface is operating correctly, bring it down with ifdown ath and up again with ifup ath0. Then check the output of iwconfig ath0 to see that rate, channel and others are what they are supposed to be. Use iwlist command to get more in-depth output.
Installing hostapd on Debian etch is very straightforward: just do a aptitude update && aptitude install hostapd and you're done. If for some reason you want a newer version, you can get it from hostap homepage.
With default settings hostapd is not of much use. Luckily configuring it is relatively straightforward once you know what you are doing. The file is most likely located in /etc/hostapd/hostapd.conf and it is heavily commented. In this example file I have removed all unnecessary parts and comments. Refer to your original configuration file for more information.
# /etc/hostapd/hostapd.conf # Interface to use as an accesspoint interface=ath0 # Driver interface type (hostap/wired/madwifi; default: hostap) # If you use Atheros-based card then use the madwifi driver driver=madwifi # Logging and debugging settings: more of this in original config file logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 debug=0 dump_file=/tmp/hostapd.dump # SSID to use. This will be the "name" of the accesspoint ssid=MyAP # WPA settings. We'll use stronger WPA2 # bit0 = WPA # bit1 = IEEE 802.11i/RSN (WPA2) (dot11RSNAEnabled) wpa=2 # Preshared key of between 8-63 ASCII characters. # If you define the key in here, make sure that the file is not readable # by anyone but root. Alternatively you can use a separate file for the # key; see original hostapd.conf for more information. wpa_passphrase=fdajk5akj32j9fdakfj3r0jfakjf3akljf3a30rfal3rj0a3fjkaj3alk # Key management algorithm. In this case, a simple pre-shared key (PSK) wpa_key_mgmt=WPA-PSK # The cipher suite to use. We want to use stronger CCMP cipher. wpa_pairwise=CCMP # Change the broadcasted/multicasted keys after this many seconds. wpa_group_rekey=600 # Change the master key after this many seconds. Master key is used as a basis # (source) for the encryption keys. wpa_gmk_rekey=86400
This configuration should get you going, but make sure you read all the documentation that comes with hostapd so that you get a better understanding of what these settings mean. After configuring hostapd, try starting it with /etc/init.d/hostapd restart, then follow the output it writes into /var/log/daemon.log. You can try connecting to the AP from clients, which should now work. You don't get any real connectivity until you do some extra configuration, but hostapd should work just fine.
If you simply want to be able to connect to the Internet from wireless clients, you could probably just bridge the wireless interface with the accesspoint's Internet-connected interface. I have not tried this approach, so I don't know how well that would work. I want to use internal LAN resources also, so I have configured the accesspoint to do IP masquerading whenever it's necessary.
If you only have two network interfaces and don't want to get your hands too dirty, you can use something like firestarter to configure you accesspoint to do IP-masquerading (a.k.a. Internet connection sharing) automatically. If you have more interfaces, you can use fwbuilder, which is easier to understand than the rather unintuitive iptables syntax. Then again, if you understand the basics of packet filtering, you can just as well write the rules yourself. Below is an example script you can use to get started with iptables and IP-masquerading:
#!/bin/sh # Firewall for Debian Etch accesspoint # Program paths and variables IPTABLES="/sbin/iptables" # Wlan interface WLANIF=ath0 # External, Internet-facing interface EXTIF=eth0 # Loopback interface, which has to defined or # shit hits the fan. LOOPIF=lo # Wireless LAN address and netmask. In this # case addresses 192.168.0.0 - 192.168.0.254 # are reserved for it. WLAN="192.168.0.0/24" echo "-----------------------------------------------" echo "Starting Debian Etch accesspoint firewall echo "-----------------------------------------------" # Enable IP-forwarding. Otherwise we won't be able # to forward any traffic from the WLAN to the Internet echo "Enabling IP-forwarding" echo 1 > /proc/sys/net/ipv4/ip_forward # Remove all previously made rules echo "Removing old rules" $IPTABLES -F $IPTABLES -X # Create custom chains for inbound and outbound # traffic on the WLAN interface and the external # interface + some other custom chains. This is # done to simplify mainteinance. echo "Configuring custom chains:" $IPTABLES -N in_extif $IPTABLES -N out_extif $IPTABLES -N in_wlanif $IPTABLES -N out_wlanif $IPTABLES -N ssh_log $IPTABLES -N spoof_log ############################################### ################ CUSTOM CHAINS ################ ############################################### ################ ssh_log chain ################ # * Log SSH connection attempts. You don't need this # if you are not running a sshd server listening on # the external interface. If you remove this, make # sure to remove all references to it from other # parts of this script echo " ssh_log" $IPTABLES -A ssh_log -j LOG --log-level warning --log-prefix "SSH connection" $IPTABLES -A ssh_log -j ACCEPT ################ spoof_log chain ############## # * Log IP spoofing attempts (mostly noise). # Disabled for now bacause kernel should handle # IP-spoofing attempts automatically. echo " spoof_log" ################ in_extif chain ############### # * External interface, coming in echo " in_extif" # Allow max 3 SSH connections per minute from the Internet. # Log all connection attempts (jump to ssh_log chain). $IPTABLES -A in_extif -i $EXTIF -p tcp -m tcp --dport 22 -m state --state NEW -m limit --limit 3/minute --limit-burst 3 -j ssh_log $IPTABLES -A in_extif -i $EXTIF -j DROP ################ out_extif chain ############## # * External interface, going out echo " out_extif" # Accept all outgoing traffic $IPTABLES -A out_extif -o $EXTIF -j ACCEPT $IPTABLES -A out_extif -o $EXTIF -j DROP ################ in_wlanif chain ############## # Wlan interface, coming in echo " in_wlanif" # * Allow all incoming traffic to the WLAN interface $IPTABLES -A in_wlanif -i $WLANIF -s $WLAN -j ACCEPT $IPTABLES -A in_wlanif -i $WLANIF -j DROP ################ out_wlanif chain ############# # Wlan interface, going out echo " out_intif" # * Allow all outgoing traffic from the WLAN interface $IPTABLES -A out_wlanif -o $WLANIF -d $WLAN -j ACCEPT $IPTABLES -A out_wlanif -o $WLANIF -j DROP ############################################### ################ STANDARD CHAINS ############## ############################################### echo "Configuring standard chains" ################ POSTROUTING chain ############ echo " postrouting" # Masquerade connections if they arrive from specified addresses, # in this case from the wireless LAN $IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.0/24 -j MASQUERADE ################ FORWARD chain ################# # Forward chain processes packets that arrive to # the accesspoint but are not destined for it. # This includes, for example, packets that are sent # from WLAN clients to the Internet via the AP. echo " forward" # Set policy to DROP $IPTABLES -P FORWARD DROP # Related & established $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Drop any new or invalid packets coming from external interface $IPTABLES -A FORWARD -i $EXTIF -m state --state NEW,INVALID -j DROP # New connections from WLANIF $IPTABLES -A FORWARD -i $WLANIF -o $EXTIF -m state --state NEW -j ACCEPT # Drop everything else $IPTABLES -A FORWARD -j DROP ################ INPUT chain ################## echo " input" # Set policy to DROP $IPTABLES -P INPUT DROP # Allow inbound loopback $IPTABLES -A INPUT -i $LOOPIF -m state --state NEW -j ACCEPT # Allow related & established packets $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Jump to per-interface chains $IPTABLES -A INPUT -i $EXTIF -j in_extif $IPTABLES -A INPUT -i $WLANIF -j in_wlanif # Drop all other packets $IPTABLES -A INPUT -j DROP ################ OUTPUT chain ################## echo " output" # Set policy to DROP $IPTABLES -P OUTPUT DROP # Allow outbound loopback $IPTABLES -A OUTPUT -o $LOOPIF -m state --state NEW -j ACCEPT # Related & established $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Jump to per-interface chains $IPTABLES -A OUTPUT -o $EXTIF -j out_extif $IPTABLES -A OUTPUT -o $WLANIF -j out_wlanif # Drop all other packets $IPTABLES -A OUTPUT -j DROP
This script is a stripped-down version of my own and I have not tested it in a live environment. Therefore I suggest that you try to run it and then verify that everything is ok by checking the output of iptables -L -v. This command lists contents of all built-in and custom chains and produces rather easily readable output. If you need help with packet filtering basics, take a look at Rusty Russell's guide to iptables and/or google with "packet filtering". When the script is working as it's supposed to, make sure that it starts automatically on boot by adding it to /etc/rc.local:
#!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. # # Start our new firewall /etc/ap.fw exit 0
Before you proceed, you should be aware that it is not necessary to use a DHCP server to create a LAN or to share an Internet connection. In fact, a misconfigured DHCP server will probably make you ISP quite angry. A typical misconfiguration is such that your DHCP server listens to requests from the external (=Internet-connected) interface, not just from the internal interface(s). This is actually what Windows Internet connection sharing does by default - it listens for requests on all network interfaces, at least according to our University's official network guides. I have no personal experience on this subject, however.
As DHCP is used by clients to obtain their IP-address (plus some other information), they can't send the request to a specific DHCP server's IP-address. If they tried, DHCP server would not know to which IP they would respond to, because the client wouldn't yet have an IP-address. In addition, the whole idea of DHCP is to allow clients to be autoconfigured without knowing anything about the network they are connecting to.
So, instead of asking the DHCP server directly, the clients send a broadcast query to their ethernet segment. This broadcast is most likely intercepted by all DHCP servers in the same segment. If your misconfigured DHCP server replies faster than your ISP's DHCP server, the client will get IP/DNS/Gateway information from your computer - in effect joining your LAN. Most likely they will lose connectivity to Internet and complain to your ISP. When tens or hundreds of people lose their Internet connectivity, you can rest assured that the ISP will find out the cause pretty quickly, and hold you accountable for all the damage. The extent of the damage depends on how large network segment you are connected to, and on various other network settings. This is exactly why our university has prohibited the use of DHCP in home LAN's without special permission.
Luckily there are several ways with which you can mitigate the risks associated with using a DHCP server. First of all, make sure that all DHCP requests from the external interface are blocked by the packet filter. If you use a script similar to the one above, you should be covered. In addition, you need to limit which interfaces DHCP server will listen on. In Debian, this is done by editing the file /etc/default/dhcp:
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests? # Separate multiple interfaces with spaces, e.g. "eth0 eth1". INTERFACES="ath0"
In this case, we'll only listen for request coming in from the interface ath0. Make sure that you don't have your external interface here. Also take extra care to check this setting whenever you switch/add network cards. If possible, tie each ethernet device to a specific network adapter. This has been done in various ways during past years, but you should try if using udev and iftab would do the trick:
# /etc/iftab # This file assigns persistent names to network interfaces. # See iftab(5) for syntax. eth0 mac 00:20:04:51:B2:5C arp 1 eth1 mac 00:01:F5:7E:2F:49 arp 1
You can check your adapter's MAC address by issuing ifconfig eth0 or similar. In addition, you can do some extra protective measures from within the dhcpd configuration file, which is shown below:
# /etc/dhcpd.conf
# Deny all unknown clients and do not try to be authoritative
# source of DHCP information by default
deny bootp;
deny unknown-clients;
not authoritative;
use-host-decl-names on;
# Your ISP's name servers go here
option domain-name-servers 115.52.121.1, 115.52.121.2;
# Your ISP's domain name
option domain-name "your.domain.com";
# The local address and subnet mask of this accesspoint
option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
# How long before clients have to re-request their IP-address
# information.
default-lease-time 86400;
max-lease-time 86400;
# There has to be a subnet declaration for each interface in
# your computer. Otherwise dhcpd will bail at startup.
# This is the wlan subnet declaration
subnet 192.168.0.0 netmask 255.255.255.0 {
# You can either define a range of addresses that are
# given to connecting clients, or define static IP-
# addresses for each client based on their NIC's
# hardware address. You can also combine the two
# approaches if you like.
#
# Hand out addresses from this pool
#range 192.168.0.100 192.168.0.105;
# Define a static IP for a specific client
host your_first_client {
hardware ethernet 00:04:82:0B:15:33;
fixed-address 192.168.0.101;
}
# Define a static IP for a specific client
host your_second_client {
hardware ethernet 00:D0:59:64:63:E5;
fixed-address 192.168.0.102;
}
}
subnet 115.52.0.0 netmask 255.255.0.0 {
# Extra measures to make sure that no-one from the
# external interface can get an IP-address from us
# by a mistake.
deny unknown-clients;
not authoritative;
}
You can define directives globally (at the top), or inside subnet declaration. Global defaults are inherited automatically, but they can be overridden in subnet declarations. Should dhcp server fail to start, check /var/log/daemon.log to see what went wrong. See man dhcpd.conf for more information.
The client-side configuration is pretty similar to server-side configuration. First edit the file /etc/network/interfaces. This is not as easy as on the server, because Debian has a special way of handling wpa_supplicant and the interfaces-file. All the necessary information is available in Debian's documentation - see /usr/share/doc/wpa_supplicant, man wpa_supplicant and man interfaces for more information. It just takes quite a while to make all those pieces of information into a coherent whole. Hope my research will save somebody from all that pain :). So, here's my /etc/network/interfaces which has support for wpa_supplicant built in "The Debian Way":
# /etc/network/interfaces
auto lo
iface lo inet loopback
# Wired ethernet
iface eth0 inet dhcp
# The physical wireless interface has to be set to
# "manual" mode to make it integrate nicely with
# wpa_supplicant in Debian.
iface ath0 inet manual
# The driver to use
wpa-driver wext
# The file which contains roaming information.
# We are not really conserned about roaming, but
# this file contains all of our preferred networks
# to which wpa_supplicant will connect automatically.
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
# "home" is a keyword which is used in
# /etc/wpa_supplicant/wpa_supplicant.conf to tie this
# entry and a network definition in wpa_supplicant.conf
iface home inet dhcp
# Set some iwconfig variables
pre-up /etc/init.d/ath0_preup
# Reconfigure firewall after interface has been created
post-up /etc/init.d/firewall restart
The file ath0_preup is similar to the one at server side:
#!/bin/sh # Set rate to auto iwconfig ath0 rate auto # Set transmit power to max iwconfig ath0 txpower 18 # Disable all powersaving features for testing purposes iwconfig ath0 power off
Configuring wpa_supplicant is quite straightforward. Just edit the file /etc/wpa_supplicant/wpa_supplicant.conf as shown below:
# /etc/wpa_supplicant/wpa_supplicant.conf
# This file is basically a list of those networks you wish
# wpa_supplicant to connect to. It will sometimes try
# connecting to other networks as well, whether you want
# it to or not :).
# Don't touch these unless you know what you're doing
ctrl_interface=/var/run/wpa_supplicant
update_config=0
# This is our primary (home) network
network={
# Accesspoint's SSID
ssid="MyAP"
# id_str refers to the entry in /etc/network/interfaces
id_str="home"
# The pre-shared key
psk="fdajk5akj32j9fdakfj3r0jfakjf3akljf3a30rfal3rj0a3fjkaj3alk"
# Protocol, keymanagement and ciphers. Must match those that the
# accesspoint uses
proto=WPA
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
# Give this network the highest priority
priority=100
}
# It might be useful to define other networks besides our
# primary network. It is possible to create additional entries
# for these into /etc/network/interfaces, if required. Remember
# to give an id_str in here and use that as the interface name
# in /etc/network/interfaces.
network={
ssid="Opensystem"
key_mgmt=NONE
priority=99
}
While wpa_supplicant should work quite well with settings given above, you will most likely run into trouble if you remove your wireless card on the fly, stop the interface or something similar. If you fail to connect to the AP, try doing the following:
root@localhost:~# ifdown ath0 root@localhost:~# ifconfig ath0 down root@localhost:~# ifup ath0
This helps for me, because sometimes the script /etc/init.d/wpa-ifupdown gets confused and this procedure fixes it. It took a while to figure this out, so I hope this saved somebody else's precious time :).
If you want to use samba, nfs or some other filesharing server on you AP, you should definitely take a look autofs. It is especially useful when you're dealing with unreliable networks such as wireless LAN's. Take a look at my previous WLAN HOWTO, Securing insecure wireless home network with IPSec for more information.
