Notices

Happy to help.

BTW, did "dpkg -l | grep aircrack-ng" return one or two results? It's quiet likely you had both "aircrack-ng" and "aircrack-ng-1.1" or something like the latter installed. If so it would explain where the extra binaries came from. (That's where all the aircrack-ng packages would put the binaries into until I took over maintenance and figured out how to change install paths.)

At any rate, if that's the case I suggest removing all the 'extra' aircrack-ng binaries from /usr/local/bin and /usr/local/sbin - they're most likely going to be much older versions.

Good luck with your work on fAircrack

Yep, I got two results, the second one was for aircrack-ng 1.0.3, which I have since removed from the /usr/local/bin/ path. . The "which aircrack-ng" command provided the answer that you expected, however the program when called with sudo went to the older version (which was the reason for this whole discussion on your thread). Anyway, it's fixed now, and anybody else with the same problem has a solution mapped out here.

Greetz traceur.

It would seem that airmon-ng is totally brorken. This is because airmon-ng relies upon some switches for 'ps' that are not available for busybox or BB power.

There are only two ways (that I can think of) to fix this problem.

1. Package full-fat ps from debian lenny armel and make aircrack-ng depend on it.

2. Rip airmon-ng apart and make it specific for the n900. Airmon-ng is a generic tool designed to put any card into monitor mode. Thus it has a lot of hardware 'detection' and failsafe routines. The n900 has 1 card. There is only 2 ways to put it into monitor (iw or iwconfig (probably more)). Thus airmon-ng can be modified to be n900 specific.

If you have any interest in updating aircrack-ng I will start on the latter if you cannot be assed with the former (which would be the better solution (less chance of future breakage)).

Hey, and my apologies that I'm just now seeing this.

Are you sure this is still the case? I don't remember ever having issues setting the wlan0 interface into mon0 mode using 'airmon-ng start wlan0', nor killing the mon0 interface using airmon-ng stop mon0'. I just tested it currently, and it still works, and I remember using it on/off over the last half-year without any issues.

So, what exactly did you mean by broken? That it was printing flawed output (I wouldn't know that, as I've only ever used aircrack-ng suite on my N900s)? Or are there use-cases where it fails to create the mon0 interface successfully?

Whats up on the project??
Fixes updates new features

So I realized a while back that what vi_ meant up above was that the output from ps as executed by airmon-ng, while never giving me issues starting/stopping interfaces, is broken. I also saw someone gave me a patch 2 years ago in the garage page for aircrack-ng, fixing just that thing, so I'm going to take a look at finally fixing that sometime.. in the next month. Besides that last I checked (not too recently) nothing else exciting happened in aircrack-ng upstream world. I'm expecting to have more free time in another month or two, which is when I hope to at least for a while come full steam back into my projects in this community.

Edit: Oh god I just realized posting in this thread for the first time in ever with nothing new to show for it will just get everyone's hopes up and then dash them when they see it was bumped up.

Seems aircrack-ng is still alive, they're pushing 1.2 beta's. It's expected to have one more beta and then 1.2 final. Any chance to get the 1.2beta3 already in the devel repos?
And then when final arrives to get that thing to testing?

Alright, I'm finally taking a look at this.

I was initially going to just go ahead and grab 1.2-rc1 and push that. However, I noticed something interesting:

http://trac.aircrack-ng.org/ticket/1362 <-- Apparently upstream discussions about the broken-ness of their 'ps' usage actually happened. Yay, upstream cares about portability.

So you'll notice in the bottom comment, it says how airmon-zc is going to replace airmon-ng in the future (milestone 1.3). Well, if we take a look at the 1.2-rc1 code, it does not look like either airmon-ng nor airmon-zc are actually improved/patched. But, if we take a look at the svn trunk, we see that airmon-zc is missing, airmon-ng has seemingly been replaced with extensively modified contents of airmon-zc, and it actually has a bunch of checks for compatibility with busybox's ps and other tools. Great.

So now I'm considering just going ahead and pushing the current trunk revision to -devel. (Yes, it might break - that's what -devel is for.) This should in theory fix our nagging busybox ps problem. BUT, this move will force us to bring in another dependency: ethtool. So I'm going to go ahead and package that up for the repos as well, and test that out first.

So that's where we are at.

P.S. [rant]
I've spent a lot of time writing shell scripts, and nowadays, whenever I look at other people's shell scripts, I want to cry. For example:

Why does everyone use FOO_BOOL=1 or FOO_BOOL=0 followed by tests like:
if [ $FOO_BOOL = 1 ]
in their shell scripts, when the following is much more clean and elegant and requires the shell to do less work:
FOO_BOOL=true or FOO_BOOL=false
..followed by
if $FOO_BOOL
[/rant]

[edit1]ethtool has been successfully built by the autobuilder, now we just wait until it gets popped into extras-devel itself. Notably, my testing with the ethtool packaged in Debian Sid earlier, ethtool complained about our wireless driver being strange/unknown, BUT nonetheless, it seemed to work fine - then again, that might be like how busybox ps 'worked fine' with our airmon-ng. It still put stuff into monitor mode correctly, just failed some of its internal checks... Point being, we may have a similar situation on our hands. In the meantime: I've been trying to upload the new aircrack-ng to the autobuilder, but it keeps complaining about the tar file for some reason. Not sure what's up with that.[/edit1]

Ran into a build issue with various macros not defined that the newer libc6 includes, but ours in the autobuilder doesn't. So, there will be a delay while I figure out how to proceed.

Alright, here's where I'm at.

First issue was it complaining about le16toh, le32toh, being undefined. Turned out they had included their own header with the relevant functions defined for compatibility for Android - so with that out of the way it at least builds (whether or not it will run correctly, now that I'm not so sure about, but one can hope. If not, I can painstakingly copy in the relevant pieces of endian.h and dependencies from a more recent glibc/eglibc out of the Debian armel libc6-dev package, and hope that will work). So I think that's a resolved-enough problem.

Second issue, and I'd like someone who knows more about this to chime in. These are undefined:
NL80211_CHAN_NO_HT
NL80211_ATTR_WIPHY_FREQ
NL80211_ATTR_WIPHY_CHANNEL_TYPE
..normally they ought to be defined in linux/nl80211, and I'm not quite sure if I'm just being dumb and not including the right package for build-depends, or if our 2.6.whatever kernel is too old to even have those. I know some NL80211 stuff is new in the 3.* line of Linux kernels, just not sure if all of it, or the parts we need, are.

If there's no headway on this for a while, I'm going to instead try to build the 1.2-rc1 version instead of the latest trunk revision, and if that's successful, I'll try to just package the newer airmon-ng (formerly airmon-zc) script in place of the less portable, not-busybox-ps-handing variant still in 1.2-rc1.