Configuring wireless Ethernet with Red Hat Enterprise Linux 5

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Even Linux advocates admit that Linux is not as user-friendly as it should be when it comes to mobile networking:

“Networking on Linux right now is painful for the mobile desktop user, especially in comparison to other operating systems. A laptop user should never need to use the command line or configuration files to manage their network; it should ‘Just Work’ as automatically as possible and intrude as little as possible into the user’s workflow.”

GNOME NetworkManager project website

Oh how true!

A couple of nights back, I was staying at a hotel which only offered Wi-Fi connectivity for guest Internet access. That’s all very well if you have Wi-Fi configured on your laptop but, since rebuilding on Red Hat Enterprise Linux (RHEL) 5 last week, I haven’t got around to setting up the Intel PRO Wireless 2200BG adapter in my notebook. It turns out that it is pretty straightforward, once you have worked out what to do.

I recently wrote about configuring wireless Ethernet with Fedora Core 5 (using the same computer). After a long-winded effort, installing updated drivers, kernel modules and firmware, I finally got it working but only on one network and not with the NetworkManager applet. Then, I found out that the drivers are included in the kernel by default – all that is required is the correct firmware.

As it happens, the same is true for RHEL (lsmod | grep ipw2200 told me that ipw2200 and ieee80211 were both present in the kernel) and Jeff at nethub.org suggests (for CentOS, which is basically a rebadged version of RHEL):

“…download the firmware from the Intel Pro/Wireless 2200GB SourceForge project

[…]

After downloading the file, type in the following commands as root:

tar -zxf ipw2200-fw-2.0.tgz
mv *.fw /lib/firmware/
rmmod ipw2200

Then, wait a few seconds, and type:

modprobe ipw2200

It’s actually even easier than that – the RHEL supplementary CD includes an RPM for the appropriate firmware (so why it’s not installed by default I don’t know) and, after installing the package and running modprobe ipw2200, eth1 became visible in my computer. Running service NetworkManager start and service NetworkManagerDispatcher start launched the NetworkManager applet too; although to make the change permenant, I used chkconfig NetworkManager on and chkconfig NetworkManagerDispatcher on. I also found that a reboot was required before all the wireless network components got themselves in order.

Following this, it was a case of selecting the appropriate SSID from the NetworkManager icon, and supplying the appropriate security details when prompted.

Network Manager - security

Following that, a connection was established (and NetworkManager even activates/deactivates the wired network connection as appropriate).

Network Manager - connected

It seems that getting wireless in Linux is becoming easier but it’s still not as simple as it should be. NetworkManager helps (a lot) but if the leading Linux distribution had automatically detected my industry-standard hardware (as Novell SUSE Linux Enterprise did… and as Windows did), it would have been a whole lot easier.

Running Red Hat Enterprise Linux without a subscription

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve written previously about why open source software is not really free (as in monetary value), just free (as in freedom). Companies such as Red Hat and Novell (SUSE) make their money from support and during Red Hat Enterprise Linux (RHEL) setup, it is “strongly recommended” that the system is set up for software updates via Red Hat Network (RHN), citing the benefits of an RHEL subscription as:

  • “Security and updates: receive the latest software updates, including security updates, keeping [a] Red Hat Enterprise Linux system updated and secure.
  • Downloads and upgrades: download installation images for Red Hat Enterprise Linux releases, including new releases.
  • Support: Access to the technical support experts at Red Hat or Red Hat’s partners for help with any issues you might encounter with [a] system.
  • Compliance: Stay in compliance with your subscription agreement and manage subscriptions for systems connected to [an] account at http://rhn.redhat.com/

You will not be able to take advantage of these subscriptions privileges without connecting [a] system to Red Hat Network.”

Red Hat Enterprise Linux 5 installer

Take a look at Red Hat Enterprise Linux (RHEL) and you’ll see that it’s actually quite expensive – a standard subscription for a machine with up to 2 processor sockets including 1 year’s 12×5 telephone support, 1 year of web access and unlimited incidents is €773.19 [source: Red Hat Online Shop, Europe]. That is not something that I can afford and even though Red Hat gave me a copy of RHEL 5 as part of my recent training, it only includes a 30-day subscription. Now they have launched Red Hat Exchange – a new service whereby third party open source software solutions are purchased, delivered and supported via a single, standardized Red Hat subscription agreement with consolidated billing covering the complete application stack. It’s a great idea, but the pricing for some of the packages makes using proprietary alternatives seem quite competitive.

In fairness to Red Hat, they sponsor the Fedora Project for users like me, who could probably make do with a community-supported release (Fedora is free for anyone to use modify and distribute) but there is another option – CentOS (the community enterprise operating system), which claims to be:

“An Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendor[‘]s redistribution policy and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork.) CentOS is free.”

Hmm… so which North American Enterprise Linux vendor might that be then ;-)

So what about RHEL systems for which the subscription has expired? I’m not sure what the legal standpoint is but there is a way to receive updated software using an unregistered copy of RHEL. Firstly, configuring additional repositories like Dag Wieer’s RPMForgethere are even RPMs available to set up the correct repository! Then, there are the various RPM search sites on the ‘net, including:

I’ve found that using these, even if there is not an appropriate RHEL or generic RPM available, there is often a CentOS RPM (which often still carries the el5 identifier in the filename). These should be safe to install on an RHEL system and in those rare cases when a bleeding edge package is required, there may well be a Fedora version that can be used. So it seems that I can continue to run a Linux distribution that is recognised by most software vendors, even when my RHN subscription expires.

Installing VMware Server on Red Hat Enterprise Linux 5

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Red Hat logo VMware logoLast year, I wrote about installing VMware Server on Fedora Core 6. At the time, I was using version 1.0.1 (build 29996) and tonight I needed to load the latest version 1.0.3 (build 44356) on my laptop, which is now running Red Hat Enterprise Linux (RHEL) 5. In theory, installing on a popular enterprise distribution such as RHEL ought to be straightforward but even so there were some things to watch out for (some of which were present in my earlier post). The following steps should be enough to get VMware Server up and running:

  1. Download the latest VMware Server release and register for a serial number (i.e. give VMware lots of marketing information… everything but my inside leg measurement… and make a mental note that I mustn’t lose the serial number this time).
  2. Prepare the system, installing the following packages and dependencies:
    • gcc (v4.1.1-52.el5.i386)
      • glibc-devel (v2.5-12.i386):
        • glibc-headers (v2.5-12.i386).
      • libgomp = (v4.1.1-52.el5.i386).
    • kernel-devel (v2.6.18-8.el5.i686).
    • xinetd (v2.3.14-10.el5.i386).
  3. Install VMware Server (rpm -Uvh VMware-server-1.0.3-44356.i386.rpm).
  4. Configure VMware Server (/usr/bin/vmware-config.pl):
    • Display and accept the EULA, then accept defaults for installation of MIME type icons (/usr/share/icons), desktop menu entries (/usr/share/applications), application icon (/usr/share/pixmaps), allow the configuration to build the vmmon module (using /usr/bin/gcc), enable networking, enable NAT, probe for an unused private subnet, do not configure additional NAT subnets, enable host only subnets, robe for an unused private subnet, do not configure additional host-only subnets, port for connection (902) default location for virtual machine files (/var/lib/vmware/Virtual Machines, creating if necessary) and finally, provide the serial number when requested.
      • All the prompts should work at their defaults; however it may be necessary to answer the question “What is the location of the directory of C header files that match your running kernel? [/usr/src/linux/include]” with /usr/src/kernels/2.6.18-8.el5-i686/include (or another version of the kernel-devel tools).
      • Building the vmmon module will fail if gcc is not present.
      • If the installer is being run under X, the serial number can be pasted into the terminal when requested.
    • The configuration script will have to be re-run if it finds that inetd or xinetd are not installed
  5. Extract the VMware management user interface from the archive (tar zxf VMware-mui-1.0.3-44356.tar.gz) and run the installation program (./vmware-mui-distrib/vmware-install.pl):
    • Display and accept the EULA, then accept defaults for installation of the binary files (/usr/bin), location of init directories (/etc/rc.d), location of init scripts (/etc/rc.d/init.d), installation location (/usr/lib/vmware-mui, creating if necessary), documentation location (/usr/lib/vmware-mui/doc, creating if necessary), allow vmware-install.pl to call /usr/bin/vmware-config-mui.pl and define the session timeout (default is 60 minutes).
  6. Extract the VMware Server console package from the client archive, or download it from the VMware management interface at https://servername:8333/ (it may be necessary to open a firewall port for TCP 8333 using system-config-securitylevel in order to allow remote connections).
  7. Install the VMware Server console (rpm -Uvh VMware-server-console-1.0.3-44356.i386.rpm).
  8. Run the vmware-config-server-console.pl script (not vmware-config-console.pl as stated in the documentation) – accept the EULA and if prompted, enter the port number for connection (default is 902).

At this point, you should have a working VMware Server installation accessible via the VMware Server Console icon on the Applications | System Tools menu, by using the vmware command from a terminal, or via a browser session. The final stage is to set up some virtual machine. I simply copied my previous image from an external hard disk to /var/lib/vmware/Virtual Machines and then opened it in the console (from where I could update the VMware Tools) but the (Windows) VMware Converter utility is available for P2V/I2V/V2V migrations (replacing the VMware P2V Assistant) and preconfigured VMs can be obtained from the VMTN virtual appliance marketplace.

Using Active Directory to authenticate users on a Linux computer

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’m not sure if it’s the gradual improvement in my Linux knowledge, better information on the ‘net, or just that integrating Windows and Unix systems is getting easier but I finally got one of my non-Windows systems to authenticate against Active Directory (AD) today. It may not sound like much of an achievement but I’m pretty pleased with myself.

Active Directory is Microsoft’s LDAP-compliant directory service, included with Windows server products since Windows 2000. The AD domain controller that I used for this experiment was running Windows Server 2003 with service pack 2 (although the domain is still in Windows 2000 mixed mode and the forest is at Windows 2000 functional level) and the client PC was running Red Hat Enterprise Linux (RHEL) 5.

The first step is to configure the Linux box to use Active Directory. I ran this as part of the RHEL installation but it can also be configured manually, or using system-config-authentication. The best way to do this is using LDAP and Kerberos (as described by Scott Lowe) but Scott’s advice indicates that would require some AD schema changes to incorporate Unix user information; the method I used is based on Winbind and doesn’t seem to require any changes on the server as Winbind allows a Unix/Linux box to become a full member of a Windows NT/AD domain.

Winbind settingsThe settings I used can be seen in the screen grab, specifying the Winbind domain (NetBIOS domain name), security model (ADS), Winbind ADS realm (DNS domain name), Winbind domain controller(s) and the template shell (for users with shell access), following which Winbind join I selected the Join Domain button and supplied appropriate credentials and the machine was successfully joined the domain (an error was displayed in the terminal window indicating that Kerberos authentication failed – not surprising as it hadn’t been configured – but the message continued by reporting that it had fallen back to RPC communications and resulted in a successful join).

For reference, the equivalent manual process would have been something like:

  1. Edit the name service switch file (/etc/nsswitch.conf) to include the following:
  2. passwd: files winbind
    shadow: files winbind
    group: files winbind
    netgroup: files
    automount: files

  3. Edit the Samba configuration file (/etc/samba/smb.conf) to include the following configuration lines in the [global] section:
  4. workgroup = DOMAINNAME
    security = ads
    password server = domaincontroller.domainname.tld
    realm = DOMAINNAME.TLD
    idmap uid = 16777216-33554431
    idmap uid = 16777216-33554431
    template shell = /bin/bash
    winbind use default domain = false

  5. Edit the PAM authentication configuration (/etc/pam.d/system-auth) to append broken_shadow to account required pam_unix.so and to insert:
  6. auth sufficient pam_winbind.so use_first_pass
    account [default=bad success=ok user_unknown=ignore] pam_winbind.so
    password sufficient pam_winbind.so use_authtok

  7. Join the domain:
  8. /usr/bin/net join -w DOMAINNAME -S domaincontroller.domainname.tld -U username

  9. Restart the winbind and nscd services:
  10. service winbind restart
    service nscd restart

It’s also possible to achieve the same results using authconfig (as described by Bill Boswell).

Once these configuration changes have been made, AD users should be able to authenticate, but they will not have home directories on the Linux box, resulting in a warning:

Your home directory is listed as:

‘/home/DOMAINNAME/username

but it does not appear to exist. Do you want to log in with the / (root) directory as your home directory? It is unlikely anything will work unless you use a failsafe session.

or just a simple:

No directory /home/DOMAINNAME/username!

Logging in with home = “/”.

This is easy to fix, as described in Red Hat knowledgebase article 5367, adding session required pam_mkhomedir.so skel=/etc/skel umask=0077 to /etc/pam.d/system-auth. After restarting the winbind service, the first subsequent login should be met with:

Creating directory ‘/home/DOMAINNAME/username

The parent directory must already exist; however some control can be exercised over the naming of the directory – I added template homedir = /home/%D/%U to the [global] section in /etc/samba/smb.conf (more details can be found in Red Hat knowledgebase article 4760).

At this point, AD users can log on (using DOMAINNAME\username at the login prompt) and have home directories dynamically created but (despite selecting the cache user information and local authorization is sufficient for local users options in system-config-authentication) if the computer is offline (e.g. a notebook computer away from the network), then login attempts will fail and the user is presented with the following warning:

Incorrect username or password. Letters must be typed in the correct case.

or:

Login incorrect

In order to allow offline working, I followed some advice relating to another Linux distribution (Mandriva disconnected authentication and authorisation) but it still worked for me on RHEL. All that was required was the addition of winbind offline logon = yes to the [global] section of /etc/samba/smb.conf along with some edits to the /etc/pam.d/system-auth file:

  • Append cached_login to auth sufficient pam_winbind.so use_first_pass.
  • Add account sufficient pam_winbind.so use_first_pass cached_login.

These changes (along with another winbind service restart) allowed users to log in using cached credentials (once a successful online login had taken place), displaying the following message:

Logging on using cached account. Network ressources [sic] can be unavailable

Unfortunately, the change also prevented local users from authenticating (except root), with the following strange errors in /var/log/messages:

May 30 11:30:42 computername pam_winbind[3620]: request failed, but PAM error 0!
May 30 11:30:42 computername pam_winbind[3620]: internal module error (retval = 3, user = `username')
May 30 11:30:42 computername login[3620]: Error in service module

After a lot of googling, I found a forum thread at LinuxQuestions.org that pointed to account [default=bad success=ok user_unknown=ignore] pam_winbind.so as the culprit. After I removed this line from /etc/pam.d/system-auth (it had already been replaced with account sufficient pam_winbind.so use_first_pass cached_login), both AD and local users could successfully authenticate:

May 30 11:37:25 computername -- username[3651]: LOGIN ON tty1 BY username

I should add that this configuration is not perfect – Winbind seems to take a minute or so to work out that cached credentials should be used (sometimes resulting in failed login attempts before allowing a user to log in) and it also seems to take a long time to login when working offline, but nevertheless I can use my AD accounts on the Linux workstation and I can log in when I’m not connected to the network.

If anyone can offer any advice to improve this configuration (or knows how moving to a higher domain/forest functional level may affect it), please leave a comment below. If you wish to follow the full LDAP/Kerberos authentication route described in Scott Lowe’s article (linked earlier), it may be worth checking out Microsoft Services for Unix (now replaced by the Identity Management for Unix component in Windows Server 2003 R2) or the open source alternative, AD4Unix.

Passed the Red Hat Certified Technician exam

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Red Hat Certified TechnicianPhew! I’ve just read an e-mail from Red Hat informing me that I passed the Red Hat Certified Technician (RHCT) exam that I took this morning.

The confidentiality agreement that I had to sign makes it practically impossible for me to talk about my exam experience but Red Hat’s RHCT exam preparation guide gives the most important details and without giving away any of the specifics, I can confirm that it was one of the most challenging certification exams I’ve ever taken (which is good, because having passed actually means something).

Apart from living and breathing Linux for the last few days, my preparation consisted of attending an RH033 course last year (including the now-discontinued RH035 Windows conversion course – my own quick introduction to Linux for Windows administrators may be useful as a substitute) and spending this week on an RH133 course (which includes the RH202 practical exam); I also have some limited experience from running Linux on some of my own computers and I worked on various Unix systems at Uni in the early 1990s. In short, I’m a competent technician (as the certification title indicates) but not a Linux expert.

As for my next steps, the Novell and Microsoft Interop Ability partnership directly impacts upon my work, so I imagine that any further work I do with Linux will be related to Novell (SUSE) Enterprise Linux. Even so, RHCT is a well-respected qualification, which is why I wanted to gain that certification (especially after setting off down that path last year). It’s unlikely that I’ll gain the necessary experience to go forward to attempt Red Cat Certified Engineer (RHCE) or Red Hat Certified Architect (RHCA) status (at least not in my day job) but I may convert to Novell’s Certified Linux Professional (CLP)/Certified Linux Engineer (CLE) path at a later date. In the meantime, it’s about time that I updated my Microsoft credentials…

Mac vs. PC (vs. Linux)

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few months back, I wrote a post about the Mac vs. PC ads (which, funny as they are, as a user of Macintosh, Windows and Linux PCs, I find to be a little misleading sometimes and downright untruthful others) before following it up when I heard an amusing Mac vs. PC parody on BBC Radio 4’s The Now Show. It was interesting to hear that Mac Format magazine judged the ads as ineffective because the largest group of consumers to whom they appeal are already Mac users (although Apple’s continuation of the Get a Mac campaign would suggest that it is working for them) and, in the comments on my recent post about some of the consumer-targeted features in Windows Vista being just as good as the functionality offered by Mac OS X, I was criticised for saying:

“Apple’s Get a Mac campaign draws on far too many half truths that will only become apparent to users after they have made the decision to switch, splashed out on the (admittedly rather nice) Apple hardware and then found out that the grass is not all green on the other side.”

Regardless of the effectiveness (or honesty) of the original ads, late last night, whilst researching for my rebuttal of those comments, I came across some more Mac vs. PC ads:

I’ve said before that the whole “my operating system is better than your operating system” nonsense is quite ridiculous really but the TrueNuff guys have it all just about summed up:

“Why would you love a Mac? Computers are computers. Macs are great. So are PCs. So are toasters – what’s your point? It’s just a computer – get over it.”

I’m enjoying the spoof ads though!

Running VMware Server Console on a Mac

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last year, I bought a 20″ wide-screen monitor which I run at a resolution of 1680×1050 pixels. Working with all that screen space is fantastic (especially with 4 virtual desktops), except that I’ve got so used to it that the standard 1024×768 pixels on the notebook PC that I use for work seems too small and an upgrade is out of the question as the PC is only 18 months old.

For a while now, I’ve been running the notebook on the desk next to my main display but I’m running out of desk space. As I virtualised my corporate Windows XP build a while back, I thought it would be great if, when I’m working at home, I could run the Linux VMware Server Console on my Mac (which is connected to the large display). The virtual machine would still be limited to 1024×768 but I could access corporate applications in the VMware Server Console and do the big screen stuff (web, e-mail, document edits, etc.) natively on the Mac, using the whole display. Yes, I know that if I used Microsoft Virtual Server I could run it in a browser, but I’d need ActiveX and I’m not using Internet Explorer. Similarly RDP is an option, but I find it to be a bit flaky on an Intel Mac. Anyway, I’m a (pseudo-)geek and so I need to feed on problems like this from time to time!

Actually, much of the hard work has already been done for me – googling for vmware console mac soon turns up Rui Carmo’s article at The Tao of Mac on how to run [the VMware Console] remotely with Apple’s X11; however Rui’s article was written a while ago now and my VMware Server (v1.0.1-build 29996) installation on Fedora Core 5 doesn’t use the command vmware-console – instead I have to use vmware. Nevertheless, it got me 90% of the way there:

  • On the (Linux) VMware Server:
    • Configure SSH and X11 forwarding (my original post used a Windows client and public/private keys but the principles are similar – this time I used password authentication, making sure that the PasswordAuthentication yes and X11Forwarding yes lines were present in /etc/ssh/sshd_config and restarting the SSH daemon with service sshd restart).
    • Locate an appropriate keyboard map in /usr/lib/vmware/xkeymap/, edit the map if necessary (there is a VMware article about keyboard mapping on a Linux host that may be useful – don’t worry that it’s a VMware Workstation document) and edit ~/.vmware/preferences to include xkeymap.language="keyboardmap" (I used gb101 for my Apple UK keyboard).
  • On the Mac:

At this point VMware Server Console ran successfully under X11 on my Mac; however whenever I powered on a virtual machine all I saw was a black screen and a message in the xterm window which read:

X11 connection rejected because of wrong authentication.

After trying a remote VMware Server Console connection to localhost and restarting the Linux host (I’m not sure which, if either, of these made a difference) I found that the virtual machine was actually starting but that for some reason the display wasn’t being repeated in the X11 VMware Server Console on the Mac; however this time there was a different message displayed:

Unable to connect to the MKS: You need execute access in order to connect with the VMware Server Console. Access denied for config file: /var/lib/vmware/Virtual Machines/virtualmachinenname/virtualmachinenname.vmx.

After setting execute permissions to the virtual machine configuration file chmod +x virtualmachinenname.vmx (changing the permission set from 640 to 751), I was able to successfully view the VM on the Mac (and simultaneously on the Linux host) – the only (very minor) issues are that the mouse pointer is solid white when accessing the virtual machine (so sometimes I lose it) and that the sound is not forwarded (no big deal). Now my notebook PC is docked on a shelf away from the desk, with the lid closed, and I’m running the VMware Server Console from the Mac, having reclaimed some space on my desk.

Creating a FAT32 volume in excess of 32GB

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few months back I wrote about some of the issues I was having with using FAT32-formatted disks for data transfer between Windows, Mac OS X (and Linux) PCs, because although FAT32 supports file systems up to 2TB in size, the format utilities within Windows support a maximum partition size of 32GB and FAT32 only supports files up to 4GB (which doesn’t sound like an issue until you start copying .ISO DVD images and digital video files around).

Even though I use MacDrive for reading OS X disks on Windows XP, I still find it useful to have a FAT32 disk to back up the VMware Server virtual machine which I use to run Windows XP on a Linux notebook PC for my daily work. I did find a great utility a few weeks back for reading ext3 disks on Windows (I think it was Explore2fs), but it’s the universal acceptance of FAT32 that makes it so easy to use everywhere. The trouble is that my virtual machine is about 31GB in size and growing – consequently I needed to create a partition larger than 32GB.

In my original post, I mentioned that FAT32 volumes in excess of 32Gb can be created – Windows is able to read or write larger volumes it just can’t create them natively (the workaround is to use another operating system or third-party tools). In my case, I used the Mac OS X Disk Utility – the important point is to ensure that the disk options are set to use as master boot record (not a GUID partition table or an Apple partition map) after which MS-DOS File System becomes available as a formatting option, allowing me to create a FAT32 disk which filled my entire 55.89GB disk – plenty of room for my virtual machine files and more.

Configuring wireless Ethernet with Fedora Core 5

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last year, I wrote a post about my efforts in configuring wireless Ethernet with SuSE Linux 10.0. I couldn’t maintain a connection (at the time I was using an IBM ThinkPad T40, a D-Link DWL-G630 PCMCIA card and a D-Link DWL-2000AP+ access point) but this week I decided to give it all another try, this time on a Fujitsu Siemens Lifebook S7010D, which was already running Fedora Core 5 and has a built-in Intel Centrino chipset (hence it should be more widely supported by Linux than the D-Link card was – avoiding the need to use NDISwrapper).

The good news is that the Lifebook’s wireless chipset does have Linux support in the form of native drivers. The bad news is that it’s still not as easy as it should be to get this working! Having said that, I went down so many blind alleys that I’m not really sure what I did in the end to get the drivers installed. Hopefully the jumble of notes below will provide one or two pointers for someone else.

Identifying the hardware

First of all, I needed to know what type of wireless hardware I had and a spot of googling quickly turned up Jean Tourrilhes Linux Wireless LAN Howto, which contains links to many resources but actually gives me the answer to my question – there are three main Intel PRO/Wireless chipsets – the 2100 is an IEEE 802.11b card, the 2200 adds IEEE 802.11g support and the 2915 supports IEEE 802.11a. The later cards also add support for increased security (WPA, etc.). I already knew that the card in my notebook supported 802.11g (pointing to an Intel PRO/Wireless 2200) but confirmed this with the lspci command, returning (in part):

01:0d.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)

Downloading and installing drivers

After arming me with information about my computer hardware, Jean’s howto set me off in the direction of two open source projects – the IEEE 802.11 subsystem for Linux and the Intel PRO/Wireless 2200BG driver for Linux project. One slight problem for me is that the drivers contained on these two sites need to be compiled… and I’m a sort of namby-pamby-need-to-have-it-already-built-for-me Linux user (sorry, but I am). Time to hit my search engine of choice again, this time turning up tutorials for installing Fedora Core 5 on a Dell Latitude D610 (it seems I’m not alone in not being “a ‘compile from source’ guy”) and installing Fedora Core N on a Dell Latitude D600 (including Intel PRO/Wireless 2200BG support) as well as a comment on a Fedora Core 5 Tips and Tricks page that suggested the following process for installing the earlier Intel PRO/Wireless 2100 (for which the process should be similar except for the actual driver files):

Some have asked for step by steps to install the drivers for the Intel Centrino Pro Wireless 2100 chip set. Here is an easy way to get up and running and have a nice GUI in GNOME. This assumes you already have NetworkManager installed from the base Fedora Core 5 repository.

yum install NetworkManager NetworkManager-gnome

Update your system to the latest kernel. Be careful as this can break other kernel modules you have installed, so be sure you have the source/RPMS handy for any packages that may need to be recompiled/reinstalled.

yum update kernel

Add the ATrpms (atrpms.net) repositiory to yum.

wget http://ATrpms.net/RPM-GPG-KEY.atrpms
rpm --import RPM-GPG-KEY.atrpms

Next, install the drivers using yum. There are several dependacies [sic] that it will install as well.

yum install ipw2100

Next, enable NetworkManager to start on boot up.

chkconfig NetworkManager on
chkconfig NetworkManagerDispatcher on

Reboot your machine so the new kernel module is loaded.

init 6

Once you boot up and login to GNOME, you should see a new icon by the clock. This is very similar to the wireless manager one can find in a very popular commercial OS. (Names omitted to protect the innocent.)

This was all very well, until I got to the point of installing Intel/PRO 2200 drivers (using yum install ipw2200 in place of the yum install ipw2100 command in the quote above), which just flatly refused to find anything appropriate.

To further complicate things, in the process, I’d updated to the latest i686 kernel (2.6.20-1.2300.fc5 in place of 2.6.17-1.2157_FC5) and I could only find RPMs at ATrpms for:

  • IEEE802.11 networking stack and kernel modules.
  • Intel PRO/Wireless 2200 firmware.
  • Intel PRO/Wireless 2200 driver.

but crucially, not the kernel modules for the Intel PRO/Wireless 2200 (I’ve since found them listed in a section for RPMs that are still being tested) and rpm -Uvh ipw2200-1.2.0-45.1.fc5.at.i386.rpm returned:

error: Failed dependencies:
ipw2200-kmdl-1.2.0-45.1.fc5.at is needed by ipw2200-1.2.0-45.1.fc5.at.i386

Time to roll up my sleeves and compile some drivers… a task which I approached with some trepidation but with a lot of help from a LinuxQuestions.org thread about getting ipw2200 working with Fedora Core 4.

After downloading and extracting IEEE802.11 (ieee80211) v1.2.16 and Intel PRO/Wireless 2200 (ipw2200) v1.2.0 (with firmware v3.0), I ran ./remove-old twice – once from the the ieee80211-1.2.16 directory and again from ipw2200-1.2.0 (I had to run chmod +x remove-old first for ieee80211). Then, I ran make and make install for ieee80211 and again for ipw2200, although this produced a lot of errors and I’m not sure that it was successful. Only once I’d done that did I find that Fedora Core 5 includes ipw2200 v1.0.8 and all that is required is to install was the firmware (yum install ipw2200-firmware), which I had done earlier with rpm -Uvh ipw2200-firmware-3.0-9.at.noarch.rpm.

Not knowing what sort of state my system was in, I rebooted and hoped for the best. Fortunately, this mixture of installation methods had resulted in a working wireless network stack, as shown by the output from dmesg (only the relevant output is shown here):

ieee80211_crypt: registered algorithm ‘NULL’
ieee80211: 802.11 data/management/control stack, 1.2.16
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.0kmprq
ipw2200: Copyright(c) 2003-2006 Intel Corporation
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection

iwconfig eth1 showed that I had even connected to a network (completely by accident), although it was not mine (G604T_WIRELESS and BELKIN54G are popular free wifi providers in the town where I live)!

Warning: Driver for device eth1 has been compiled with version 21
of Wireless Extension, while this program supports up to version 19.
Some things may be broken…

eth1 IEEE 802.11g ESSID:”G604T_WIRELESS”
Mode:Managed Frequency:2.437 GHz Access Point: 00:0F:3D:BA:1F:B2
Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0
Retry limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=55/100 Signal level=-68 dBm Noise level=-88 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:14 Missed beacon:15

Connecting to my (secured network)

Once again, I found a guide on the ‘net (Durham University’s wireless Linux quick guide) which helped me enormously with configuring a connection to my (WPA) secured network. For some bizarre reason, NetworkManager (which should provide a GUI interface to connect to whatever networks are detected) refused to connect; however I managed to maintain a stable connection by configuring the wpa_supplicant configuration file (/etc/wpa_supplicant/wpa_supplicant.conf) to read:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=users

network={
ssid="Home"
scan_ssid=1
pairwise=TKIP
psk="mysecretkey"
group=TKIP
key_mgmt=WPA-PSK
proto=WPA
}

Then, running wpa_supplicant -Dwext -ieth1 -c/etc/wpa_supplicant/wpa_supplicant.conf to connect to the network (after I’d resolved some issues in the configuration file – diagnosed using the -dd option for wpa_supplicant – discovering that the SSID is case sensitive).

After issuing the dhclient eth1 command to obtain an IP address (and verifying that one had indeed been obtained using ifconfig eth1), iwconfig eth1 returned:

Warning: Driver for device eth1 has been compiled with version 21
of Wireless Extension, while this program supports up to version 19.
Some things may be broken…

eth1 IEEE 802.11g ESSID:”Home”
Mode:Managed Frequency:2.437 GHz Access Point: 00:13:46:
xx:xx:xx
Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0
Retry limit:7 RTS thr:off Fragment thr:off
Encryption key:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Security mode:open
Power Management:off
Link Quality=100/100 Signal level=-19 dBm Noise level=-88 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:1

Start the wireless interface at boot time

In order to make eth1 active at boot time, it was necessary to run system-config-network and add the device to the common profile. At first I followed Bill Moss’ Fedora Core 2 network profiles article but then decided that it would be better to maintain a single profile, with both wired (eth0) and wireless (eth1) interfaces activated when the computer starts.

In order to start wpa_supplicant at boot time it was necessary to add the following commands to /etc/rc.local:

/sbin/ifdown eth1
/usr/sbin/wpa_supplicant -Dwext -ieth1 -c/etc/wpa_supplicant/wpa_supplicant.conf -Bw
sleep 5
/sbin/dhclient eth1

The main drawback with this approach is that the wireless radio is permanently active. Ideally, NetworkManager could be used with wpa_supplicant; however, for now the workaround is to use the Lifebook’s radio on/off switch.

Miscellaneous notes

One guide that I found suggested that the following commands were necessary in order to enable the wireless connection:

depmod -a
modprobe ieee80211
modprobe ipw2200

In practice, I haven’t found this to be necessary but this could be because Fedora Core 5 already included the appropriate configuration items by default.

iwlist, wpa_cli and wpa_gui are useful commands for examining connection properties. Other useful commands when troubleshooting are be lsmod | grep ieee80211 and lsmod | grep ipw2200.

Before the operating system would route packets across the wireless connection, I found it necessary to take down the wired connection (ifdown eth0).

SSH addendum

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Since my recent posts about using SSH to securely remote administer Mac OS X, Linux and Windows computers, a couple of extra points have come up that are probably worth noting:

  • To use the console interactively, it may be better to use PuTTY (putty) than PuTTY Link (plink). In seems that PuTTY Link is fine for setting up a tunnel and then connecting using VNC, RDP or another remote control method but I found that control codes were echoed to the console window when I connected to a Linux of Windows computer and the command line experience was generally better using PuTTY interactively. This is because (quoting from the PuTTY documentation) “The output sent by the server will be written straight to your command prompt window, which will most likely not interpret terminal control codes in the way the server expects it to […] Interactive connections like this are not the main point of Plink”.
  • For another method of generating SSH keys, an online SSH key generator is available (I haven’t tried it myself).