[LOM]

I don't understand why the option driver binds to if#1. It should not.

The option driver for kernel 3.1.0 did not include 12d1:14cf so it is either due to using option+new_id (binds to all interfaces except storage) or a wrongly modified and recompiled option driver.

[bmork]

I don't understand why the option driver binds to if#1. It should not.

The option driver for kernel 3.1.0 did not include 12d1:14cf so it is either due to using option+new_id (binds to all interfaces except storage) or a wrongly modified and recompiled option driver.

No version of the option driver includes 12d1:14cf.

But you're of course absolutely right: v3.1 didn't contain the class+vendor matching either, which is why this fails. That patch was added in v3.6 and the v3.1 stable branch had already been dead for a long time at that point. The patch is of course included in the longterm stable branches v3.0, v3.2 and v3.4.

Why would anyone want to use a v3.1 kernel?

[ab2005a]

Hi guys, thanks for the responses. To be honest though; I am completely lost. I guess the suggestion is to upgrade to a newer kernel. I will try that later today or tonight to see what happens, then report back.
I may as well explain that I use the 3.1 kernel because it is the only kernel with which I can successfully use my wireless interface, I am unable to use a wired connection. Though it should be simple enough to enable wireless networking in the 3.2.0-4 kernel ( the latest kernel in the debian wheezy repos) I have been able to do so. I think it is easier to get something working when you already have an internet connection so my hope is to get the dongle working on my present kernel, cross my fingers in the hope that it also then works on the latest kernel and then use the mobile broadband connection to help me get the wireless interface working on 3.2.0-4

[bmork]

Hi guys, thanks for the responses. To be honest though; I am completely lost. I guess the suggestion is to upgrade to a newer kernel. I will try that later today or tonight to see what happens, then report back.
I may as well explain that I use the 3.1 kernel because it is the only kernel with which I can successfully use my wireless interface, I am unable to use a wired connection. Though it should be simple enough to enable wireless networking in the 3.2.0-4 kernel ( the latest kernel in the debian wheezy repos) I have been able to do so. I think it is easier to get something working when you already have an internet connection so my hope is to get the dongle working on my present kernel, cross my fingers in the hope that it also then works on the latest kernel and then use the mobile broadband connection to help me get the wireless interface working on 3.2.0-4

If upgrading from a Debian 3.1 kernel to a supported Debian 3.2 kernel breaks your wireless then you should report that as a bug against than Debian kernel immediately. Run the reportbug script after booting the failing 3.2 kernel and save the report to a file. Then boot back to the working kernel and submit the bug report.

The Debian kernel team is usually very helpful and interested in regressions like this. It could be a simple matter of some new firmware missing or something like that. But note that this isn't necessarily a bug. There has never been a Debian release using a v3.1 kernel, so upgrading from a v3.1 kernel isn't a supported use case. The supported upgrade pattern is 2.6.32 -> 3.2 directly…

Still, I'd report it as a bug to see if they can provide some hints. The reportbug script should collect all interesting data.

Trying to get mobile broadband working with a v3.1 kernel, knowing that this kernel lacks support for the modem you are using, seems a bit futile. It's of course possible, but the solution you end up with will be wrong for any supported kernel.

[ab2005a]

Thanks for your help and suggestions bmork. I guess it is not a bug in the kernel that breaks my wireless. The issue is, at least partly, that I am too far away from the router. Using the native driver and any kernel works fine if I am next to the router however when I am far away, I can only connect using the windows driver and ndiswrapper and kernel 3.1. The people at debian, quite rightly, wish that I use the native driver but I've not been able to get it working at this distance with any kernel. I have also some issues with headers and loading modules for kernels higher than 3.1 when trying to use ndiswrapper... or something along those lines. You may have already guessed that I am no linux expert.

Also, I don't understand how I have 3.1 if it was never released under debian, I guess I installed 3.0 originally and ugraded or dist-upgraded to 3.1 at some stage, I always used aptitude and I never changed the repos.

None of this is related to the k3772 issue anyway I suppose; though if I get k3772 working in the 3.2 kernel it would make it a lot more convenient to try and get the wireless working there too

[bmork]

Also, I don't understand how I have 3.1 if it was never released under debian, I guess I installed 3.0 originally and ugraded or dist-upgraded to 3.1 at some stage, I always used aptitude and I never changed the repos.

There was a 3.1 kernel package in sid (and possibly also testing) at some point. This is an intermediate development version and isn't the same as a *release*. The released and currently supported Debian kernels are

squeeze: 2.6.32
wheezy: 3.2

There have been a lot of kernel packages between these, but none of them were part of any release. The significance of this is that the supported and tested upgrade path is 2.6.32 => 3.2, and only that.

You should of course expect any intermediate versions to work, but there are some catches wrt upgrading from an unsupported version. For example, if you compare the firmware requirements of a typical wireless network driver in squeeze and wheezy:

Code: Select all

bjorn@canardo:~$ modinfo -k 2.6.32-5-amd64 -F firmware iwlagn
iwlwifi-4965-2.ucode
iwlwifi-5150-2.ucode
iwlwifi-5000-2.ucode
iwlwifi-6050-4.ucode
iwlwifi-6000-4.ucode
bjorn@canardo:~$ modinfo -k 3.2.0-4-amd64 -F firmware iwlagn
iwlwifi-5150-2.ucode
iwlwifi-5000-5.ucode
iwlwifi-6000g2b-6.ucode
iwlwifi-6000g2a-5.ucode
iwlwifi-6050-5.ucode
iwlwifi-6000-4.ucode
iwlwifi-100-5.ucode
iwlwifi-1000-5.ucode
iwlwifi-135-6.ucode
iwlwifi-105-6.ucode
iwlwifi-2030-6.ucode
iwlwifi-2000-6.ucode

you will notice that e.g the iwlwifi-5000 firmware version jumps from 2 to 5. Unsupported intermediate kernel versions have used version 3 or 4, but because those versions aren't needed in any released kernel they are not part of the Debian firmware package:

Code: Select all

bjorn@nemi:~$ dpkg -L firmware-iwlwifi
/.
/usr
/usr/share
/usr/share/bug
/usr/share/bug/firmware-iwlwifi
/usr/share/bug/firmware-iwlwifi/presubj
/usr/share/doc
/usr/share/doc/firmware-iwlwifi
/usr/share/doc/firmware-iwlwifi/changelog.gz
/usr/share/doc/firmware-iwlwifi/copyright
/lib
/lib/firmware
/lib/firmware/iwlwifi-105-6.ucode
/lib/firmware/iwlwifi-2030-6.ucode
/lib/firmware/iwlwifi-6050-5.ucode
/lib/firmware/iwlwifi-2000-6.ucode
/lib/firmware/iwlwifi-5150-2.ucode
/lib/firmware/iwlwifi-4965-2.ucode
/lib/firmware/iwlwifi-6000g2b-6.ucode
/lib/firmware/iwlwifi-6050-4.ucode
/lib/firmware/iwlwifi-135-6.ucode
/lib/firmware/iwlwifi-5000-5.ucode
/lib/firmware/iwlwifi-6000-4.ucode
/lib/firmware/iwlwifi-3945-2.ucode
/lib/firmware/iwlwifi-1000-5.ucode
/lib/firmware/iwlwifi-6000g2a-5.ucode
/lib/firmware/iwlwifi-5000-2.ucode
/lib/firmware/iwlwifi-100-5.ucode

This reduces the number of firmware files in Debian, but does mean that you have to take special considerations if you are doing unsupported upgrades via intermediate kernel versions.

As usual, you are expected to know what you are doing if you decide to run Debian unstable or testing.