[Touch-packages] [Bug 1525392] Re: unable to use Sprint/Franklin U301 modem (16d8:6008, CMOTECH CMO6008) on modern Ubuntu (Wily/Xenial)

2015-12-15 Thread Wladimir Mutel
created related ModemManager bug https://bugs.freedesktop.org/show_bug.cgi?id=93392 ** Bug watch added: freedesktop.org Bugzilla #93392 https://bugs.freedesktop.org/show_bug.cgi?id=93392 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1525392] Re: unable to use Sprint/Franklin U301 modem (16d8:6008, CMOTECH CMO6008) on modern Ubuntu (Wily/Xenial)

2015-12-13 Thread Wladimir Mutel
To my big surprise, it worked with Kubuntu 12.04 So it is a clear regression, most probably caused by adding QMI support to the kernel and to the ModemManager, also by ModemManager relying on newer QMI versions than those provided by older modems, and by absence of testing ModemManager on this

[Touch-packages] [Bug 1525392] Re: unable to use Sprint/Franklin U301 modem (16d8:6008, CMOTECH CMO6008) on modern Ubuntu (Wily/Xenial)

2015-12-13 Thread Wladimir Mutel
It did not work with default setup of Kubuntu 14.04, but I made it work after blacklisting modules qmi_wwan & cdc_wdm as recommended at some Internet pages like http://kubuntu.ru/node/13046 (https://translate.google.com/translate?sl=ru=en=y=_t=uk=UTF-8=http%3A%2F%2Fkubuntu.ru%2Fnode%2F13046 ==url)

[Touch-packages] [Bug 1525392] Re: unable to use Sprint/Franklin U301 modem (16d8:6008, CMOTECH CMO6008) on modern Ubuntu (Wily/Xenial)

2015-12-12 Thread Wladimir Mutel
from Debian 8.2, packages : ii linux-image-3.16.0-4-amd643.16.7-ckt11-1+deb8u6 amd64 Linux 3.16 for 64-bit PCs ii modemmanager 1.4.0-1 amd64 D-Bus service for managing modems ii network-manager

[Touch-packages] [Bug 1525392] Re: unable to use Sprint/Franklin U301 modem (16d8:6008, CMOTECH CMO6008) on modern Ubuntu (Wily/Xenial)

2015-12-11 Thread Wladimir Mutel
I was given this modem and asked if I could make it work with Linux. I could hold it till next Thursday, after which getting it back for testing could become more difficult. I also tested it with Debian 8.2, also without success (but with different behaviour, at least it was able to initialize