WEP key wrong and static IP address setting

Hi,

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.

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?

Thanks.
Bin

 

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 www.google.com" 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
(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.

 

~ > 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

 

Aaron Leonard дµÀ£º

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?
http://www.microsoft.com/technet/network/wifi/wlansupp.mspx

 

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:
<http://support.microsoft.com/kb/894568>
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.

 

~ > ~ > 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?