I have got a ZTE MF-193E modem which worked fine before. 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. Also, when the same machine is booted from a 15.04 DVD, the modem works fine.) When I insert the modem, it gets detected alright, a CD icon is displayed in Unity with the name of the modem. It gets registered in the network, but eventually fails to connect. (More detailed report on tests and attempts can be found here, http://askubuntu.com/q/703725/82650)
I looked at the report and it's too detailed :) You can probably give us this info quicker than me digging through that long page... Could you attach here: * debug log of MM/NM running successfully in 15.04. * debug log of MM/NM running bad in 15.10. Make sure the same APN is used in both tests. Could you also tell me the exact versions you're testing in each Ubuntu release? And last but not least, would it be possible if you compile and test with ModemManager 1.4.12, which is the last stable release we've done some months ago? Thanks.
Created attachment 120586 [details] Log files and relevant explanations/descriptions
The tests were run in the following sequence: 1. Ubuntu 15.10 with MM 1.4.10. 2. Ubuntu 15.10 with MM 1.4.12. 3. Ubuntu 15.04 with MM 1.4.0. The log files are in the attached zip file. I have tried best to make the directory and file names self-explanatory. Please refer to the 0README file in each directory for further information.
(In reply to Aleksander Morgado from comment #1) > I looked at the report and it's too detailed :) > > You can probably give us this info quicker than me digging through that long > page... > > Could you attach here: > * debug log of MM/NM running successfully in 15.04. > * debug log of MM/NM running bad in 15.10. > Make sure the same APN is used in both tests. > > Could you also tell me the exact versions you're testing in each Ubuntu > release? > > And last but not least, would it be possible if you compile and test with > ModemManager 1.4.12, which is the last stable release we've done some months > ago? > > Thanks. Do you need any more information? I uploaded those files before the vacations. Still waiting desperately for a solution.
There's something wrong somewhere :) With MM 1.4.0 in Ubuntu 15:04 we had: Creating modem with plugin 'ZTE' and '4' ports tty/ttyUSB3 at (primary) tty/ttyUSB1 at (secondary) tty/ttyUSB3 data (primary) tty/ttyUSB0 qcdm 'ZTE' modem, VID 0x19D2 PID 0x2003 (usb) With MM 1.4.10 in Ubuntu 15:10 we have: Creating modem with plugin 'Generic' and '4' ports tty/ttyUSB1 at (primary) tty/ttyUSB3 at (secondary) tty/ttyUSB1 data (primary) tty/ttyUSB0 qcdm 'Generic' modem, VID 0x8086 PID 0x27CC (usb) Looks like the modem requires ttyUSB3 for primary/data, not ttyUSB1. But the main issue here is that MM is picking the device with the USB VID/PID of the ehci host controller (8086/27CC), not the modem USB VID/PID (19D2/2003)... and this is the first time I've seen this happening...
BTW; the test with MM 1.4.12 didn't get the proper MM debug logs...
Can you provide the output of the following command in Ubuntu 15.10? $ sudo udevadm info -a /dev/ttyUSB3
Also, could you build and run the test/lsudev program within ModemManager sources, and attach the output?
Created attachment 120848 [details] ModemManager 1.4.12 logs
(In reply to Aleksander Morgado from comment #6) > BTW; the test with MM 1.4.12 didn't get the proper MM debug logs... I am not sure what you meant by the proper logs for MM 1.4.12. As I have already pointed out since ModemManager got shutdown, further tests were not possible. Rerun the following tests and attached the MM log anyway. Purged the currently installed ModemManager. Installed ModemManager 1.4.12 from source. There were many unmet dependencies which had to be fulfilled during compilation. Rebooted machine. ModemManager --version gives, ModemManager 1.4.12. Soft disconnected Ethernet connection. Ran, sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/Ubunut15.10MM1.4.12.January072016.log.txt Since ModemManager got shutdown, further tests were not possible. Wrapped up the log. Please let me know if you need anything more.
(In reply to Aleksander Morgado from comment #7) > Can you provide the output of the following command in Ubuntu 15.10? > > $ sudo udevadm info -a /dev/ttyUSB3 Okay attached as, udevadm_info-a_dev_ttyUSB3.output
Created attachment 120849 [details] Output of sudo udevadm info -a /dev/ttyUSB3
(In reply to Aleksander Morgado from comment #8) > Also, could you build and run the test/lsudev program within ModemManager > sources, and attach the output? As I build the command from sources (MM 1.4.10) and run ./lsudev I get, ** (process:22938): WARNING **: Usage: ./lsudev [subsystem] Which subsystem name should I use?
lsusb tty
(In reply to Aleksander Morgado from comment #14) > lsusb tty Gah... "./lsudev tty"
(In reply to mmasroorali from comment #10) > (In reply to Aleksander Morgado from comment #6) > > BTW; the test with MM 1.4.12 didn't get the proper MM debug logs... > > I am not sure what you meant by the proper logs for MM 1.4.12. As I have > already pointed out since ModemManager got shutdown, further tests were not > possible. Rerun the following tests and attached the MM log anyway. > > Purged the currently installed ModemManager. Installed ModemManager 1.4.12 > from source. There were many unmet dependencies which had to be fulfilled > during compilation. Rebooted machine. ModemManager --version gives, > ModemManager 1.4.12. Soft disconnected Ethernet connection. Ran, > > sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee > /tmp/Ubunut15.10MM1.4.12.January072016.log.txt > > > Since ModemManager got shutdown, further tests were not possible. > Wrapped up the log. > > > Please let me know if you need anything more. What I meant is that your instance of manually run ModemManager couldn't acquire the bus name: Could not acquire the 'org.freedesktop.ModemManager1' service name This is because as soon as you "killall ModemManager", the system restarts it for you. If you're using systemd you can disable that by something like: $ sudo systemctl disable ModemManager $ sudo systemctl stop ModemManager // Now run with --debug If you're not using systemd you can move the /usr/sbin/ModemManager binary somewhere else so that the system doesn't know how to auto-restart it.
(In reply to Aleksander Morgado from comment #15) > (In reply to Aleksander Morgado from comment #14) > > lsusb tty > > Gah... "./lsudev tty" Okay added new attachment.
Created attachment 120856 [details] Output of ./lsudev tty
(In reply to Aleksander Morgado from comment #16) > (In reply to mmasroorali from comment #10) > > (In reply to Aleksander Morgado from comment #6) > > > BTW; the test with MM 1.4.12 didn't get the proper MM debug logs... > > > > I am not sure what you meant by the proper logs for MM 1.4.12. As I have > > already pointed out since ModemManager got shutdown, further tests were not > > possible. Rerun the following tests and attached the MM log anyway. > > > > Purged the currently installed ModemManager. Installed ModemManager 1.4.12 > > from source. There were many unmet dependencies which had to be fulfilled > > during compilation. Rebooted machine. ModemManager --version gives, > > ModemManager 1.4.12. Soft disconnected Ethernet connection. Ran, > > > > sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee > > /tmp/Ubunut15.10MM1.4.12.January072016.log.txt > > > > > > Since ModemManager got shutdown, further tests were not possible. > > Wrapped up the log. > > > > > > Please let me know if you need anything more. > > What I meant is that your instance of manually run ModemManager couldn't > acquire the bus name: > > Could not acquire the 'org.freedesktop.ModemManager1' service name > > This is because as soon as you "killall ModemManager", the system restarts > it for you. If you're using systemd you can disable that by something like: > > $ sudo systemctl disable ModemManager > $ sudo systemctl stop ModemManager > // Now run with --debug > > If you're not using systemd you can move the /usr/sbin/ModemManager binary > somewhere else so that the system doesn't know how to auto-restart it. Okay, I understand. Added new logs. Please let me know if this is not alright.
Created attachment 120857 [details] ModemManager 1.4.12 logs (UPDATED)
(In reply to mmasroorali from comment #20) > Created attachment 120857 [details] > ModemManager 1.4.12 logs (UPDATED) Still not ok... "Could not acquire the 'org.freedesktop.ModemManager1' service name"
(In reply to Aleksander Morgado from comment #21) > (In reply to mmasroorali from comment #20) > > Created attachment 120857 [details] > > ModemManager 1.4.12 logs (UPDATED) > > Still not ok... "Could not acquire the 'org.freedesktop.ModemManager1' > service name" But anyway, the issue looks to be out of MM, at least the "ID_VENDOR_ID" property of the ttys are not ok, 8086 is the VID of the host controller, not the VID of the modem...
(In reply to Aleksander Morgado from comment #21) > (In reply to mmasroorali from comment #20) > > Created attachment 120857 [details] > > ModemManager 1.4.12 logs (UPDATED) > > Still not ok... "Could not acquire the 'org.freedesktop.ModemManager1' > service name" Moved MM to another unconventional directory and executed it from there, but does not look okay. Uploaded the log anyway.
Created attachment 120864 [details] 120857: ModemManager 1.4.12 logs (UPDATED 2)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/18.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.