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: http://home2.btconnect.com/Taniwha/gprs.html Please consider adding GPRS networking support to NetworkManager.
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.
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.
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.
Created attachment 292151 [details] syslog messages when a pcmcia modem is inserted.
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.
Created attachment 292155 [details] HAL .fdi file
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.
.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> </match> </match> </match>
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?
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.
Dan, any updates on this? I have svn3235 installed.
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.
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)
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?
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.
Guys, 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. Thanks.
(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.
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?
FWIW, I also noticed that hal-info/NM from updates-testing are having troubles to communicate.
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.
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?
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".
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. NetworkManager-0.7.0-0.6.7.svn3369.fc8 hal-info-20080215-1.fc8 kernel-2.6.24.2-7.fc8 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> </match> </match> </match> I even rebooted after adjusting hal-info. Relevant parts of syslog in the attachment. 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? Thanks.
Created attachment 296514 [details] syslog output for a failed nokia/cable connection
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.
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 :)
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 OPTIONS: I18n 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 OK AT+CREG? +CREG: 0,1 OK 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? Thanks.
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.
It seems to me that lshal output matches with my fdi entry but I e-mailed the lshal to you just for sure.
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? Thanks.
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.
Created attachment 296809 [details] wvdial gsm connection ok
Created attachment 296810 [details] nm gsm connection fail
Daniel: Could you further modify the code with the attached patch and try to get the debug output like you have already?
Created attachment 297474 [details] Patch for further debugging of serial issues
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.
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?
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, btw).
Daniel: can you try latest SVN? r3415 please. Thanks!
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.
Created attachment 297526 [details] nm gsm serial conn ok
Created attachment 297527 [details] nm gsm conn hang
Some related remarks I noticed during the successful gsm connection: - in the connection info window hardware address was empty - probably can't be known? - 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. Thanks.
Daniel: going to need some more work in NM to handle this case...
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 /org/freedesktop/Hal/devices/usb_device_421_802_noserial_if0_serial_unknown_0: 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 /org/freedesktop/Hal/devices/usb_device_421_802_noserial_if0_serial_unknown_0: 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.
FWIW, GSM connections are still problematic with rev 3533.
Daniel; can you try with http://koji.fedoraproject.org/koji/taskinfo?taskID=570554 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!
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. Thanks.
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. Thanks!
closing; feature has been around for a while and works pretty well :)