Why I Hate Radio (mobile – wifi – et al): A Rant

I’m fed up with how things are with radio – at least with amateur radio (which I enjoy thoroughly) you can do something about these problems.

Sitting here in the local library and using their wireless, my system is re-negotiating about once a minute (there it goes!) which means that any web pages stall or die half-way through, and Firefox may lock up entirely until the network either returns or fails outright.

Another (larger) library nearby provides the same service without the constant reconnection to a new wireless access point – although that library has poor reception in various areas; better take that laptop on a ride through the library to get the best reception. Some sections of that library have no reception at all (like the children’s section).

Yet another (but very small) library has excellent wireless – presumably because they have only one access point which blankets the entire library (I said it was small).

None of this talk of wifi talks about the speed: 11Mb/s is a theoretical maximum for 802.11b which was surpassed in the 1980s by 10BaseT (which is now obsolete).

Mobile phone response is no better. From my house, I can see the phone tower – though it is not overhead, but a half-mile away or so. Even so, I can’t get a connection, every phone call is a mash of incomprehensible clips, and the cellular internet comes and goes (but mostly goes, dropping off or not allowing connections at all).

This cellular reception is from a company that provides blanket service across the upper midwestern United States.

When will wifi and mobile phone carriers provide strong, constant access without dead spots, and with reasonable speeds?

Tethering a Nokia 6165i to a Compaq nc4010 using Bluetooth (Kubuntu)

This was not that hard to do – for a sysadmin and geek – but not for a general user. One of the things I like about Kubuntu is its ease of use and preconfigured and debugged desktop, but here it fails. Setting up a dialup networking connection is sorely inadequate, and is completely unintuitive. Most of this problem stems from several problems:

  • The menu structure in KNetworkManager is very obtuse and non-obvious.
  • Configurations created by kppp and by KNetworkManager (running kppp) result in two different configurations in two different locations.
  • Configuration of the ppp0: network device is not available anywhere related to networking.

A lot of this problem stems from the way KNetworkManager is set up; however, the network configuration interface should also allow for the creation of a ppp0: device.

There also seems to be no way to create a tethered link to a bluetooth device without using the command line. Not a problem for me nor for many of you, but for a general user it would be a real stumbling block. (I guess I shouldn’t be surprised; from the project page comes this bit about dial-up support: The rudimentary dial-up support gives the user the ability to connect dial-up connections configured using YaST. There is much room for improvement. As of 16/11/2007 in Opensuse 10.3, this is broken.).

Most of the directions I took from this article titled Bluetooth DUN tethering – Linux and KDE (Might work with Gnome) from PinStack.com (a support site for Blackberry users).

In this case, I will assume that you know how to pair a cell phone device with your Linux laptop; it’s fairly easy (though not completely intuitive). I’ll also assume that all of the requisite bluetooth support is available and already installed.

You’ll need to get the MAC address for the bluetooth device. This could be done any number of ways; from the command line this will do:

$ hcitool scan
Scanning ...
00:12:D1:C9:DF:5E Nokia 6165i

After the MAC address is found, then the next step is to find the appropriate bluetooth channel for dial-up networking. This can be done using the sdptool command:

$ sdptool browse
Inquiring ...
Browsing 00:12:D1:C9:DF:5E ...
Service Name: Dial-up networking
Service RecHandle: 0x10000
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100

A lot of information spits out, but the relevant one for me was this entry. Now create the serial link that connects the “modem” to the operating system – in particular, a device /dev/rfcomm0 is created for communicating with the bluetooth modem (which is what the phone becomes). This is done thusly:

# rfcomm bind hci0 00:12:D1:C9:DF:5E 1

Once this is done, assuming the right channel was chosen, then kppp can be configured. Because of the conflict between kppp configuration and the KNetworkManager configuration, a setup step may be worth doing (as root):

# cd ~/.kde/share/config/
# rm -f kppprc
# ln -s ~me/.kde/share/config/kppprc

What this does, then, is make it so that your personal configuration for kppp is also used by root. Now kppp can be run from the command line (since it’s already open, right?) and you won’t have to go searching for the configuration in the menu tree:

$ kppp

After kppp is configured, you should be able to use your phone as a cellular modem. The configuration I used (for U.S. Cellular) worked, and has been described in these pages in the past.

Expanding and Protecting Your Wireless LAN

There was a great article over at ComputerWorld about making sure that you get the most from your wireless setup. Besides just being able to get reception in that far bedroom, isn’t it also nice to know you have knowledge that you can utilize in your workplace?

Most of the stuff is rather straightforward and perhaps evident to you already: but this article puts it all in one place, and shows you some ways to improve your recieption that you may not have thought of (such as Flatwire!).

If you go ahead and enhance your wireless signal range, you’ll have to deal with the possibility that nefarious people don’t find your network and go for a ride at your expense. Rob Flickenger has a short piece on the O’Reilly Network about how easy it is to break into a wireless network that isn’t properly secured. George Ou wrote over at ZDNet clear back in 2005 about the Six Dumbest Ways to Secure a Wireless LAN – and followed it up two years later with Wireless LAN Security Myths that Won’t Die. He also collected some of the best wireless LAN security articles into a free ebook called the Ultimate Guide to Enterprise Wireless LAN Security.

It may have been now three (almost four!) years since that article George wrote came out, but I still hear some of these myths even today.

OpenSolaris has a Marvell Libertas Driver! (and ZyDAS too!)

I previously discussed FreeBSD support for the Marvell Libertas chipset, and also some of the details of industry reception of this chipset.

I noticed recently that on OpenSolariswireless support page, the malo driver (from OpenBSD) for the Marvell 8335 chipset is now available (though at version 0.1). If you are using OpenSolaris on a laptop, this may be the way to go.

Also listed is a driver for the ZyDAS 1211 chipset (a USB wireless chipset), another that I’ve mentioned in the past. The driver is the zyd driver and is also at version 0.1.

There is a fabulous list of all the OpenSolaris drivers and the devices they support. With a printout of this list, you can be sure of getting a card which is well supported by OpenSolaris – and perhaps by other UNIX variants and by Linux as well.

Marvell 8335 Chipset: The State of the Union

Previously I mentioned the Marvell Libertas 8335 wireless chipset. In researching further the Marvell chipsets, it turns out that some of the Marvell drivers (though not the 8335) even have problems with Windows Vista.

The Ubuntu Linux community seems to have some nice documentation on using the Marvell 8335 chipset (the Linux driver is called mrv8k), including specific instructions for the TRENDnet TEW-421PC. The blog My Favorite Ubuntu has some nice instructions specifically about using the PM150NXT08 Wireless Adapter by NEXXT with Ubuntu Edgy.

The One Laptop Per Child (OLPC) project stirred up some serious controversy when the project went with the Marvell Libertas chipset, resulting in a very unhappy letter from Theo deRaadt. The Jem Report has an article that explains most all sides fairly well. In short, using the Marvell chipset required signing of an NDA, which means that the information thus learned cannot be used by the open source community to build or enhance drivers for this chipset.

It turns out also that the drivers for (some?) Marvell products require the use of proprietary firmware; thus, even with an open source driver the system still requires proprietary products to operate.

However, in spite of the fact that Marvell is the bane of the open source platform, it turns out that it seems to be the darling of the commercial builders. When Netgear chose the Marvell platform, Marvell released a press release about the fact and generally seemed to strut shamelessly. The press release was widely reported; here is the report as seen in the EETimes.

The Linley Group (who?) went so far as to state (in 2006) that Marvell’s chipsets were the best 802.11g chipsets in the market. This, of course, comes from Marvell (as reported by the Wireless Broadband Exchange Magazine here). If you want to see more awards and press releases ad nauseum from Marvell, check out their web site.

My current recommendation about the Marvell chipsets and those products designed around them: avoid them and go with the (perhaps older) better supported chipsets from other companies.

Supporting the Marvell Libertas 8335 Under FreeBSD

If you’ve been following along, I’ve been trying many operating systems on my Compaq Armada E500. The hardware has been preforming superbly, and does not have any problems except that everything current seems to think that 128M of memory is a pittance. FreeBSD 6.2, however, did install.

The biggest problems have been wireless and USB support. Since my USB port disintegrated (it split in two, the plastic key came out, and the pins bent!) I’ve been limited to Cardbus cards. The system came with a Zonet 1502 which I mistakenly thought used a Realtek chipset like the Zonet 1500 and 1501 (the FreeBSD ral(4) driver).

I used ndisgen(8) to create a kernel module based on the Windows driver. This went flawlessly, and the module loaded perfectly – recognizing the card immediately:

cardbus1: Resource not specified in CIS: id=14, size=10000
ndis0: <Marvell Libertas 802.11b/g Wireless (8335)> mem 0x88000000-0x8800ffff,0x
88010000-0x8801ffff irq 11 at device 0.0 on cardbus1
ndis0: NDIS API version: 5.0
ndis0: Ethernet address: 08:10:74:05:11:8f

The device, however, never seems to turn on – the power light never lights – and thus, the link light never activates. It would appear I can modify at least some of the parameters but not others – such as the channel. The power light never comes on whatever I might do.

Pulling the card and reinserting generates an error for some reason.

Investigating this card turns up the fact that it is supported under OpenBSD, and that the chipset is known for being closed. This article discusses the author’s experiences with the Netgear WG511 v2 (perhaps one of the most common cards containing the Marvell Libertas chipset) and his OpenBSD system with Kismet. The OpenBSD folks use the malo(4) driver to control such a beast, the word malo having some interesting Spanish meanings.

In a 2007 slide presentation titled “Open Documentation for Hardware” about the state of open source hardware documentation, Theo de Raadt stated that “Marvell is being dragged open kicking and screaming“. He also noted that “No other operating system has as many 802.11 drivers builtin“.

There is some discussion about using the Netgear WG511 v2 with Linux, again using the Windows NDIS drivers.

The FreeBSD Handbook was useful in investigating this generic ndis0 wireless card configuration; specifically, Section on setting up a network card using a Windows NDIS driver, and Section 29.3 on wireless networking.

Wikipedia has an article that compares open source wireless drivers which has proved to be quite informative; if this Zonet card does not work, I may use this article to help choose another card.

With the advent of this research, if FreeBSD doesn’t work out, I’ll probably go to OpenBSD after imaging the disk.