output of lsusb:

bernadette@E4300HJZH1L1:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 413c:8147 Dell Computer Corp. F3507g Mobile Broadband Module
Bus 005 Device 002: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications Processor
bernadette@E4300HJZH1L1:~$

Also, is there now a way to see and/or edit the init strings that are being passed by Network Manager?

Here is an output of wvdial:
bernadette@E4300HJZH1L1:~$ sudo wvdial ATT
[sudo] password for bernadette: 
--> WvDial: Internet dialer version 1.61
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CFUN=1
AT+CFUN=1
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1, "IP", "Broadband"
AT+CGDCONT=1, "IP", "Broadband"
OK
--> Modem initialized.
--> Sending: ATDT*99#
--> Waiting for carrier.
ATDT*99#
~[7f]}#@!}!}!} }9}#}%B#}%}(}"}'}"}"}&} } } } }%}&mD%}(|3~
CONNECT
--> Carrier detected.  Waiting for prompt.
~[7f]}#@!}!}"} }9}#}%B#}%}(}"}'}"}"}&} } } } }%}&mD%}(0^~
--> PPP negotiation detected.
--> Starting pppd at Thu Feb  7 09:30:31 2013
--> Pid of pppd: 5874
--> Using interface ppp0
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> Disconnecting at Thu Feb  7 09:30:34 2013
--> The PPP daemon has died: A modem hung up the phone (exit code = 16)
--> man pppd explains pppd error codes in more detail.
--> Try again and look into /var/log/messages and the wvdial and pppd man pages for more information.
--> Auto Reconnect will be attempted in 5 seconds
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CFUN=1
AT+CFUN=1
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1, "IP", "Broadband"
AT+CGDCONT=1, "IP", "Broadband"
OK
--> Modem initialized.
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CFUN=1
AT+CFUN=1
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1, "IP", "Broadband"
AT+CGDCONT=1, "IP", "Broadband"
OK
--> Modem initialized.
--> Sending: ATDT*99#
--> Waiting for carrier.
ATDT*99#
~[7f]}#@!}!}!} }9}#}%B#}%}(}"}'}"}"}&} } } } }%}&[05]=)5b1~
CONNECT
--> Carrier detected.  Waiting for prompt.
~[7f]}#@!}!}"} }9}#}%B#}%}(}"}'}"}"}&} } } } }%}&[05]=)5.\~
--> PPP negotiation detected.
--> Starting pppd at Thu Feb  7 09:30:43 2013
--> Pid of pppd: 5891
--> Using interface ppp0
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> Disconnecting at Thu Feb  7 09:30:43 2013
--> The PPP daemon has died: A modem hung up the phone (exit code = 16)
--> man pppd explains pppd error codes in more detail.
--> Try again and look into /var/log/messages and the wvdial and pppd man pages for more information.
--> Auto Reconnect will be attempted in 10 seconds
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CFUN=1
AT+CFUN=1
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1, "IP", "Broadband"
AT+CGDCONT=1, "IP", "Broadband"
OK
--> Modem initialized.
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CFUN=1
AT+CFUN=1
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1, "IP", "Broadband"
AT+CGDCONT=1, "IP", "Broadband"
OK
--> Modem initialized.
--> Sending: ATDT*99#
--> Waiting for carrier.
ATDT*99#
~[7f]}#@!}!}!} }9}#}%B#}%}(}"}'}"}"}&} } } } }%}&:}%[06]}+[01]V~
CONNECT
--> Carrier detected.  Waiting for prompt.
~[7f]}#@!}!}"} }9}#}%B#}%}(}"}'}"}"}&} } } } }%}&:}%[06]}+M;~
--> PPP negotiation detected.
--> Starting pppd at Thu Feb  7 09:30:57 2013
--> Pid of pppd: 5904
--> Using interface ppp0
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> pppd: [18]��[08]���[08](��[08]
--> Disconnecting at Thu Feb  7 09:30:57 2013
--> The PPP daemon has died: A modem hung up the phone (exit code = 16)
--> man pppd explains pppd error codes in more detail.
--> Try again and look into /var/log/messages and the wvdial and pppd man pages for more information.
--> Auto Reconnect will be attempted in 20 seconds
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CFUN=1
AT+CFUN=1
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1, "IP", "Broadband"
AT+CGDCONT=1, "IP", "Broadband"
OK
--> Modem initialized.
^Z
[1]+  Stopped                 sudo wvdial ATT
bernadette@E4300HJZH1L1:~$ 


AS you can see....the connection keeps dropping and trying again.  Something is clearly not right with the pppd??  But with Network Manager, I don't even get this far.  Its not sending these AT commands at all.

(In reply to comment #2)
> Also, is there now a way to see and/or edit the init strings that are being
> passed by Network Manager?
> 

In MM git master, you can provide a custom initialization sequence for a specific plugin by overriding the following methods from the Modem interface:

    /* Asynchronous modem initialization operation */
    void (*modem_init) (MMIfaceModem *self,
                        GAsyncReadyCallback callback,
                        gpointer user_data);
    gboolean (*modem_init_finish) (MMIfaceModem *self,
                                   GAsyncResult *res,
                                   GError **error);

wow....totally lost.  As I am still quite new to the whole Open source/Ubuntu platform, I would really not be to ashamed to ask for more in-depth explanations...  :-)

How do I get to "MM git master", and what does the script mean that you provided??

(In reply to comment #4)
> wow....totally lost.  As I am still quite new to the whole Open source/Ubuntu
> platform, I would really not be to ashamed to ask for more in-depth
> explanations...  :-)
> 
> How do I get to "MM git master", and what does the script mean that you
> provided??

MM git is the repository where the code is stored; 'master' is the main branch of development; see:

http://cgit.freedesktop.org/ModemManager/ModemManager/log/

There is a generic initialization sequence for the modems; but different vendor specific plugins can override that and provide their own. Somewhat explained here:

http://www.lanedo.com/~aleksander/modem-manager/api-20121005/api/ref-overview-plugin-specific-modems.html

If you believe we would need to provide a new initialization sequence for MM; e.g. adding the +FCLASS=0; then that could be done in the plugin-specific modem object, by overriding the modem_init() and modem_init_finish() methods.

Created attachment 235423 [details] [review]
Patch adding more init commands

So, the attached patch adds some init commands to the MBM implementation. While probably it doesn't fix anything, wouldn't mind to have a look at the logs after the patch is applied.

I still think that the problem is with the network registration, though. So, another test to do would be to open the tty port with minicom and follow the steps of the vwdial script that you have; *but* before the ATD call, issue AT+CREG? and AT+CGREG? to check registration status. If you can connect even if those say "unknown" registration status, then we could be closer to something.

Here are the results of the minicom test:


bernadette@E4300HJZH1L1:~$ sudo minicom -s
[sudo] password for bernadette: 


Welcome to minicom 2.5

OPTIONS: I18n                                                                
Compiled on May  2 2011, 00:39:27.                                           
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+CFUN=1                                                                           
OK                                                                           
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0                                            
OK                                      
AT+CGDCONT=1, "IP", "Broadband"         
OK                                      
AT+CREG?                                
+CREG: 0,4                              
                                        
OK
AT+CGREG?
+CGREG: 0,4

[[ And this is where I entered the ATDT*99# ]]
OK
~�}#�!}!}!} }9}#}%�#}%}(}"}'}"}"}&} } } } }%}&§�}!}>��~
CONNECT
~�}#�!}!}"} }9}#}%�#}%}(}"}'}"}"}&} } } } }%}&�

I attempted to try this on ttyACM1, but it just kept sending its own command 

AT+CIND?
OK

And I couldn't seem to get my commands to register.  Perhaps that is the port used for GPS??

AT init commands are usually not the problem when things don't work, even though a lot of people think they are.  Typically it's later in the process.

CREG=0,4 is "unknown" registration status, which indicates something isn't set up or working correctly with the modem.

The fact that ATD starts PPP doesn't actually mean anything, since the PPP is between the computer and the WWAN card, *not* the network.  And its likely failing because the modem isn't registered, as shown by CREG=0,4.

The MM logs here (https://launchpadlibrarian.net/130478546/mmlog.txt) indicate that the modem never registers to the network, and that is the actual problem here.  Until the modem registers, neither PPP or the ethernet data interface wwan0 is going to actually work, which is why ModemManager waits for the modem to register.

Using minicom without MM running; note that you can run "minicom -D /dev/ttyXXX" where XXX is USB0, ACM0, whatever, and then you don't need to edit random minicom files to get the right port.

Do the following:

AT+CFUN=1
AT+CFUN?     (to ensure it's in mode 1 which is powered up)
AT+CREG?

if the CREG continues to say "0,4" then you're not registered and we can try the following:

AT+COPS=0,,

and then run AT+CREG? again to see if anything changes.  If nothing does, try this:

AT+COPS=?

to perform a network scan.  This can take up to two minutes.  What do you get from the result?  Next:

AT+CREG?

to see if the modem registered with a network it found during the scan.

(In reply to comment #6)
> I still think that the problem is with the network registration, though. So,
> another test to do would be to open the tty port with minicom and follow the
> steps of the vwdial script that you have; *but* before the ATD call, issue
> AT+CREG? and AT+CGREG? to check registration status. If you can connect even if
> those say "unknown" registration status, then we could be closer to something.

I don't think the modem starting PPP here even when unregistered is a sign of any success, because PPP just dies right after indicating that the modem will start PPP at any point.  Note that in the wvdial logs, you're seeing pppd send a bunch of ConfReqs, but no corresponding responses come back from the network, and eventually pppd just gives up and kills the connection.

Output after running minicom -D on /dev/ttyACM0:

First I stopped and then restarted NetworkManager.  Then I stopped all modem-manager before running minicom.


bernadette@E4300HJZH1L1:~$ sudo NetworkManager
bernadette@E4300HJZH1L1:~$ sudo killall modem-manager
bernadette@E4300HJZH1L1:~$ sudo killall modem-manager
bernadette@E4300HJZH1L1:~$ sudo stop modem-manager
stop: Unknown job: modem-manager
bernadette@E4300HJZH1L1:~$ sudo killall modem-manager
bernadette@E4300HJZH1L1:~$ sudo minicom -D /dev/ttyACM0

Welcome to minicom 2.5

OPTIONS: I18n 
Compiled on May  2 2011, 00:39:27.
Port /dev/ttyACM0

Press CTRL-A Z for help on special keys                                             
                                                                                    
                                                                                    
OK                                                                                  
AT+CFUN=1                                                                           
OK
AT+CFUN?
+CFUN: 1

OK
AT+CREG?
+CREG: 0,4

OK
AT+COPS=0,,
OK
AT+CREG?
+CREG: 0,4

OK
AT+COPS=?
+CME ERROR: 30






 CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.5    | VT102 |      Offline

Oh, also, check to be sure the antennas are attached to the card.  I was doing some testing for another issue with MBM devices, and if the antennas aren't connected, they will report CREG state 4.

CME ERROR 30 is "No network service".  The card literally cannot see any network.  At this point, I'm thinking either there's very very weak signal in your location, the antennas aren't correctly connected, or the card doesn't support frequencies that your provider uses.  What country are you located in and what network provider do you have?

Oddly, I'm able to run AT+COPS=? on my F5521gw with the antennas disconnected, even though it ends in ERROR 5 seconds later.  I could dig out my F3507g if we need to check further.

I have a Dell Latitude E4300 with Dell Wireless 5530 (Tri-band HSDPA 7.2/HSUPA 2.0 & GPS) installed
Carrier = AT&T
Network = HSPA 3G

I am in the US - New York City to be exact.  We've got EXCELLENT 3g and 4g coverage out here.


Oddly enough, before I formatted the harddrive and removed all traces of Windows 7, this machine worked fine using AT&T Connection Manager.  The antennae had to have been connected for it to work under windows.  I just don't understand this.  Network Manager is able to see the onboard card.  Modem manager is able to see the onboard card.  lsusb and /dev outputs are able to see the card.   

I am totally puzzled as to why this does not work in Ubuntu, but works in windows. *sigh*

OK....perhaps I could remove and then reseat the device on the motherboard.  Or should I just unhook the antennae and then rehook??  You have no idea how badly I need to get this stuff working.  I thought I was really on to something with the whole wvdial connection stuff, but maybe not.

if you have a dell 5530 (aka Ericsson F3507g) and you have time in your life to work with me, I would truly appreciate it.

OK!!!  OK!!! OK!!!!   (In reply to comment #12)

> Oh, also, check to be sure the antennas are attached to the card.  I was doing
> some testing for another issue with MBM devices, and if the antennas aren't
> connected, they will report CREG state 4.


OMG!!! DAN YOU ARE THE MAN!!!!  How on earth did this work in windows without the antenna connected to the card!!!

I attached the white and black antennae, then rebooted.  Network Manager all of a sudded showed me a new message:  YOU ARE NOW REGISTERED ON THE GSM NETWORK

WWHHHHAAAATTTT!!?!?!  I just clicked my ATT Connection that I setup before (that NEVER worked..) and that was it!!  I am using it right now!!  Dear Lord, I would have NEVER in a MILLION years thought to connect those things. 

I even went to google maps, and it picked me up in New York!!!  I am soooo ready to test a few more machines...but then I'm am rolling this out to the Project Managers like crazy!!

Thank you to everyone who assisted here.  Dan, Aleksander, and Marius!!  You guys are my team.  

You can put this BABY TO REST...LOL!!!

let me know whatever logs you wanna see....

Created attachment 235445 [details]
connection info

Excellent!  Good to know that it now works as expected.  I don't think I would have arrived at the antenna conclusion if I hadn't been looking for a way to trigger a forced-disconnect for fixing bug 690868.

If you have any other issues, let us know.  Good luck on the deployment!

I truly would have never ever thought that the antennas could be disconnected... Easy fix then :)