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
