Samo - I get that error whenever I set the fcc auth and modemmanager is currently running. My solution is 1) set fcc auth. 2) systemctl restart modemmanager.service 3) add-bearer 4) etc... I think it has something to do with --no-close options in libmbim. It's really hacky for now. But it's what I use until modemmanager gets a stable release that sets the fcc auth.
On Fri, Jun 24, 2016 at 2:58 PM, Samo Ratnik <samo.rat...@gmail.com> wrote: > > So, no success on my end as well. Here's the report. > > First of all, up until today, I had NetworkManager enabled. I've described > the problems here (and I was using Arch's stock libmbim, libqmi and > modemmanager at that point): > https://bbs.archlinux.org/viewtopic.php?pid=1636411 > > Today, I disabled the NetworkManager. I also compiled the latest state in > "qmi-over-mbim" branches for all three libs locally (as already described > here: http://pastie.org/private/jdrdgnmzlfvsn2fv8mva). I thought since the > AUR packages that Joshua is mentioning were last updated on April 16th that > could make a difference (I've contacted the current AUR maintainer but > didn't heard back). But despite the disabled NetworkManager, I couldn't > start the ModemManager: http://pastie.org/private/cqaheh4qdftw9p1hlxjw. How > do I "register" the service if I compile it locally? > > Then, I uninstalled (via `sudo make uninstall`) all three locally compiled > libs, installed the AUR packages and Arch's stock modemmanager. Now I'm > getting a "couldn't connect the bearer: > 'GDBus.Error:org.freedesktop.libmbim.Error.Status.NotInitialized: > NotInitialized'" error when I try to connect the bearer and the modem: > http://pastie.org/private/7lbsbeiyde9th5yp2rnova. > > Regards, > Samo > > > On Fri, Jun 24, 2016 at 11:21 PM, George Tepnadze > <george.tepna...@gmail.com> wrote: >> >> Signal quality was 64 or 49 but still no ping or traffic. >> Checked other traffic types (telnet, ssh, www and etc) but no RX traffic >> so it doesn't work for sure. >> Also tried to connect with qmi-network with no success, no traffic. >> >> # /usr/bin/qmi-network /dev/cdc-wdm1 start >> Loading profile at /etc/qmi-network.conf... >> APN: 3g.ge >> APN user: unset >> APN password: unset >> qmi-proxy: yes >> qmi-over-mbim: yes >> fcc auth: yes >> static ip: yes >> error: couldn't set FCC authentication: QMI protocol error (26): >> 'NoEffect' >> Starting network with 'qmicli -d /dev/cdc-wdm1 >> --wds-start-network=apn='3g.ge' --client-no-release-cid --device-open-proxy >> --device-open-mbim'... >> IP_FAMILY=IPV4 >> IPV4_ADDRESS=10.112.83.119 >> IPV4_CIDR=10.112.83.119/28 >> IPV4_SUBNET_MASK=255.255.255.240 >> IPV4_GATEWAY_ADDRESS=10.112.83.120 >> IPV4_PRIMARY_DNS=81.95.167.65 >> IPV4_SECONDARY_DNS=81.95.167.66 >> MTU=1500 >> IFACE=wwp0s20f0u2i12 >> Saving state at /tmp/qmi-network-state-cdc-wdm1... (IFACE: wwp0s20f0u2i12) >> Saving state at /tmp/qmi-network-state-cdc-wdm1... (CID: 51) >> Saving state at /tmp/qmi-network-state-cdc-wdm1... (PDH: 63249600) >> Network started successfully >> >> # /usr/bin/qmi-network /dev/cdc-wdm1 status >> Loading profile at /etc/qmi-network.conf... >> APN: 3g.ge >> APN user: unset >> APN password: unset >> qmi-proxy: yes >> qmi-over-mbim: yes >> fcc auth: yes >> static ip: yes >> Loading previous state from /tmp/qmi-network-state-cdc-wdm1... >> Previous CID: 51 >> Previous PDH: 63249600 >> Getting status with 'qmicli -d /dev/cdc-wdm1 >> --wds-get-packet-service-status --client-cid=51 --client-no-release-cid >> --device-open-proxy --device-open-mbim'... >> Status: connected >> >> >> On Fri, Jun 24, 2016 at 11:55 PM, Michael Shell <li...@michaelshell.org> >> wrote: >>> >>> On Fri, 24 Jun 2016 12:57:35 +0200 >>> Bjørn Mork <bj...@mork.no> wrote: >>> >>> > This means that some operators filter the Google DNS servers. >>> >>> >>> In addition to using a VPN, one option to overcome such increasingly >>> commonb and vile ISP behavior is DNSCrypt: >>> >>> https://dnscrypt.org/ >>> >>> The list of known encrypted DNS servers is stored in >>> /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv >>> >>> The DNS crypt daemon is started like: >>> >>> /usr/sbin/dnscrypt-proxy --daemonize -u dnscrypt >>> --resolvers-list=/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv >>> --resolver-name=open >>> dns >>> >>> To bypass ISP UDP traffic filters, you can add the --tcp-only option. >>> There also is --resolver-address=<ip>[:port] >>> >>> See >>> >>> man dnscrypt-proxy >>> >>> for details. >>> >>> Just set your /etc/resolv.conf to contain: >>> >>> # the local DNSCrypt proxy >>> nameserver 127.0.0.1 >>> >>> and the system will use the DNSCrypt proxy connection for >>> DNS lookups. >>> >>> BTW, many mobile ISPs, at least T-Mobile, are now using a web >>> proxy to snoop on all open http (non-https) traffic. >>> >>> The days of any unencrypted web traffic are coming to an >>> end and with good reason it seems. >>> >>> >>> Cheers, >>> >>> Mike Shell >>> _______________________________________________ >>> ModemManager-devel mailing list >>> ModemManager-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel >> >> >> >> _______________________________________________ >> ModemManager-devel mailing list >> ModemManager-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel >> > > > _______________________________________________ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
