Strange behaviour of Sierra Wireless MC7430

Tue Oct 17 07:59:34 UTC 2017

Hi Aleksander,

is their a way that I can set the modem in transparent/bridge mode and 
does this mean that I will get the ip address of the modem automatically 
on my wwan0 interface as soon as I start the network ?

BR

Erik

On 10/17/2017 09:48 AM, Aleksander Morgado wrote:
> Hey,
>
>> The MC7430 does behave very strange when I try to setup ip connectivity to
>> it.
>>
>> When I bring the modem on line  qmicli -d /dev/cdc-wdm0
>> --dms-set-operating-mode=online I see the modem attaching on our cell and in
>> the Attach accept message it gets an IP address. That address is not
>> automatically added to the wwan0 interface. Verification of the
>> nas-serving-system returns the following info
>>
>> qmicli -d /dev/cdc-wdm0  --nas-get-serving-system
>> [/dev/cdc-wdm0] Successfully got serving system:
>>      Registration state: 'registered'
>>      CS: 'attached'
>>      PS: 'attached'
>>      Selected network: '3gpp'
>>      Radio interfaces: '1'
>>          [0]: 'lte'
>>      Roaming status: 'off'
>>      Data service capabilities: '1'
>>          [0]: 'lte'
>>      Current PLMN:
>>          MCC: '1'
>>          MNC: '1'
>>          Description: 'Test1-1'
>>      Roaming indicators: '1'
>>          [0]: 'off' (lte)
>>      3GPP location area code: '65534'
>>      3GPP cell ID: '769'
>>      Detailed status:
>>          Status: 'available'
>>          Capability: 'cs-ps'
>>          HDR Status: 'none'
>>          HDR Hybrid: 'no'
>>          Forbidden: 'no'
>>      LTE tracking area code: '1'
>>      Full operator code info:
>>          MCC: '1'
>>          MNC: '1'
>>          MNC with PCS digit: 'no'
>>
> At this stage, from the point of view of the user, you just got
> registered to the network but no data call was explicitly started by
> the user (regardless of whether the modem got an IP from the LTE
> network, which always happens as soon as the modem gets registered in
> LTE).
>
>> However when I try to get information about the IP address using  qmicli -d
>> /dev/cdc-wdm0  --wds-get-current-settings I get
>>
>> error: couldn't get current settings: QMI protocol error (15): 'OutOfCall'
>>
> As above, the user didn't start explicitly a data call, so OutOfCall error.
>
>> Until a few days ago this would just return me the assigned IP address. If I
>> than start the network (can someone explain me what this does) I get the
>> following  qmi-network /dev/cdc-wdm0 start
>>
> "Start the network" means to start a data call explicitly. The user
> requests a data call to the modem and gets assigned a "session id" for
> the call.
>
>> Loading profile at /etc/qmi-network.conf...
>>      APN: internet
>>      APN user: unset
>>      APN password: unset
>>      qmi-proxy: no
>> Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-format
>> '...
>> Device link layer protocol retrieved: raw-ip
>> Getting expected data format with 'qmicli -d /dev/cdc-wdm0
>> --get-expected-data-format'...
>> Expected link layer protocol retrieved: raw-ip
>> Device and kernel link layer protocol match: raw-ip
>> Starting network with 'qmicli -d /dev/cdc-wdm0
>> --wds-start-network=apn='internet'  --client-no-release-cid '...
>> Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 35)
>> Saving state at /tmp/qmi-network-state-cdc-wdm0... (PDH: 62876480)
>> Network started successfully
>>
> At this point the network was started, i.e. the data call was established.
>
>> If I than ask for the current settings qmicli -d /dev/cdc-wdm0
>> --wds-get-current-settings I get
>>
>>   Current settings retrieved:
>>             IP Family: IPv4
>>          IPv4 address: 10.188.20.18
>>      IPv4 subnet mask: 255.255.255.252
>> IPv4 gateway address: 10.188.20.17
>>      IPv4 primary DNS: 8.8.8.8
>>                   MTU: 1500
>>               Domains: none
>>
> These are the settings that the modem requires to be set in the
> network interface. Two options here: either IP settings assigned by
> the network (transparent/bridge mode) or assigned by the modem itself
> (router mode).
>
>> The first thing I noticed is the netmask. I don't know where the modem is
>> getting this from but it is definitely not coming from the core network.
>> Anyway if I assign 10.188.20.18/24 to the wwan0 interface I see that wwan0
>> is configured but the Link encap is UNSPEC
>>
> The netmask is just so that the next hop (the gateway IP that the
> modem assigned to itself) is in the same subnet is within the range
> defined by the netmask.
>
>> wwan0     Link encap:UNSPEC  HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>>            inet addr:10.188.20.18  P-t-P:10.188.20.18  Mask:255.255.255.0
>>            inet6 addr: fe80::d37a:aed3:aeb:4d4/64 Scope:Link
>>            UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>            TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
>>            collisions:0 txqueuelen:1000
>>            RX bytes:0 (0.0 B)  TX bytes:504 (504.0 B)
>>
> The UNSPEC link encap is because this interface is in raw-IP mode;
> i.e. no ethernet headers, just IP packets.
>
>> If I than try to ping from my raspberry pi which has the modem connected to
>> a host behind the core network, I see nothing arriving in the GTP tunnel on
>> core network, however when I ping from the host behind the core network to
>> 10.188.20.18 I get replies from the ping , I even see them in both
>> directions going through the GTP tunnel but on my linux interface (wwan0) on
>> the rasberry pi I don't see any packet being received or transmitted. So it
>> looks as if the Sierra Wireless card is responding to the pings but it is
>> not offering its IP capabilities to the my Linux.
>>
> How are you doing the ping?
> Do you have rp_filter disabled for the WWAN?
>