Adam Vazquez Kb2jpd Internet Mobile w/ Treo wrote:
The wireless card is operating in a medium full of unpredictable vectors. You are using a wireless card. The frequencys that it is designed for are full of other radio users and emitters, such as microwave ovens wireless phones and of course other wireless users.
You're using a wireless connection. Using it will advertise to others that you have a valid network connection. If they have a closer or more solid radio connection, you will have to contest your wireless connection.
So I have multiple GPSs, GSM/GPRS/UMTS modems, trunk radios and other radio transponders in my office (which happens to be a radio lab) along with a WLAN. All of which was installed by a radio engineer, selecting the appropriate channels on the configurable equipment to make sure we have the least amount of interference possible. We normally have 3 laptops connected on the AP in the lab. When everybody that can possibly connect to the AP in the lab we are up to about 9 laptops. The laptop in question works fine when running Windows and have no issues when using the network. I therefore doubt that the WLAN or wireless cards are at fault.
Change your channel allocation to one less used and monitor your traffic. Change the locations of your access point and your workstation so you have best reception.
We have moved the AP to about 5 meters from the office where there is no radio interference. We also added shielding around all the radio equipment and used shielded cable to antennas outside on the roof. We have tested this and there is no RF leakage. On all the laptops we have a 100% signal strength and it never drops. We rarely have disconnects and it is normally caused by someone talking with a mobile trunk radio below our AP. I have emailed Intel and they said: [quote] We had a user reporting similar problems a while ago and it ended up being the dhcp client they were using that would periodically take down the network interface. Try running your dhcp client so that it doesn't attempt to bring the inteface up or down itself (with dhcpcd you can do that with -o. I'm not sure what dhclient might use) You can also check the kernel logs for any indication of if there is a carrier loss for any preiod of time (reassociation, etc.) Load the module w/ debug set to 0x43fff: % . load debug=0x43fff and then see the kernel log when you experience your problem (dmesg | less) [/quote] I will therefore use that as a starting point. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.8/113 - Release Date: 2005/09/27