'ip-config-unavailable' error when USB modem tries to connect

networking network-manager usb-modem modem mobile-broadband

5,132

Solution 1

The modem has started functioning in Ubuntu 16.04. This version is still in development phase, but works fine in my laptop.

I wish I could provide more technical details on how it started functioning.

Solution 2

Loading the ofono package did good, probably, but apparently your modem model, ZTE MF193E, is not on the ZTE list. Comparing it to other ZTE modems, eg MF190J, this modem is likely to need the same special udev rule, to run usb_modeswitch when the dongle is inserted, and to achieve that you may, as root, add a new udev rule to the file
/lib/udev/rules.d/40-usb_modeswitch.rules
with the following two lines e.g., somewhere near the # ZTE MF190J comment:

# ZTE MF193E
ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"

plus a blank line, so it looks pleasant to the eye.

It's probably wise to reboot after that, only to find it all works like magic :-)

Or not. As you know, this is deep water for me, but if it still doesn't work, another ModemManager debug log would be needed, for another wild guess.

EDIT:

I'm now looking at the two lines in modemmanager.txt:

[mm-broadband-bearer.c:1254] connect(): Launching 3GPP connection attempt with APN 'WAP'

and

[mm-broadband-bearer.c:994] parse_pdp_list(): Found PDP context with CID 1 and PDP type ipv4 for APN 'wap'

I'm guessing the first refers to your broadband set up, while the latter refers to the internal binding to a "PDP context" (whatever that is). By the looks of it, the modem offers 9 alternative contexts, including one with apn='WAP', but the ModemManager settles for a case insensitive match.

The case difference might be the cause of the subsequent problem: e.g., that ppp wants a 'wap' configuration (rather than 'WAP') and doesn't find it, or that the remote end expects apn='WAP', but gets 'wap' which it chokes on.

The first option could easily be tested (and ruled out, probably) by changing your configuration to use 'wap' instead of 'WAP'. You may have tried this before, but at that time without the ofono package, so another test won't hurt, although the second option is more likely.

The second option is also more of a problem, given that there is an upper-case "PDP context" match available from the modem. Googling this issue, it appears that case insensitive match is correct by the (apparently relevant) specification "3GPP TS 23.003 chapter 9.1", and a patch to do this was added to ModemManager in November last year (into its version mm-1-4, I can gather). So in this case, your modem hasn't been told, and it expects case sensitive matching, while ModemManager unfortunately uses case insensitive matching straight out rather than as a fallback.

One solution for the second problem is of course to use a different ModemManager: either by finding and installing a version prior to this patch, or (with enough spare time), roll your own ModemManager. But neither is something to do at a whim, so maybe we need to browse around a bit to gain more evidence that this is (now) the problem, and if possible find other ways to work around it. Or with a bit of luck, someone who knows something drops by...

EDIT 2

Yes, version rollback is not easy due to dependencies. And rolling your own is far from a joy as well.

Two possible useful tools: command mmcli and (http://m2msupport.net/m2msupport/module-tester/).

The problem, I think, is that ModemManager picks PDP context 1 with apn='wap' where it should pick PDP context 9 with apn='WAP'. Maybe this can be addressed by using one of those tools. Either to be able to force a selection of 9 during connection, or by deleting the bad 'wap' contexts from the modem, which the module-tester tool is advertised to be capable of.

The modem-tester tool seems to be a java tool in the browser, so you need your browser set up to know where your java is, and you need that java to be known about. Then please explore that approach; I haven't used it myself, but seeing the screenshots, I'm guessing it will present the PDP contexts as the 'Data Calls' tab, where you first take note of everything it shows, and then edit the 'wap' entries to distort the 'wap' apn labels to be, say, 'wap1' and 'wap2' (so as to "hide" them when looking for 'WAP'). Then save and close, and juggle the dongle again. Grab a log; it seems syslog is sufficient now, in case it still refuses to play.

The mmcli command also seems useful in this story; do man mmcli to read about it, but I didn't see anything about PDP contexts there.

EDIT 3

Good call! to test from the DVD. That told us that I'm on the wrong track with the APN, and that it all lies in getting ppp to come up. At least, that'd be my new tree to bark at.

Firstly we take note that there's a version difference for pppd (from 2.4.5 to 2.4.6), but that's probably not an issue, as then everyone on a dongle would have been on this excursion.

Hmm, ppp; I need to stir up my last-millennium memories :-). Unfortunately I'm busy today, but I'll touch base when next I have time, to see how far you've come. My first back alleys to look into would be: 1) is the user in the right group? 2) are the credentials right? 3) are the ppp/chat configurations file mod's right? The ppp debug log comes out in nm.txt (as per a few days ago), but there should also be a way to ask it for more detailed logging.

EDIT 4

Ensure /etc/ppp/pap-secrets and /etc/ppp/chap-secrets have group dip (using chgrp as needed) and mode 740 (or -rw-r-----) (using chmod as needed). Mine didn't.

EDIT 5

How about this tree, then: Comparing the working wvdial syslog with non-working syslog, it seems that for some reason wvdial used ttyUSB3 while the non-working ModemManager keeps using ttyUSB1. I'm not sure if it's at all significant, but apparently but ttyUSB1 and ttyUSB3 both respond as AT capable modems.

So, as a test, maybe you can edit /etc/wvdial.conf so it under [Dialer Defaults] includes the line:

Modem = /dev/ttyUSB1

for the one test, and ttyUSB3 for another; both running as root; just to see if there is a different behaviour. Especially, if using ttyUSB1 is a problem whereas using ttyUSB3 is not, then it'd be good to look into how to make ModemManager use ttyUSB3 as well. For any other test outcome, I'd say we'll go back to chasing ferrets in ppp land.

EDIT 6

The dmesg log can be ignored I think; it's been like that in all logs. The new syslog only shows the ttyUSB3 test, but maybe we can assume that life gets better if NetworkManager can be tought to use ttyUSB3 and ignore ttyUSB1 (for this modem).

I also found (https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784) with especially post #10 disconcerting :-(

The apparently applicable udev rule in /lib/udev/rules.d/77-mm-zte-port-types.rules doesn't apply, but'd supposedly be where to go. And, with only a very rudimentary, pre-101 insight into the udev magic, I would anyhow consider questioning its 4th line, which says:

SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end"

I think that line needs an initial # so as to be commented out. In detail, my reading of the file is that it requires a calling state of SUBSYSTEM=="tty" and SUBSYSTEMS="usb" in order to use the good bits, including the "2003" product rules, and at least for testing, it should be safe to skip the "tty" filtering. And I don't have anything better right now.

EDIT 7

After having spent some quality time with my favourite search engine, I believe slightly more that the ttyUSB choice is a root problem here. The udev rule I pointed at is ok, and you should revert that edit.

However, I've started to believe that the configuration rules towards the end of that file, for product id "2003" are misleading. From the logs, it looks to me, that product id "2003" is actually the memory device side of the dongle, whereas the modem side has product id "1232". You can test this by replicating the two "2003" rules for product id "1232", in file /lib/udev/rules.d/77-mm-zte-port-types.rules

ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"

or better, add a new file beside it, e.g. named 78-ralph.rules, but then you also need to add the SUBSYSTEM and SUBSYSTEMS protection around it.

Then, pull out the dongle, run udevadm control --reload (or reboot), and insert the dongle. And then yet another syslog capture, unless it now happens to work.

The effective problem, though, is that ModemManager discards the plugin libmm-plugin-zte.so at pre-probing, and ends up using a generic modem handler. If I'm right about product id, then this might be the reason; that pre-probing looks for a ID_MM_ZTE_PORT_TYPE_MODEM attribution, and this is lacking for product id "1232" (before the patch), with the effect that the zte plugin gets discarded.

EDIT 8

The syslog log is a bit short; missing the beginning where ModemManager fails to install the zte plugin. However, it's clear that the Generic modem plugin is used anyhow. Now, it may be that the usb_modeswitch rule I gave you early on is wrong as well; it decides to switch to "2003" when I thought it switched from "2003". But, man usb_modeswitch (which I should have looked at before) kind of suggest that it shifts to a product id rather than from it. In any case, the log shows that to happen. Thus, please change that rule to use "1232" instead, and try yet again.

If nothing else, at least I've got to learn a little bit about udev.

EDIT 9

Good. The problem is still (or also) that ModemManager drops the ZTE plugin at pre probing. The ModemManager debugging logs for 15.10 (log sets "debuglogs*") all tell the story that the ZTE plugin is discarded due to the vendor-id/product-id test.

Go to the source, Luke! I took this opportunity to sight the ModemManager source code briefly, and it indicates that the plugin as a table of vid/pid that doesn't include 19d2/2003 ... though, I haven't found that table source, so I couldn't verify.

Or maybe there's a timing issue here. E.g., that the ModemManager runs pre-probing while the device is 19d2/1232. That thought is aligned with the observation that having the 78-mm-zte-port-types-RALPH.rules udev rules makes ModemManager a little bit happier with the device. But then, why doesn't it stay happy and make use of that plugin when the device is switched to 19d2/2003?

Maybe more logs are needed :-) With ModemManager debugged, and also a capture of the command udevadm monitor --e |& tee udevadm.log (in another terminal) when you plug in the device. I got that command from (https://wiki.ubuntu.com/DebuggingUdev)

Do this two times: once without 78-mm-zte-port-types-RALPH.rules and once with the rules... both times from a fresh reboot. I.e.

setup /lib/udev/rules.d with or without the *-RALPH.rules file
pull out the device
reboot
setup ModemManager for debugging and setup udevadm capture
plug in the device and wait a minute
pack up log files
repeat from 1 with next test

That logging should tell where the ZTE plugin is dropped, and as I understand, it'll also tell about the udev event handling.

EDIT 10

(I'm almost at the end of my tether here, but I have one or two more breaths left:-)

Firstly, all the udev decorations seem to end up as they should, with just a couple of question marks in a couple of the attributes. In particular, the 78-*-RALPH.rules should be thrown away; it's not useful.

I think I can read out something from this, but I'm not exactly sure how it should be fixed. Basically, as I see it, when the dongle is plugged in there is a flurry of udev events. Focusing on those concerning ttyUSB1, there is an "early" event:

KERNEL[3867.310990] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1 (usb)

which causes the usb_serial driver to be loaded, and /dev/ttyUSB1 to appear. That in particular causes another event:

KERNEL[3867.435102] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

I think that also triggers ModemManager. You have to go to syslog to see evidence of this, since there's no strict correlation between the logs. The event is time stamped 3867.435102, and syslog presents its nearest subsequent ModemManager log line just after a kernel log line stamped 3867.437412.

In my line of thinking, ModemManager should not be triggered yet, but only after the subsequent ttyUSB1 event:

UDEV  [3867.580427] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

which has attached the ZTE attributes.

In the MM log, we would be at the line stamped 1449934745.363291, which apparently is a "real time" time stamp rather than a "kernel time" stamp.

ModemManager then is done with its pre-probing at1449934745.450398, i.e., 87ms later, which in kernel time terms would be near 3867.524519 and 55ms before that "good" UDEV event report above.

Note that in syslog, ModemManager does lodge complaints that ttyUSB1 does not have its attributes set, and maybe that complaint is related to the "marking" happening in 80-mm-candidate.rules. By the comment in that file, that marking appears to be an attempt to deal with exactly with this problem, but if so, it doesn't seem to work in this case.

Maybe one possibility to resolving this would be to change the "tty" rule in 80-mm-candidate.rules to be:

ENV{.ID_PORT}=="?*", SUBSYSTEM=="tty", ENV{ID_MM_CANDIDATE}="1"

In my mind, that would ensure that the ID_MM_CANDIDATE setting gets delayed until the ZTE attributes are set. The .ID_PORT setting is an effect of a 60-serial.rules rule (called 60-persistent-serial.rules before), and the added condition to the marking rule is simply that it has a value.

The condition is not exactly a ZTE attribute, only so as to keep the rule more generic. One step more specific would be to rather require ENV{.MM_USBIFNUM}="?*" instead, since that assignment here happens by 77-mm-zte-port-types.rules.

In general I'm not very sure about udev rule ordering, and I'm also not at all sure that this really stops ModemManager from acting too quickly. However if it doesn't, then 80-mm-candidate.rules would have little to no function, and maybe then it all would come down to the "improvements" to ModemManager from 15.04.

EDIT 21

sigh. Probably irrelevant, but you may want to check your 7-zte-mutil_port_device.rules file; is that a remnant from other experimentation? Anyhow, not relevant here.

There's still almost a second between 515.558184 and 516.381549 where ModemManager eagerly and erroneously grabs /dev/ttyUSB1, and whilst complaining about it not being set up, still goes through pre-probing and discards the ZTE plugin. In other words, the rule patch doesn't make ModemManager wait.

I suppose you also tested using ENV{.MM_USBIFNUM}="?*" instead of ENV{.ID_PORT}=="?*".

Actually, to confirm whether or not setting ENV{ID_MM_CANDIDATE}=1 is of any importance, you should temporarily move away 80-mm-candidate.rules, then see (in syslog) if then ModemManager ignores /dev/ttyUSB1 or not. I suspect "not".

And then, well, maybe you can use a working version, such as 14.04, and if you need, perhaps run 15.10 in a virtualbox, unless of course it's already all is in a virtualbox.

I think I need to claim defeat at this point.

5,132

Masroor

I teach. And love it.

Updated on September 18, 2022

Comments

Masroor over 1 year
I have got a ZTE MF-193E modem which worked fine before. When I bought this modem more than a year ago, it worked readily out of the box. Now, as Ubuntu is progressing in version, things are becoming more and more difficult for me.

This modem even worked a couple of months back with Ubuntu 15.04 (64-bit). Now, in Ubuntu 15.10 (64-bit), it can not connect.

I have set up a mobile broadband connection. I have tried various strings for APN, but this has not been an issue before.

(The modem works fine in Windows 10, so, this is not a hardware issue at all. Also, Modem Manager GUI nicely detects this device. SMSs can be sent and received without any problem.)

When I insert the modem, it gets detected alright, a CD icon is displayed in Unity with the name of the modem. A few seconds later, I get a message box
```
Mobile Broadband Network: you are registered on the home network
```
near the network icon.

When I try to connect, the wireless icon in network manager applet starts those centrifugal motions, but eventually it fails to connect and a message tells me that I am offline.

The line I could isolate from /var/log/syslog is this,
```
NetworkManager[628]: <info>  (ttyUSB1): device state change: ip-config
> -> failed (reason 'ip-config-unavailable') [70 120 5]
```
Though, I am not sure whether this is the relevant one.

More lines from /var/log/syslog can be found here.

Update 1 - December 06 2015

As pointed out by one kind member, tried the nf_conntrack_pptp module approach.

Executed the following commands,
```
$ lsmod | grep nf_conntrack_pptp | wc -l
0

$ sudo modprobe nf_conntrack_pptp
lsmod | grep nf_conntrack_pptp
nf_conntrack_pptp      20480  0
nf_conntrack_proto_gre    16384  1 nf_conntrack_pptp
nf_conntrack          106496  2 nf_conntrack_proto_gre,nf_conntrack_pptp
```
Then tried my modem, the same failure. No discernable change in the log either.

Update 2 - December 06 2015

Executed as root,
```
systemctl restart network-manager.service
```
No output on screen (terminal).

Corresponding log from the above point to an attempt to connect using the modem can be found here.

Update 3 - December 06 2015

Installed ofono and then tried the modem again.

Please see the log here.

Update 4 - December 06 2015

Again executed as root,
```
systemctl restart network-manager.service
```
Corresponding log from the above point to an attempt to connect using the modem can be found here.

Update 5 - December 06 2015

Changed all "deny" to "allow" in /etc/dbus-1/system.d/nm-dispatcher.conf.

Tried connecting. No luck.

A few network connect and disconnect with Ethernet connection.

Followed by sudo systemctl restart network-manager.service.

Modem plug out and plug in.

Tried connecting again. Does not connect.

The log is here.

Update 6 - December 06 2015

Executed
```
sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt
```
and
```
export NM_PPP_DEBUG=1
sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log.txt
```
Could not run mm-test.py due to multiple errors. Did find the file at the indicated location. Got this from, https://github.com/openshine/ModemManager/blob/master/test/mm-test.py.

The above commands are somewhat different from those in the Wiki.

The log files are here.

Update 7 - December 07 2015

Executed again (after the suggested change in /lib/udev/rules.d/40-usb_modeswitch.rules and reboot)
```
sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt
```
and
```
sudo NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --log-level=debug --no-daemon > /tmp/nm.log.txt
```
The /var/log/syslog is included as well.

The log files are here.

Update 8 - December 08 2015

The updated set of logs are here.

Update 9 - December 08 2015

Test 1
1. This time booted the computer from an Ubuntu 14.04 32 bit DVD. As soon as the computer booted, started capturing the MM log.
2. Inserted the modem. lsusb showed that it was being recognized as a 19d2:1232 device which needs to be swithced to a 19d2:2003 device. Since installation of usb-modeswitch requires reboot of the machine (and hence loose the installation for DVD run), I prepared a custom switch file and switched the modem from command line (sudo usb_modeswitch -I -c 19d2:2003).
3. As soon as the switching was accomplished, I was informed that I was on Mobile Broadband Network and a New Broadband Connection appreard in network manager menu.
4. I setup the above connection in the usual way (APN name was not an issue), and the connection was established automatically.
5. I disconnected and ejected the modem.
6. Stopped capturing the MM log.
The complete MM log and syslog for the session start to modem eject can be found here.

Test 2

The same test with an Ubuntu 14.04 64 bit DVD.

The logs can be found here.

Update 10 - December 09 2015

This time tested with wvdial and found that if wvdial is run as root, we get a successful connection.

The wvdial conf and log, and corresponding syslog are here

Primary conjecture: the situation might have something to do with user group of the corresponding user.

But as indicated here,

With all these tools, to establish a dialup connection, the user has to be member of the "dip" and "dialout" groups, so put all users who are supposed to connect via dialup into these groups.

But as we can find,
```
$ groups masroor
masroor : masroor adm dialout cdrom sudo dip plugdev lpadmin sambashare family wireshark
```
So, the user is already a member of the indicated groups.

Now, perhaps the issue boils down to either of these points,
1. Which additional group does the user need to be?
2. How do we run the mobile broadband connection setup process as root? (security issues?)
Update 11 - December 09 2015

wvdial works with USB3 and does not work with USB1.

Please find the syslog here.

Also included is the output of dmesg | grep tty > /tmp/dmesg.tty.txt. But see those four lines near start of the file?

Update 12 - December 10 2015
1. Commented out line 4 (SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") in /lib/udev/rules.d/77-mm-zte-port-types.rules.
2. Rebooted my machine. Soft disconnected the cable and inserted the modem.
3. Tried to connect. Unsuccessful.
The syslog file is here.

Update 13 - December 10 2015

Out of sheer desperation, to see whether some local changes are affecting the connection, tested the machine with Ubuntu 15.04 and 15.10 DVDs.
1. Booted the machine with Xubuntu 15.04 64 bit DVD. The connection was successful like a charm.
2. Booted the machine with Ubuntu 15.10 64 bit DVD. The connection failed just like before.
What happened between 15.04 and 15.10?

So frustrating.

Update 14 - December 10 2015
1. Created a new file /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules as instructed in the answer.
2. Rebooted my machine (or executed sudo udevadm control --reload, actually tried both). Inserted the modem.
3. The modem got recognized.
```
$ lsusb
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
```
4. Soft disconnected the cable and tried to connect using the modem. Unsuccessful.
5. Ejected the modem.
The machine hangs once, is that a random event? My machine does not usually hang once in year.

The syslog file and the created rule files are here.

Update 15 - December 11 2015
1. Added the following lines to /lib/udev/rules.d/40-usb_modeswitch.rules.
```
# ZTE MF193E
ATTR{idVendor}=="19d2", ATTR{idProduct}=="1232", RUN+="usb_modeswitch '%b/%k'"
```
2. Left the file /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules intact.
3. Rebooted my machine. Inserted the modem.
4. The modem got recognized.
```
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
```
5. Soft disconnected the cable and tried to connect. Unsuccessful.
6. Ejected the modem.
7. Removed /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules.
8. Rebooted and tried the whole process again. Unsuccessful again.
The syslog file (complete, I did not take the risk of missing any important part) and the mentioned rule file (40) are here.

Update 16 - December 11 2015
1. Left only one 1232 rule in /lib/udev/rules.d/40-usb_modeswitch.rules, removed the other one.
2. Executed sudo udevadm control --reload.
3. Inserted the modem.
4. The modem got recognized.
```
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
```
5. Soft disconnected the cable and tried to connect. Unsuccessful.
6. Ejected the modem.
But did not we test the default system above? Did you mean to leave /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules in its place?

The syslog file (complete, I did not take the risk of missing any important part) and the mentioned rule file (40) are here

Update 17 - December 11 2015
1. Commented out the 1232 rule in /lib/udev/rules.d/40-usb_modeswitch.rules, added one for 2003.
```
# ZTE MFxxx
# Added on December 11 2015
ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"
```
2. Executed sudo udevadm control --reload.
3. Inserted the modem.
4. The modem got recognized as a 1232 device. I am not offered to try connecting (as far as my knowledge goes, it will not be registered to broadband network unless switching has happened to 2003)
```
Bus 001 Device 008: ID 19d2:1232 ZTE WCDMA Technologies MSM
```
5. Ejected the modem.
The syslog file and the mentioned rule file (40) are here

Update 18 - December 11 2015
1. Put all the rule files in their original form.
2. Watched lsusb output every one second using a shell script. Captured output in time stamped files.
3. Inserted the modem. (The modem first appears in the file lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). As we can find from the captures, it is clear that it switches from a 1232 device to a 2003 one.
4. Tried to connect. Unsuccessful.
5. Ejected the modem.
The syslog file, time stamped lsusb outputs and the mentioned rule files are here.

Now, you may want to match the syslog outputs with the time stamps.

Update 19 - December 11 2015

Performed this test in a completley new direction with the wish that I could isolate the issues.
1. Saved in a portable media /lib/udev/rules.d/40-usb-media-players.rules and /lib/udev/rules.d/77-mm-zte-port-types.rules (from the Ubuntu 15.10 machine).
2. Booted the machine using Xubuntu 15.04 64 bit DVD.
3. Executed diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt. The first file is from the one saved from 15.10.
  
  Examination of the diff file shows no idProduct 1232 or 2003.
4. Executed diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Again, the first file is from the one saved from 15.10.
  
  Again, examination of the diff file shows no idProduct 1232 or 2003.
5. Inserted the modem. The modem got recognized as a modem.
```
$ lsusb
Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
```
6. Could connect readily after setting up a mobile broadband connection.
7. Ejected the modem.
8. Installed the latest USB_ModeSwitch.
```
diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules
```
  Now returns NULL, as expected.
9. Executed sudo udevadm control --reload-rules.
10. Inserted the modem. The modem got recognized as a modem.
```
$ lsusb
Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
```
11. Could connect readily.
I could have tried upgrading MM and NM to that of Ubuntu 15.10, just to see where it breaks. I actually tried but gave up due to endless dependency problems.

All the above mentioned diff files are here.

Update 20 - December 12 2015

Test 1
1. The /lib/udev/rules in original condition.
2. The modem device has not been inserted yet in this session.
3. Setup ModemManager for debugging and setup udevadm capture.
```
sudo udevadm monitor --e |& tee udevadm.update20.WITHOUT78.log
sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee MM.update20.WITHOUT78.log
```
4. Plugged in the modem and waited till it says that it is registered in broadband network.
5. Tried to connect unsuccessfully.
6. Ejected the modem.
7. Packed up log files.
Test 2

Repeated the above test with /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules in place.

The log file names are self-explanatory.

All the above log files plus syslog and the 78 rule files are here.

I wish all the log files came with time stamps, making matching easier.

Update 21 - December 15 2015
1. Changed the rule file as suggested.
2. Rebooted my machine.
3. Inserted the modem and tried connecting. It did not work.
The rule file and the syslog are here.

Update 22 - December 16 2015

As advised in one comment, installed various kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ and tried connecting using the modem after booting in each.
1. 4.2.8-040208-generic, failure.
2. 4.1.15-040115-generic, failure.
3. 4.0.9-040009-generic, failure.
So, perhaps, we can rule out the kernel issue.

Update 23 - February 16 2016

The modem has started functioning in Ubuntu 16.04. This version is still in Alpha 1, but works fine in my laptop.
- KGIII over 8 years
  
  I bumped into a similar issue in the past and ended up having to disable DHCP and using gateway address numbers from the cell company and using Google's DNS servers. This was two or three years ago and I don't recall the exact steps needed nor do I know if this is the same problem but the error was almost verbatim. Wish I could help more.
- Masroor over 8 years
  
  @KGIII I will want to give this a try. Just one idle query, if it has something to do with DHCP, how come it works in Windows? Does DHCP server make any difference when allocating the address? Moreover, the same Linux machine (in which the modem fails to connect) works with Ethernet DHCP. Anyway, a real life experiment will be worth a thousand idle debates.
- KGIII over 8 years
  
  I'd guess Windows handles networking in a different manner and may have been already configured to deal with this specific hardware or hardware type. I haven't really paid much attention to Windows as of late so I'm probably not the best source of information for that.
- Masroor over 8 years
  
  @KGIII I tried setting the addresses. Unfortunately, the only two options available for a mobile broadband connection are two flavors of, Automatic (PPP). So, that is a closed road. Thanks anyway.
- Masroor over 8 years
  
  @RalphRönnquist Thanks for your comment. The situation is exasperating for me. This modem has worked before in Ubuntu and works today in Windows. Then why should not it work in Ubuntu? I am absolutely clueless.
- Ralph Rönnquist over 8 years
  
  Over at (forums.opensuse.org/showthread.php/…) was a vaguely related discussion, with the suggestion to modprobe nf_conntrack_pptp A shot in the dark probably, but it may be worth to try.
- Ralph Rönnquist over 8 years
  
  At (bbs.archlinux.org/viewtopic.php?id=194042) you'll find a couple of more notes in that line of study.
- Masroor over 8 years
  
  @RalphRönnquist Tried the nf_conntrack_pptp approach. Does not seem to work. See my update.
- Ralph Rönnquist over 8 years
  
  Ok. A few lines up in your log there's the note about "'NM_IS_DEVICE (self)' failed", and googling it leads to another work-around suggestion. Namely, with the device plugged in, do "sudo systemctl restart network-manager.service". (Now we are deep into the NetworkManager bug list..) If at all a fix, it's not a long term fix, but a run-time patch that needs to be repeated.
- Masroor over 8 years
  
  @RalphRönnquist Tried, please see my update.
- Ralph Rönnquist over 8 years
  
  Progress of some sort, I suppose. I would suggest that now it's the new complaint about "ofono" to deal with. There is an ofono package to install; do you have it installed? otherwise, please install it, and then man-handle the dongle once to see what happens (capture log please).
- Masroor over 8 years
  
  @RalphRönnquist Updated.
- Ralph Rönnquist over 8 years
  
  Let us continue this discussion in chat.
- muru over 8 years
  
  Just to eliminate the kernel as a source of problems, can you try installing the 4.0 and 4.1 kernels from kernel.ubuntu.com/~kernel-ppa/mainline and testing them?
- Masroor over 8 years
  
  @muru Please see my update 22. Does not look like a kernel issue.
- heemayl over 8 years
  
  Sir, have you got any chat notification? If not, we need to create a new room and add @RalphRönnquist there too so that others can discuss the stuffs done and to be done..
- Masroor over 8 years
  
  @heemayl It was there but don't see any now. Please create one. So far, I have used only the automatic ones.
- heemayl over 8 years
  
  Sir, I have created a new one chat.stackexchange.com/rooms/33038/discussion-on-q-703725 @RalphRönnquist please join the new room, we need you too..
- Masroor over 8 years
  
  He is at a +10 time zone. So, might be a bit late for him. Perhaps earlier in the day is more suitable.
- heemayl over 8 years
  
  @Masroor Sir, seems so..this is the problem with others too.."they" are in the wrong TZ :) ..we might have to rely on comments at the end :)
- Ralph Rönnquist over 8 years
  
  Yes, let's vote for a flat Earth, and then everyone can have breakfast together :-) ... I'll try to look in tonight; sometime about 4-8pm on your clock.
Masroor over 8 years

Unfortunately, it did not work. Please see the logs in my question.
Ralph Rönnquist over 8 years

Hmm. This log suggests it's coming up at modem level, but failing at ppp level. Would you mind get the nm.txt log happening as well, and possibly syslog, for a plugout/in gesture. Btw, I suppose its not also on cable when you plug in the modem.
Masroor over 8 years

Updated the same .zip file with two more logs included. I make it a point to (soft) disconnect the cable when making the tests. Though the cable has never been an issue before. Previously, after buying data packs before a travel, I always tested the modem in my home machine (PC) with the cable connected and subsequently used the modem in my laptop. Again, thanks for asking, there is no harm in making it sure.
Ralph Rönnquist over 8 years

Note my edit in the answer: next wild guess. cheers.
Masroor over 8 years

Tried with a number of APN strings, lowercase/uppercase, everything. No luck. Frustration is on the way.
Masroor over 8 years

Installed the older version (1.0.0) of ModemManager. Got this during installation, invoke-rc.d: modemmanager.service doesn't exist but the upstart job does. Nothing to start or stop until a systemd or init job is present. Get this while trying to start MM, ModemManager[10859]: <info> ModemManager (version 1.0.0) starting... ModemManager[10859]: <warn> Could not acquire the 'org.freedesktop.ModemManager1' service name ModemManager[10859]: <info> ModemManager is shut down
Ralph Rönnquist over 8 years

No worries. I'm old enough to chose my pleasures ;-). New edit.
Masroor over 8 years

Since do not seem to make modem-tester tool recognize my device (did you see that is specifically mention two manufacturers, though there is an All), used the modem (successfully, seems hard to believe to me based on the last couple of weeks) with 14.04 DVD, captured the logs. Please see my update. What could be wrong with 15.10?
Masroor over 8 years

Based on your, "back alleys to look into would be: 1) is the user in the right group?", we may have some substantial progress. Please see my update. Are we seeing the end of tunnel?
Ralph Rönnquist over 8 years

Ensure /etc/ppp/pap-secrets and /etc/ppp/chap-secrets have group dip (using chgrp as needed) and mod 740 (or -rw-r-----) (using chmod as needed). Mine didn't.
Masroor over 8 years

Changed as suggested, rebooted even. But it did not work. Hard to believe. Please see this page, around middle, Exec=gksudo "Teletalk_3G". This suggests that we are on the right track. But this utility will not install in 64 bit. And the NM method should work, as it did three months back.
Masroor over 8 years

Tested and updated.
Masroor over 8 years

The discussion on udev rules is very very deep water for me. As far as I understood, you are questioning some lines in the rule file, which apparently moves the reader to end unless some tty is not found. Performed test and updated. Please see my post.
Masroor over 8 years

I had a feeling that this time it will be successful. But it did not. See the update. It may be mentioned that in the successful DVD cases, the lsusb outputs are identical to the one in update 14.
Masroor over 8 years

Thanks. I am a bit confused about the doable in last sentence. The created rule in /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules already contains 1232. How should I change it? Please be specific.
Ralph Rönnquist over 8 years

Sorry, I meant the very first rule I suggested in this answer, in /lib/udev/rules.d/40-usb_modeswitch.rules.
Ralph Rönnquist over 8 years

Right. One more test: apparently there was a "1232" rule already in 40-usb_modeswitch.rules and just maybe this makes it switch twice. Comment out or remove mine (one of them), and then test it again. I'll keep reading the log meanwhile.....
Ralph Rönnquist over 8 years

Actually. It would all make more sense to me that there should be a switch rule for 2003 and no rule for 1232. That is, if the device registers as 2003 then it should be be switched (to 1232), but if it registers as 1232 than no switching should occur. I hadn't realized there was a 1232 before.... so: in short, put it back to be my 2003 rule, then find and comment out the 1232 rule. Test, and weep.
Masroor over 8 years

Okay, ignore update 16, and wait for update 17.
Ralph Rönnquist over 8 years

Maybe I am confused. Could you please capture lsusb for me; it should tell which product id it is now and what that product id is. But there's all too much switching happening in the log file. Is there something else that want it switched? Where? How?....
Masroor over 8 years

Each of the last few updates contains output of lsusb. Please take note of points 3 or 4 in the last few ones, update 14 (3), 15(4), 16(4) and 17(4). In the first three cases, initially it remained as 1232 only to get switched to 2003 a few seconds later, when it got registered in the mobile broadband. The only exception is the last one. And as my learning process goes, unless it gets switched to 2003, it is not a modem, it is a storage device. Please see this.
Ralph Rönnquist over 8 years

Thanks, apparently lsusb title is the same for 1232 and 2003. The thing is in the log, when switch to 2003, the subsequent lines suggest memory device, and when switched to 1232 they suggest a modem. to me. So this may be opposite for the one you ref'ed. Maybe a lsusb -v would tell the difference?
Masroor over 8 years

Please take note of updates 18 and 19. But specially for 19, please don't get misguided by me. My knowledge is very shallow and I am simply trying to learn by supplying information to you.
Ralph Rönnquist over 8 years

Unfortunately(?) the usb_modeswitch rule for this device was already in the standard rule set.
Masroor over 8 years

Which IP address should I type in? This is a PPP connection.