Fixing the Blinking LED on Intel WiFi cards

Introduction
I've recently got hold of a Dell D430 laptop and installed Mint 13 Maya on it intending to use it as a small laptop to carry around with my photography kit as it's small, light and lasts two hours on a battery charge. Installing Mint wasn't a problem, and I've been surprised how quick the laptop is to use. All the components work as they should and the laptop is fast becoming the first device I reach for when I want something done quickly in the field.

However, like many people, I've had one gripe with whole set up - the annoying flashing WiFi LED just below the screen. This happens because Dell, like many other manufacturers, uses an Intel WiFi chipset in their laptops and the Intel developers who put together the Linux drivers for the chipset decided in their wisdom to make the LED 'flash' to indicate that it was passing traffic. This has annoyed so many people that a quick search will reveal a large number of solutions on the Internet where people in one way or another have 'fixed' this problem in their own particular environments.

So why do I feel the need to write another?

Well, after trying a fair few of these solutions none of them actually worked on my setup. This is not to say that these other solutions do not work - just that I wasn't successful getting them to work for me. So I've written a blog explaining how I turned off the LED rather than just a prescriptive 'do-this-then-that'.

Step One - understanding how to tackle the problem
The Intel WiFi drivers are usually installed as a family of modules that work together with the linux kernel to set up and run the WiFi chipset. Judging by the people with the same hardware as me, at least one of the module names contained the letters 'iwl', so, armed with this, I listed the modules by typing this comment into a Terminal window:

$ lsmod | grep iwl

This gave me the response

$ lsmod | grep iwl
iwl3945                73111  0 
iwl_legacy             71134  1 iwl3945
mac80211              436455  3 iwl3945,iwl_legacy
cfg80211              178679  4 iwl3945,iwl_legacy,mac80211$

So I now need to find out which of these files contain the control for the LED. This leads me to:

Step Two - installing some Linux diagnostic tools
We will need to look at the capabilities of each of these modules to see which one(s) can control the LED and to do this we need to download sysfsutils. This is a set of utilities built upon sysfs, a virtual filing system in more recent kernels that lets you investigate a systems' device tree. To install the tools open a terminal window and in the window type:

$ sudo apt-get update
$ sudo apt-get install sysfsutils

Once the install is complete, you can run the systool command on each of the modules to see which module has a parameter option to control the LED. (in the examples below I chop the end of the report off to save space and make the response more meaningful):

$ systool -m iwl3945 -av
Module = "iwl3945"

  Attributes:
    initstate           = "live"
    refcnt              = "0"
    srcversion          = "301B04B4010DED41B0830D0"
    uevent              = 
    version             = "in-tree:s"

  Parameters:
    antenna             = "0"
    disable_hw_scan     = "0"
    fw_restart          = "1"
    swcrypto            = "1"

  Sections:
    .altinstr_replacement= "0x00000000"
    .altinstructions    = "0x00000000"

    [ -- some output removed for clarity -- ]

$ systool -m iwl_legacy -av
Module = "iwl_legacy"

  Attributes:
    initstate           = "live"
    refcnt              = "1"
    srcversion          = "275221577F5CCA15EDB6755"
    uevent              = 
    version             = "in-tree:"

  Parameters:
    bt_coex_active      = "Y"
    led_mode            = "0"

  Sections:
    .altinstr_replacement= "0x00000000"
    .altinstructions    = "0x00000000"

    [ -- some output removed for clarity -- ]

$

You can see from this that the module iwl3945 does not have a parameter option to set the LED mode but iwl_legacy does have such a parameter - the line led_mode = "0" in the list above. So, to stop the LED flashing we need to configure iwl_legacy to switch the LED on for WiFi active and off for WiFi inactive. But what setting for led_mode should we use? The answer lies in the output of another command:

$ modinfo iwl_legacy
filename:       /lib/modules/3.2.0-23-generic/kernel/drivers/net/wireless/iwlegacy/iwl-legacy.ko
license:        GPL
author:         Copyright(c) 2003-2011 Intel Corporation 
version:        in-tree:
description:    iwl-legacy: common functions for 3945 and 4965
srcversion:     275221577F5CCA15EDB6755
depends:        mac80211,cfg80211
intree:         Y
vermagic:       3.2.0-23-generic SMP mod_unload modversions 686 
parm:           led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking (int)
parm:           bt_coex_active:enable wifi/bluetooth co-exist (bool)
$

What we want is option 1 - On(RF On)/Off(RF Off). Now we need to configure the module to control the LED this way.

Step Three - making the change.
To make the change to the LED we need to unload the iwl_legacy module, change its configuration file and finally reload the module. In sequence then:

$ sudo modprobe -r iwl_legacy 
FATAL: Module iwl_legacy is in use.
$ 

If you see this, then you've made a mistake. You will need to unload the other iwl module first, as this module is preventing the other from being unloaded. (you will naturally turn off your WiFi connection at the same time, so be careful!) :

$ sudo modprobe -r iwl3945
$ sudo modprobe -r iwl_legacy 
$ 

Now the modules are unloaded you can make the changes.

$ cd /etc/modprobe.d
$ sudo nano iwl_legacy.conf

In nano enter this line then save the file and exit nano.

options iwl_legacy led_mode=1

Now re-start the two modules

$ sudo modprobe iwl_legacy 
$ sudo modprobe iwl3945
$ cd ~
$

Finally check that iwl_legacy is properly configured - and check on your laptop that the LED is behaving as it should.

$ systool -m iwl_legacy -av
Module = "iwl_legacy"

  Attributes:
    initstate           = "live"
    refcnt              = "1"
    srcversion          = "275221577F5CCA15EDB6755"
    uevent              = 
    version             = "in-tree:"

  Parameters:
    bt_coex_active      = "Y"
    led_mode            = "1"

  Sections:
    .altinstr_replacement= "0x00000000"
    .altinstructions    = "0x00000000"

    [ -- some output removed for clarity -- ]

$

Assuming all of the above has been completed and you have a non-blinking LED, the last thing to do is to shut the laptop down completely and then restart it - just to make sure the configuration works the next time it is used.

Conclusion
You should now have a laptop without a blinking LED.  You may also find this approach to tackling the blinking LED problem may be useful with other WiFi chipsets and it would be good to know if this approach helps you stop that annoyingly blinking LED too.  Please add a comment below and let me know.

Update following Mint 17 (Qiana)
I've just updated my D430 to Mint 17 (Cinnamon) and had to repeat the steps in this blog article to stop the blinking LED again!!  You'll be pleased to know that I used the same approach as I presented in this blog and everything was the same except one of the files has changed its name in the new release.

iwl_legacy is now called iwlegacy. This means that this blog article is still valid for Mint 17 - except wherever you read iwl_legacy you should substitute iwlegacy instead.  This also applies to the line you need to put into iwlegacy.conf:

options iwlegacy led_mode=1

Good luck!

Getting Devmon to start automatically with Xymon on Ubuntu

Introduction
Xymon is a brilliantly simple network management tool that runs reliably in the background and can graph, alert and track pretty much anything you want. I use Xymon for example to monitor a number of things around my home - including all my servers and devices, the quality of my Internet - and the temperature in and around the house.  I've developed many of the scripts I use to carry out this monitoring myself using Perl.  However, while Xymon supports the monitoring of remote devices via ICMP or TCP port tests or custom scripts, it doesn't currently provide any sensible form of SNMP monitoring.  Luckily, help is at hand in the shape of Devmon. Devmon is a Perl daemon that is designed to supplement and enhance the capabilities of either a BigBrother or Hobbit/Xymon monitoring server allowing that server to monitor remote devices via SNMP (Simple Network Management Protocol) and integrate this information within the same displays on the BigBrother/Hobbit display server.

However, the documentation with Devmon is sparse and rather lacking, especially around getting it started when the server starts up.  There are example scripts for Red Hat available in the package but nothing for Ubuntu.  I've set about rectifying this and I present my start-up approach to Devmon using Ubuntu's Upstart system.

While Ubuntu supports the more traditional init-based scripts to start and stop services, it is better to think about using Upstart instead, as it is a more robust services management daemon that allows for things like dependencies, custom events/triggers, pre & post initialisation steps  and resource limitations, amongst other things.

Installation of  Xymon and Devmon
The full installation of Xymon and Devmon is beyond the scope of this article, so I'll summarise what I've done here so you can adapt my scripts and notes for your own use:

• Xymon is installed under /home/xymon with a username of xymon.  It stores its logfiles in /var/log/xymon/
• Devmon is installed under /usr/lib/devmon with a username of xymon (so editing scripts and templates is all completed under the one username) and logs to /var/log/devmon/devmon.log

Configuring Upstart
There are plenty of Upstart tutorials on the Internet - and an excellent 'Cookbook' to check out, so I won't repeat that here.  All that is necessary is to say that:

• Upstart's scripts are stored in the /etc/init directory and all end in .conf.
• Upstart logs its output to logs for each script in /var/log/upstart/

To work out what I needed to get devmon running I set up PuTTY to have three sessions open to my server.  One I used to edit and test the script, one I had set to display the devmon logfile (tail -f /var/log/devmon/devmon.log) and one was set to show the upstart script (tail -f /var/log/upstart/devmon.log).  I found the easiest way to get the script I needed was to take another script as a template and then edit it to start devmon instead.  My script, devmon.conf, is shown below.

#!upstart
description "DEVMON Hobbit/Xymon SNMP tool upstart script"
author "Martin Davies"

start on runlevel [2345]
stop on runlevel [!2345]

env PIDFILE="/var/run/devmon/devmon.pid"
env DEVMON_USER="xymon"
env DEVMON_DIR="/usr/lib/devmon/"

script
        if [ ! -d "${DEVMON_DIR}" ]; then
                echo "${DEVMON_DIR} missing, aborting."
                exit 1
        fi

        exec start-stop-daemon --start -c ${DEVMON_USER} -d ${DEVMON_DIR} --exec ${DEVMON_DIR}devmon -- -f

end script

That's all it took.  Looking closer at the script:

These two lines comment the script and give enough info for anyone to see what the script is for

description "DEVMON Hobbit/Xymon SNMP tool upstart script"
author "Martin Davies"

These next lines simply tell Upstart when to run the script (the figures in brackes are the runlevels of Ubuntu)

start on runlevel [2345]
stop on runlevel [!2345]

Then we set up the environment variables to set the PID file, the user Devmon runs under and the directory that devmon is installed in

env PIDFILE="/var/run/devmon/devmon.pid"
env DEVMON_USER="xymon"
env DEVMON_DIR="/usr/lib/devmon/"

Finally the script itself.  First we check that the install directory exists and if it does we run devmon as per the user and directory settings set above.  While testing, I recommend that you add -vvv --debug to the end of 'exec start-stop-daemon' line.

script
    if [ ! -d "${DEVMON_DIR}" ]; then
        echo "${DEVMON_DIR} missing, aborting."
        exit 1
    fi
    exec start-stop-daemon --start -c ${DEVMON_USER} -d ${DEVMON_DIR} --exec ${DEVMON_DIR}devmon -- -f
end script

Addendum:
I had cause to shut down my server the other day to replace a disk and when it was restarted Devmon didn't start. The problem I saw was that the Devmon entries on Xymon pages stayed purple. Even when starting Devmon by hand I still had purple entries for devmon in the xymon web pages

martin@homeserver:~$ sudo start devmon
devmon start/running, process 28703
martin@homeserver:~$ 

You can see here that Devmon reports as starting but after a few minutes I still had purple icons. Looking at the Devmon log file gave me the answer:

martin@homeserver:~$ cat /var/log/devmon/devmon.log
[14-07-28@21:51:39] Shutting down
[14-07-30@22:18:12] Cant write to pidfile /var/run/devmon/devmon.pid (No such file or directory)
[14-08-05@18:09:00] Cant write to pidfile /var/run/devmon/devmon.pid (No such file or directory)

It turned out that a kill script from the old init.d based setup had not only deleted the pidfile but had also deleted the directory too. So I removed the killscript and re-created the pidfile directory:

martin@homeserver:~$ sudo mkdir /var/run/devmon/
martin@homeserver:~$ sudo start devmon
devmon start/running, process 30369

And looked at the log file again and saw this line

[14-08-06@21:40:16] Cant write to pidfile /var/run/devmon/devmon.pid (Permission denied)

Meh! OK - one more step and we're done:

martin@homeserver:~$ sudo chown xymon:xymon /var/run/devmon
martin@homeserver:~$ sudo start devmon
devmon start/running, process 32309
martin@homeserver:~$ cat /var/log/devmon/devmon.log

Finally. The last few lines on the log file read

[14-08-06@21:40:16] Cant write to pidfile /var/run/devmon/devmon.pid (Permission denied)
[14-08-06@21:47:09] ---Initilizing devmon...
[14-08-06@21:47:09] Node 0 reporting to localhost
[14-08-06@21:47:09] Running under process id: 32309
[14-08-06@21:47:09] Entering poll loop

And sure enough, after a few minutes, the Devmon icons came back to life. I'll check the script again and see if I need to put further tests in the script.  If I do, I'll update the post and let you know.

As usual, please get in touch if this has been useful and drop me a comment if you need more info - or if you find a mistake!

Updating Ubuntu 11.10 to 12.04 gives problems with Samba and Greyhole

I run an Ubuntu server as a central home server holding all my media (photographs, music etc.) and the files we all use and share as a family in a safe and easy environment - rather than have different versions stored on each person's PCs and devices.. The server provides file shares via Samba and provides file resilience using Greyhole. Both have been configured and the server has run successfully for over a year since it was installed. Recently I upgraded my server from Ubuntu version 11.10 to Ubuntu version 12.04 LTS using the Ubuntu instruction Run 'do-release-upgrade' to upgrade All went well apart from two 'little' issues.

• The first issue was that Zoneminder (a CCTV security monitoring program)  'broke' during the upgrade due to changes made within mySQL during the upgrade.
• The second was that my shared folders stopped working.

While the first issue I can leave till another day, the second issue needed fixing right away as the server contents were needed that evening.

No pressure then.... ;o)

The first step I tried was to be clear about what had gone wrong. My Samba config was unchanged from before the upgrade and both services (Samba and Greyhole) had started without error. From my Windows 7 desktop I could access and browse my home directory without any issues. (I use this folder as a link between my Windows world and my Ubuntu world so this share is not maintained by Greyhole). However, while I could see all the other shares held on my server I could not browse into them to access the files. Instead, Windows 7 reported that it could not access the shares in an error window like the example below:

The next steps were to look at the logs for Samba on my server.

martin@homesvr:~$
martin@homesvr:~$ cd /var/log/samba/
martin@homesvr:/var/log/samba$ cat log.win7desktop

I noticed lots and lots of error messages like this:

[2013/04/14 20:09:42.217273,  0] smbd/service.c:869(make_connection_snum) vfs_init failed for service movies
[2013/04/14 20:09:42.226322,  0] smbd/vfs.c:173(vfs_init_custom) error probing vfs module 'greyhole': NT_STATUS_UNSUCCESSFUL
[2013/04/14 20:09:42.226446,  0] smbd/vfs.c:315(smbd_vfs_init) smbd_vfs_init: vfs_init_custom failed for greyhole
[2013/04/14 20:09:42.226518,  0] smbd/service.c:869(make_connection_snum) vfs_init failed for service movies
[2013/04/14 20:09:42.231051,  0] smbd/vfs.c:173(vfs_init_custom) error probing vfs module 'greyhole': NT_STATUS_UNSUCCESSFUL
[2013/04/14 20:09:42.231172,  0] smbd/vfs.c:315(smbd_vfs_init) smbd_vfs_init: vfs_init_custom failed for greyhole
[2013/04/14 20:09:42.231244,  0] smbd/service.c:869(make_connection_snum) vfs_init failed for service movies

However, for Greyhole there were no real issues:

martin@homesvr:~$ greyhole -S

Currently idle.

Recent log entries:
  Apr 14 20:09:52 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:10:02 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:10:12 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:10:22 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:10:33 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:10:43 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:10:53 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:11:03 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:11:13 7 sleep: Nothing to do... Sleeping.
  Apr 14 20:11:23 7 sleep: Nothing to do... Sleeping.

Last logged action: sleep
  on 2013-04-14 20:11:23 (7s ago)

martin@homesvr:~$
martin@homesvr:~$ greyhole -i
/media/hdd2/gh:       0 kBps
/media/hdd1/gh:       0 kBps
/media/hdd3/gh:       0 kBps
/media/hdd4/gh:       0 kBps
---

So this led me to suppose that the breakdown is between Samba and Greyhole, and, entering the following command:

martin@homesvr:~$ cat /etc/samba/smb.conf

shows me the config for the share I was investigating:

[movies]
    comment = Movie Library
    path = /share/movies
    browsable = yes
    guest ok = yes
    read only = yes
    force user = nobody
    force group = nogroup
    write list = martin
    dfree command = /usr/bin/greyhole-dfree
    vfs objects = greyhole

Printing PDF documents from Ubuntu

I use both Ubuntu and Windows applications depending on what computer I am nearest to and consequently I tend to notice things that are present in one operating system that may be absent or difficult in the other.  One example of this is the ability to print a document in PDF format.  Now I know you can easily save or export documents in PDF format from the excellent Office-type suites on either platform but what do you do if, for example, you want to keep a permanent record of a purchase you've made on the web?

The best way to do this would be to print the confirmation as a PDF document, a sort of electronic printout you can save and use anywhere.  On Windows, I use the excellent PDF-Creator which does the job admirably.  Having this installed means I can print emails and web pages as PDF documents giving me electronic confirmations of web purchases when I make them (so much easier than paper copies)

You cannot easily do the same on Ubuntu.  However, getting the same ability to print to PDF is not difficult and only means you need to load a specific printer type. I've provided a list of instructions you can follow to install PDF printing on Ubuntu.

Running X-windows ... on Windows.

I run a number of computers from an old Compaq Evo N410C as a netbook, through to a new Dell Studio 15 laptop with all the bells and whistles.  I also run different operating systems - mainly Windows and Ubuntu ( http://www.ubuntu.com ).  The problem is, I often have files and projects scattered across the various computers depending on when and where I use them.  Therefore I want to be able to hop from computer to computer to get to the files I need pretty well from anywhere - even from my Android phone.

So what to do?  The usual approach people take is to use some type of remote desktop application - such as VNC or RDP.  This is easy enough, but overlays one desktop (the remote one) on another (the local one)  On a laptop this makes it dfficult to work between the two screens and is sometimes slow to update - not to mention awkward to share information between the remote and local machines. 

Better by far is to be able to run the application on the target machine but have the output displayed on the screen in front of you.  Impossible?  Not if you use linux.  Unix and Linux machines have been able to run software on a remote machine like this for almost twenty years.

This is what you do to run linux apps on a linux PC but have the windows viewable on a Windows PC or laptop:

Updates are available - press OK to download and install.....

There is nothing more annoying for PC users than the pop-up window - usually just after turning the computer on - that insists that 'updates are available' and almost forces you to update there and then. All you wanted to do was quickly check your email or browse for something on the 'net and you're held up by yet another update. If it's not Windows, it's Adobe, or Java. Or worse, your Anti-virus software.

As these update independently, it seems to me to happen almost every time you turn the computer on, and if you use more than one - say a laptop and a desktop - you know that you're going to get twice the hold-up - once on the desktop and once again on the Laptop the next time you turn it on.

Can I ask Microsoft to implement a standard update 'core' program that is part of the security centre on Windows and publish an API to every developer for Windows? My suggestion is that such a program should be used by developers who can then drive their updates through this core and we poor users can then schedule all updates to take place at a convenient time to us - not at the whim of each developer.

Ubuntu manages it. Mandriva manages it. Red Hat manages it. Why not Windows?

After all, aren't we supposed to be in control of 'our' computers?