I've been using the long-ago EOL'ed (end-of-line) Ubuntu 10.04LTS as my main OS for several years now. So, apart from the developers still issuing security-updates for it, development-wise it is dead, with most of its application repositories not having been updated for years (but thankfully, are still on-line). Critical packages I had taken to building myself from source, but increasingly, 10.04's frozen-libraries (Python for instance) are no longer being supported either, so attempted builds often fail with unmet-dependencies.
Searching for a replacement, I settled on Mint 17 using the Mate Desktop. Frankly, I expected more from Mate - a 'fork' of the no-longer-supported Gnome2 desktop - which I thought should at least have been on-par with Gnome2 by now. No major faults, just lots of annoying little things that don't seem to work 'quite right'. After initially believing that the snazzy Compiz desktop compositor would no longer work with Mate, I was elated when I got it going, but not perfectly - currently after logging on, I need to immediately change the desktop 'Appearance', which 'fixes' Compiz's initially-broken multiple workspace feature - changing the desktop-appearance in this way somehow gets multiple-workspaces working properly again! Annoying but bearable, at least for now.
Anyway, after installing a brand-spanking new OS on a brand-spanking new SSD (Transcend 256GB) I hoped against hope that Wireless might at last also be working properly. I didn't have to wait long - within 5 minutes, Linux wireless had lost its internet connection! That was the final straw, I resolved there and then get to the bottom of this issue (somehow!).
My first act was to order a new wireless network-interface-card (NIC). Seeing as most of my suffering for the past several years had revolved around Atheros cards (specifically the ath9k driver-class), those were obviously ruled out. My experience with my Intel card (IWL3945) had been none too favourable either, but given that Intel is still heavily engaged in both developing and financing development of Linux systems, I decided to give them another go. Ended up getting a Intel 5100 NIC for a very reasonable $10 all-in.
From the get-go, this seemed much more reliable than the (2) Atheros cards. Nevertheless, there still seemed to be breaks in communication. I had always known that my router's (TP-Link MR-3420) software seemed 'suspect'. Often while cursing the Atheros cards as I restarted Linux (often the only recourse), to my dismay I'd find that I still had no signal! But rebooting the router would fix the problem! It was while Googling for others that were suffering similarly with this router that I came across the OpenWrt project.
OpenWrt it turns out is a Linux-based (yipee!!!) OS for embedded-systems. Frankly I had never thought of my router like that, so was excited by the possibility of being able to swap out firmware that I knew was buggy for one that hopefully contained less bugs. Actually it was an Aussie-based 'fork' of OpenWrt that I first came across located here, affectionately known as ROOter. These guys apparently focus on working out the configuration details of the newer modems available, then combining these configuration-scripts with the current OpenWrt releases.
The slight downside to upgrading your router's firmware is that you run a real risk of 'bricking' it should anything go wrong during programming! I've just recently found out that as long as you're prepared to get your hands dirty (and can solder) it's possible to un-brick them through a combination of software and a serial-cable. That said, I've not had to go down that road (yet) despite flipping back and forth between different firmware-flavours over the past few weeks. One interesting (and suspicious) thing about the MR-3420 router is that it employs an Atheros chip (AR6722) which also uses the very-suspect (to me anyway!) ath9k Linux driver. I'd love to know where TP-Link sourced the AR6722 driver-code that's in their firmware. Wouldn't surprise me in the least if it was the buggy ath9k driver-code that they used - it would at least explain a lot!
Anyway, although I've been playing with ROOter for about 2 weeks, I would need to leave things 'undisturbed' for at least a month or two before I could do an apples-to-oranges comparison between OpenWrt and the original TP-Link firmware - something I haven't thought of doing yet, as I've been, well, 'playing' with it. What was quite disappointing to find was that neither of my Huawei modems (E169G, E122) were recognised by ROOter, although both connected to the internet OK - all the statistics-fields of the live-connection are left blank though. This wasn't helped when 3 days a go, my 'fast' (7.5Mb/s) E122 modem suddenly died. I chose the easiest option and simply upgraded my modem via my ISP - €30 for a E5220 modem and another 12 month contract. Much more than just a modem as it turns out - faster 21Mb/s speed, battery-backed with in-built routing for up to 5 external connections. Downsides - no external antenna support, and no microSD-card slot. Unfortunately, this modem is not recognised by either the TP-Link firmware or the latest ROOter firmware. Nor can it be controlled via the router (the other two modems can), so they cannot be used in combination. The downside of connecting using just the E5220 is that the signal between the E5220 and the computer(s) is noticeably weaker - understandable, since the router comes equipped with 2 large 3dBi antennas! But as I'm composing this on that very setup, it obviously works well enough. Surprisingly, the incoming signal from the ISP's nearest cell-tower is displayed as 'strong', even though the speed-tests done so far average only about 200-300MB/s at best - so not much better than what I was receiving with the other two modems, and certainly nowhere near what I was regularly receiving at my old address (600-700MB/s).
So a mixed bag really, result-wise. I now have 2 NIC's installed in my laptop, although only one of them is ever being used. Several times already, the Atheros NIC has lost the signal completely. Switching to the Intel 5100 has resulted in an immediate resumption of the feed. As far as I'm aware, the 5100 has yet to slip up. Then again, the MR-3420 is now out of the loop completely, so it's really a different combination of software/hardware that's being tested...
No comments:
Post a Comment