MC7430 Connection problem

[Alexandru Ardelean]

On Tue, Oct 3, 2017 at 9:57 AM, Erik Kazandjian
<erik.kazandjian at accelleran.com> wrote:
> Another question I have is why are there 2 devices ?

Good question.
I'll also have to ask this.

I remember someone telling me that there's a primary and a secondary modem.
And I am seeing both.
But I am lost on the questions of why/how/what/huh?.


>
> BR
>
> Erik
>
>
> On 10/03/2017 08:43 AM, Alexandru Ardelean wrote:
>>
>> On Tue, Oct 3, 2017 at 9:38 AM, Erik Kazandjian
>> <erik.kazandjian at accelleran.com> wrote:
>>>
>>> Hi,
>>>
>>> I managed to set an ip address on my interface and pass data once.
>>> However
>>> this was a lucky shot as I can not reproduce it.
>>>
>>> This is what I have done.
>>>
>>> I rebooted the pi
>>>
>>> ifconfig  wwan0  down
>>> echo Y > /sys/class/net/wwan0/qmi/raw_ip
>>> ifconfig  wwan0  up
>>>
>>> The strange thing that I noticed here is that my wwan0 interface no
>>> longer
>>> has a hw address ?
>>>
>>> wwan0     Link encap:UNSPEC  HWaddr
>>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>>>            UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500 Metric:1
>>>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>            TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
>>>            collisions:0 txqueuelen:1000
>>>            RX bytes:0 (0.0 B)  TX bytes:11670 (11.3 KiB)
>>>
>>> wwan1     Link encap:Ethernet  HWaddr 86:10:a5:53:2a:0a
>>>            inet addr:169.254.80.97  Bcast:169.254.255.255
>>> Mask:255.255.0.0
>>>            inet6 addr: fe80::5d36:cbca:3f4f:c40f/64 Scope:Link
>>>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>            TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
>>>            collisions:0 txqueuelen:1000
>>>            RX bytes:0 (0.0 B)  TX bytes:12074 (11.7 KiB)
>>>
>>> I set modem in standby, this causes the modem to dettach (as it
>>> automatically attaches when it comes up)
>>>
>>> qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=low-power
>>>
>>> Then I bring it online again
>>>
>>> qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=online
>>>
>>> This command causes the modem to attach again. So then I stop the network
>>>
>>> qmicli -d /dev/cdc-wdm0  --wds-stop-network=disable-autoconnect
>>>
>>> Network cancelled... releasing resources
>>> [/dev/cdc-wdm0] Network stopped
>>>
>>> When I than try to setup the network mannually (not usin gqmi-network) I
>>> get
>>> the following message
>>>
>>> qmicli -d /dev/cdc-wdm0 --wds-start-network=apn='internet',ip-type=4
>>> --client-no-release-cid
>>>
>>> error: couldn't start network: QMI protocol error (26): 'NoEffect'
>>> [/dev/cdc-wdm0] Client ID not released:
>>>      Service: 'wds'
>>>          CID: '42'
>>>
>>> Which makes the following call fail.
>>>
>>> qmicli -d /dev/cdc-wdm0  --wds-get-current-settings
>>> error: couldn't get current settings: QMI protocol error (15):
>>> 'OutOfCall'
>>
>> You need to wait for the device to register to a network.
>> Using --nas-get-serving-system to check that it says "registered" at
>> Registration state:
>> I suspect that is why you get NoEffect when you connect via
>> wds-start-network, and OutOfCall when you check settings.
>>
>> I've noticed that MC7430 takes quite some time [ compared to MC73xx ]
>> to connect to a tower.
>> Not sure why though.
>>
>> Alex
>>
>>>
>>> Using the same set of commands I managed to get it working once. So I'm
>>> still not clear how I can reproduce the successfull case
>>>
>>> Thanks for any help
>>>
>>> Erik
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 10/02/2017 10:45 PM, Bjørn Mork wrote:
>>>>
>>>> Aleksander Morgado <aleksander at aleksander.es> writes:
>>>>
>>>>> Ah, true... then no idea why it didn't allow updating that... first
>>>>> time I've seen this.
>>>>>
>>>>> Erik, can you manually run this?
>>>>> $ sudo -s
>>>>> # echo Y > /sys/class/net/wwan0/qmi/raw_ip
>>>>
>>>> The driver will refuse to change mode if the netdev is running.  I.e. if
>>>> the interface is up.  It should log an error and the write should return
>>>> -EBUSY in this case.
>>>>
>>>> The driver will also notify other drivers of the upcoming type change,
>>>> allowing them to block it.  This will prevent mode change if you have
>>>> added the wwanX device to a bridge for example (which isn't a good idea
>>>> for a raw ip device).  The sysfs write should still return an
>>>> appropriate error code.
>>>>
>>>>
>>>>
>>>>
>>>> Bjørn
>>>
>>>
>