Last week I wrote about how Windows Server 2008 can be used as a great workstation OS too… then I realised that I didn’t have any wireless networking capabilities. Although Device Manager reported that my device was working properly, there were no networks available for connection. I wondered if that was because my Intel 4965AGN card was one of the devices that won’t play nicely with Windows Vista SP1 (and hence possibly not Windows Server 2008 either) but it turns out to be a little simpler than that – as Ambrish Verma highlights on a TechNet Forum post, the Wireless LAN service is not enabled by default on Windows Server 2008. After adding this feature in Server Manager, I could browse the available wireless networks and connect successfully.
It’s getting on for midnight and I’m here in a hotel room in Prague, after fighting to get my Internet connection working (again). There’s a T-Mobile hotspot here but I’ve been having problems with it all week. A few nights back I couldn’t successfully login after buying a 24-hour pass from the hotel, so I returned the pass for a refund. Then, later in the day it seemed to be working again, so I paid 595KÄ (about Â£15, or $30) for another 24-hour pass and was able to browse the ‘net and connect to work over the VPN. Sorted. Or at least I was until I went out for the evening and returned to my room to do some more work only to find that the connection was so slow as to be unusable.
The Google homepage took about 90 seconds to load and everything else timed out – either as unreachable, or coming back as a google search on the domain name.
As Google seemed to be the only site responding (pinging the gateway came back with Reply from gatewayipaddress: Destination net unreachable), I ran a ping test using
ping www.google.com -t and after a while I could see that I was losing about half the packets on the wire:
Ping statistics for ipaddress:
Packets: Sent = 157, Received = 74, Lost = 83 (52% loss),
Approximate round trip times in milli-seconds:
Minimum = 45ms, Maximum = 69ms, Average = 49ms
Restarting the computer didn’t seem to help. Neither did disconnecting and and reconnecting the wireless network connection. So I called (T-Mobile’s English helpline for the Czech Republic) but after 35 minutes on hold at international mobile rates (goodness knows how much that cost), I gave up.
Thanks for nothing T-Mobile.
After a week of fighting with this (and a successful call to T-Mobile, during which they admitted that I could have held on all night because there were no English-speaking staff working…), I’ve discovered that logging out manually (from the link on the page displayed after a successful login, or by typing
logout. in the browser address bar) works fine; however if T-Mobile log me out for inactivity, and occasionally when the connection suddenly drops of its own accord, the only remedy is to shut down the computer, wait a while (the shortest I’ve tried was about half an hour) and then start up again, after which everything seems to work as expected.
According to the receptionist at the hotel where the hotspot is, only the people in my group (all attending Microsoft training) have reported any problems. Hopefully this information is useful to some other poor soul who’s trying to get their T-Mobile Wi-Fi connection to work.
(For reference, I’m using Windows Vista Enterprise Edition, 32-bit, with an Intel Centrino 2200BG chipset and Internet Explorer 7.0.6000.16546.)
I’ve just got back from a couple of weeks holiday – a rare opportunity to spend some quality time with my wife and sons. Over that time, blogging has taken a back seat – although I had taken my laptop with me it was on the basis that it was somewhere to back up the digital photos and anything remotely work-related was strictly banned… but I’m an Internet junkie and I just had to get online.
Turning on the laptop revealed weak signals from a number of free wifi providers in the area with names like “Netgear”, “Linksys” and “D-Link”. Of course, these were unsecured access points using default configurations but more worrying were the wireless networks that Windows Vista classed as security-enabled, named “BTHomeHub-xxxx“.
The BT Home Hub is a popular ADSL router in the UK and, although I’ve never used one, judging by what I saw WEP appears to be the default configuration (I certainly didn’t find any evidence of anybody using anything else) – BT Home Hub users should be made aware that wired equivalent privacy (WEP) is by no means secure and can be cracked very quickly, as Michael Ossmann details in his WEP dead again articles part 1 and part 2 and as Steve Gibson explained in episode 89 of the Security Now podcast (transcript).
I should stress that I did not use any of the methods that Mike or Steve describe to hack into anybody’s network but I was tempted. Next time I may even give it a try… all in the name of security research of course.
It’s Saturday afternoon, the sun is shining, and I’m in my den, blogging. Which makes me a bit of a saddo.
Actually, I’m just posting items that I wrote in my hotel a couple of nights back… and I’ll soon get back to doing something more wholesome with my weekend. You see, normally I like to stay at Hilton hotels because:
- In my experience, the rooms are comfortable, with a contemporary dÃ©cor.
- The staff deliver great customer service (something that is increasingly rare to find in the UK).
- I can get a reliable high-speed Internet connection in my room.
Sure, the iBahn Internet connection is pretty expensive (Â£15 for 24 hours) but if I’m working late into the evening for nothing more that the price of a broadband connection, then I figure that the company is getting value for money. In fact, it’s not unusual for me to work at the hotel the next morning too, because the connection is faster than the one I use at work!
Unfortunately, last Thursday night, the Internet connection in my room wasn’t working, so I tried the BT Openzone hotspot instead. After repeatly trying to connect, I eventually got a connection but lost it before I even had the chance to pay. Eventually, I gave up, figuring that there must be something up with my Wi-Fi stack. Later, I googled “BT Openzone Linux” and found that:
“Some hotspots may not support Linux-based Intel Centrino mobile technology systems”
[buried deep within a BT press release]
Thanks (for nothing) BT. IEEE 802.11b/g access shouldn’t care about my choice of operating system!
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.”
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/
Then, wait a few seconds, and type:
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.
Following that, a connection was established (and NetworkManager even activates/deactivates the wired network connection as appropriate).
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.
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.
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.
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.
- 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 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 <email@example.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
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:
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
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:xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx–xxxx Security mode:open
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:
/usr/sbin/wpa_supplicant -Dwext -ieth1 -c/etc/wpa_supplicant/wpa_supplicant.conf -Bw
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.
One guide that I found suggested that the following commands were necessary in order to enable the wireless connection:
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.
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 (
It’s well known that the proprietary extensions employed by some vendors to increase the speed/range of their wireless Ethernet (IEEE 802.11) equipment can cause issues (and sometimes refuse to work with one another at all); however there is something else to consider when working with older wireless kit – the network will automatically slow down to match the slowest device. Added to the fact that wireless networks already share bandwidth (WiFi is not switched), even a fast network could well have dropped to the lowest common denominator and may be operating at 11Mbps (or slower) because of a single 802.11b adapter.
When I upgraded my wireless network to 54Mbps 802.11g, I left my wife’s PC untouched because I didn’t want to inadvertently affect her business. When I finally upgraded her PC this evening I removed the legacy Compaq WL110 card and saw an instant improvement in file transfer speeds across the wireless link from our office to my server!
With high-speed 802.11n (draft) equipment coming onstream, it’s important to remember that upgrading the network is not enough and for the full benefits to be achieved will be necessary to upgrade every connected device too – including all those laptops with built-in wireless capabilities – potentially a very costly exercise.
A couple of weeks back, I wrote a post about the 40th anniversary of the creation of Milton Keynes, Britain’s last “new town”, the Borough of which includes the town where I live. That post included some rather tenuous technology links, one of which was VNU’s report that Milton Keynes is to become the site for the UK’s largest area of high-speed wireless broadband access – for free (in addition to the first WiMAX deployment in the UK).
According to the local press:
“Free Internet access is spreading across Central Milton Keynes as Britezone grabs people’s imagination. Already the two shopping centres and [the main street adjacent to the shopping centre] offer free connection for wi-fi phones and laptops… Britezone was launched less that three months ago and has been an immediate success… It couldn’t be simpler to register: as soon as you enter the Britezone your phone or laptop will offer Britezone as an ISP option and you click on it to be connected for free”.
[Milton Keynes Citizen, 1 February 2007]
Skeptical as ever, yesterday afternoon I decided to check it out, hunting down hotspots in Central Milton Keynes.
To be fair, the map that accompanied the text I just quoted showed two distinct rings of coverage, with more planned as sponsors are found. Interestingly, one of the main sponsors is the local newspaper, and a search of their website for Britezone turns up no results – not even a link to the (badly written – both in terms of textual information and coding) Briteyellow website. I headed for the point where the two rings overlapped most – “The Boulevard” – an area full of coffee shops situated between The Centre: MK and Midsummer Place. I fired up my Windows XP laptop, searched for Wireless networks and… no Britezone, although I did find a variety of wireless networks, both secure and insecure.
After walking a little further, into the middle of a busy thoroughfare, I spotted what could have been a wi-fi antenna on the roof of the shopping centre and finally picked up a weak signal (much to the bemusement of passing shoppers), connected and opened a browser, entering the walled garden and registering for my free 12-hour access code.
The registration process was not simple – it required giving away chunks of personal information in mandatory form fields (name, mobile phone model and number, address, sex, age, inside leg measurement… well maybe not inside leg measurement but far more information than I was happy to part with for some free wireless access) and although the mobile phone model didn’t show up as a mandatory field, I couldn’t register until I provided the details.
Once online, I could browse the ‘net (I didn’t try much else) but I set about tracking the signal to see how extensive the Britezone is. As I found the strongest point, I spotted, mounted on the roof, outside Marks and Spencer, a Strix Systems access point. I wandered a little further around the shopping centre, and although I found many wireless networks on my travels, there was no evidence of Britezone anywhere outside this very small zone of coverage!
At the time of writing, Milton Keynes’ free wi-fi coverage seems pretty poor. I’m sure it will get better but it got me thinking about who this service is actually aimed at. Wandering around a shopping centre with a laptop, I felt pretty vulnerable (and got a lot of strange looks). Once the rest of the city centre is covered then it may be of use for office workers but most businesses will already have Internet connectivity (and I wouldn’t trust a free hotspot to run a corporate network). I can see that metropolitan coverage will be good for home users (as the local cable network was built with aluminium cables – not copper – and so has technical difficulties to overcome before it can be used for broadband access) but there will be competition as Pipex Wireless is trialling WiMAX services in parts of Milton Keynes (the first users have been connected already). Given that Briteyellow, who operate the wi-fi service I tested, were so keen to gather my mobile phone model and number it seems likely that the main beneficiaries will be smartphone users and one of the registration options was to be notified of special offers. At this point, I realised the whole point – it’s not about free Internet access, but advertising – imagine the scenario – as you pass HMV (for example), the details of the latest CD releases pop up on your mobile… and there’s 10% off if you show the advert in store – you get the picture? Free Internet access is just the hook. Another service on offer is a low-cost softphone and instant messaging solution – why use your (expensive) mobile cellular phone when you can use a free wi-fi network and pay them for your phone calls?
Britezone is certain to have its uses. Whether it will ever cover the entire city (or even the whole city centre) is yet to be seen but until it covers the many parks and green spaces, or a few coffee shops where I can sit in comfort with my laptop (without constantly looking over my shoulder), I don’t think I’ll be using it again. I do wish them luck though – the service certainly has potential, as long as they can expand the coverage. In the meantime, I’ve registered my interest in the Pipex WiMAX service. Further information on broadband coverage in Milton Keynes can be found via the Milton Keynes broadband action group.
Alex and I were debating the pros and cons of various operating systems during our geekfest (working on my latest website project, in the pub) last weekend – he’s just bought a new Mac (and works with them all day), so, like most Mac users I know, he can’t see why anyone would possibly want to use anything else (not quite true, but that’s the gist of it). Meanwhile I sat down at his Mac and couldn’t even work the mouse properly to open up Firefox and pull some information off the ‘net. I complained that standard keyboard shortcuts didn’t work (I had to use the Apple key instead of control) and he said it’s because I only use Windows. I disputed that – I like GNOME on Linux – and the reason I like it is that it works like Windows, only better. It’s got a cleaner interface but most of the keyboard shortcuts that I know still work. But even Linux is not ready for complete newbies. It’s come a long way since I first used it back in 1993 – in fact it’s advancing at a tremendous pace – but even Linux Format magazine acknowledges this month that it needs to be approached “with an awareness that it takes time and patience to use properly”. Linux is not for everyone. I’ve got nearly 20 years of PC experience under my belt (12 years designing, supporting and implementing systems using Microsoft software), and I’m still struggling with Linux (although getting on much better since I spent last week learning a bit about Red Hat Enterprise Linux).
So, what’s the point of this rambing? Well, last night, after weeks of wrangling, I finally got a non-Windows operating system to connect to my wireless network. I gave up trying to do this on Solaris (after the Solaris NDIS wrapper toolkit failed to compile on my system and I couldn’t get a satisfactory answer to my post at the OpenSolaris.org forums) and instead went for a popular Linux distro (SuSE 10.0, which Novell very kindly sent me a copy of a few weeks back).
There are many reports on how to do this out there on the ‘net, but none of them worked exactly for me. What follows is what I did with SuSE 10.0 on an IBM ThinkPad T40, with a D-Link DWL-G630 PCMCIA card and a D-Link DWL-2000AP+ access point, configured to use WPA-PSK (TKIP) and proven to work using a selection of Windows clients.
SuSE 10.0 comes with packages for NdisWrapper (v1.2), wireless tools (v28 pre-8) and WPA supplicant (v0.4.4), I used YaST to check that these were all installed and located the netrt61g.inf, rt61.cat and rt61.sys files from the CD supplied with my network card. I don’t think the .cat file is required, but I copied them all to /tmp anyway.
Next, following the advice for installing NdisWrapper on SuSE Professional 9.2, I ran the following commands from a terminal window (logged in a root) to install the network card:
ndiswrapper -i drivername.inf
In my case this was netrt61g.inf, and the response was Installing netrt61g. Next, I entered:
to check the status of the NDIS drivers and saw the response:
Installed ndis drivers:
netrt61g driver present
The next part is to load the module, using:
This doesn’t return a response, but using
iwconfig should return details for a new interface (in my case it was wlan0). At this point, I hadn’t yet inserted the card, but all seemed fine with the card driver configuration.
I then used YaST to configure the new wlan0 interface (although I could have made the edits manually, YaST saves me from missing something). The instructions I followed used YaST to edit the system configuration (System, /etc/sysconfig Editor), although some settings need to be added into text files manually, so they might as well all be done that way:
That should be it for a basic wireless Ethernet configuration (although it may also be necessary to set any other network interfaces to start on cable connection, on hotplug, etc., rather than at boot time). For those of us using a secure network, there’s still more to do as it’s necessary to configure WPA Supplicant. It should be as simple as configuring /etc/wpa_supplicant.conf, then issuing a few simple commands:
ifconfig wlan0 up
wpa_supplicant -Dndiswrapper -iwlan0 -c/etc/wpa_supplicant.conf -dd
Sadly, that didn’t work for me. Even now, I’m not sure that the contents of my /etc/wpa_supplicant.conf file are correct – that’s why I haven’t published them here; however it maybe useful to know that the package also includes command line (wpa_cli) and graphical (wpa_gui)
utilities for troubleshooting and managing the interface. wpa_cli was pre-installed as part of the package on my system, but I didn’t get anywhere until I obtained wpa_gui from the latest stable release of wpa_supplicant (v0.4.8).
cp wpa_gui /usr/sbin
Only after typing
wpa_gui -iwlan0 was I able to scan for an AP and locate the available networks:
Then I could connect using the appropriate WPA key:
The connection doesn’t last long (it drops a few seconds after the 4-way handshake shown above), but at least it seems I have a working configuration (if not a stable one…).
So, it wasn’t easy. In fact, I’d say that wireless support is one of Linux’s weak spots right now, not helped by the fact that the device manufacturers generally only support Windows. Even now, I have some issues – like that my connection drops and then I can’t re-establish it – but I think that might be an issue with using Windows drivers and NdisWrapper. At least I know that I can get a connection – and that’s a step in the right direction.
Last week I wrote about upgrading my wireless network. It’s been running well since then, so this afternoon I decided to go ahead with stage 3 – configuring wifi protected access (WPA). As I haven’t set up a RADIUS server here, and to be honest, it would be overkill for a small network like mine, I decided to implement WPA-PSK (pre-shared key), as detailed in Steve Lamb’s post (and blogcast) on the subject.
Initially, it all went well, simply setting the access point to use WPA-PSK and defining a passphrase. Within a few minutes, I had entered the passphrase on two of my notebook PCs and all was working well (one using a Compaq WLAN MultiPort W200 and one using an Intel PRO/Wireless 2200BG network connection) but then I hit some real problems. My wife’s PC (the whole reason for us having a wireless network) and my server were refusing to play with the access point displaying the following message when I selected the wireless network and entered the network key:
The network password needs to be 40 bits or 104 bits depending on your network configuration.
This can be entered as 5 or 13 ASCII characters or 10 or 26 hexadecimal characters.
This seemed strange to me – there was no mention of any no such restrictions when I set up the WPA-PSK passphrase (the network key). With one machine running Windows XP SP2 and the other running Windows Server 2003 SP1, WPA support shouldn’t have been a problem (I double-checked the server with the D-Link AirPlus DWL-520+ wireless PCI adapter and once I’d manually switched the properties to WPA-PSK using TKIP, I was able to enter the network key and connect as normal).
It seems that for some reason, the D-Link card had defaulted to using WEP, and sure enough, once I set it to use WPA-PSK, the network description changed from security-enabled wireless network to security-enabled wireless network (WPA).
So, three machines working, one to go.
I read in Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article that WPA is “both more secure and easier to configure than WEP, but most network cards made before mid-2003 wonâ€™t support it unless the manufacturer has produced a firmware update”. The problem machine was using a Compaq WL110 Wireless PC Card, which I was given around 2002/3 (when we first put in the 802.11b network) so it sounded plausible that I might need a firmware update. A little more googling turned up the does/can the WL110 support WPA? thread on the HP IT Resource Center which gave me the answer. No, there is no firmware upgrade (card support was dropped before the WPA specification was finalised), but if you download the Agere version of the drivers, and tell Windows XP that the WL110 is a 2Wire Wireless PC Card, WPA is available and it works (even inside the WL210 PCI adapter)!
So, that’s all done – a working, (hopefully) secure, wireless network, all for the price of a new access point.