It didn’t take too long to compile and install kernel 2.6.30-1 on the Aspire One. I didn’t apply any patches, just vanilla sources. After I installed and rebooted, I looked at a few things. More on that in a second because after I looked at those things I looked at the kuki Linux site and saw they had 2.6.30-1 with a few patches including one I want: acerhfd to better control the AA1 fan. (Edited: My vanilla kernel has LED.)
After I installed it, I looked again at those things I mentioned before. Here’s the one thing that I found interesting.
Under my kernel, I saw that the first AP I associated with was my own. Under the kuki kernel, it went to the unencrypted SSID I’ve mentioned before. And under kuki it did a bit more. Under the generic Ubuntu kernel in crunchbang, there were only a couple attempts to associate with that AP. This kernel is like the fucking Energizer bunny: it just keeps going.
wlan0: direct probe to AP xx:xx:xx:xx:xx:xx try 1 wlan0: direct probe to AP xx:xx:xx:xx:xx:xx try 2 wlan0 direct probe responded wlan0: authenticate with AP xx:xx:xx:xx:xx:xx wlan0: authenticated wlan0: associate with AP xx:xx:xx:xx:xx:xx wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: associate with AP xx:xx:xx:xx:xx:xx wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x401 status=12 aid=0) wlan0: AP denied association (code=12) wlan0: associate with AP xx:xx:xx:xx:xx:xx wlan0: association with AP xx:xx:xx:xx:xx:xx timed out wlan0: authenticate with AP yy:yy:yy:yy:yy:yy wlan0: authenticated wlan0: associate with AP yy:yy:yy:yy:yy:yy wlan0: RX AssocResp from yy:yy:yy:yy:yy:yy (capab=0x431 status=0 aid=4) wlan0: associated
x=neighbor’s
y=mine
I didn’t believe that the first time I saw it so I rebooted into each kernel. This is my third time switching between them and it holds true so far. When my kernel booted, it didn’t try to associate with anything but my own router — which is how it should work. When the kuki kernel is running (as it is right now), it keeps trying to associate with that other one, even more times than under the stock Ubuntu/#! kernel.
I don’t know if the difference between the kuki kernel and mine is just coincidence or if there’s some issue between patched kernels and vanilla that might have something to do with what I’ve been complaining about how it’s been trying to associate with an AP other than what’s specified in the relevant wireless configuration (which right now is still NetworkManager — and which I thought might have more to do with this).
For what it’s worth, my fan is running non-stop still even though lsmod shows acerhfd is loaded (along with some crypto modules I’ll need to blacklist). That fan module is the primary reason I’m using the kuki kernel right now. If I continue to see the same AP issues described above, I’m switching back to the vanilla kernel until I can figure out wtf is happening — and why.
PREVIOUS REFERENCES TO ISSUE:
http://lucky13linux.wordpress.com/2009/07/12/oh-no-not-again/
http://lucky13linux.wordpress.com/2009/07/11/getting-ready-for-crunchbang-de-bloat-etc/
http://lucky13linux.wordpress.com/2009/07/10/crunchbang-more-jwm-screenshots/
http://lucky13linux.wordpress.com/2009/07/10/crunchbang-update-jwm-aterm-acpiwifi-issues-and-office-software/
UPDATE1: Maybe it’s not the kernel after all. I removed the kuki kernel and booted my own for about the fifth time. This time it showed a pattern more similar to the generic/default kernel:
[ 28.717834] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 30.585365] wlan0: direct probe to AP xx:xx:xx:xx:xx:xx try 1 [ 30.784127] wlan0: direct probe to AP xx:xx:xx:xx:xx:xx try 2 [ 30.984132] wlan0: direct probe to AP xx:xx:xx:xx:xx:xx try 3 [ 31.185114] wlan0: direct probe to AP xx:xx:xx:xx:xx:xx timed out [ 129.061657] wlan0: authenticate with AP yy:yy:yy:yy:yy:yy [ 129.063526] wlan0: authenticated [ 129.063540] wlan0: associate with AP yy:yy:yy:yy:yy:yy [ 129.065835] wlan0: RX AssocResp from yy:yy:yy:yy:yy:yy (capab=0x431 status=0 aid=4) [ 129.065852] wlan0: associated [ 129.067151] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
That’s from the last boot with the generic/default kernel from #!. There’s no difference between that and what my vanilla kernel just did except sequence numbers.
Back to square one.
UPDATE 2: I booted into Windows (yea, it’s Patch Tuesday!) and then back into #! (which had its own Ubuntu patches today in addition to new kernels and my own upgrade of libmtp), and checked again. This is what I’d been seeing earlier — no attempt to authenticate with the other AP.
[ 47.750281] wlan0: authenticate with AP yy:yy:yy:yy:yy:yy [ 47.751795] wlan0: authenticated [ 47.751805] wlan0: associate with AP yy:yy:yy:yy:yy:yy [ 47.754153] wlan0: RX AssocResp from yy:yy:yy:yy:yy:yy (capab=0x431 status=0 aid=4) [ 47.754168] wlan0: associated
Look, no xx:xx*. Just mine. Like it SHOULD do every fucking time.
Nothing like consistency, eh. Five boots with my own kernel and only one boot did it try to associate with any other AP; four boots with kuki kernel and all four with extracurricular association attempts; every boot with the stock kernel associates with the other AP if it’s available.
I’m giving up for tonight.
