Robert Parker wrote: > But now when I connect to my wirelees access point it gives me a > 'connecting' message and finally connects only to immediately drop > out and start connecting all over again.
What configuration are you using to connect to it? Are there any clues to the problem in /var/log/syslog around the problem? Basically unless we see something it isn't going to be possible to help. (And unfortunately since you are the one seeing the problem it may not be possible for us to guess correctly at the reason anyway.) > My access point is unsecured, I don't know if that has any bearing > on the problem. In theory it shouldn't. But the difference between theory and practice is the difference between theory and practice. Your device is an Atheros and that has a good reputation. YMMV. Always worked well for me. There are several steps in the WiFi connection process. Off the top of my head: 1. Associate. 2. If DHCP is configured then perform DHCP protocol. If your wifi is associating and immediately disassociating then there could be a problem with the driver. Try unloading and reloading the driver. This sometimes works for me and others on the list have reported it similar. rmmod drivername ; sleep 1 ; modprobe drivername If the wifi is associating okay then it will typically DHCP. (Unless a static configuration has been chosen.) If the DHCP fails then the device will be deconfigured. If the device associates then it should be able to transmit and receive dhcp packets. If this is prevented then dhcp will fail and the device will be deconfigured. The dhcp might fail if the device is not tranfering dhcp packets properly. Or if a firewall is blocking those packets. If you have a firewall then try the connection with the firewall disabled. I often use tcpdump to try to capture the dhcp protocol but this is trickier since the device is always going up and down. For tcpdump use the device "any" to listten to any configured network. Another useful tool is 'dhcpdump'. But usually if packets are being transfered then it will work and if packets are not being transferred then it won't work. It is also possible for all to work okay on the client end but to have the dhcp on the server end to fail. A typical failure configuration is to have too few dynamic IP addresses available on the pool. For example one open wifi access point that I know at one of the local airports has only 25 IP addresses in the pool. It allocates those addresses for 24 hours. At 6am in the morning you can associate and get an IP address. By 10am in the morning all of the 25 IP addresses have been allocated and leased for 24 hours. They will not free up again until the next day. This is a misconfiguration of the wifi access point's dhcp server configuration for the task that it is trying to do but it creates this behavior of not being able to get wifi access from it due to a server configuration issue even though the client is okay. (Workaround hack: If you know the configuration then you can bypass DHCP and set a static configuration for it.) This next item I am going to mention isn't really associated particularly with wifi. The DHCP will transfer routing information. That is usually always good. The DHCP will transfer nameserver information. This is sometimes troublesome. If the nameserver is broken then it leads to a confusing situation where the network connection is established but no names can be looked up. Since humans generally deal with names it makes it appear as if the network is both up and down at the same time. If you hear people suggesting a particular known good nameserver such as 8.8.8.8 that is the problem they are addressing. However I believe it is better to fix the real underlying problem rather than work around it. Good luck! Bob
signature.asc
Description: Digital signature
