Quote:
Originally Posted by tredegar
There you go, it wasn't so difficult after all.
It would be a good idea to post the ONE LINE that worked for you, so others searching for the solution can find it.
|
And save others having to read the web page? But where is the fun in that? You made me read it you sadist!
This following stuff will all make more sense if you read tredegar's link above in it's entirety first. It's a fairly dull read but only takes 20 minutes or so.
Well, from that web page you can find out how to query easily the udev database specifically for a device node. Originally my USB HSDPA modem was
/dev/ttyUSB0. So, I did:
Code:
udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0)
This shows you a bunch of paragraphs which are a chain from bottom to top with the bottom being your device and then several of the parent ones appearing to also be my device. It says at the top of the output before the block of configuration blocks:
Quote:
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
|
So that means I can use any/all of the attributes from the first paragraph, but I can only pick one other paragraph to use attributes from.
Well, here were the first four paragraphs under that lovely instructive notice:
Quote:
looking at device '/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/ttyUSB0/tty/ttyUSB0':
KERNEL=="ttyUSB0"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/ttyUSB0/tty':
KERNELS=="tty"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/ttyUSB0':
KERNELS=="ttyUSB0"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0':
KERNELS=="1-6:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="option"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="03"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{modalias}=="usb:v12D1p1003d0000dc00dsc00dp00icFFiscFFipFF"
|
The paragraph following was also related only to my USB modem, but there is already enough spam there so I won't add anymore. I could just match
KERNEL=="ttyUSB0" for my purposes, but I decided to be a little more creative and perhaps it will help others also. First I needed to know where the rules lived on my system so...
Code:
[root@jaydee ~]# strings `which udevd` | grep '^/.*rules'
/etc/udev/rules.d
/.udev/rules.d
/lib/udev/rules.d
Seems like they live in /etc/udev/rules.d.
That web page above says it's likely you want your rules to load first. So they need to have a lower number than most of the files in that directory (the file names begin with a number). I went for:
Code:
[root@jaydee ~]# cat /etc/udev/rules.d/10-local.rules
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", DRIVERS=="option", ATTRS{bInterfaceNumber}=="00", NAME="hsdpa", RUN+="/usr/bin/wvdial &>/dev/null&"
Why
ATTRS{bInterfaceNumber}=="00"? My Huawei E220 modem provides two USB serial ports, you can read the other one for connection quality information and similar but you cannot connect with it. The other device is provided at /dev/ttyUSB1 so:
Code:
[root@jaydee ~]# udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB1) | fgrep 'ATTRS{bInterfaceNumber}'
ATTRS{bInterfaceNumber}=="01"
They have a different number here so the action won't trigger on the wrong USB serial interface.
And now I want to make that rule active:
Code:
[root@jaydee ~]# udevadm control --reload_rules && udevadm trigger --subsystem-match=usb-serial && echo "Everything seems peachy"
Everything seems peachy
SUBSYTEM=="tty" being from my top paragraph and the other options being from the fourth. The
NAME="hsdpa" allows for this to happen:
Code:
[root@jaydee ~]# ls -l /dev/hsdpa
crw-rw---- 1 root uucp 188, 0 2009-05-13 21:24 /dev/hsdpa
Before-hand it was called
/dev/ttyUSB0 which is the kernels name for it. I preferred this more descriptive name. The only other bit to explain is
RUN+="/usr/bin/wvdial &>/dev/null&". This launches wvdial into the background sending it's output to null. Notice the & on the end of the command. That sends it into the background. It's important. From the webpage above again:
Quote:
The functionality introduced here allows you to run a program after the device node is put in place. This program can act on the device, however it must not run for any extended period of time, because udev is effectively paused while these programs are running. One workaround for this limitation is to make sure your program immediately detaches itself.
|
So it's important to do that.
The only problem with the setup is that it doesn't connect on boot. Since I can just unplug and plug the dongle back in in about 0.25 seconds from where I sit after I get my login prompt which will cause it to dial I haven't bothered to find out why (if you know feel free to enlighten! No doubt I could trigger the tty subsystem from /etc/rc.local but shouldn't it work without that?)
Oh, and in case you need a /etc/wvdial.conf for GSM connections:
Code:
[root@jaydee ~]# cat /etc/wvdial.conf
[Dialer Defaults]
Init2 = ATZ
Init2 = ATE0V1&D2&C1S0=0+IFC=2,2
Modem Type = Analog Modem
Phone = *99#
ISDN = 0
Username = ignored
Password = ignored
Modem = /dev/hsdpa
Baud = 460800
Stupid Mode = 1
With some GSM modems you need to tell it where to connect to but mine finds it's own way. If you have to do that there's plenty of pages on the internet that will tell you how to do it.
So there you have it. Automatic GSM modem. It's quite a generic rule too so there's a good chance it will work on your GSM/HSDPA modem too if it's similar and if it isn't you should have all the info you need there to cook your own rule.