How-To: Fix slow reconnection to Wireless after suspend/sleep in Linux

Every time I’d put my LMDE-running machine to sleep the wireless wouldn’t come up for maybe a minute or so, which isn’t ideal. This could be caused by a variety of conditions, but in my case it turned out that the IPv6 “Automatic” setting was trying to use IPv6 DHCP, and was waiting for this to time-out before accepting the IPv4 DHCP lease.

To change this behaviour, you can modify the IPv6 settings from Automatic to Ignore, like this:

Disabling IPv6 in Gnome 3

If you’re not using Gnome Shell (like in the above screenshot), then maybe try modifying /etc/network/interfaces – really, it’ll depend on your Linux distro where the config is located.

Once IPv6 was disabled the IPv4 DHCP lease was accepted immediately on resume – and it could be the case that if you’ve got the same symptom that it’s caused by the same issue. Regardless, it’s certainly one of the easier things worth trying before you go looking into more involved solutions.

Source: https://bugzilla.redhat.com/show_bug.cgi?id=708450.

How To: Make VirtualBox Use Your Router’s DHCP to get an IP Address in Linux

Update: The method below for getting a virtualbox IP from your DHCP works (in linux) – but it turns out there’s an easier way (kindly pointed out by Mike in the comments below). You can just change your VirtualBox network settings from NAT to Bridged Adapter and point it at eth0/wlan0 or whichever connection is being used for networking. Then, optionally, you can configure the MAC address of the bridged adapter and set your router to assign a specific IP to a specific bridged adapter. Also, the built-in Bridged Adapter method works to deploy solutions from XNA Game Studio to my Xbox 360, so I’m rapt! Thanks, Mike!

VirtualBox Bridged Adapter Settings

Note: The below bit is for linux only, the above method should work on any host OS!


VirtualBox is an awesome bit of kit and I <3 it long time ten-dorrah. But by default when your virtual copy of Windows/Linux/Solaris/Whatever grabs an IP address, it does so through NAT, and at version 3.0.4, this means it gives us a default Category A network address (i.e. 10.x.y.z).

It’s a working cat-A address, as in it’s fully functional and can talk to the Internet and all that, but sometimes life is a lot easier if you have an IP in the same range as the DHCP pool your router is dishing out. For example, my lappy is 192.168.1.101 internally, my Wii might be 192.168.1.102, the NAS .103 etc, so I want my virtualboxen to take addresses like .104, .105 and such.

I’m doing this to bridge my wireless connection on wlan0, if you’re bridging an ethernet connection substitute eth0 or whatever connection as necessary.

Also, to perform the bridging using this method, you’ll need some tools (feel free to sudo apt-get install NAME-OF-TOOL as necessary):
– 1.) uml-utilities
– 2.) parprouted
– 3.) bcrelay

Now, with that lot installed, run the following commands (provided here in bash script form):

Now, fire up VirtualBox and for your machine of choice change the network selection from NAT to tap0 as shown:

VirtualBox-tap0

Then boot up your virtual machine and check the IP:

VirtualBox-bridged-IP

Great. Super. Smashing. =D

Note: The entire reason I wanted to grab an IP from the router was so my virtual copy of XP could be on the same network as my XBox 360, so I could deploy games to it through XNA Studio 3.1, however XNA Studio is very fussy about timing when it comes to registering the 360, and although it can see the 360 using the bridge, and it tries to connect, it times out before it can fully establish a connection. I guess I’ll have to go with an IP routes method of bridging if I want it to work for that purpose, but as yet I haven’t quite figured it all out. Will keep trying when I have time, or if you know a way, feel free to call me technically incompetent and sling a solution in the comments! Cheers!

How To: Fix Wireless Connection Drops on the Intel 4965 Chipset in Jaunty 9.04

There’s a problem with the iwlagn wireless driver that ships with Jaunty by default, and you’ll find that when wireless connectivity drops you’ll have errors like these in your dmesg log:

[126774.231915] iwlagn: Microcode SW error detected. Restarting 0x2000000.
[126774.252811] iwlagn: MAC is in deep sleep!

Now, you can reset the connection easily enough with sudo ifdown wlan0 && sudo ifup wlan0, but thankfully the fix is already in the updated version of the iwglan driver in backports, so just go:

A swift reboot later and wireless ain’t gonna drop out on you any time soon – hurrah!