Bend in the Weather (Entries tagged as networking)

Linux Printing - where is the fun in that

mbottrell@gmail.com (Matt) — Thu, 22 Jan 2009 04:16:00 +1100

Ahh the good ol' days.

I distinctly remember the days when you would stick a printer on the network and then wrestle with the sucker getting the right settings so your printouts didn't look like Egyptian hieroglyphics.
Installing custom filters and weird control files were all the norm. Not so much now.

Thanks to Michael Fox advice, I purchased a Brother Mono Laser printer this week (that handles Duplex/Networking as well). The Brother HL-5250DN works 100% under Linux and just required installing the PPDs off LinuxPrinting.org (though it was working fine prior to that just via CUPS and the included driver). What's even more surprising is that they have a Linux section on the Brother website.

I had the printer uninstalled from the box, read the 'setup instructions' included (plug this, remove that, etc), and had it printing duplex in < 10 minutes!

Before Michael's advice -- I had avoided Brother printers -- mainly due to having a PoS Brother plain-paper Fax machine. It seems their printers are much better than their Faxes.

So a big thanks to Michael.

So I ask Linux developers... stop making it so easy to install hardware. Otherwise everyone will be running Linux before too long!

Now -- I only need a bookcase in my office, and I've completed my new office setup!

Internet Usage Monitoring - conky style!

mbottrell@gmail.com (Matt) — Mon, 19 Jan 2009 03:18:00 +1100

In Australia Internet users are limited to the amount they may download. Each Internet Service plan normally involves a speed and download limit. Failing to keep an eye on this and exceed your limit normally effects the user in question either by:

Paying exorbitant excess fees that can be as much as $150/GB!
Being 'throttled' by your ISP, in effect turning your lovely xDSL/Cable connection into something slower than dial-up.

As you can image, most people wish to avoid these. As a result ISPs provide a usage meter normally on their site, however you have to remember to view it, which unless you're diligent in doing so, you can still run over your quota.

Previously I've relied on the fabulous Firefox extension NetUsage, however this meant you had to have a browser open. This isn't always the case, and I found it frustrating to have to load a browser just to check my usage. (I could just login to the ISP's usage meter if I had a browser open).

I've seen others produce mrtg graphs and even Cacti graphs to display their usage; however they too also rely on having a browser open.

Ideally, I want to have my usage available, when I wanted, and without loading a browser.

I use conky on my desktop to display a range of information. It seemed a logical step would be to integrate a meter into my conky setup.

As you can see from the graph in the picture to the left, it displays a raw percentage of what has been used, as well as a visual bar graph. Below that is the raw data, showing exactly how much I've downloaded (~11.5GB), what my ISP believes my quota to be (55GB in this case), and when this billing period ends (the 13^th of every month).

I can now view my current Internet usage at a glance, without the need to load any additional program.

So how did I achieve it? Like many ISPs, my ISP provides an interface to the raw data. This is used by 3^rd party utilities like NetUsage and others to parse and generate the information. Internode (my ISP) has such an interface.

A quick and dirty script and I was able to spit out the graph in a format conky liked. Whilst this works directly with Internode, similiar ISPs have such interfaces and you will be able to hack the script to suit your own environment.

Below is the simple bash shell script used to generate the data:
#!/bin/bash # Get usage information from Internode's web page. # Setup to run once every half hour. # # Set the username and password Username=INTERNODE_USERNAME Password=INTERNODE_PASSWORD # Grab the details Temp=`wget -q -O - --post-data "username=${Username}&password=${Password}" --user-agent="Conky ISP Quota Grabber 0.1" https://customer-webtools-api.internode.on.net/cgi-bin/padsl-usage` # Generate the percent used. echo $Temp|gawk '{print $1/$2*100}'> /tmp/node-graph.txt Percent=`cat /tmp/node-graph.txt` echo $(printf %.0f $Percent) > /tmp/node-percent.txt # Break up the values into their respective parts Values=($Temp) echo "Used: $(printf %.0f ${Values[0]})MB Quota: ${Values[1]}MB Period Ends: ${Values[2]}" > /tmp/node-text.txt # Time to leave. exit

Sure it's not the most secure script (It stores your username/password in plain text). For me, the script sits on my desktop machine... and is protected by file permissions. The password I use for my ISP I also don't consider highly sensative. (It's important to note that most people throw around their password in clear-text across the Internet when picking up their mail with POP3! ). It does however do the job.

The above shell script I run every 30 minutes from cron.

It is then up to your ~/.conkyrc file to display the results. Here is the snippet of the appropriate code for the ~/.conkyrc file that will do that for you:

${color orange}INTERNET USAGE ${hr 2}$color ${execi 900 cat /tmp/node-percent.txt}% ${execibar 900 cat /tmp/node-graph.txt} ${execi 900 cat /tmp/node-text.txt}

There you have it, a simple ISP usage meter sitting right on your desktop.
It's not the most elegant or complicated program, however it serves it's purpose extremely well. YMMV.

Strange IRC messages from across the Indian Ocean

mbottrell@gmail.com (Matt) — Tue, 04 Nov 2008 20:34:00 +1100

Leave your IRC client set to away for a day, and then check your private chats later that night.

It's amazing some of the strange banter you get:

[someuser] hi..
[someuser] yesterday we completed the network config change in all servers, and now network part is clear
[someuser] ;P
[someuser] ;P
[someuser] :p
[someuser] please ignore above 3 lines

For the record, I was helping a fellow admin out with configuring a series of bonded interfaces for a server (7 connections - 3 bonded, one not).

I take it the first two lines of the message tells me it's been completed.
The next 3 lines were meant for someone else, whilst the last the user recognised what they had done.

The lesson for today: Check which window you're in before typing.

Setting up simple virtual box networking

mbottrell@gmail.com (Matt) — Wed, 24 Sep 2008 03:39:00 +1000

I've seen many people that run Windows under VirtualBox to run those legacy applications that just haven't made it across to Linux.

Too often I see people messing about with Ethernet bridging because they feel the need to have some incoming ports on the machine active to the outside world.
Fair enough, however it's a complex way to accomplish that. You're much better using the simple NAT interface, particularly if it's only a few incoming ports.

NAT under VirtualBox does indeed allow incoming ports. Knowing how to set these up is the key!

By definition, a NAT internal IP uses an IP address in the private address space defined by RFC1918. Namely one from these networks:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Most people are familiar with 192.168.0.0/24 or 192.168.1.0/24 which many ADSL routers provide. Many know that you can setup port forwarding in their router to allow external IPs access to a particular port/service on their internal machine. Virtual Box is no different.

Like a network router that can be configured so that accessing a particular port on the router it can be sent directly to the machine(s) behind it. How is this accomplished under VirtualBox? You just configure a port on the host machine to be forwarded to the IP and port on the virtual machine.

VirtualBox ships with a nifty little GUI. It's simple but effective. Unfortunately much of the power to configuring your virtual machines is not found in this tool.
VirtualBox also packs some handy cli tools for managing your virtual machines.

One such tool is the VBoxManage utility. Infact this is the tool we'll be using to enable some port forwards.

Let's enable the Remote Desktop Protocol in our Virtual Machine. This Virtual Machine is called MyVM for ease of use:

VBoxManage setextradata "MyVM" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/vmrdp/Protocol" TCP
VBoxManage setextradata "MyVM" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/vmrdp/GuestPort" 3389
VBoxManage setextradata "MyVM" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/vmrdp/HostPort" 3389

As you can see we passed several arguments to VBoxManage. You'll find by just running VBoxManage without any arguments that it will list all it's available options (there is quite a few!).

In this example the arguments are:

setextradata: Inform VBoxManage that we wish to do additional configuration of our Virtual Machine.
"MyVM": The name of our virtual machine.
"VBoxInternal....": The key we wish to change. In this example, it's a new port forwarding rule on our specific ethernet card. (You'll find more information in the UserManual for Virtual Box for a list of available ones)
Final value: The actual value we wish to set for the key.

So what did the 3 lines accomplish?

We informed VBoxManage that we wanted to configure a TCP rule (named vmrdp) for our first ethernet card (pcnet)
We set the TCP port we want to send the forwarded packets to within the virtual machine. (GuestPort 3389)
We then defined the port we wanted to listen to on the VirtualBox Host (HostPort 3389)

Now basically from anywhere on you can hit your Virtual Box Host on TCP/3389 (eg: Your Linux desktop), and it will forward the packets through to your virtual machine. Neat 'eh? If you are on your Linux box and running VirtualBox in say headless mode.. you can get a remote desktop session by just connecting to localhost:3389.

Some things to also remember:

If you need TCP and UDP rules... you need to define them seperately.
You need to set a 'working' port forward with the triple configuration above (it takes 3 commands to get a working port forward.
No two rules can have the same name. This also counts for a service that runs on both UDP/TCP on the same port. In that instance name it something like myserviceudp and myservicetcp to distinguish them.
Port forwarding is set across reboots. You don't need to do this multiple times.
VBoxManage basically edits the xml configuration file for your Virtual Machine. If you don't want the port forwards any more... just edit the xml file directly is the fastest and easiest way (likewise once you get the hang of it and the format, there is nothing stoppign you editing the xml definition file directly).

Other things you should know about NAT networking include:

By default the NAT network is 10.0.2.0/24.
The actual network can be changed using VBoxManage modifyvm "MyVM" -natnet1 "10.10.1.0/24" (Change the last value to your desired network/netmask.)
The IP assigned by the VBox DHCP server will be .15, with a gateway of .2.

That's a brief introduction to some of the features you can accomplish with VBoxManage. Explore a little and you'll be amazed how much you can customise.

Have fun!

802.11n - The official delivery of pipe dreams

mbottrell@gmail.com (Matt) — Sat, 31 May 2008 15:18:00 +1000

The IEEE's 802.11n standard is supposed to bring high speed wireless to the masses.
It's been in draft longer than most can remember, and from the schedule it appears that it won't be out of draft release and make it to a final specification until Dec 2009. This is from a working party that was setup in January 2004!

Sure there was a rival groups in the early days, but as of July 2005 these rivals (TGn Sync, WWiSE, and MITMOT) all agreed to merge their proposals into the TGn draft.

Last month we saw Draft 4 of the specification approved, and there is already talk of a Draft 5... how many before we get something into our hands?

Sure, there is a bunch of 'Draft 2.0' 802.11n devices on the market. It's risky business deploying one now. Why?

Being at 'draft' status each manufacturer has a different interpretation of the standard. This can mean that different manufacturers equipment is unlikely to work well (if at all), in addition different releases from the same manufacturer has no guarantee of interoperbility
There is no guarantee that these devices (wireless cards, embedded chips and Access Points) will be upgradeable to the final specification.
Not all the details of the specification have been sorted out (thus the draft). You're likely to run into some 'interesting' issues.

Even before the release, 802.11n will be a failure. Harsh words yes... but let me explain.

Many believe it will be the silver bullet for networking, with the promise of delivering 600Mbps. Many read that as 'data throughput' - that's not the case, it's raw bit-rate.

How many people to you currently speak to that use an 802.11g network whinge that they aren't seeing 54Mbps transfers?

Expect anywhere between 30-70Mbps in real world data-transfer rates.

Many have moved their cordless phones from the overburdened 2.4Ghz spectrum up to the 5Ghz area. (Just look at any new cordless phone -- most are shipping in this space). 802.11n will operate in both the the crowded 2.4Ghz space and the 5Ghz range.

Expect to see the same issues we saw when 2.4Ghz wireless networks first came out with a range of devices interfering with the 802.11n network. (on either 2.4Ghz or 5Ghz).

MIMO (multiple input, multiple output) does help somewhat, in extending the quality, range and provides multiple streams.

The draft allows for up to 4 antennas on either end, but you'll be lucky to see one of these. Expect dual antennas to be the norm.

In addition, high-throughput will require high performing CPUs (particularly if you have encryption enabled -- which should be unless you want to be wifi-jacked). Home wireless network routers are notorious for having underpowered CPUs... whilst they will get a little jump in grunt, expect them to falter if attempting several large data transfers at the same time.

It appears 802.11n routers will be a mine-field for some time for consumers, there are loads of options and those cheaper ones are likely to miss the bells and whistles... watch out for the cheapies that can't do both bands. Many are working solely in the 2.4Ghz range. Most of those on the market presently are only Draft-2.0 models, so they are quite a fair way from the 'final spec' (We know of 5 drafts at least prior to the final spec).

Ars Technica has a great review on current 802.11n routers. What they have to say doesn't suprise me. These are speeds all running in 802.11n mode and show the average of UDP/TCP throughput results at multiple locations:

Device	2 feet	25 feet	35 feet
Apple AirPort Extreme @ 2.4Ghz	22.75Mbps	25.15Mbps	17.80Mpbs
Apple AirPort Extreme @ 5.0Ghz	44.30Mbps	34.20Mbps	12.65Mpbs
Netgear RANGEMAX Next Wireless Router	28.48Mbps	24.83Mbps	5.39Mpbs
D-Link XtremeN Wireless N Gigabit Router	56.10Mbps	17.42Mbps	FAIL!
Linksys Wireless-N Gigabit Router with Storage Link	44.37Mbps	20.10Mbps	10.70Mbps

For those Aussies wonder what the feet is in metres (well it was a US review).
1 metre ~= 3.28 feet. On the flip side, 1 foot ~= 30.48cms

So these results were measured at: 60.96cms, 7.62 metres, and 10.67 metres. Nothing out of the ordinary and actually relatively close for at least the first two. If you were < 1 metre away, just plug in an Ethernet cable!

One thing 802.11n will deliver is supposedly better range. so those struggling with dropouts on a 802.11g network may like the upgrade... though it will come at a cost. Don't expect the devices to come cheap. A 'decent' 802.11n device currently costs upwards of $200USD.... plus adding in all the cards you'll need, you could be up for some serious dollars.
From all reports if you want the range and speed - get the 5.0Ghz models.. though if it doesn't support 2.4Ghz you won't have backwards compatibility with 802.11g devices.

You will also notice most currently advertise 270Mbps or 110Mbps..... it's no where near real-world results. I would love to see one of these manufacturers demonstrate their delivery of these speeds, to date -- we haven't seen anything near them. Advertising raw bit speed is also misleading and these makers know it... they are aware when people look at speeds they normally are looking at 'real world' speed performances. I expect more outrageous claims to be made and the infamous 600Mbps will soon start to be sprouted. Realistically on a '600Mbps device' -- don't expect anything beyond 80Mbps. See that Ethernet cable isn't looking that old at all.

Me, I'll stick with 802.11g for the time being.. . I only use it currently to get to the Wii and the MythTV box. Occassionally I might use it for our laptops or visitors (if I can't be bothered running an Ethernet cable from the switch).

I'm laying Gigabit Ethernet on Cat6 throughout my new house (48 ports baby! ), and expect that all bar the Wii will be on that.

For streaming High Definition Video, don't expect your sparkling new 802.11n device to handle it, or if it does, don't expect multiple streams.

For a specification that been in the thinking tank now for 4 years, the current speeds are pretty disappointing.

Opening up your home NAS

mbottrell@gmail.com (Matt) — Thu, 29 May 2008 03:15:00 +1000

The Maxtor Shared Storage Plus

I've owned a Maxtor Shared Storage Plus NAS (MSS+) device for quite a while. It was reasonably cheap when we picked it up and it's well and truly paid for itself saving me on several occasions!

It's basically a 500GB disk inside an enclosure that you network (10/100Mbps), and contains 2 additional USB ports so you either plug additional USB storage or a USB printer into (to make it a networked printer).

In our instance we use it mainly for backing up. For this purpose it serves well.

We ran into a problem today when the device filled.
That was unusual, as we traditionally have loads of space left on it (we only backup our content/configurations), not the OS or applications... and we purge old backups.

A closer inspection showed that the backup software we were running on the Windows machine was actually not removing old archive files. That explained the lack of disk space.

It seemed under certain conditions that the Windows machine was unable to delete the files it created. This now appears more an issue with Windows then the actual backup software. (I could delete the mentioned files using Nautilus fine under Linux, just not through Explorer!)

MSS Plus Web Administration Interface

Whilst the device itself has worked flawlessly (it basically creates SMB based shares), it did become a problem when large amounts of files needed to be deleted (it was dreadfully slow over SMB - as it appeared to require a full stat of the files to be deleted, prior to even commencing the delete ). This could take hours before one file was ever deleted.

It always was frustrating that besides the web-interface to manage the device, that SMB appeared to be the only option available for file management.

Many people have used SLUGs (aka NSLU2 - LinkSys's NAS device). This allowed people to use modified firmware to create a nice embedded Linux device, allowing them to install additional software and expand on the base functionality.

How nice would this be with my MSS+

I thought I would take a peep at the support website, as I realized that this device too is likely to use OSS software such as Samba to create it. Low and behold, the source code was available.

This got my creative juices running! Could I use this to create a modded version myself and add items like NFS, FTP and SSH to the device? Surely someone else has already thought the same thing.

Apparently they have! OpenMSS is just that. Not only does it put down a telnet server by default (so you can login, they have got BusyBox working on it as well.

From my reading it appears NFS is there, just was never enabled on the original firmware image. It also allows you to install additional software, as well as a bunch of software from the ports made available through the work by the guys over as nslu2-linux.org.

It looks like with little work I'll be able to have an FTP, NFS and rsync all as options, as well as SSH to login to the box.
The list of packages available is breath-taking, and I can see a lot of work has gone into the porting.

What's even better, the web-interface and existing data stay intact when migrating over to OpenMSS -- just the ability to get into the heart of the box is opened up.

So I think it's now a case of having a play around and actually getting some 'smarts' into this device. I'm doing away with the Windows backup software and we'll look at running a central backup from the device itself to pull in backups from other hosts using rsync. (much nicer). I see ccollect is one of the packages available, so this may indeed do the trick... just through on vixie cron at the same time and I've got a nice simple and effective solution.

I felt a little cheated initially when I heard of the SLUG (after my MSS+ purchase) now I'm feeling quite happy that I can play in the same league!

It's a job for later in the week/weekend (when time permits), but it appears I may have just solved some of the issues that has been burning me for ages (access to the device and trouble free backups from Windows to it). I'll keep you posted on the outcome.

Don't ya just love OSS -- putting the power back in the users hands!

Asterisk, Snom-300 VOIP phone and Power Over Ethernet.

mbottrell@gmail.com (Matt) — Tue, 13 May 2008 18:16:00 +1000

Well it's coming up to the end of financial year, and like many businesses we needed to make a few purchases. (That or pay more corporate tax -- hmmm let me think.. more toys or more tax? )
Generally we don't make many purchases throughout the year and then buy up large near the end of the financial year. (well unless something fails!)

As such we decided to get a decent VOIP phone. We currently use a LinkSys SPA3102 with our cordless phone, but wanted to get a phone with a decent headset so we could talk hands free easily.

Snom-300. An excellent VOIP phone, with fantastic voice quality and a solidly built professional phone.

We spoke to a few people, did the research and settled on a Snom VOIP phone. In particular, we elected the Snom-300 as the phone of choice for us. Whilst it claims it's the 'base phone', unless you're mega-boss or a telemarketing guru I doubt the snom-320 or snom-360 phones are really required. (They basically have a lot of additional buttons and few features added to the base functionality).

You can configure the phone via the LCD menu system, or use the built in web based configuration. The web-based configuration is very well laid out and easy to navigate and locate what you need.

Upgrading the phones firmware is extremely easy and quite painless. You can watch the progress of the phone being flashed, and it's quite novel to see items like chroot, mount appear on your phones LCD.

Chroot, mount you say?! Yup, at the heart of every Snom is a Linux kernel. Whilst this wasn't the sole reason for buying the device, it's handy to know that with a bit of time I could in theory hack the phone.

The Snom-300 HS-MM3 headset is both comfortable and functional. Sound is clear and crisp through it.

I unfortunately get stuck is long boring teleconferences far too often, so I wanted to ensure I also had a phone that was able to plugin in a headset. Not all IP VOIP phones we looked at seemed to have that feature.

The Snom phones do, however they use an RJ-11 headset connection instead of a 2.5mm or 3.5mm jack that people are most familar with. (Many cordless phones also use the 2.5/3.5mm jacks).

As such, we decided to purchase them. They don't come cheap but are worth it. It's a much better solution than getting 'neck cramp' attempting to hold the phone under your chin, or even speaker phone (which seems to pickup more background noise), which can annoy anyone else within earshot.

With the headset, I'm able to easily keep working on my computer; punching away on the keyboard, and those on the other end are none the wiser! (Well besides being too distracted to really keep up with the conversation; dang! I think I just let my secret out....and to think -- people just thought I was vague on the phone!)

Our current setup has me registering both the ATA and the Snoms devices registering directly to our VOIP provider. This works fine, and allows multiple out going calls at the same time, but means only our ATA rings for incoming calls (we have two DIDs).

It makes sense, as the ATA picks up the incoming request and responds... well before the Snoms do. How to resolve?

Easily -- Asterisk to the rescue!

I can setup Asterisk as our local PBX (or PABX for those in Australia!), and have all devices register to it. Then the Asterisk server registers with our Voice Provider.

A bit of Asterisk config and I should be able to get all the phones to ring. In addition, it will allow me to use T.38, add MOH, and voice mail. I also like the ability to have local extensions so we can forward calls between various devices. Currently both Pauline and I share an office, but in our new house we'll be up other ends of the house. So call transfers make sense. I think it would be great to also create an IVR application that puts telemarketers into a loop of endless questions. (randomly generated of course -- so they aren't aware!) Though I think Paul Dwerryhouse's idea is probably the solution.

I'm a newbie to Asterisk (though I've been aware of it for a while -- I just haven't had a need for it)... so I imagine it might take me some time to configure it all up as we desire.

Once done, the only thing Telstra will be getting out of us will be the cheapest line rental we can pay. (They overcharge for that as well!) Though, there is not much getting around it whilst stuck on an ADSL1 connection.

Another purchase we made for the upcoming house was a nice 48-port managed Gigabit switch that contains 12 POE (Power over Ethernet) ports. These will be used to power our phones in the future, saving the need for the current power-pack.

The switch we went for is a D-Link DGS-3100-48P. Like most large switches it's full of fans and sounds like a DC-7 taking off. As a result, it's safely packed back in it's box and will be used after the house move!

We also purchased to UPSes (the old ones had dead batteries) -- strangely it's cheaper buying new UPSes than batteries.
So we ended up with 1 x 1500VA UPS and a 1 x 2200VA UPS.
It appears we'll probably need one more 1500VA.
I went with Powerware UPSes as their is reasonably good local support (and hopefully battery replacements!), and nut seems to work well.

All in all it's been a good month for hardware toys to play with.
Shame a fair bit of this new gear is a few months off until we get into the new house!

Now if only those Intel 8-core Xeons were out.... (my desired replacement server that will consolidate everything down!) If you wish to view a demo of what's coming.. take a look at the Intel demonstration.

Is Australia's Federal Government plan for a high-speed network up to scratch?

mbottrell@gmail.com (Matt) — Sat, 12 Apr 2008 22:42:09 +1000

High speed Internet is not a luxury in the modern life anymore. It is becoming a mandatory requirement for business, education and the delivery of entertainment/information to households.

Only this week the Communications Minister Stephen Conroy announced a tender bid process to "enable world-class, high-speed broadband for all Australians". This $4.7 billion dollar deal is expected to deliver FFTN access across the country to some 98% of the population.

The week prior Conroy laid the boots into the ill-fated WiMax based OPEL deal that was setup under the Liberal regime. The dumping of the $958 million wireless deal is likely to see that money moved into the FTTN deal.

I don't disagree with the dumping of the WiMax deal, as questions about it's reported effectiveness have been raised globally.

The $4.7b National Broadband Network tender is expected to deliver minimum download speeds of 12Mbps (no talk of upstream data rates) to 98% of Australian homes and businesses and should be rolled out and made operational progressively over five years using FTTN or FTTP technology.

Is this FTTx deal going to cut it?

Continue reading "Is Australia's Federal Government plan for a high-speed network up to scratch?"

Telstra at it's finest.

mbottrell@gmail.com (Matt) — Thu, 07 Feb 2008 23:44:25 +1100

We all love taking the piss outta Telstra.

Though they do make the job easy on us...

These two YouTube videos sum it up well.

Video 1: http://www.youtube.com/v/Py6kF7761Eg

Video 2: http://www.youtube.com/v/Vfz7yTqF6aE

The joys of Linux wireless (Part 1)

mbottrell@gmail.com (Matt) — Fri, 25 Jan 2008 00:36:08 +1100

Anyone who's played with Linux has come across the mixed bag that is wireless Ethernet cards under Linux.

Wireless chipset makers have been slow on the uptake supporting Linux. This is through decent hardware specs so coders can put together a decent open-source driver to releasing their own proprietary object blob that doesn't confirm with the kernel wireless framework; thus ensuing a range of flaming hoops need to be jumped through in order to get it to work.

Add to the pain the much discussed often loved/hated Network Manager to the list, and your sure to create pain for the majority of ordinary 'Ma and Pa Kettle' users.    Linux forums and mailing lists are full of frustrated people attempting to get wireless networking going successfully and stable under Linux, particularly after it was pretty much a no-brainer under Windows.

I was well aware of the grief many had experienced, and treaded carefully when entering into the mix.   I really wanted to have our MythTV box that connects to our Plasma TV running wirelessly to avoid the pain of running Ether into the lounge. (The house we are building will have the entire house wired for Gigabyte Ether -- so this won't be a problem moving forward!).

After a few weeks of researching I settled on a D-Link DWL-510.   It was supposed to have reasonable good Linux support.

This is where the story gets interesting...

The D-Link returns the following useful information from lspci:

05:06.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
        Subsystem: D-Link System Inc DWL-G510 Rev C
        Flags: bus master, slow devsel, latency 32, IRQ 20
        Memory at d5000000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 2

Recent Linux 2.6.x series kernels have been shipping a module called rt61pci.ko This is apparantly this 'new' module is to support 'newer' chipsets. (The DWL-510 has been around for several years).

The crazy thing is that the module recognizes the card and auto-loads. This confuses the hell outta people, as they end up seeing the module load cleanly, but unable to do anything with it.

By default most modern distros ship the driver... so people assume because the driver loaded without error it will work. Unfortunately this is not the case, and normally send people down the wrong path of trying to debug/resolve an issue that won't be fixed with that driver. Do a search on "Linux RT61" on Google and you'll see what I mean!

More on this and how it was resolved another day...