Yet another EM7455 question

Fri Jun 24 22:23:12 UTC 2016

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.ratnik at 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.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
>>
>
>
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>