WEP key wrong and static IP address setting

Don't get hung up on "connected". What matters is that your client associates with AP, has full, workable IP config, and has its packets routed properly.

In manually setting IP, you're ignoring all the other stuff the DHCP server on the AP would be providing: netmask, gateway, dns servers, mostlikely domain-name.

You can check the full IP config., etc. in Windows (which version/SP, please?) with winipcfg (GUI) or at shell "ipconfig /all". If that passes muster, then "tracert

" or some other hostname would tell you much about how it's talking with the world. They are easily researched, and left as an exercise.

Meanwhile ... why not just enter the same key? And make it a _good_ one: long, melange of do-do with WPA. Few or no words found in dictionary is a starter. Don't waste your time with WPA, most especially if you're in an area of any population density.

HTH, J

I think what he is trying to say is that if the WEP key is mis-typed, but they use static IP's, there is no real connectivity ( packets don't flow) but the PC believes the AP is connected. As a matter of course, I always re-type the WEP keys just to make sure I have typed them in correctly, but I also always use DHCP. Is there any reason not to use DHCP? Most AP's have simple DHCP servers built into them.

Gordon

Gordon Montgomery Living Scriptures, Inc snipped-for-privacy@lsi.com (anti spam - replace lsi with livingscriptures) (801) 627-2000

Got me. Don't want to interpret, rather ask for restatement, whatever.

Belief really not relevant here. :') "Just the facts, ma'am" said Friday. I'd only manually configure IP if I were sure of what I'm doing, and test, test, test. Else, if DHCP server is properly configured, I'd have it do all client config, period. Same as at work. Great stuff.

It always helps to study and understand things- part of what I was indicating to OP. Else it's random poo.

J

Gordon got the idea of me. Things it not that simple. I am a software programming that produce the wifi connection tools. My customer is not smart as you all here who knows when the connection inactive its needed to check the WEP key. They don't know this and will only complain to us when they enters a wrong WEP key but with a static IP.

I don't want to get the answer of "guess by people, and try". Even ping some internet host is not feasible, because "connected to AP" doesn't necessarily means "connected to internet".

I need to find a general way to effectively reduce the customer complains, is it any way to get some infomation from the 802.11 frame to catch the fact that something is probably wrong. With WPA, I can get the infomation now for the MAC layer frame.

Again, don't give me the naive answer because I am asking a really technical question here.

Hi!

That's what seems to happen on this end. If I deliberately mistype my security keys, there seems to be a connection established. Of course, nothing flows over it.

Yes, in some cases. Assigning static IP addresses to things like printers, network attached storage devices and anything else you don't want to be a "moving target" on your network is a good idea. With DHCP doling out addresses, devices may not always get the same address. This depends upon the implementation of the DHCP server your AP/router uses. Some assign the same address (my old Microsoft AP did this) based on MAC (hardware) addresses. Others assign random addresses using whatever addresses are currently listed as being unoccupied. Still other devices (the DD-WRT firmware can be configured this way) are configurable to whichever behavior you'd prefer.

Sometimes DHCP won't work. I have a bunch of Token Ring clients on my network that are connected to the Ethernet network using an IBM 8229 LAN bridge. DD-WRT simply won't supply IP addresses to these computers, so I have to set them manually. (Why this is I don't know...computers with TR that are running Windows XP *do* get IP addresses, but all other systems don't.)

William

Hi!

Not to discount your question, but maybe some training of the users is in order. They should have some basic understanding of what is going on. If they do not, they will be in trouble more often than not and unable to do anything at all to fix the problem or possibly even report it.

If wireless security is not needed, then turn it off. That should solve the problem, and nobody will have to know anything about security.

If wireless security is needed (and it is a good idea to have it on anyway), consider creating a connection profile using the connection management software included with your wireless hardware or operating system. This should store the settings and maintain them. The users then won't need to know anything unless the software completely loses its mind or is removed/reinstalled.

William

Hi Bin,

~ In Windows, if AP A's WEB key is 1111111111, but I input the WEP key ~ to 2222222222 and set the IP address to static , say 192.168.1.3. The ~ windows will connect to AP A, and it reports connect successfully. But ~ obviously, the data can't transfers.

Yes, if you have configured 802.11 open authentication with static WEP, you can and will get into this situation.

~ This makes software designers very hard to junior users who don't know ~ why 'connected' but can't transfer data. Is there way to optimize ~ this?

You can monitor your wireless adapter stats. If decrypt errors are incrementing after 802.11 open authentication/association succeeds, then it's a good bet that you are dealing with a WEP key mismatch.

Well, you can use shared key authentication instead of open. This will prevent you from doing a successful 802.11 authentication, if the static WEP keys don't match.

Some will note that shared key WEP is even easier to crack than open with static WEP. The rejoinder to which would be: don't use WEP at all, use WPA.

Aaron

I doubt how can you get the stats about the decrypt errors? The hardware can only decrypt the data and throw it up to the various stack, it's up to the stack to see is it the data valid. But if you can't get the IP from the AP, who will send you the data to let you check whether it is decrypt error?

So it is impossible.

~ On May 15, 7:13 am, Aaron Leonard wrote: ~ > Hi Bin, ~ >

~ > ~ In Windows, if AP A's WEB key is 1111111111, but I input the WEP key ~ > ~ to 2222222222 and set the IP address to static , say 192.168.1.3. The ~ > ~ windows will connect to AP A, and it reports connect successfully. But ~ > ~ obviously, the data can't transfers. ~ >

~ > Yes, if you have configured 802.11 open authentication with static WEP, ~ > you can and will get into this situation. ~ >

~ > ~ This makes software designers very hard to junior users who don't know ~ > ~ why 'connected' but can't transfer data. Is there way to optimize ~ > ~ this? ~ >

~ > You can monitor your wireless adapter stats. If decrypt errors are ~ > incrementing after 802.11 open authentication/association succeeds, ~ > then it's a good bet that you are dealing with a WEP key mismatch. ~ ~ I doubt how can you get the stats about the decrypt errors? The ~ hardware can only decrypt the data and throw it up to the various ~ stack, it's up to the stack to see is it the data valid. But if you ~ can't get the IP from the AP, who will send you the data to let you ~ check whether it is decrypt error? ~ ~ So it is impossible.

I wouldn't say "impossible".

If you have an API into your wireless adapter's stats, then it may be able to give you access to the decrypt error counters.

There is still an open question as to whether the AP will attempt to send the client any data, after the client associates, in order to trigger the decrypt errors.

I just now tested with a Cisco CB21AG card talking to a Cisco AP, with a mismatched WEP key ... I see that the card is logging a decrypt (or, as it puts it, "Encryption") error every 30 seconds or so.

If you do not have an API into your wireless adapter and do not have access to the AP's control plane, and if you cannot configure shared key authentication, then I agree, you will not know that you are experiencing a WEP key mismatch.

Aaron

What did the wrong encrypted packet come from? And as I stated the underlying hardware can't know whether the data is valid or not until it sends to up layer, so how can it log the decrypt event?

Have you tried enabling the wireless logs to see what information is gathered when this happens?

Bin Chen hath wroth:

It really depends on Microsoft definition of "connected". To the average user, connected means that you're done and that everything wireless should work. To Microsoft, it means that you have successfully found the proper SSID and successfully established an association with an access point. Now, you're ready to exchange encryption keys and authentication data. The problem is that Microsoft wireless zero config and many connection managers do not offer connection progress information. You get the "connected" message, followed by "obtaining DHCP...", where it sits for a while until it times out. Not very user friendly as there are many steps in between the initial "connect" and where it actually obtains a DHCP IP address. Worse, if you setup a static IP address on the client, you get no "obtaining DHCP..." message. It just sits there with "connected" on the screen, while it's merrily doing something else in the background.

I've been told that the reason for the lack of encryption and authentication status is that that this information is not available in the NDIS 5 drivers. I have not verified this information, but my attempts to find such data was unsuccessful.

To correct this problem, Microsoft would have had to read the IEEE-802.11 and change the "connected" term to the more proper "associated with..." term. It would also need to have added connection progress status. There was quite a bit of work done on Vista to fix various wireless issues, but supplying useful information to the user was not included. Maybe the next service pack or whatever.

Please note that some connection managers, such as Intel Proset, have copious diagnostics, logging, and connection progress indications.

As others have noted, Microsoft does offer WZC logging, which should show any connection problems. The problem with this approach is that it generates far too much logging information. A simple WEP connection log might be several hundred lines long. It's in there, somewhere. Also, the troubleshooting article does not cover driver issues, which are all too common. Driver tracing increases the number of log files to dig through substantially. See:

for a list.

Incidentally, WEP sucks. Use WPA or WPA2.

~ > I just now tested with a Cisco CB21AG card talking to a Cisco AP, with ~ > a mismatched WEP key ... I see that the card is logging a decrypt ~ > (or, as it puts it, "Encryption") error every 30 seconds or so.

~ What did the wrong encrypted packet come from?

The AP transmitted an 802.11 frame to the client that was encrypted with the "wrong" (from the client's standpoint) WEP key.

See 802.11-1999 sec. 8.2.3 for how the incoming frame is decrypted in WEP. If the calculated ICV (ICV') does not match the ICV received in the frame, then "the received PMDU is in error and an error indication is set to MAC management".

Now look in Appendix D for the dot11WEPUndecryptableCount counter. If you watch this, you will see it increment, if you have a WEP key mismatch *and* if the AP should happen to send a data frame to you (which I don't believe you can count on happening, however.)

~ And as I stated the ~ underlying hardware can't know whether the data is valid or not until ~ it sends to up layer, so how can it log the decrypt event?

Not true. The underlying hardware does implement the WEP decrypt function, so it can log the decrypt error accordingly.

Aaron

Thank you! This is what I want, I will check this soon. ^&^

Confirmed, it is true!

Yes, the problem is that I can't count on such packets happening, but I wonder when it is happening, what packets will send to the station using the right WEP key? If it will send this, an attacker can easily get the 'sample' by only one time and use this 'sample' to do the brute force crack, it is more dangerous, I think.

~ On May 17, 2:50 am, Aaron Leonard wrote: ~ > ~ > I just now tested with a Cisco CB21AG card talking to a Cisco AP, with ~ > ~ > a mismatched WEP key ... I see that the card is logging a decrypt ~ > ~ > (or, as it puts it, "Encryption") error every 30 seconds or so. ~ >

~ > ~ What did the wrong encrypted packet come from? ~ >

~ > The AP transmitted an 802.11 frame to the client that was encrypted with ~ > the "wrong" (from the client's standpoint) WEP key. ~ >

~ > See 802.11-1999 sec. 8.2.3 for how the incoming frame is decrypted in WEP. ~ > If the calculated ICV (ICV') does not match the ICV received in the frame, ~ > then "the received PMDU is in error and an error indication is set to ~ > MAC management". ~ ~ Confirmed, it is true! ~ >

~ > (which I don't believe you can count on happening, however.) ~ ~ Yes, the problem is that I can't count on such packets happening, but ~ I wonder when it is happening, what packets will send to the station ~ using the right WEP key? If it will send this, an attacker can easily ~ get the 'sample' by only one time and use this 'sample' to do the ~ brute force crack, it is more dangerous, I think.

If you're worried about a "brute force crack", then you should't use WEP at all.

Aaron

Got it, thank you. And can you answer me the question that when the AP will send right encrypted data to the associated but wrong WEP station, whats data will be send?