Airdrop-ng lorcon error

Hey

Can anyone help or has any ideas to my problem.
I installed Airdrop and am Running Bt4 final,2 wireless cards,one im using for injecting is alfa awus306h.

Followed the instructions,it worked perfect the first time no problem,knocking off my other laptop connection as it should.

But now when i try to repeat the process im faced with this error:

Code:

---

Error Message from lorcon:
Failed to set channel 138 22:Invalid argument
Unable to set channel card does not seem to support it
Skipping packet

Sent 4 packets 1 times each
Waiting 0 sec in between loops

Rule Number 1
d/00:0F:XX:XX:BE:D8|00:1A:XX:XX:94:2F
{'raw': 'd/XX:XXCC:60:BE:D8|00:1A:XX:XX:94:2F', 'state': 'd', 'clients': ['00:1A:XX:XX:94:2F'], 'bssid': '00:0F:XX:XX:BE:D8'}
Deny 00:1A:XX:XX:94:2F client to XX:XX:XX:60:BE:D8 bssid


Attempting to TX 4 packets 1 times each

Error Message from lorcon:
Failed to set channel 138 22:Invalid argument
Unable to set channel card does not seem to support it
Skipping packet

Error Message from lorcon:
Failed to set channel 138 22:Invalid argument
Unable to set channel card does not seem to support it
Skipping packet

---

some packets are getting through but 70% of them are not which makes the deauth unsucessfull.

Anybody any ideas?

Thanks
Awesome tool btw well worth checking out.

***** Problem has seemed to iron itself out,i think intial problem was caused by the airodumps output csv.

It looks like it was trying to set to channel 138 which of course wont work..

I can only imagine that the airodump bug was causing channel 138 to be seen and that airdrop was
trying to apply a rule on it.

Suppose you could try filtering the airodump output down to the network you are looking at specifically before running
airdrop and see if that removes the issue.

Of course that may limit the scope of airdrop depending on what your plans were !

I've also had this before, and I believe it's because the AP isn't in your card's range. maybe the client is, but the AP needs to be aswell to succesfully deauth the client. airodump cannot determine the correct channel the AP is using, and posts strange channels like 110,138,.. and tells airdrop to use those channels, which aren't correct so it fails.
try a simple injection test on that AP, then you'll know.

L

What is your command?

Code:

---

root@bt:/pentest/wireless/airdrop-ng# python airdrop-ng.py -b -i mon0 -t /root/petest-01.csv -r /root/rules

---

in rules file is and I allow ZyXEL1 cause its where Im connected

Code:

---


a/ZyXEL1|any
d/any|any

---

cheers for the feedback guys.
I dont it was a issue in regards range of AP Lucifer,as i was pretty close.But the issue did resolve itself and works fine now.

I would probably agree with what =TAPE= said

Quote:

---

It looks like it was trying to set to channel 138 which of course wont work..

I can only imagine that the airodump bug was causing channel 138 to be seen and that airdrop was
trying to apply a rule on it.

---

As i was pretty sure it was a problem with Airodump .csv output and not Airdrop as otrginally thought.

Thanks

Pieface

yes ofcourse it's the csv that was wrong, airodump couldn't determine the correct channel, and this could've been caused by being too far away from the ap, or like tape said, due to a bug.

grtz, .L