aircrack taking way too long

[whiterabbit7500]

I'm in the beginning stages of a pen-test on a clients wireless network, and ran into a bit of an issue today I've never seen before. The client is running a WEP network, with no obvious special authentication or MAC filtering present, as I was able to authenticate and associate right away. There were no clients showing activity, so I proceeded to perform a clientless 0841 attack using aireplay-ng. I was capturing IV's just fine, and got to about 150k after about 30 mins, but aircrack was still unable to find the key. I've never run into this before, as all my WEP cracks have found the key after no more then 20 mins, even on WEP40. Any ideas what might be causing this need for so many IV's? I was no more then 30 yards away from the main building, and was receiving a decent strength signal.

[addyall]

Its possible that the WEP key is is longer than 128-bits. When running aircrack-ng on the cap file try the -K argument. I ran into a problem like a just described when trying it on a 256-bit key.

[TheLaw]

I have had this several times before.

What are the exact commands you are using with aircrack-ng?

[Gitsnik]

You could be dealing with some cisco kit - WEP-CKIP has caught me out in the past when I haven't had a reliable client connection to use.

[whiterabbit7500]

the thought crossed my mind, but from what I've seen from this client so far, they don't have any sort of organized IT structure to implement something like that. Unfourtunatly, it's a black-box job, so I need to figure out as much as possible without asking them directly for the info. I tried going again today using my hawking/cantenna setup, but the opposite happened, as I received a much better signal, but got a VERY slow IV stream, only about 50-60 per minute.

edit: Nevermind, after a quick refresh via google, it probably is CKIP giving me problems. Whats a workaround for this protocol, if any? I know it's more or less a evolution of LEAP, so would LEAP cracking tools work?

[Gitsnik]

TBH I've never looked into a workaround for it. I did always find it strange that it wasn't covered in the OSWP, so perhaps it's just not considered wide spread enough. Every time I encounter it, one either has a client to work with, or makes use of a second access point on the same network (assuming the infrastructure *has* two access points).

A quick skim of this may prove useful, but YMMV.