[SOLVED] Intel Centrino Ultimate-N 6300 Troubles

[jyoung]

Hey Folks,

The problems / solutions described here sound similar to what I'm seeing. Do you think this could be the right solution for me?

https://forums.gentoo.org/viewtopic-t-880149.html

[jyoung]

Guys?

[roarinelk]

do you still have the same iwlagn errors in the kernel log?
First install a newer kernel, and then emerge all 4 net-wireless/iwl6*-ucode packages.

[jyoung]

There are no mentions of iwlagn in /var/log/kern.log. Would there be, though, since it's not able to get through the boot-up process? Remember, it hangs at the uevents step and I have to kill it at the power button.

I guess what I'm asking is if there would be any records left in /var/log/kern.log from a failed reboot? After I kill the failed reboot, swap out the wireless card, and reboot again, would any messages from the failed reboot still be in there?

[jyoung]

Okay, I've also updated my net-wireless/iwl6*-ucode packages. When I wrote last December the only one available was iwl6000, but now 6005, 6030, and 6050 are available; I've installed them all.

This actually changed things a lot. Now the computer boots and gets through the uevents step, which is where it was hanging before. Sadly, when I try to start dhcp with dhcpcd wlan0, it then hangs. The machine is totally frozen in the sense that it won't kill the process with ctrl+c, and I can't switch to another screen using the function keys (I haven't started X at this point).

Any ideas? To me it seems like the same or a similar phenomenon is occuring at at later step.

[jyoung]

Another update: I was curious which of the net-wireless/iwl6*-ucodes was actually responsible for the new functionality of the wireless card. So, I removed them all and re-emerged them one at a time, each time trying the wireless card. It turns out it was the iwl6000 firmware that was allowing me to detect the wireless card at all. This makes a lot of sense because the intel wireless linux page (http://intellinuxwireless.org/?n=downloads) which is linked to off the gentoo wireless page (http://en.gentoo-wiki.com/wiki/Iwlwifi), indicates that iwl6000 is the firmware that the Ultimate-N 6300 card needs. I can only assume that my earlier hang-at-boot issues were due to an older version of the same iwl6000 firmware or something about my configuration has changed since I last had this problem. The later possibility makes a lot of sense; probably before my machine was enabling wlan0 at boot and hanging, whereas now it's leaving me to enable it later on by hand (which then causes it to hang in the same way).

However, as roarinelk suggested earlier, I've check my kernel log. While I reported before that there were no mentions of iwlagn in it, there are now. That is a big change from previous behavior. I'm guessing that it's because I can now complete the bootup process with the card in place? Here's the results of 'grep iwlagn /var/log/kern.log' that apply to the most recent bootup. There are no obvious warnings, but then if it's only reporting stuff from the bootup there wouldn't be (since that's successful now).

Mar 30 11:20:20 murbella kernel: [ 9.109357] iwlagn 0000:06:00.0: PCI INT A -> Link[Z016] -> GSI 21 (level, low) -> IRQ 21
Mar 30 11:20:20 murbella kernel: [ 9.109388] iwlagn 0000:06:00.0: setting latency timer to 64
Mar 30 11:20:20 murbella kernel: [ 9.109419] iwlagn 0000:06:00.0: pci_resource_len = 0x00002000
Mar 30 11:20:20 murbella kernel: [ 9.109421] iwlagn 0000:06:00.0: pci_resource_base = ffffc90001f8c000
Mar 30 11:20:20 murbella kernel: [ 9.109423] iwlagn 0000:06:00.0: HW Revision ID = 0x35
Mar 30 11:20:20 murbella kernel: [ 9.109540] iwlagn 0000:06:00.0: irq 41 for MSI/MSI-X
Mar 30 11:20:20 murbella kernel: [ 9.109609] iwlagn 0000:06:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
Mar 30 11:20:20 murbella kernel: [ 9.109714] iwlagn 0000:06:00.0: L1 Enabled; Disabling L0S
Mar 30 11:20:20 murbella kernel: [ 9.126178] iwlagn 0000:06:00.0: device EEPROM VER=0x436, CALIB=0x6
Mar 30 11:20:20 murbella kernel: [ 9.126180] iwlagn 0000:06:00.0: Device SKU: 0X1f0
Mar 30 11:20:20 murbella kernel: [ 9.126181] iwlagn 0000:06:00.0: Valid Tx ant: 0X7, Valid Rx ant: 0X7
Mar 30 11:20:20 murbella kernel: [ 9.126205] iwlagn 0000:06:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
Mar 30 11:20:20 murbella kernel: [ 9.580220] iwlagn 0000:06:00.0: loaded firmware version 9.221.4.1 build 25532

[jyoung]

Hey, the folks on this wiki seem to mention my problem in a round about way. They explain how to setup wpa_supplicant. As part of the trouble shooting section, they suggest trying iwconfig and dhcpcd. At the bottom of this section, they mention that if the system hangs (like mine is), then something is setup wrong. Sadly, they don't go on to elaborate. Do you folks think this could be a refernce to my problem? Should I talk to these folks to see if they could suggest diagnostics for this problem? Also, do you think wpa_supplicant would be more successful than iwconfig and dhcpcd?

http://www.gentoo-wiki.info/HOWTO_Wireless_Configuration_for_TUDelft

[kimmie]

jyoung,

The iwlagn module has been completely superceded by iwlwifi in recent kernels. I would try a 3.2 kernel.

[jyoung]

Thanks kimmie, that could me a real game changer for me. My goal is to upgrade my system this weekend; I'll post back when that's done.

[jyoung]

Okay, after some complications I've upgraded to kernel version 3.3, and I've switched over to the Iwlwifi driver. Thanks again, kimmie, for pointing out this significant change.

Sadly, I'm still having similar problems. When I boot up, my maching gets stuck when it starts dhcpcd. It's definitely stuck (I've left it for hours just to make sure it won't eventually get past this step). Boot up messages prior to this indicate that the wireless card is being detected. Also, in the interests of being thorough, I tried compiling the Iwlwifi driver into the kernel rather than as a module (which is explicitely advised against on the wiki page: http://en.gentoo-wiki.com/wiki/Iwlwifi, but why not give it a try?), and the effect was the same.

Any suggestions? I'm starting to wonder if it's something about my setup other than the driver - what do you folks think?

[jyoung]

Another question: is there any way to get more information back from dhcpcd about why it's hanging? Can I set it to be verbose? One complication is that it's hanging at boot - is there any way to tell it not to launch dhcpcd at boot so that I can launch it later by hand?

[jyoung]

Hi Folks,

I was thinking that perhaps one of my config files has an explicit reference to eth1, or perhaps to the old broadcom card. When I put the new intel card in (the one that doesn't work), it appears as wlan0. Of course this back when I didn't have dhpc starting at boot (a few posts back). So, I did a grep -r eth1 in my /etc directory, and, sure enough, there is a reference to eth1 in /etc/udev/rules.d/70-persistent-net.rules. I've copied the text below:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0c:ee:e6:89:56:73", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Now, if you recall, back when I first posted my machine was hanging at boot at the point where it processes uevents, so it makes some sense that the problem might be in this configuration file. Where should I go from here? I could comment out the reference to eth1. Or, write a rule for wlan0. But, there already seems to be a wlan0 rule:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:d7:1a:66:34", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

Is there something wrong with this wlan0 rule? If so, that would seem to be an explanation. That said, it's kind of weird that the machine would boot and detect wlan0 at all (as it has done in the past, though, not now).

[Tolstoi]

Hey jyoung,

thanks for pointing that out. I never cared about udev rules. After reading your post I took a look at my 70-persistent-net.rules file just to
see that only one entry was correct - the one pointing to my eth0 wired connection.
I simply deleted the whole file and now my connection works flawlessly again - at least for now.

[jyoung]

Hi Tolstoi,

I tried this technique myself, with no luck. If I commented out the wlan0 rule, the machine simply got at processing uevents. May I ask, what was your original situation? What symptoms was your machine having? And, what kind of machine and wireless card is it? And, one final question, how did you know which rules in 70-persistent-net.rules were correct and which weren't?

[Tolstoi]

I never had problems with Intel wireless card until I recently swapped my Broadcom card for an Intel 6200 wireless one. I always ran into connection problems, either a dropping connection, no connection at all or one building up slowly. I tried a lot without success.

After your post I took a look at the udev file and recognized old configurations which must have been around from the times of my 4695 Intel card, and the Broadcom. I decided to delete the whole file.

Next thing I did was that I built the 6000 ucode into the kernel. The wireless kernel settings are built in and not as modules. So everything works fine now here.

[jyoung]

One thing I hadn't done so far was build the ucode into my kernel. I did that, but no change. I also booted off a live CD, and the 70-persistent-net.rules file that it created was the same as the one I'm already using. I now suspect that, while I may have had udev problems in the past, my current problem is just with DHCP. Do you know of any reason that it might hang on startup?

[Tolstoi]

Are you using some kind of networkmanager like NetworkManager or Wicd or Wpa_Supplicant ?

[jyoung]

No, I used to use NetworkManager but pulled it out about six months ago because I wanted something that was more hand-on, and also that I could run without starting X11. I've been using wireless tools, but had wpa_supplicant installed. Just in case wpa_supplicant was somehow confusing wireless-tools, I just now unemerged it; no change, my boot-up still hangs when the dhcp client tries to start.

I've done some google searching for clues on what might cause this. I'm finding a lot of hits for dhcp troubles, but none seems to really describe what I'm having.

I'm not sure how much your've read through the older posts, but in the past my dhcp has not launched on boot, and I'm not sure why it is now. Back when it didn't launch at boot, I was able to boot up successfully, but the machine hung in a similar way when I tried to launch dhcp manually.

[jyoung]

One more thing to save you from digging through older posts: I'm upgrading from a broadcom wireless card to this intel wireless card, and I when I put the broadcom card back in I don't have the problem with dhcp.

[Tolstoi]

I had problems with my Broadcom card using the broadcom-sta driver for that model. So I switched to Intel.

I'm sure you've done that already but I would remove everthing related to Broadcom, then go through the guides again, to check if you've got everything right. Check if you have net.eth0 and net.wlan0 linked to net.lo, if you've added net.wlan0 to the default runlevel, kernel settings etc. .
Sometimes it's just a small thing we just overlooked. I don't have any dhcp problems for my part.

[jyoung]

Wow, I had actually forgotten to create a net.wlan0 linked to net.lo. I did this, and I recompiled my kernel after removing everything related to broadcom, but with no effect. Then I tried one more trick, compiling the iwlwifi driver as a module. The wiki for the iwlagn driver recommends to compile it as a module. When I switched over to the newer iwlwifi driver, I've been trying both the in-kernel and module compiles. This time, just a few minutes ago, when I compiled the iwlwifi driver as a module, I got stuck at the processing uevents step again. This is kind of odd since the main reason that the wiki indicates that compiling the driver as a module is important is because the firmware on the harddrive isn't available to the kernel when it's first loaded (since the harddrive isn't mounted). Now that my firmware is compiled into the kernel, I wouldn't think this would matter.

The one other trace of the broadcom stuff is the broadcom-sta driver itself. One other test would be to try and remove that and see what happens. Unfortunately, I'm going out of town for a couple of days and I won't be able to tinker with this until Monday at the earliest. If you think of any other ideas or possible fixes or diagnostics over the weekend, feel free to post them and I'll them a try early next week.

[Tolstoi]

Well, I've got all the settings for iwlwifi that are pointed out in the wiki built in the kernel. And as mentioned above the firmware as well. As you're not using any kind of networkmanager take a look at your /etc/rc.conf at the line rc_hotplug.

[jyoung]

Okay, I compiled the driver into the kernel (along with the firmware), and then had a look at my rc.conf file.

My rc.conf had the line:
#rc_hotplug="*"

The comments above it seemed to suggest that this line would be useful for bringing up services such as wlan0, so I uncommented this line and attempted to reboot. The machine still got stuck, but the error messages were different and it's not clear that it got stuck at the same point. As a copy and paste is impossible, I've written them down and transcribed them here:

*Bringing up interface eth0
*No configuration specified; defaulting to DHCP
*dhcp ...
*Running dhcp ...
*dhcpcd[1709]: version 5.5.6 starting
*dhcpcd[1709]: eth0: waiting for carrier

At this point the computer waiting about 30 seconds, and then proceeded with:

*dhcpcd[1709]: timed out
*dhcpcd[1709]: allowing 8 seconds for IPv422 timeout
*dhcpcd[1709]: timed out
*ERROR: net.eth0 failed to start
*Bringing up interface wlan0

This is where the computer got stuck. Thi s error seemed familiar, so I looked in my log and found and entry from about ten months ago saying that I had commented out this line, 'rc_hotplug="*" ', in order to surpress the attempt to initialize eth0 when there's no ethernet cable plugged in. At that point in time the machine wasn't attempting to start up wlan0 and then getting stuck, I just wanted to not have to wait 30 seconds during boot-up while the computer figured out that it wasn't plugged into a network.

That said, it's not clear to me what's really going on. What configuration is it expecting? I mean DHCP is a great default, but should I be telling it that explicitely? Why does it take 30 seconds to figure out that there's no ethernet cable plugged in? And, perhaps most important, is there any way to get feedback on why wlan0 is failing to startup? Some kind of verbose setting?

[jyoung]

Some google searching on my problem did not reveal any clues as to why net.wlan0 gets stuck. But, by setting rc_hotplug="net.wlan0 !net.*" I surpress the attempt to start eth0 at boot. But, wlan0 still gets stuck. It's actually not clear to me that starting it at boot in this fashion is useful. If I could prevent it from starting at boot and then start it manually with infconfig, maybe I could learn more about what's going on?

[Tolstoi]

Did you add net.wlan0 to the default runlevel? Perhaps that's the issue. Your rc.conf looks ok now with net.wlan0 added to the uncommented rc_hotplug line.