Has anyone had this problem?:
My wireless signal works great EXCEPT when I enable 128 Encryption keys. Once I do this I can connect to the Router, but am not able to ping back to it. Therefore cannot connect to the internet and browse.
Once I disable and then reconnect back to the router, I can ping back to the router. Therefore I can connect and browse fine.
What gives...any suggestions?
Ron
What type of wireless adapter are you using?
The WIFI alliance that certifies interoperability of devices does not include testing of 128 bit wep encryption, only 64. So if you have a device brand A access point and device brand b wireless adapter there is no guarantee they will work together at 128.
Actually, it turns out there are different "standards" for converting ASCII to Hex WEP keys, so if your AP and client radio drivers are different brands, you might want to use HEX in both places...
Maybe D-Link?
Nothing, but if they aren't exactly the same, they aren't going to match up. Making a random 128-bit key is easy enough that I've never bothered with passphrase generation, and I don't reccomend it due to some chance of incompatability.
Yes.
What version BEFW11S4? It's on the serial number tag. Extra points for supplying the firmware version. Points taken away if you have an obsolete revision firmware.
Suggestion: Kindly disclose what client radio you're using.
Assuming you did everything right (like type in the proper WEP key), the usual problem is the LENGTH of the WEP key. Some clients require that the ASCII WEP key be exactly 5 characters for 64 bit WEP and exactly 13 characters for 128 bit WEP. No more, no less. Apple requires that one preface the WEP with some cryptic symbol to identify the key as hexadecimal, in addition to making it exactly the right length. One vendor (name forgotten) simply truncated extra long WEP keys so that it was impossible to guess the correct corresponding WEP key. Anyway, try exactly 13 ASCII characters or exactly 26 Hex characters.
I beg to differ. When this came up in the past, I did a quick check of online and firmware based ASCII to Hex converters. I found one that screwed up by adding a null terminator to the Hex string. Another would truncate at 5 or 13 characters and automagically guess if it were 64 or 128 bits. All the others converted with a simple ASCII character to Hex character conversion. One ASCII character equals two Hex characters. There's only one way to do that. I mean what could be simpler?
In article , Jeff Liebermann wrote: :I beg to differ. When this came up in the past, I did a quick check :of online and firmware based ASCII to Hex converters. I found one :that screwed up by adding a null terminator to the Hex string. :Another would truncate at 5 or 13 characters and automagically guess :if it were 64 or 128 bits. All the others converted with a simple :ASCII character to Hex character conversion. One ASCII character :equals two Hex characters. There's only one way to do that. I mean :what could be simpler?
Fix WEP key passphrase generation. Certain passphrase genarates the wrong keys.
I'm not sure if it's the same issue or not, but there was at least one device that took the user passphrase of non-fixed length and ran it through an algorithm (e.g., CRC or MD5 like functions) to generate the
64 bit hex key, to save the user from having to enter stuff in hex. There was, though, a flaw in the initial version that caused it to only be able to generate a subset of the possible octets, with the result that the generated keyspace was *much* smaller than it should have been. [I suspect that it was indeed Linksys and that the above shows when it was fixed.]
Groan. Another one. I wasn't aware of that bug.
I don't think too many vendors "randomize" the WEP key. However, I don't see these because all of my WEP keys are in currently in Hex, where no conversion is necessary. I started doing that after wasting a few hours doing battle with a Linksys WAP11 (unknown version) trying to get a compatible WEP key. I then repeated the time burner with a MR814v1 and a Toshiba laptop with some unknown Centrino 802.11b/g card. Hex always works. ASCII screws up. At the time, I wasn't in the mood for diagnosing the cause and assigning the blame, so I just started doing everything in Hex.
Rhetorical question: How can any vendor screw up something so simple?
There are different ways to generate a WEP key from a *password*. It was a mistake to introduce the whole "password" business into wireless encryption. It only created greater complexity and confusion in the name of simplification.
No longer. Apple formerly required a $ to preface hexadecimal keys, but all that is now handled by a pop-up menu. See .
One down, one to go. Do you know if Apple still insists that the ASCII keys be exactly 5 chars (64bit) and 13 chars (128bit) long? The examples in the above article are all exactly 5 and 13 chars long. Never mind, I found it:
Argh. I've been using hex for too long to notice what's happening with the ASCII to Hex conversion game. Orinoco uses straight ASCII characters to Hex conversion. Everyone else seems to be using some type of hash code generator. I'm not sure about the algorithms used but I do have some clues:
ASCII to Hex generator Perl script:
I checked on an SMC, and a Netgear router, maybe Linksys, but I forget. I keyed in abcde for the string on a 64 bit key. None of the hex keys generated (four keys displayed on each router) looked like 61 62 63 64 65. Isn't that straight ASCII-Hex? What other conversion would you apply?
Ahh, print "using common wifi driver algorithms.nn";
Someone else indicated that it was a "password". Therefore the hex is an encryption of your password. I put in the hex to my SMC router and my Orinoco card, which under WinXP didn't seem to have a place for text anyway, saw that it gave me a 30% performance hit according to iperf, and turned it off.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.