LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (http://www.linuxquestions.org/questions/linux-networking-3/)
-   -   NetworkManager doesn't detect GSM modem (http://www.linuxquestions.org/questions/linux-networking-3/networkmanager-doesnt-detect-gsm-modem-724911/)

senseproof 05-09-2009 05:43 PM

NetworkManager doesn't detect GSM modem
 
Hi fellows,

Hope you can help with this one. I can connect to the internet using wvdial but NetworkManager is a no-no. Here is some information that's relevant:

Code:

# lsusb | fgrep Huawei
Bus 001 Device 010: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem

Code:

# NM_SERIAL_DEBUG=1 NetworkManager --no-daemon
NetworkManager: <info>  starting...
-- Error received: File exists
-- Original message: type=0x14 length=56 flags=<REQUEST,ACK,ATOMIC> sequence-nr=1241908582 pid=4198544
NetworkManager: <WARN>  nm_generic_enable_loopback(): error -17 returned from rtnl_addr_add():
Sucess

NetworkManager: <info>  (eth0): new Ethernet device (driver: 'XXXXXX')
NetworkManager: <info>  (eth0): exported as /org/freedesktop/Hal/devices/net_XX_XX_XX_XX_XX_XX
NetworkManager: nm_device_wifi_new: assertion `driver != NULL' failed
NetworkManager: <info>  (ttyS0): ignoring due to lack of mobile broadband capabilties
NetworkManager: <info>  (eth0): device state change: 1 -> 2
NetworkManager: <info>  (eth0): bringing up device.
NetworkManager: <info>  (eth0): preparing device.
NetworkManager: <info>  (eth0): deactivating device (reason: 2).

/dev/ttyUSB0 is the Huawei. NetworkManager didn't look at it?

Code:

#  /lib/udev/nm-modem-probe --verbose --export /dev/ttyUSB0
L: main(): (/dev/ttyUSB0): usb-vid 0x0000  usb-pid 0x0000  usb-intf 0  driver '(null)'
L: main(): probing /dev/ttyUSB0
L: modem_send_command(): Sending: 'AT+GCAP
'
L: modem_send_command(): Sending: 'AT+GCAP
'
L: modem_send_command(): Sending: 'AT+GCAP
'
L: modem_send_command(): Sending: 'AT+GMM
'
ID_NM_MODEM_PROBED=1
L: main(): /dev/ttyUSB0: caps (0x0)

Code:

# /sbin/udevadm info --export-db | awk '/ttyUSB0/,/^$/'
P: /devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
E: NM_MODEM_DRIVER=option
E: NM_MODEM_USB_INTERFACE_NUMBER=00
E: ID_NM_MODEM_GSM=1
E: ID_NM_MODEM_PROBED=1


tredegar 05-10-2009 12:19 PM

Network Manager is, IMHO, a piece of s***

I suggest you use wvdial

You could put the command(s) you need to get connected in /etc/rc.local and if the dongle is plugged in when you boot, you'll be connected.

Otherwise you could create some desktop icons that run scripts to have you connect / disconnect.

Please put your linux distro in your profile (see mine, at the left?)

senseproof 05-10-2009 02:00 PM

I am using wvdial, it was surprisingly easy, wvdialconf /etc/wvdial.conf and then I just changed the number to dial *99#. It wasn't perfect but it was enough to get online and access google to find out how to do the other settings.

The thing is I pull the dongle out and push it back in again. Mind you, I could use halevt to start wvdial when I do that, eh?

And the mysteriously vanishing wvdial.conf but I don't expect that was the programs fault.

Unfortunately I am infected by the GUI disease and prefer pretty graphical things for system configuration as they allow me to lead a lazier life in regards to learning and keeping up with how to configure every little program. Or they are supposed to!

OK, I'll just wait until it's more mature. You have convinced me. Distro added to profile...

tredegar 05-10-2009 02:38 PM

Quote:

I am using wvdial, it was surprisingly easy
Linux is supposed to be easy. Mostly, it is, and it gets better every week.
Quote:

The thing is I pull the dongle out and push it back in again.
Why would you want to do that?

If you really want to do that, you can, but you'll have to read up about writing udev rules first.
udev is a daemon which allows any device-specific scripts to be run when a USB device is first plugged in. Maybe halevt can do the same, but I am very happy with udev.

See here: http://www.reactivated.net/writing_udev_rules.html

Quote:

And the mysteriously vanishing wvdial.conf but I don't expect that was the programs fault.
Cat / child on your keyboard?
Fault lies between keyboard & chair?

I run a firewall, it is in my DSL modem/router (which happens to run linux, it's a Netgear, it seems they do by default): No problems at all.

Quote:

Unfortunately I am infected by the GUI disease and prefer pretty graphical things
GUIs are all very well, but if you want to know what is really happening, you'll need to learn a little command-line stuff. Again, it is easy and fun to learn. It is also awesome when that basic knowledge lets you solve your problems before you have to resort to LQ.

M$ doesn't give you this option. Once you have learnt to use linux, trust me, you'll like it.

Quote:

Distro added to profile
Good. Maybe now you'll feel bold enough to add your country as well (there are LQ users in all TZs, and it helps to know.)

senseproof 05-10-2009 03:59 PM

Quote:

Originally Posted by tredegar (Post 3536327)
If you really want to do that, you can, but you'll have to read up about writing udev rules first.
udev is a daemon which allows any device-specific scripts to be run when a USB device is first plugged in. Maybe halevt can do the same, but I am very happy with udev.

See here: http://www.reactivated.net/writing_udev_rules.html

Thanks for the udev link. I have written a halevt rule for it before I came back and saw your reply... udev looks like it does the same sort of thing as halevt (and more) but is more powerful (and a little more complicated).

With my halevt rule I have the problem that it triggers as soon as the device is in so wvdial is called before the /dev/ttyUSB0 file it uses to talk to the modem exists. Can this sort of problem be solved with udev? I could make a little script that just sleeps and loops for it to appear but it seems like the sort of thing there is going to be a facility for?

Quote:

Originally Posted by tredegar (Post 3536327)
Fault lies between keyboard & chair?

Probably. I'd just done something very odd to the system but nothing that should have modified that file. Another program probably got confused and clobbered it.

Quote:

Originally Posted by tredegar (Post 3536327)
I run a firewall, it is in my DSL modem/router (which happens to run linux, it's a Netgear, it seems they do by default): No problems at all.

That's all very well but such devices only stop inbound connections. If there were ever exploits in Firefox that caused memory corruption, then an attacker could be on your system without your knowing it. And if there were ever privilege escalation attacks for the Linux kernel itself or any privileged daemon, then your system could be rooted, connecting outbound traversing your NAT or mapping uPnP ports without you (or me) even knowing it.

Quote:

Originally Posted by tredegar (Post 3536327)
GUIs are all very well, but if you want to know what is really happening, you'll need to learn a little command-line stuff.

This is true, I'd rather spend the time doing other things though :)

senseproof 05-12-2009 12:30 AM

As it turns out, udevd is EASIER than halevt (!). It only took one line to set up the USB dongle to do what I wanted. And all the required information was on that web page you pasted (which did have to be read in full to get the hang of it properly).

Nice one... It makes me wonder why they just didn't make a GUI to do that... it took just ONE LINE of config...

tredegar 05-12-2009 07:58 AM

Quote:

it took just ONE LINE of config...
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.

senseproof 05-13-2009 03:50 PM

Quote:

Originally Posted by tredegar (Post 3538180)
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.

tredegar 05-14-2009 12:53 AM

Quote:

And save others having to read the web page? But where is the fun in that? You made me read it you sadist!
Yes, but I think you maybe enjoyed it ;)

Thanks for taking the time to write that comprehensive, useful and well-formatted follow-up. I have bookmarked it next to the writing udev rules link.


All times are GMT -5. The time now is 04:36 AM.