WEP key wrong and static IP address setting

Discussion in 'Wireless Internet' started by Bin Chen, May 9, 2007.

  1. Bin Chen

    Bin Chen Guest

    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
     
    Bin Chen, May 9, 2007
    #1
    1. Advertisements

  2. Bin Chen

    barry Guest

    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
     
    barry, May 9, 2007
    #2
    1. Advertisements

  3. 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
     
    Gordon Montgomery, May 9, 2007
    #3
  4. Bin Chen

    barry Guest

    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
     
    barry, May 9, 2007
    #4
  5. Bin Chen

    Bin Chen Guest

    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.
     
    Bin Chen, May 10, 2007
    #5
  6. 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
     
    William R. Walsh, May 10, 2007
    #6
  7. 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
     
    William R. Walsh, May 10, 2007
    #7
  8. 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
     
    Aaron Leonard, May 15, 2007
    #8
  9. Bin Chen

    Bin Chen Guest

    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.
     
    Bin Chen, May 15, 2007
    #9
  10. ~ > 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, May 15, 2007
    #10
  11. Bin Chen

    Bin Chen Guest

    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?
     
    Bin Chen, May 16, 2007
    #11
  12. Bin Chen

    kev Guest

    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
     
    kev, May 16, 2007
    #12
  13. 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.
     
    Jeff Liebermann, May 16, 2007
    #13
  14. ~ > 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
     
    Aaron Leonard, May 16, 2007
    #14
  15. Bin Chen

    Bin Chen Guest

    Thank you! This is what I want, I will check this soon. ^&^
     
    Bin Chen, May 17, 2007
    #15
  16. Bin Chen

    Bin Chen Guest

    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.
     
    Bin Chen, May 17, 2007
    #16
  17. ~ > ~ > 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
     
    Aaron Leonard, May 17, 2007
    #17
  18. Bin Chen

    Bin Chen Guest

    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?
     
    Bin Chen, May 18, 2007
    #18
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.