ath5k: monitor/promiscuous mode broken with channel hopping

[undefined]

ubuntu 10.04/"lucid lynx"
i386
linux-image-2.6.32-23-generic 2.6.32-23.37

ath5k sees LLC, but not data, packets when channel hopping in monitor/promiscuous mode (eg kismet, airodump).

start of email thread on linux-wireless (bug report -> diagnosis -> patch)
http://www.spinics.net/lists/linux-wireless/msg50910.html

corresponding patch in recently released 2.6.32.16
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=commit;h=0a1a8d8443d8deeb30985b531f34542c97c095a6

i looked in the most recent (2.6.32-24.38) changelog and didn't see any applicable references to "ath5k", so i presume this bug has not been fixed in a proposed update.

i figure this is a low priority bug/patch (except for us white/black hats), but consider this bug report my vote for inclusion in lucid's kernel and the above linux-wireless email thread another ubuntu user's vote (ie "The 2.6.32 kernel shipped in lucid never sees data packets.").

thanks for maintaining the linux kernel in ubuntu!

[Jeremy Foshee (jeremyfoshee)]

Hi undefined,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/daily/current/ . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 602795

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[undefined (undefined)]

my apologies if i seem a bit miffed, but after researching the bug, tracking the issue upstream, all the way to a 2.6.32-stable release, and including all that information in the original bug report, it appears my bug report wasn't even read as all i get is an automated message saying:

 * i need to test the problem in the current maverick build, but maverick is using 2.6.35 (not lucid's 2.6.32), you're not going to backport the driver from 2.6.35 to 2.6.32 (as i already included a link to the patch), and i'm not going to upgrade from a recently released LTS (lucid) to an unreleased non-LTS to fix this well-documented problem.
 * i need to rebuild the kernel myself to help upstream debug the issue, but upstream is already aware of the issue (see linux-wireless email thread referenced in original bug report) and has even provided a patch (see git commit to 2.6.32-stable in original bug report).

i would understand if this bug was undiagnosed, a fix was unknown, and/or upstream was unaware, but none of that is the case. instead all the work has been done and all ubuntu needs to do is prioritize the bug/patch and decide whether to include it in a future kernel package (or prove my research into the recent lucid proposed-update kernel package wrong due to ubuntu's lack of detail in the changelog and i'll test it). i will be happy to test a proposed-update to insure it fixes the problem, or if absolutely necessary to convince ubuntu to include the patch, then i'll build and test the kernel myself (current ubuntu kernel source + upstream patch), but i think it is a disservice to contributors to send them on unnecessary tangents (testing a daily build which doesn't even include the same kernel version and building an upstream kernel when upstream is fully aware of and has already resolved the problem) with an automated message.

if ubuntu does not consider this upstream bug/patch important enough to include in a LTS release, then simply say such and avoid the automated, unnecessary user requests.

nonetheless, thank you for maintaining the linux kernel package in ubuntu.

[Weedy (weedy2887)]

+1

Flip a coin and include or close this bug.

[undefined (undefined)]

the previously referenced patch applied cleanly to linux-source-2.6.32 2.6.32-23.37 and the resulting kernel package (built on lenny amd64 in a lucid i386 pbuilder chroot with kernel-package 12.032 and the .config from linux-headers-2.6.32-23-generic 2.6.32-23.37) fixed my problem (i ran kismet overnight and not only picked up LLC packets, as before, but data packets too).

so, in short, both weedy and i have shown that the bug exists in lucid and that the upstream patch fixes the problem (specifically the latest kernel source in lucid-updates, though i know 2.6.32-24.38 exists in lucid-proposed, but based on its changelog, there's no reason this shouldn't apply there).

btw, my hat goes off to weedy for his work with upstream in isolating the bug (eg bisecting) and testing the patch.

[undefined (undefined)]

this bug was fixed in 2.6.32-25.44, which included patches from the upstream stable 2.6.32.16, and was documented in bug #607824.