I needed to get Ubuntu to use my HTC phone as a modem. The only, only way I could get it to work was with WvDial. I even wrote a HOWTO - http://ubuntuforums.org/showthread.php?t=315927 . WvDial did one thing nothing else would, it let the user specify a blank password. 100% required for Sprint. That's why the new stuff won't work even now. It works, works well and seems stable. Why fix it if it isn't broken?
Although "disappointing," this IS an open source success story, which is an aspect that the OP didn't focus on much.
After lots of iteration, wvdial got to the point where it worked really darn well. Now, it apparently works really well for cell phone networks, without anyone having to spend lots of money to develop proprietary solutions and iterate/bugfix over time to make them work well.
It's just too bad they don't have unit tests and (thus) people are afraid to mess with the code.
It's just too bad they don't have unit tests and (thus) people are afraid to mess with the code.
Not always connected. Of the software I am using right now, only xmonad and rxvt-unicode have unit tests. Everything else, including the OS kernel, networking stack, filesystem, etc., is completely untested, but is still pretty easy to modify without breaking things horribly. I always unit test my software, but they are not necessarily essential.
Before WvDial, dialup on Linux sucked so hard. I cringed when I read WvDial in the title because it brought back memories of what it replaced. I didn't realize how long it's been...I always think of myself as having used Linux for "about ten years", but I've been thinking of myself that way for at least five years.
I'm surprised to learn that people are still using modem emulation on cell phones, though...it's been about five years since I've seen a phone that could do that (though only a couple of years since I got a phone that could be tethered via USB or Bluetooth).
My Verizon USB-3G modem is basically only usable under Linux if I use WvDial and treat it like dial-up. It's equally hilarious when you find out that connecting requires the hardcoded password of "777" regardless of your individual details.
Depends on USB or BT profiles supported by the phone.
If it supports only USB CDC ACM or BT DUN, you are stuck with dialing. If it supports USB CDC ECM, USB RNDIS (Windows has to be special...) or BT PAN, things are much better and the phone is just another ethernet interface in your computer.
We really need a modernized version of WvDial for wifi on Linux. The whole setup process is still so clunky. It seems to just randomly detect the wrong encryption scheme so shockingly enough my WPA key doesn't work as a WEP key, it can't figure out that if I have 5 open networks it should use the strongest signal automatically, if one of those 5 networks keeps dropping it won't pick one of the others or if DHCP fails it will just sit there doing nothing instead of trying another one of the networks. If someone could analyze how people actually use wifi and solve 90% of the most common setup problems it would be a huge boost for Linux usability.
Wicd seems to solve all of the problems you listed here. Unfortunately distros seem to push their own broken or feature-lacking interfaces instead of adopting and extending this one (ubuntu, looking at you). It will not reconnect you to a network with a stronger signal automatically unless you lose the connection though - which I think is a good solution, because you don't want to be disconnected at 99% of some big download, just because the signal level changed (without actually disconnecting you).
But I agree... the state of distro-default applications for both ppp-based 3G and serious wifi is disappointing. I needed wvdial to connect to O2-uk. Not because it was impossible with gnome-ppp, but because only wvdial gave me enough debug information to figure out why I couldn't connect the first time.
Yes, wicd is great and continues to get better. After having no automated wireless support for so long, it's easier to manage wireless connections on my laptop with linux (Slackware, no less!) than it is with Windows (XP), and almost as painless as OS X on my Macbook. I'm sure my opinion is subjective, but it's worth applauding the contribution made by this excellent project.
No matter how old a technology is, there is always someone somewhere still using it. Search for abacus, sliderules, punchcards in google, there's an active group somewhere discussing it.
I recently finished a project to customize Ubuntu to add support for some USB 3G modems. For the ones supported out of the box, the Ubuntu tools "just work". Supporting additional modems was rather complicated by the multiple layers in between the modem and NetworkManager.
First, when you plug in the modem, it rarely shows up as a modem. Sometimes it shows up as a CD drive containing drivers for Windows and OS X. To turn it into a modem, a special USB sequence needs to be sent. The program we used was usb_modeswitch (http://www.draisberghof.de/usb_modeswitch/). The ubuntu package is rather nice in that it automatically sets up udev rules to switch the modems when they are plugged in. Some types of modems are also detected and automatically switched by the driver in the kernel.
After the device is switched to "modem mode", it doesn't mean there's a /dev/ttyUSB* device ready. A lot of these 3g modems don't expose a standard CDC ACM interface (why that is I don't know), requiring manual invocations of "modprobe usbserial vendor=0x1234 product=0x5678" so the generic USB serial driver can be used. The generic USB serial driver has the additional suckiness of only being able to hold one vendor/product ID pair at a time. Some HOWTOs on the net guide the user towards recompiling the option.ko kernel module to add the relevant vendor/product IDs.
After there is a /dev/ttyUSB* device, doesn't mean that it will show up in NetworkManager. NetworkManager actually installs a udev rule that runs a probe command (nm-modem-probe) to make sure that the device is indeed a modem. The nm-modem-probe command sends AT-command queries, parses the answers, and exports variables like ID_NM_MODEM_PROBED=1 and ID_NM_MODEM_IS707_A=1 (for a CDMA/EVDO modem). If nm-modem-probe doesn't think your device is a modem, it won't show up in NetworkManager. Fortunately we can run our own commands after nm-modem-probe to override the variables for modems that we support.
Fortunately the modems we tried all had no problems with NetworkManager's hardcoded, unconfigurable init string. If this had not been the case we might have been forced to use gnome-ppp which is a wvdial frontend.
This is why wvdial is still recommended in this day and age. People can just say "modprobe usbserial vendor=0x... product=0x...", "copy this file to /etc/wvdial.conf", "run wvdial" and for the most part, it works well enough for a personal user that just has that one modem.
I think one of the major problems of "user-friendly" linux distributions/desktops nowadays is, that they try to make almost everything work automatically and without providing sufficient tweaking tools for the case where the automatic things fail. The usual argument being brought forward is that "my grandmom would be scared if I present her a 'Enter custom AT initialisation string:' entry field", the net result being that grandmom now has to search the web and download wvdial and the corresponding configuration file.
On the other side, the UMTS-USB-Dongle vendors (and network operators that sell those) aren't interesting in generic solutions that work out of the box with every compouter or operating system: Their products don't differ by (easily measureable) performance- or feature parameters and are distinguishable only by the added bling- and eyecandy the bundled windows-software provides.
I only used UMTS/GPRS internet connectivity a few times in the past, so my oppinion stated here is not based on any solid experience, but I know that it can work very well without much effort if a useful interface is chosen (a HTC smartphone provided a emulated ethernet card via USB to my Linux notebook). On the other hand with the currently sold popular UMTS-USB-dongles one has to jump through a lot of hoops just to disable the added bling the vendors try to impose on the Windows user and finally get to a useful modem-emulation port that, in the end, is handled by the well-proven infrastructures very well.
{e.g.: having to register the USB vids/pids with usb-serial instead of using the generic modem class, using special registers on the stick to disable the emulated driver-cdrom on the stick instead of using USB alternate settings, sending magic commands to enable the correctly working AT command interface instead of defaulting to, re-configuring GPRS APN, and finally dialling the magic *99-telephone number, or whatever it was, I forgot most of it already. The last item finally will work with any GUI friendly dialer, I'd say, but who cares about doing the first steps on the console?}
