I JUST fixed a problem with the router and I have another.. here is the previous problem:


Windows, Macintosh, and Linux alike couldn't connect to the router.

I tried downgrading the firmware I tried reboots... even looking at neigborhooding packets and routers to look for interferrance.

I fixed it by REloading the fireware, reseting the configs, and setting up a low key encryption.


Now I got another problem:
Now that everyone is connected, and working, linux has a problem.

Our network is cloaked, and has a 64bit key. The other compters are able to connect. I was able to connect as well for the first 3 hours or so. Then I lost the connection, and now I can't connect anymore.

What should I do?

Extra info:
Di-524
64-bit key WEP
cloaked network
3.02 firmware version
madwifi driver

A "cloaked network"? I'm assuming you mean that you don't broadcast your SSID. At any rate, you don't give much detail about what you've tried to regain your wireless connection. Any details would be helpful. However, what I would do would be to first set the WEP key with iwconfig, then set the ESSID, also with iwconfig, then request an IP address or assign one.

Yes, that's correct, I don't broadcast the SSID

To connect I would do the following commands:

iwconfig ath0 essid MyNet key `cat mykey`
dhclient ath0

and I would get my network... After a certain amount of time, I lose my connection. I noticed in Mandrake that my key was set to "00" ... So I reentered my key... then I decided to do the whole setup again, with the full iwconfig command, and use dhclient... no success...

I even tried to reset the router when the network wasn't in use. That didn't do it as well.

I reformated my PC and installed FC (not because of the problem, I know better than to do that it was because Windows needed reformating and I needed to write a better partition table)
It doesn't work in FC as well...

I think I'll try to change my MAC address and see if it'll do any changes, for the debuging purpose.

Could you post the make/model of this card? I've been doing a little googling to see if I could come up with anything and mostly what I'm finding is complaining about this being a hardware problem. In particular some D-Link cards seem to be susceptible to this sort of nonsense, especially the 802.11 b/g cards. To be fair, this was happening in both Windows and Linux, so since you're dual booting, you might want to see if it behaves or not in Windows.

You also might want to rummage through your logs and see if the card is complaining about anything. And to be honest, mucking about with MAC addresses usually doesn't accomplish anything unless your router supports filtering clients based on the MAC address. Changing the router's MAC address isn't going to do diddly for this problem.

The card is Atheros Communications Inc AR5212 802.11abg NIC
The router is Di-524

Now, I'm debugging on the moment...

In linux:
su
cd /sbin
./iwconfig ath0 essid MyNet key thekeyinhex
./ifconfig up

I get:

ath0 IEEE 802.11 ESSID:"MyNet"
Mode:Managed Frequency: 2.437 GHZ (continually changing... as it's scanning) Acess Point 00:00:00:00:00:00
Bit Rate: 1 Mb/s Tx-power=18 dBm Sensitivity 0/3
Rety:Off RTS thrff Fragment thrff
Encryption key:xxxx-xxxx-xx Security mode:restrictd
Power Managementff
Link QUality=0/84 Signal level=-95 dBm Noise Level=-95 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx exessive retires:0 Invalid misc:0 Missed beacon:0

I just tried in windows now: it works...

back in linux... it doesn't... but every other network does.

I suppose there is no answer?

Then I guess I'll have to fix it myself

I, and everyone else on this board, donate our time when we have it. Believe it or not, while I'm willing to help you, I have more pressing matters.

I rarely set my WEP key and SSID in the same command, mainly because you usually need to set the WEP key first in order for there to be a decent connection. You also might want to try setting it a couple of times in a row to see if it will take.

I didn't mean to offend you
I appreciate everyone that takes the time to place a reply. (to me or anyone else)

Thank you for your time

have a nice day

To be honest, I'm a bit stumped by your cards inability to connect to the access point. If I were in your shoes, I'd try entering the ESSID and WEP key in different order (usually WEP key first) and see if some particular combo works better than the others. You also might try setting the IP address, gateway and DNS list by hand and see if that allows you to connect. And I would spend some time looking at the logs and see if the card is complaining when it starts up.

Anything in the logs? in dmesg?

Have you tried turning on the SSID broadcast to see if it helps? (Turning it off is not a security feature)

Maybe try unloading the MadWiFi module and loading it manually to see if it errors (although anything there *should* show up in dmesg).

the logs don't report anything that shows the loading failed.

[root@localhost sbin]# cat /var/log/dmesg | grep "ath"
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
ath_rate_sample: 1.2
ath_pci: 0.9.6.0 (EXPERIMENTAL)
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: H/W encryption support: WEP AES AES_CCM TKIP
ath0: mac 5.9 phy 4.3 radio 4.6
ath0: Use hw queue 1 for WME_AC_BE traffic
ath0: Use hw queue 0 for WME_AC_BK traffic
ath0: Use hw queue 2 for WME_AC_VI traffic
ath0: Use hw queue 3 for WME_AC_VO traffic
ath0: Use hw queue 8 for CAB traffic
ath0: Use hw queue 9 for beacons
ath0: Atheros 5212: mem=0xe8200000, irq=201
[root@localhost sbin]#

I can connect to other SSIDs.
Unloading and reloading the module doesn't help

I will try changing to SSID broadcast settings when the network is unused again.

thanks

Amazingly, I have decloaked the network, and it works.

What could have cause this problem? Is it just because I was not broadcasting a beacon?

Clients expect the beacon to be there. Many people report that they cannot connect at all with WPA if the beacon is off. Some have trouble connecting even with WEP.

As I've said before, with apologies for repeating myself, SSID broadcast disable does no hide your wireless LAN. The radio signal and all of the details are still available. The only folks who may be blind to it are those with the crudest of tools and who would present no threat anyway.

Leave it on, let your neighbors know what channel you're on so that they can use another - if they're that aware. Many aren't, I know.

The folks at Netstumbler.org do suggest using cloaking for better security.
ftp://ftp.blackthornsystems.com/pub/WLAN_Sec_Home.pdf

You don't really see a cloaked network in kismet (or any passive sniffer) unless there is traffic, so it does offer some protection against wardrivers or bad-hacks who might sniff your area periodically. These are the folks to worry about, because for them wireless devices open up the door for anonymous electronic crime. Your neghbors are probably just interested in free internet... and if they're patient, yes, they will sniff your network if it it cloaked. Consider cloaking to be as effective as shrouding your house behind a lot of trees... most folks won't realize it is behind the trees, so most won't bother breaking in. (And, while all your neighbors do know where you live, you also know all your neighbors.)

(On the other hand, though, Netstumbler will pickup a cloaked network. But, it is not a passive tool. Then again, de-authentication attacks will illuminate a network with clients. Hmmm. Its a crazy world!)

Since doing so makes it appear to obscure networks to those using their tool, it makes sense that they would. A lot of people propagate this misconception. Doesn't make it right.

Not true. The network is displayed immediately. A probe attempt will reveal the SSID immediately. Except that the driveway and mailbox give you away, and the neighbor kid with time and intent might be the one to worry about.