HUAWEI E220 Workaround for kernels < 2.6.20
HUAWEI E220 is supported natively by Linux, over usbserial.ko (usbserial-generic) interface. Linux kernel versions prior to 2.6.20 have some problems with it, as the SCSI CDROM fakevolume with drivers for Microsoft systems gets automounted by usbstorage.ko module, preventing serial device /dev/ttyUSB0 from working properly. Try out my workaround-kit!
Simply download the package and do the following:
$ tar xjvf huawei.tar.bz2
$ cd huawei
# make info
Latest version 0x0008 works fine with SUSE 10.1, openSUSE 10.2, Fedora Core 5, Ubuntu 6.06, 6.10, 7.04, Mandriva Free2007Spring, and many many more! Check your system!
What is this supposed to do on my system?
The package contains an udev rule 99-huawei.rules. This rule tells the system to ignore the pseudo SCSI CDROM with the drivers and assigns usbserial.ko driver tothe modem and a PC user interface device. If the udev works, you should find two ttyUSB* devices in your /dev directory (sometimes 3 if usb_storage.ko is not active). If you don't have any other USB serial devices connected to your PC at the moment, modem should be assigned to /dev/ttyUSB0 and the user interface device to /dev/ttyUSB1
I have a 2.6.20 and later kernel. Do I still need huawei.tar.bz2?
No, on kernels newer than 2.6.19 both usb_storage.ko and usbserial.ko are aware of HUAWEI E220 modem and no further action needs to be taken. You should find three /dev/ttyUSB* devices directly after you plug E220 into a usb port. I recommend you, however, to take a look at the configuration files regardless of your kernel version. Configuration files for pppd and wvdial are included.
What is /dev/ttyUSB2 ? Do I need it?
No, it's just a leftover after the pseudo scsi disc. It should come up only if usb_storage.ko is not active (or is aware that it's not supposed to be active in kernels after 2.6.19
I do have a kernel newer than 2.6.19 but when I try to plug the modem into a USB port there is only ttyUSB0 in the /dev dir? The modem wokrs only when I boot up with it plugged in. Why?
It looks like option.ko module does its job here.
run lsmod|grep option to find out
To resolve this issue you can blacklist the option module. However, if your udev persistently loads it up you can remove option.ko and perform depmod afterwards.