Yet another EM7455 question

Fri Jun 24 21:58:13 UTC 2016

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.tepnadze at 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 <list1 at michaelshell.org>
> wrote:
>
>> On Fri, 24 Jun 2016 12:57:35 +0200
>> Bjørn Mork <bjorn at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>>
>
>
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20160624/1426e9cb/attachment-0001.html>