Bug 296851 - RFE: integrated Mobile Broadband support
Summary: RFE: integrated Mobile Broadband support
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 388701
TreeView+ depends on / blocked
Reported: 2007-09-19 19:43 UTC by Daniel Qarras
Modified: 2008-04-20 16:00 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2008-04-20 16:00:29 UTC

Attachments (Terms of Use)
syslog messages when a pcmcia modem is inserted. (2.79 KB, application/octet-stream)
2008-01-18 14:55 UTC, Russell Harrison
no flags Details
HAL .fdi file (1.42 KB, text/plain)
2008-01-18 15:06 UTC, Dan Williams
no flags Details
syslog output for a failed nokia/cable connection (3.33 KB, text/plain)
2008-03-02 15:37 UTC, Daniel Qarras
no flags Details
wvdial gsm connection ok (677 bytes, text/plain)
2008-03-04 21:26 UTC, Daniel Qarras
no flags Details
nm gsm connection fail (2.53 KB, text/plain)
2008-03-04 21:27 UTC, Daniel Qarras
no flags Details
Patch for further debugging of serial issues (1.44 KB, patch)
2008-03-10 17:57 UTC, Dan Williams
no flags Details | Diff
gsm-serial debugging with svn rev 3412 (4.21 KB, text/plain)
2008-03-10 20:06 UTC, Daniel Qarras
no flags Details
nm gsm serial conn ok (5.80 KB, text/plain)
2008-03-10 22:06 UTC, Daniel Qarras
no flags Details
nm gsm conn hang (4.58 KB, text/plain)
2008-03-10 22:07 UTC, Daniel Qarras
no flags Details
nm gsm conn perfect (3.58 KB, text/plain)
2008-04-17 16:10 UTC, Daniel Qarras
no flags Details
nm gsm conn debug log (6.54 KB, text/plain)
2008-04-18 15:34 UTC, Daniel Qarras
no flags Details

Description Daniel Qarras 2007-09-19 19:43:41 UTC
In the spirit of Bug 136663 and Bug 296841:

Using a GPRS connection with a mobile phone over IrDA/Bluetooth/cable is a great
way to stay connected while roaming. Adding support for this to NetworkManager
would greatly simplify setting up such connections. GPRS connections need
operator specific data but that is very static at least in developed countries
and is available in public: 


Please consider adding GPRS networking support to NetworkManager.

Comment 1 Daniel Qarras 2007-11-15 21:00:45 UTC
FWIW, I think this is actually rather noteworthy feature as some new laptops
nowadays include GSM/GPRS support and a SIM card slot.

Bug 217049 perhaps also related to this.

Comment 2 Dan Williams 2007-12-03 16:32:53 UTC
Changing this bug into a tracker for mobile broadband card support, both
GSM-based and CDMA-based.  This work is already ongoing and some support for
GSM-based cards has been committed upstream, and will filter down to Fedora when
it's usable.

Comment 3 Russell Harrison 2008-01-18 14:05:19 UTC
In the short term most of these cards work as USB modems.  I'm able to very
easily configure a "new modem" in system-config-network using /dev/ttyUSB0 as
the device.  I do have to know the settings I need ahead of time but if NM was
able to just present me the same options when a "GSM modem" is present would be
very nice indeed.

Signal strength and the other fancy stuff could come later.

Comment 4 Russell Harrison 2008-01-18 14:55:40 UTC
Created attachment 292151 [details]
syslog messages when a pcmcia modem is inserted.

Comment 5 Dan Williams 2008-01-18 15:06:14 UTC
Yeah, there's support for them in F8 already, but since it's not quite
prime-time yet it's not as easy to get to.  You have to write a HAL .fdi file to
tag your card's serial device as having the capability 'modem', like the
attached file which would go into /usr/share/hal/fdi/information/10freedesktop/.
 You'll have to add a block to that for your card matching the USB device and
vendor IDs.

Once the card has been successfully tagged with the 'modem' capability, NM will
find it and you can click on it from the applet menu, and it'll try to connect
with default settings.  We don't yet have the connection editor working for
mobile broadband cards, but you can edit the phone #, username, and password (if
you need to) from gconf-editor.

Comment 6 Dan Williams 2008-01-18 15:06:53 UTC
Created attachment 292155 [details]
HAL .fdi file

Comment 7 Kevin DeKorte 2008-01-18 16:42:27 UTC
ok, I created an .fdi file and it now sees my modem in nm-applet, but I get this
when I try to activate it

Jan 18 09:40:20 t60p NetworkManager: Invalid bits (0). Valid values are 5, 6, 7, 8.
Jan 18 09:40:20 t60p NetworkManager: Invalid parity (
Jan 18 09:40:20 t60p NetworkManager: Invalid stop bits (0). Valid values are 1
and 2)
Jan 18 09:40:20 t60p NetworkManager: <info>  Activation (ttyUSB0) Stage 1 of 5
(Device Prepare) complete.
Jan 18 09:40:20 t60p NetworkManager: <WARN>  check_pin_done(): PIN checking failed
Jan 18 09:40:20 t60p NetworkManager: <info>  Marking connection 'Auto GSM dialup
connection' invalid.

Comment 8 Kevin DeKorte 2008-01-18 16:43:10 UTC
.fdi entries for EX720... 

     <!-- Novatel EX720 -->
      <match key="@info.parent:usb.vendor_id" int="0x1410">
        <match key="@info.parent:usb.product_id" int="0x1120">
          <match key="@info.parent:usb.interface.number" int="0">
            <append key="info.capabilities" type="strlist">modem</append>
            <append key="info.capabilities" type="strlist">cdma</append>

Comment 9 Kevin DeKorte 2008-01-18 16:44:49 UTC
I have a pppd profile named Sprint, so I can do ifup Sprint and my modem works.
Anyway I can tell NM to just use that profile?

Comment 10 Dan Williams 2008-01-18 19:45:21 UTC
Note that there's only support right now for GSM broadband cards, which do all
the PIN/PUK stuff.  I'm going to add back the basic CDMA support again sometime
this coming week anyway, so I'll keep you posted.

Comment 11 Kevin DeKorte 2008-02-13 15:04:48 UTC
Dan, any updates on this? I have svn3235 installed.

Comment 12 Dan Williams 2008-02-13 17:18:16 UTC
Kevin; which bits are you interested in?  CDMA support should be in svn3235 as
long as you have the right HAL .fdi files as described above.  There may be one
bug with the initial connection setup that I've subsequently fixed in SVN, but I
can post a workaround.

Comment 13 Scott Douglass 2008-02-14 15:36:16 UTC
I'm using the sprint/novatel S720. I used to use the F7 Dial-up feature of
NetworkManager. I just switched to F8 and am dismayed that that feature is gone.
I've installed the .fdi file attached above which appears to have the necessary
settings for the S720 CDMA modem but still don't get the Dial-up menu with
NetworkManager (NetworkManager-0.7.0-0.6.7.svn3235.fc8) Lack of support for
dial-up is a problem for dbus aware applications which think the network is not
connected (e.g. pidgin, evolution) 

Comment 14 Kevin DeKorte 2008-02-14 15:46:23 UTC
Dan, I grabbed the latest code from updates-testing svn3302 (svn3235 didn't work
entirely right) and I can now use my Sprint card from the NetworkManager menu.
So how does this work exactly? Does it just dial #777 or is there a way to
configure this even more. Or is support for that still being worked on. 

Anyway, thanks for making this work. Also, when are the .fdi files going to be
merged into hal, so that I don't have to worry about them anymore?

Comment 15 Dan Williams 2008-02-14 17:01:09 UTC
Scott: You'll want svn3302 at least from updates-testing.

Kevin: I'm hashing out the exact interfaces in HAL upstream; hope to have that
resolved in the next week or two and then we can have the F8 and rawhide HAL
ship the correct FDI files.

Comment 16 Daniel Qarras 2008-02-16 15:19:54 UTC

it's great to see how things are progressing and I wouldn't like to ruin your
party but I have to ask is the plan to support cards only or is it possible that
the use case included in the opening comment could also be addressed in the
future? That is, GPRS connection with a mobile phone over IrDA/Bluetooth/cable.


Comment 17 Dan Williams 2008-02-18 13:01:30 UTC
(In reply to comment #16)
> it's great to see how things are progressing and I wouldn't like to ruin your
> party but I have to ask is the plan to support cards only or is it possible that
> the use case included in the opening comment could also be addressed in the
> future? That is, GPRS connection with a mobile phone over IrDA/Bluetooth/cable.

We'll likely support bluetooth next.  Come to think of it, serial cable to your
phone should already work if you tag the device in HAL with 'modem' and
'gsm'/'cdma' capabilities.

Comment 18 Kevin DeKorte 2008-02-19 19:36:13 UTC
Dan, I updated to the latest hal-info and restarted haldaemon. After that my
card quit working in NetworkManager svn3302. Is there a new network manager that
we need to work with this new hal-info?

Comment 19 Daniel Qarras 2008-02-20 20:13:32 UTC
FWIW, I also noticed that hal-info/NM from updates-testing are having troubles
to communicate.

Comment 20 Daniel Qarras 2008-02-22 17:18:14 UTC
I tested GPRS over a cable connection manually with wvdial and it works easily,
I just need the following /etc/wvdial.conf:

[Dialer Defaults]
Baud = 230400
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = ATM0
SetVolume = 0
Dial Command = ATDT

[Dialer gprs]
Modem = /dev/ttyACM0
#Init4 = AT+CGDCONT=,,”airtelgprs.com”
ISDN = 0
Modem Type = Analog Modem
Phone = *99#
Username = A
Password = B
Stupid Mode = 1

Username and password can be anything. In some cases (probably operator
specific) one needs the Init4 parameter to get DNS servers but for me this works
ok without it. So my comment in the bug opener about the need for operator
specific GPRS data is not valid, that data is not needed.

I'll report here how GPRS over a cable with NM works when latest hal-info/NM are
again dancing together.

Comment 21 Kevin DeKorte 2008-02-26 15:34:00 UTC
Dan, I know this is probably the wrong place to ask, but could you write up a
tutorial on how to have a wired or 3g/cdma card active and then share that
connection out the wireless card. Or how to have to cards active at the same
time. I've seen you talk about this in a couple of places, but I can't figure
out how to do it. Do you need two nm-applets running or something?

Comment 22 Dan Williams 2008-02-26 15:40:05 UTC
Kevin; it doesn't happen just yet, but I'm starting the multiple active device
stuff this week.  If you read the LWN quote, that was somewhat out of context :)
 As in "that's what it will be like when it lands".

Comment 23 Daniel Qarras 2008-03-02 15:34:56 UTC
I've now tested GPRS over a cable with latest NM/hal-info from F8
updates-testing. It didn't work with my Nokia phone. Below is some information.


Manully added entry in 10-modem.fdi:

      <!-- Nokia Mobile Phone via CA-42 -->
      <match key="@info.parent:usb.vendor_id" int="0x0421">
        <match key="@info.parent:usb.product_id" int="0x0802">
          <match key="@info.parent:usb.interface.number" int="0">
            <append key="info.capabilities" type="strlist">modem</append>
            <append key="modem.command_sets" type="strlist">GSM-07.07</append>
            <append key="modem.command_sets" type="strlist">GSM-07.05</append>

I even rebooted after adjusting hal-info. Relevant parts of syslog in the

When I used wvdial I saw instantly on my phone a "G" sign when it was creating a
GPRS connection but now with NetworkManager no activity at all on the phone.

Dan, do you need any extra information or other kind of testing?


Comment 24 Daniel Qarras 2008-03-02 15:37:55 UTC
Created attachment 296514 [details]
syslog output for a failed nokia/cable connection

Comment 25 Dan Williams 2008-03-02 15:48:13 UTC
So the issue is apparently "<WARN>  automatic_registration_response(): Automatic
registration timed out".  Can you:

If you're comfortable with minicom, can you talk to the phone and execute the
"AT+CREG?" command on the phone?  lets see what it says...  That's the command
that's failing above, it might be that NM just isn't expecting the reponse the
phone delivers.

Comment 26 Dan Williams 2008-03-02 15:57:15 UTC
Also, please make sure that the serial port is actually USB interface number
_0_.  I just tried this with my Nokia N80, and the usb interface number there as
8, not 0.  It worked for me, I got connected and got an IP address.  Now if only
I had a data plan and could actually talk to something with IP :)

Comment 27 Daniel Qarras 2008-03-02 17:35:04 UTC
Thanks for your prompt reply Dan! I tried minicom. My /etc/minirc.dfl is:

pu port             /dev/ttyACM0
pu rtscts           No 

And here's what I get with the command:

Welcome to minicom 2.2

Compiled on Sep 25 2007, 06:13:56.
Port /dev/ttyACM0

                 Press CTRL-A Z for help on special keys
AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0                     
+CREG: 0,1


I'm sorry but I don't understand what do you mean by making sure that "the
serial port is actually USB interface number _0_"? The device is /dev/ttyACM0
and the fdi entry also uses 0, is there something else I would need to check?


Comment 28 Dan Williams 2008-03-03 00:53:19 UTC
Sorry, I  meant that in the HAL .fdi file bits you added, make sure that the
interface number is correct.  For example, my Nokia N80's USB port was _8_, not
0 like is the case for most mobile broadband cards.  To make sure, type "lshal |
less", then "/ACM0".  Go to the immediate parent entry of that UDI in which
ttyACM0 is found, and look for it's 'usb.interface' property, and make sure that
matches with what you put into HAL.  Or, alternatively, mail me the output of
'lshal' and I'll check quickly to see what the right USB interface number is.

Comment 29 Daniel Qarras 2008-03-03 06:20:57 UTC
It seems to me that lshal output matches with my fdi entry but I e-mailed the
lshal to you just for sure.

Comment 30 Daniel Qarras 2008-03-03 19:09:00 UTC
Dan, some news (good or bad, judge yourself):

I compiled latest NM SVN trunk and ran it under DDD, sprinkled some debug
messages to nm-gsm-device.c and put a breakpoint or two there. And then, it worked!

So perhaps we're talking about some sort of timer/timing issue? Any ideas what
function should I debug? Or can you throw in a quick patch that I could try?


Comment 31 Daniel Qarras 2008-03-04 21:25:42 UTC
After more investigation it is clear that the AT commands are all ok. I checked
what NM sends and tried those with wvdial and wvdial worked all ok. NM fails
randomly but I can't get a grip what's the root cause for all this. I'll attach
example of a successful wvdial connection and a failed NM connection with serial
debugging enabled.

PWIW, my wvdial.conf posted earlier was not optimal, I've now adjusted it to
match to what NM is sending.

Comment 32 Daniel Qarras 2008-03-04 21:26:45 UTC
Created attachment 296809 [details]
wvdial gsm connection ok

Comment 33 Daniel Qarras 2008-03-04 21:27:17 UTC
Created attachment 296810 [details]
nm gsm connection fail

Comment 34 Dan Williams 2008-03-10 17:55:36 UTC

Could you further modify the code with the attached patch and try to get the
debug output like you have already?

Comment 35 Dan Williams 2008-03-10 17:57:36 UTC
Created attachment 297474 [details]
Patch for further debugging of serial issues

Comment 36 Dan Williams 2008-03-10 18:02:35 UTC
Daniel: nevermind, I think I see the issue.  Looking into how to fix it.  Your
phone apparently doesn't send data as fast as NM is expecting; it causes the
responses to get broken up into multiple reads, causing the string matching in
NM to fail.

Comment 37 Dan Williams 2008-03-10 19:40:49 UTC
Daniel: I've checked in a fix for you issue; it'll hit the next F8 update.  That
won't come for a few days more though, since I'd like to make sure the multiple
device support that's in SVN is solid enough for an F8 update.

However, I can build some F8 RPMs for you and give you the link even if I don't
submit them for an official F8 update.  Sound good?

Comment 38 Daniel Qarras 2008-03-10 20:06:04 UTC
Created attachment 297506 [details]
gsm-serial debugging with svn rev 3412

Hi Dan, thanks a lot for looking into this one. I just built and tested NM SVN
3412 but unfortunately it still doesn't work :-/ I applied the earlier debug
patch and ran NM with serial debugging enabled (which is on in svn trunk, too,

Comment 39 Dan Williams 2008-03-10 21:38:38 UTC
Daniel: can you try latest SVN?  r3415 please.  Thanks!

Comment 40 Daniel Qarras 2008-03-10 22:05:33 UTC
Dan, partial success! I managed to get it working once but unfortunately next
attempts caused a complete hang (only killall -9 NetworkManager restored the
order). I'll attach output from both cases.

Comment 41 Daniel Qarras 2008-03-10 22:06:58 UTC
Created attachment 297526 [details]
nm gsm serial conn ok

Comment 42 Daniel Qarras 2008-03-10 22:07:29 UTC
Created attachment 297527 [details]
nm gsm conn hang

Comment 43 Daniel Qarras 2008-03-10 22:16:21 UTC
Some related remarks I noticed during the successful gsm connection:

- in the connection info window hardware address was empty - probably can't be

- speed was "unknown". gconf-editor shows that it was actually 115200 so perhaps
that could be printed?

- why only speeds 115200 and 460800 are allowed, not 230400? With wvdial 230400
works ok but not 460800 (and of course 115200 is ok but it's slower). If 230400
would be supported would it be used automagically or should one use gconf-editor
or something to fix that up?

- when connecting my phone I see the msg below - I don't know what's monitoring
udi but is there any way it could be provided in this case (eg tweaking the
hal-info fdi file)?

NetworkManager: <info>  ttyACM0: Device is fully-supported using driver 'cdc_acm'.
NetworkManager: <debug> [1205185531.937315] setup_monitor_device(): No
monitoring udi provided
NetworkManager: <info>  Now managing Modem device 'ttyACM0'.

If you think it would be better to discuss about these issues in NM mailing list
just let me know and I'll post these questions there.


Comment 44 Dan Williams 2008-03-11 03:01:47 UTC
Daniel: going to need some more work in NM to handle this case...

Comment 45 Daniel Qarras 2008-03-11 06:49:14 UTC
Thanks for your patience with this one, Dan :) 3417 works a bit better, maybe 3
out of for 4 gsm connection attempts succeed, one out of four causing a hang. It
seems that the hang is not a complete lock-up but everything moves at glacial
speed then. Only additional info I can provide was something nm-applet printed
during that hang/slowdown:

** (nm-applet:5402): WARNING **: nm_object_get_property: Error getting
'Interface' for
Did not receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken.

** (nm-applet:5402): WARNING **: Error in getting VPN connections: Did not
receive a reply. Possible causes include: the remote application did not send a
reply, the message bus security policy blocked the reply, the reply timeout
expired, or the network connection was broken.

** (nm-applet:5402): WARNING **: nm_object_get_property: Error getting
'Interface' for
Did not receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken.

Comment 46 Daniel Qarras 2008-04-06 18:52:46 UTC
FWIW, GSM connections are still problematic with rev 3533.

Comment 47 Dan Williams 2008-04-17 13:12:53 UTC
Daniel; can you try with


and let me know what happens?  If something goes wrong, logs from
/var/log/messages would be quite useful as I turned on serial debugging in this
 build.  Thanks!

Comment 48 Daniel Qarras 2008-04-17 16:10:50 UTC
Created attachment 302763 [details]
nm gsm conn perfect

Dan, great news, we're "Connected, Woo!" :-)

Connecting and disconnecting happens instantly and it seems to work just
perfectly. I see few warnings in the log (I'm using 3571 from SVN) even without
debugging, but those do not seem fatal?

Anyway, great job! I'll test some more tomorrow and I'll provide log with
debugging enabled then if needed.


Comment 49 Daniel Qarras 2008-04-18 15:34:17 UTC
Created attachment 302895 [details]
nm gsm conn debug log

I've done some more testing and this seems to be rock solid! "It just works!"

FWIW, I'm attaching debugging output log from a connection, it has those two
errors/warnings but they do not seem to cause any visible harm.


Comment 50 Dan Williams 2008-04-20 16:00:29 UTC
closing; feature has been around for a while and works pretty well :)

Note You need to log in before you can comment on or make changes to this bug.