Recently added
Question
How to collect initial diagnostics data and logs for Alcatel USB dongles, needed when requesting Techship technical support?
Solution
In order to troubleshoot and solve a technical problem, we ask you to please provide information about your host system and logs from the related Alcatel USB dongles when creating a technical support ticket.
Detailed problem description and in what situations it present or can be reproduced.
Describe the host system:
-Hardware (system board, peripherals...)
-Operating system and detailed versions (E.g. Windows, Linux release, kernel...)
-Drivers and driver versions
Identify the precise details of cellular module found on label:
-Model
-SKU/BOM or P/N code
(For RMA returns the IMEI number is mandatory)
If you are running on a Linux based system, please capture the terminal logs bellow:
uname -a
lsusb
lsusb -t
ifconfig -a
ls -l /dev/serial/by-id
ls -l /sys/bus/usb-serial/devices
dmesg
The logs from the cellular module firmware can be acquired by accessing the USB enumerated serial (COM) interfaces accepting AT commands. They can be named modem, AT, PC UI etc. (In Windows device manager, found under modem or serial interfaces). Send the following AT commands bellow to module and capture the output and include them when creating the the technical support ticket.
Test that you get a reply with command:
AT
Command echo enabled:
ATE1
Basic module info:
ATI
Verbose error reporting:
AT+CMEE=2
Last error report:
AT+CEER
Firmware version:
AT+GMR
IMEI Code:
AT+CGSN
USB endpoint configuration:
AT+USBMODE?
List current configuration:
AT&V
Operational mode:
AT+CFUN?
Pin status:
AT+CPIN?
Request extended system info:
AT^SYSINFOEX
AT^SYSCFGEX?
Preferred PLMN list:
AT+CPOL?
Request resident Band:
AT+CNBP?
List network operator info:
AT+COPS?
Network registration status:
AT+CREG?
Network EPS registration status:
AT+CEREG?
Signal strength:
AT+CSQ
Packet domain attach status
AT+CGATT?
List APN details/PDP profiles:
AT+CGDCONT?
AT$QCPDPP?
PDP profiles attach status:
AT+CGACT?
Show PDP IP address:
AT+CGPADDR
AT+CGCONTRDP
RM network interface status:
AT$QCRMCALL?
The support ticket can be created after login at: https://techship.com/technical_support/
Question
How to establish a data connection with Sierra Wireless EM9190, EM9191 and EM7690 in Linux using MBIM network interface over USB
Solution
5G technology introduces new requirements on the interface links between the host systems and cellular modules.
The Linux community continuously commit necessary changes to the kernel drivers and interface management tools to improve the compatibility and performance.
Because of this, it is important that you base your Linux system builds on up-to-date kernel versions, avoiding many problems already solved.
Ensure that you have up-to-date firmware version in the cellular module. Check the dedicated product page here at Techship and the firmware downloads tab or open a technical support ticket.
Early devices and engineering samples came with a older baseline firmware version and typically need to be updated in a Windows system.
This guide describes how to establish a MBIM data connection in Linux using libmbim library and mbimcli command line interface for Sierra Wireless EM919x series modules when connected over USB to the host system.
The cdc_mbim kernel driver module and libmbim library is used.
Ensure that the cdc_mbim network kernel driver and qcserial usb-serial driver is properly loaded to the module interfaces, refer to Sierra Wireless Mobile broadband package for Linux for more details. Binary version and guide linked below.
It can be checked e.g. through dmesg, usb-devices or lsusb -t commands.
usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=1199 ProdID=90d3 Rev=00.06
S: Manufacturer=Sierra Wireless, Incorporated
S: Product=Sierra Wireless EM9190
S: SerialNumber=
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=techship_serial
I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
Should you not have the qcserial drivers loaded correctly, you can try compile our modified option usb-serial kernel driver module techship_serial from git link below and load them into your system build, it is however always recommended that you use the vendor provided or recommended drivers.
See the git readme files for details on pre-requirements, how to clone, compile and use the make file options to install the drivers.
They are available in the following git repository:
https://bitbucket.org/storjor/techship_linux_drivers/
Refer to the mbimcli manual pages for details on the control commands that can be supported by the libmbim library and mbimcli command line interface. Note however that not all mbim commands are supported by all cellular module vendors and might be dependant on chipset families, firmware versions and additional vendor specific command etc.
https://www.freedesktop.org/wiki/Software/libmbim/
Example of how to set up a cellular data connection:
Note! A working MBIM network interface data connection requires that the MBIM control message tunnel is kept open at all time also.
To keep it open, start a new session with a mbimcli command, and keep the session open after the command execution by the --no-close attribute.
The Session ID / Transaction ID number (TRID) that is opened with the mbimcli command will be given back in the reply, save it for use in the next mbimcli command.
If the session ID linked to the network data connection is closed, then the data connection on the network interface will also be closed.
Check cellular module device version and capability details:
mbimcli -p -d /dev/cdc-wdm0 --query-device-caps --no-close
Check cellular RF radio status:
mbimcli -p -d /dev/cdc-wdm0 --query-radio-state --no-close
If not enabled, set it active:
mbimcli -p -d /dev/cdc-wdm0 --set-radio-state=on --no-close --no-open=##
Check SIM card subscriber state:
mbimcli -p -d /dev/cdc-wdm0 --query-subscriber-ready-status --no-close --no-open=##
If pin is needed, enter it using --enter-pin command:
mbimcli -p -d /dev/cdc-wdm0 --enter-pin=#### --no-close --no-open=##
Check cellular network registration state:
mbimcli -p -d /dev/cdc-wdm0 --query-registration-state --no-close --no-open=##
If not registered already, try using register automatic:
mbimcli -p -d /dev/cdc-wdm0 --register-automatic --no-close --no-open=##
Check the packet data service state:
mbimcli -p -d /dev/cdc-wdm0 --query-packet-service-state --no-close --no-open=##
If packet service state is not attached, use attach command:
mbimcli -p -d /dev/cdc-wdm0 --attach-packet-service --no-close --no-open=##
To to start a data connection use the connect command, with the desired parameters for PDP APN, IP type, auth details, etc.
mbimcli -p -d /dev/cdc-wdm0 --connect=apn='data.tre.se',ip-type='ipv4v6' --no-close --no-open=##
Bring down the MBIM network interface:
ip link set dev wwan0 down
Clear any existing IP address and routes:
ip -4 -6 address flush dev wwan0
ip -4 -6 route flush dev wwan0
The mbimcli connect command returns the IP, gateway, DNS, and MTU details for the data connection if established successfully.
Enter the IPv4 details to the network interface in the Linux host system, e.g.:
ip address add 2.67.32.120/28 dev wwan0
ip link set mtu 1500 dev wwan0
Enter the IPv6 details to the network interface in the Linux host system, e.g.:
ip -6 addr add 2a02:aa1:1019:50b6:a5b0:ade:8531:b178/64 dev wwan0
ip -6 link set mtu 1500 dev wwan0
Enable the network interface:
ip link set dev wwan0 up
Apply appropriate network interface routing suitable for your use-case, e.g:
ip route add default dev
ip -6 route add default dev wwan0
You should now have a working cellular network data connection.
Test it e.g. by sending ping requests over the interface:
ping -I wwan0 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) from 2.67.32.120 wwan0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=38.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=36.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=43.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=41.5 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 36.374/39.975/43.500/2.728 ms
ping -6 -I wwan0 2600:: -c 4
PING 2600::(2600::) from 2a02:aa1:1019:50b6:e59e:4d4a:e778:f24e wwan0: 56 data bytes
64 bytes from 2600::: icmp_seq=1 ttl=52 time=156 ms
64 bytes from 2600::: icmp_seq=2 ttl=52 time=171 ms
64 bytes from 2600::: icmp_seq=3 ttl=52 time=169 ms
64 bytes from 2600::: icmp_seq=4 ttl=52 time=167 ms
--- 2600:: ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 156.153/165.508/170.577/5.576 ms
To stop the cellular data network connection use mbimcli disconnect command.
Use the Session ID from the previous mbimcli command reply in --no-open=## attribute, but do not include the --no-close attribute, doing so closes the session afterwards.
mbimcli -p -d /dev/cdc-wdm0 --disconnect --no-open=##
Bring down the interface:
ip link set dev wwan0 down
Clear any remaining IP address and routes:
ip -4 -6 address flush dev wwan0
ip -4 -6 route flush dev wwan0
It is up to the host application to manage and poll the connection state of the cellular module.
E.g. if the connection is lost temporarily due to no network coverage in the current location, the host application should tear down and re-establish the data connection when cellular module is registered in network again.
If the data connection fails for some reason several times, ensure that the connect retry attempts do not take place continuously without some extended delays in-between.
Depending on the cellular network operator, they can enforce lock-out on your subscription/device for certain time periods in order to protect the network from being flooded by requests.
Question
Example on how to establish a data connection with Telit FN980 series in Linux using MBIM mode over USB interface
Solution
Example on how to establish a data connection with Telit FN980 series in Linux using MBIM network interface over USB
5G technology introduces new requirements on the interface links between the host systems and cellular modules.
The Linux community continuously commit necessary changes to the kernel drivers and interface management tools to improve the compatibility and performance.
Because of this, it is important that you base your Linux system builds on up-to-date kernel versions, avoiding many problems already solved.
Ensure that you have up-to-date firmware version in the cellular module. Check the dedicated product page here at Techship and the firmware downloads tab or open a technical support ticket.
Early devices and engineering samples came with a older baseline firmware version and typically need to be updated in a Windows system.
This guide describes how to establish a MBIM data connection in Linux using libmbim library and mbimcli command line interface for Telit FN980 series modules when connected over USB to the host system.
The cdc_mbim kernel driver module and libmbim library is used.
Ensure that you have the Telit module in MBIM usb mode and cdc_mbim network kernel driver and option usb-serial driver properly loaded to the module interfaces.
It can be checked e.g. through dmesg, usb-devices or lsusb -t commands.
usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 10 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=1bc7 ProdID=1051 Rev=04.14
S: Manufacturer=Telit Wireless Solutions
S: Product=FN980m
S: SerialNumber=
C: #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=techship_serial
I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
I: If#=0x2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#=0x3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
I: If#=0x5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
I: If#=0x6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
I: If#=0x7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
If the option serial drivers are not correctly loaded in your current system build and kernel version, please refer to Telit Linux integration guide for details on the integration.
You can try compile our modified option kernel driver module techship_serial from git link below and load them into your system build instead also.
See the git readme files for details on pre-requirements, how to clone, compile and use the make file options to install the drivers.
They are available in the following git repository: https://bitbucket.org/storjor/techship_linux_drivers/
Refer to the mbimcli manual pages for details on the control commands that can be supported by the libmbim library and mbimcli command line interface. Note however that not all mbim commands are supported by all cellular module vendors and might be dependant on chipset families, firmware versions and additional vendor specific command etc.
https://www.freedesktop.org/wiki/Software/libmbim/
Example of how to set up a cellular data connection:
Note! A working MBIM network interface data connection requires that the MBIM control message tunnel is kept open at all time also.
To keep it open, start a new session with a mbimcli command, and keep the session open after the command execution by the --no-close attribute.
The Session ID / Transaction ID number (TRID) that is opened with the mbimcli command will be given back in the reply, save it for use in the next mbimcli command.
If the session ID linked to the network data connection is closed, then the data connection on the network interface will also be closed.
Check device details and capabilities:
mbimcli -p -d /dev/cdc-wdm0 --query-device-caps --no-close
Check cellular RF radio status:
mbimcli -p -d /dev/cdc-wdm0 --query-radio-state --no-close --no-open=##
If not enabled, set it active:
mbimcli -p -d /dev/cdc-wdm0 --set-radio-state=on --no-close --no-open=##
Check SIM card subscriber state:
mbimcli -p -d /dev/cdc-wdm0 --query-subscriber-ready-status --no-close --no-open=##
If pin is needed, enter it using --enter-pin command:
mbimcli -p -d /dev/cdc-wdm0 --enter-pin=#### --no-close --no-open=##
Check cellular network registration state:
mbimcli -p -d /dev/cdc-wdm0 --query-registration-state --no-close --no-open=##
If not registered already, try using register automatic:
mbimcli -p -d /dev/cdc-wdm0 --register-automatic --no-close --no-open=##
Check the packet data service state:
mbimcli -p -d /dev/cdc-wdm0 --query-packet-service-state --no-close --no-open=##
If packet service state is not attached, use attach command:
mbimcli -p -d /dev/cdc-wdm0 --attach-packet-service --no-close --no-open=##
To to start a data connection use the connect command, with the desired parameters for PDP APN, IP type, auth details, etc.
mbimcli -p -d /dev/cdc-wdm0 --connect=apn='data.tre.se',ip-type='ipv4v6' --no-close --no-open=##
Bring down the MBIM network interface:
ip link set dev wwan0 down
Clear any existing IP address and routes:
ip -4 -6 address flush dev wwan0
ip -4 -6 route flush dev wwan0
The mbimcli connect command returns the IP, gateway, DNS, and MTU details for the data connection if established successfully.
Enter the IPv4 details to the network interface in the Linux host system, e.g.:
ip address add 2.68.254.241/30 dev wwan0
ip link set mtu 1500 dev wwan0
Enter the IPv6 details to the network interface in the Linux host system, e.g.:
ip -6 addr add 2a02:aa1:1011:b001:5fc:6a67:296c:8852/64 dev wwan0
ip -6 link set mtu 1500 dev wwan0
Enable the network interface:
ip link set dev wwan0 up
Apply appropriate network interface routing suitable for your use-case, e.g:
ip route add default dev
ip -6 route add default dev wwan0
You should now have a working cellular network data connection.
Test it e.g. by sending ping requests over the interface:
ping -I wwan0 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) from 2.70.103.209 wwan0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=224 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=42.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=30.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=38.4 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 30.657/84.031/224.373/81.140 ms
ping -6 -I wwan0 2600:: -c 4
PING 2600::(2600::) from 2a02:aa1:1021:b9d1:8847:afd4:e35a:aa29 wwan0: 56 data bytes
64 bytes from 2600::: icmp_seq=1 ttl=52 time=173 ms
64 bytes from 2600::: icmp_seq=2 ttl=52 time=153 ms
64 bytes from 2600::: icmp_seq=3 ttl=52 time=152 ms
64 bytes from 2600::: icmp_seq=4 ttl=52 time=208 ms
--- 2600:: ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 152.108/171.523/208.073/22.623 ms
To stop the cellular data network connection use mbimcli disconnect command.
Use the Session ID from the previous mbimcli command reply in --no-open=## attribute, but do not include the --no-close attribute, doing so closes the session afterwards.
mbimcli -p -d /dev/cdc-wdm0 --disconnect --no-open=##
Bring down the interface:
ip link set dev wwan0 down
Clear any remaining IP address and routes:
ip -4 -6 address flush dev wwan0
ip -4 -6 route flush dev wwan0
It is up to the host application to manage and poll the connection state of the cellular module.
E.g. if the connection is lost temporarily due to no network coverage in the current location, the host application should tear down and re-establish the data connection when cellular module is registered in network again.
If the data connection fails for some reason several times, ensure that the connect retry attempts do not take place continuously without some extended delays in-between.
Depending on the cellular network operator, they can enforce lock-out on your subscription/device for certain time periods in order to protect the network from being flooded by requests.
Question
Example on how to establish a data connection with Simcom SIM8202x-M2 series in Linux using MBIM network interface over USB
Solution
Example on how to establish a data connection with Simcom SIM8202x-M2 series in Linux using MBIM network interface over USB
5G technology introduces new requirements on the interface links between the host systems and cellular modules.
The Linux community continuously commit necessary changes to the kernel drivers and interface management tools to improve the compatibility and performance.
Because of this, it is important that you base your Linux system builds on up-to-date kernel versions, avoiding many problems already solved.
Ensure that you have up-to-date firmware version in the cellular module. Check the dedicated product page here at Techship and the firmware downloads tab or open a technical support ticket.
Early devices and engineering samples came with a older baseline firmware version and typically need to be updated in a Windows system.
This guide describes how to establish a MBIM data connection in Linux using libmbim library and mbimcli command line interface for SIM8202x-M2 series modules when connected over USB to the host system.
The cdc_mbim kernel driver module and libmbim library is used.
Ensure that you have the Simcom module in MBIM usb mode and cdc_mbim network kernel driver and option usb-serial driver properly loaded to the module interfaces.
It can be checked e.g. through dmesg, usb-devices or lsusb -t commands.
usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=1e0e ProdID=901e Rev=04.14
S: Manufacturer=QCOM
S: Product=SDXPRAIRIE-MTP _SN:
S: SerialNumber=
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=techship_serial
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=techship_serial
I: If#=0x2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#=0x3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=techship_serial
I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
If the option serial drivers are not correctly loaded in your current system build and kernel version, you can try compile our modified option kernel driver module techship_serial from git link below and load them into your system build.
See the git readme files for details on pre-requirements, how to clone, compile and use the make file options to install the drivers.
They are available in the following git repository: https://bitbucket.org/storjor/techship_linux_drivers/
Refer to the mbimcli manual pages for details on the control commands that can be supported by the libmbim library and mbimcli command line interface. Note however that not all mbim commands are supported by all cellular module vendors and might be dependant on chipset families, firmware versions and additional vendor specific command etc.
https://www.freedesktop.org/wiki/Software/libmbim/
Example of how to set up a cellular data connection:
Note! A working MBIM network interface data connection requires that the MBIM control message tunnel is kept open at all time also.
To keep it open, start a new session with a mbimcli command, and keep the session open after the command execution by the --no-close attribute.
The Session ID / Transaction ID number (TRID) that is opened with the mbimcli command will be given back in the reply, save it for use in the next mbimcli command.
If the session ID linked to the network data connection is closed, then the data connection on the network interface will also be closed.
Check cellular RF radio status:
mbimcli -p -d /dev/cdc-wdm0 --query-radio-state --no-close
If not enabled, set it active:
mbimcli -p -d /dev/cdc-wdm0 --set-radio-state=on --no-close --no-open=##
Check SIM card subscriber state:
mbimcli -p -d /dev/cdc-wdm0 --query-subscriber-ready-status --no-close --no-open=##
If pin is needed, enter it using --enter-pin command:
mbimcli -p -d /dev/cdc-wdm0 --enter-pin=#### --no-close --no-open=##
Check cellular network registration state:
mbimcli -p -d /dev/cdc-wdm0 --query-registration-state --no-close --no-open=##
If not registered already, try using register automatic:
mbimcli -p -d /dev/cdc-wdm0 --register-automatic --no-close --no-open=##
Check the packet data service state:
mbimcli -p -d /dev/cdc-wdm0 --query-packet-service-state --no-close --no-open=##
If packet service state is not attached, use attach command:
mbimcli -p -d /dev/cdc-wdm0 --attach-packet-service --no-close --no-open=##
To to start a data connection use the connect command, with the desired parameters for PDP APN, IP type, auth details, etc.
mbimcli -p -d /dev/cdc-wdm0 --connect=apn='data.tre.se',ip-type='ipv4v6' --no-close --no-open=##
Bring down the MBIM network interface:
ip link set dev wwan0 down
Clear any existing IP address and routes:
ip -4 -6 address flush dev wwan0
ip -4 -6 route flush dev wwan0
The mbimcli connect command returns the IP, gateway, DNS, and MTU details for the data connection if established successfully.
Enter the IPv4 details to the network interface in the Linux host system, e.g.:
ip address add 2.70.103.209/30 dev wwan0
ip link set mtu 1500 dev wwan0
Enter the IPv6 details to the network interface in the Linux host system, e.g.:
ip -6 addr add 2a02:aa1:1021:b9d1:4fb:e1c9:589c:d53f/64 dev wwan0
ip -6 link set mtu 1500 dev wwan0
Enable the network interface:
ip link set dev wwan0 up
Apply appropriate network interface routing suitable for your use-case, e.g:
ip route add default dev
ip -6 route add default dev wwan0
You should now have a working cellular network data connection.
Test it e.g. by sending ping requests over the interface:
ping -I wwan0 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) from 2.70.103.209 wwan0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=224 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=42.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=30.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=38.4 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 30.657/84.031/224.373/81.140 ms
ping -6 -I wwan0 2600:: -c 4
PING 2600::(2600::) from 2a02:aa1:1021:b9d1:8847:afd4:e35a:aa29 wwan0: 56 data bytes
64 bytes from 2600::: icmp_seq=1 ttl=52 time=173 ms
64 bytes from 2600::: icmp_seq=2 ttl=52 time=153 ms
64 bytes from 2600::: icmp_seq=3 ttl=52 time=152 ms
64 bytes from 2600::: icmp_seq=4 ttl=52 time=208 ms
--- 2600:: ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 152.108/171.523/208.073/22.623 ms
To stop the cellular data network connection use mbimcli disconnect command.
Use the Session ID from the previous mbimcli command reply in --no-open=## attribute, but do not include the --no-close attribute, doing so closes the session afterwards.
mbimcli -p -d /dev/cdc-wdm0 --disconnect --no-open=##
Bring down the interface:
ip link set dev wwan0 down
Clear any remaining IP address and routes:
ip -4 -6 address flush dev wwan0
ip -4 -6 route flush dev wwan0
It is up to the host application to manage and poll the connection state of the cellular module.
E.g. if the connection is lost temporarily due to no network coverage in the current location, the host application should tear down and re-establish the data connection when cellular module is registered in network again.
If the data connection fails for some reason several times, ensure that the connect retry attempts do not take place continuously without some extended delays in-between.
Depending on the cellular network operator, they can enforce lock-out on your subscription/device for certain time periods in order to protect the network from being flooded by requests.
Question
Example on how to establish a data connection with Simcom SIM8202x-M2 series in Linux using QMI Rmnet over USB interface
Solution
Example on how to establish a data connection with Simcom SIM8202x-M2 series in Linux using QMI Rmnet over USB interface
5G technology introduces new requirements on the interface links between the host systems and cellular modules.
The Linux community continuously commit necessary changes to the kernel drivers and interface management tools to improve the compatibility and performance.
Because of this, it is important that you base your Linux system builds on up-to-date kernel versions, avoiding many problems already solved.
Ensure that you have up-to-date firmware version in the cellular module. Check the dedicated product page here at Techship and the firmware downloads tab or open a technical support ticket.
Early devices and engineering samples came with a older baseline firmware version and need to be update in Windows systems.
This guide specifically only describes how to establish the QMUX data connection part of the QMI rmnet USB interface for the SIM8202x-M2 series modules.
The qmi_wwan kernel driver module and libqmi library is used.
Ensure that you have the module in QMI Rmnet usb mode and qmi_wwan network kernel driver and option usb-serial driver properly loaded to the module interfaces.
Can be checked e.g. through dmesg, usb-devices or lsusb -t commands.
usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=1e0e ProdID=9001 Rev=04.14
S: Manufacturer=QCOM
S: Product=SDXPRAIRIE-MTP _SN:
S: SerialNumber=
C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=techship_serial
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=techship_serial
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=techship_serial
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=techship_serial
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=techship_serial
I: If#=0x5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
I: If#=0x6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
If the qmi_wwan and option drivers do not get correctly loaded in your current system build and kernel version, please refer to the manufacturer Linux integration guide.
Alternatively you can try compile our modified out-of-kernel driver module variants: techship_qmi_wwan and techship_serial and load them in your system.
See the git readme files for details on pre-requirements, how to clone, compile and use the make file options to install the drivers.
They are available in the following git repository: https://bitbucket.org/storjor/techship_linux_drivers/
Once you have drivers correctly loaded, start by disabling the related qmi_wwan network interface name:
ip link set dev wwan0 down
Ensure RAW IP configuration is enabled:
sh -c "echo 'Y' > /sys/class/net/wwan0/qmi/raw_ip"
(observe the path name including the network interface name, update to match the interface name used in your system)
Create a virtual mux interface for the qmi network interface:
sh -c "echo '1' > /sys/class/net/wwan0/qmi/add_mux"
(observe the path name including the network interface name, update to match the interface name used in your system)
Configure the data format on module side:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wda-set-data-format=link-layer-protocol=raw-ip,ul-protocol=qmap,dl-protocol=qmap,dl-max-datagrams=32,dl-datagram-max-size=31744,ep-type=hsusb,ep-iface-number=5
Here in-between you should perform necessary operations to the module prior to having the cellular network data connection established.
Things like SIM state and PIN code entry, module device registration in the cellular network, APN profile management etc.
Refer to the qmicli manual pages for details on the control commands that can be supported by the libqmi library and qmicli command line interface. Note however that not all qmi commands are supported by all cellular module vendors and might be dependant on chipset families, firmware versions and additional vendor specific command etc.
https://www.freedesktop.org/wiki/Software/libqmi/
Once module is ready and registered in cellular network we can proceed to configure and set up the data connection.
Bind the virtual mux network interface we created earlier to the client ID (CID) that gets opened, the CID id is given back in the reply:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-bind-mux-data-port=mux-id=1,ep-iface-number=5 --client-no-release-cid
It is important to use the --client-no-release-cid attribute here to keep the tunnel open at all time while the data connection is established.
If the client id CID linked to the network connection is closed, then the data connection on the qmux virtual network interface will also be closed.
Start the cellular network data connection in the normal way now, include the --client-no-release-cid attribute and use the already open CID ID you got back from previous command reply. E.g. like this:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-start-network=apn=data.tre.se,ip-type=4 --client-no-release-cid --client-cid=##
Store the packet data handle id from the command reply, to re-use when stopping the network data connection.
Request the cellular data connection IP details from the module and network with command:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-get-current-settings --client-no-release-cid --client-cid=##
Bring up the main QMI RMNET network interface:
ip link set dev wwan0 up
Apply the IP address to the qmux interface that you acquired through qmicli --wds-get-current-settings above, e.g.:
ip addr add 2.64.116.145 dev qmimux0
Apply the given MTU size to the qmux interface that you acquired through qmicli --wds-get-current-settings above, e.g.:
ip link set mtu 1500 dev qmimux0
Bring up the QMUX virtual network interface:
ip link set dev qmimux0 up
You should now have a working cellular network data connection.
Test it e.g. by sending a ping over the qmux interface:
ping -I qmimux0 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) from 2.68.152.91 qmimux0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=31.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=29.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=36.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=36.0 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 29.821/33.494/36.690/2.911 ms
Apply appropriate network interface routing suitable for your use-case, e.g:
ip route add default dev qmimux0
the qmicli --wds-get-current-settings give back DNS server addresses also if they are defined by the cellular network.
Depending on how your Linux distribution handle DNS servers you can add them or instead use a public DNS server.
To stop the cellular data network connection:
Bring down the virtual mux interface:
ip link set qmimux0 down
Flush the ip addresses:
ip -4 -6 address flush dev qmimux0
Use the --wds-stop-network attribute to stop the data connection in module, include the packet data handle and the client ID from when establishing the connection.
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-stop-network=########## --client-cid=##
Note: by not adding the --client-no-release-cid attribute this client ID will be closed after command execution.
It is up to the host application to manage and poll the connection state of the cellular module.
E.g. it the connection is lost temporarily due to no network coverage in the current location, the host application should tear down and re-establish the data connection when cellular module is registered in network again.
If the data connection fails for some reason several times, ensure that the connect retry attempts do not take place continuously without some extended delays in-between. Depending on the cellular network operator, they can enforce lock-out on your subscription/device for certain time periods in order to protect the network.
Question
How do we use an external SIM card on Telit module with onboard SIM card holder
Solution
Some Telit mPCIe modules have SIM card holders mounted onto the board itself. The data lines running to this SIM card holder are in parallell with those going out to the edge connector pins, which in turn connect to the data lines of an external SIM card holder.
However on some Telit modules the SIM Detection line is not routed out to the mPCIe pins, which means that the module cannot detect if or when a SIM card is inserted in the external SIM card holder. To get around this we use the AT commands:
AT+SIMDET=1
This command will simulate the "SIM Inserted" state and the module will then check if it is able to connect to the SIM card.
Related products
Telit HE910-G-SIM HSPA+, GPS, miniPCIe, SIM card holderTelit HE910-D-SIM HSPA+, miniPCIe, SIM card holder
Telit HE910-GL SIM UMTS, miniPCIe, SIM card holder
Telit LE910C4-EU LTE CAT-4 mPCIe SIM
Telit LE910C4-NF LTE CAT-4 mPCIe SIM
Telit LE910C1-EU LTE CAT-1 mPCIe SIM
Telit LE910C1-AP LTE CAT-1 mPCIe SIM
Telit LE910C4-AP LTE CAT-4 mPCIe SIM
Telit LE910C1-NF S.SKU LTE CAT-1 mPCIe SIM
Telit ME910C1-WW mPCIe SIM-Holder
Question
Example on how to establish a data connection with Telit FN980 series in Linux using QMI Rmnet and USB interface.
Solution
Example on how to establish a data connection with Telit FN980 series in Linux using QMI Rmnet and USB interface
5G technology introduces new requirements on the interface links between the host systems and cellular modules.
The Linux community continuously commit necessary changes to the kernel drivers and interface management tools to improve the compatibility and performance.
Because of this, it is important that you base your Linux system builds on up-to-date kernel versions, avoiding many problems already solved.
Ensure that you have up-to-date firmware version in the cellular module. Check the dedicated product page here at Techship and the firmware downloads tab.
Early devices and engineering samples came with a older Qualcomm baseline firmware versions and need to be update in Windows systems using the Telit TFI updater tool and cannot be updated with Telit XFP firmware update procedure.
This guide specifically only describes how to establish the QMUX data connection part of the QMI Rmnet USB interface for the Telit FN980 module.
The qmi_wwan kernel driver module and libqmi library is used.
Ensure that you have the module in QMI Rmnet usb mode and qmi_wwan network kernel driver and option usb-serial driver properly loaded to the module interfaces.
Can be checked e.g. through dmesg, usb-devices or lsusb -t commands.
usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=1bc7 ProdID=1050 Rev=04.14
S: Manufacturer=Telit Wireless Solutions
S: Product=FN980m
S: SerialNumber=
C: #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=techship_serial
I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
I: If#=0x5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
I: If#=0x6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=techship_serial
If the qmi_wwan and option drivers do not get correctly loaded in your current system build and kernel version, please refer to the manufacturer Linux integration guide.
Alternatively you can try compile our modified out-of-kernel driver module variants: techship_qmi_wwan and techship_serial and load them in your system.
See the git readme files for details on pre-requirements, how to clone, compile and use the make file options to install the drivers.
They are available in the following git repository: https://bitbucket.org/storjor/techship_linux_drivers/src/master/
Once you have drivers correctly loaded, start by disabling the related qmi_wwan network interface name:
ip link set dev wwan0 down
Ensure RAW IP configuration is enabled:
sh -c "echo 'Y' > /sys/class/net/wwan0/qmi/raw_ip"
(observe the path name including the network interface name, update to match the interface name used in your system)
Create a virtual mux interface for the qmi network interface:
sh -c "echo '1' > /sys/class/net/wwan0/qmi/add_mux"
(observe the path name including the network interface name, update to match the interface name used in your system)
Configure the data format on module side:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wda-set-data-format=link-layer-protocol=raw-ip,ul-protocol=qmap,dl-protocol=qmap,dl-max-datagrams=32,dl-datagram-max-size=31744,ep-type=hsusb,ep-iface-number=2
Here in-between you should perform necessary operations to the module prior to having the cellular network data connection established.
Things like SIM state and PIN code entry, module device registration in the cellular network, APN profile management etc.
Once module is ready and registered in cellular network we can proceed to configure and set up the data connection.
Bind the virtual mux network interface to the CID that gets opened, the CID id is given back in the reply:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-bind-mux-data-port=mux-id=1,ep-iface-number=2 --client-no-release-cid
It is important to use the --client-no-release-cid attribute here to keep the tunnel open all the time while data connection is established.
If the CID is closed, the data connection on the qmux virtual network interface will close also.
Start the cellular network data connection in the normal way, include the --client-no-release-cid attribute and use the already open CID ID you got back from previous command reply. E.g. like this:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-start-network=apn=data.tre.se,ip-type=4 --client-no-release-cid --client-cid=##
Store the packet data handle id from the command reply, to use when stopping network.
Request the cellular connections IP details from the module:
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-get-current-settings --client-no-release-cid --client-cid=##
Bring up the main QMI RMNET network interface:
ip link set dev wwan0 up
Apply the IP address to the qmux interface that you acquired through qmicli --wds-get-current-settings above, e.g.:
ip addr add 2.64.116.145 dev qmimux0
Apply the given MTU size to the qmux interface that you acquired through qmicli --wds-get-current-settings above, e.g.:
ip link set mtu 1500 dev qmimux0
Bring up the QMUX virtual network interface:
ip link set dev qmimux0 up
You should now have a working cellular network data connection.
Test it e.g. by sending a ping over the qmux interface:
ping -I qmimux0 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) from 2.68.152.91 qmimux0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=31.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=29.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=36.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=36.0 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 29.821/33.494/36.690/2.911 ms
Apply appropriate network interface routing suitable for your use-case, e.g:
ip route add default dev qmimux0
the qmicli --wds-get-current-settings give back DNS server addresses also if they are defined by the cellular network.
Depending on how your Linux distribution handle DNS servers you can add them or instead use a public DNS server.
To stop the cellular data network connection:
Bring down the virtual mux interface:
ip link set qmimux0 down
Flush the ip addresses:
ip -4 -6 address flush dev qmimux0
Use the --wds-stop-network attribute to stop the data connection in module, include the packet data handle and the client ID from when establishing the connection.
qmicli -p -d /dev/cdc-wdm0 --device-open-qmi --wds-stop-network=########## --client-cid=##
Note: by not adding the --client-no-release-cid attribute this client ID will be closed after command execution.
It is up to the host application to manage and poll the connection state of the cellular module.
E.g. it the connection is lost temporarily due to no network coverage in the current location, the host application should tear down and re-establish the data connection when cellular module is registered in network again.
If the data connection fails for some reason several times, ensure that the connect retry attempts do not take place continuously without some extended delays in-between. Depending on the cellular network operator, they can enforce lock-out on your subscription/device for certain time periods in order to protect the network.
Question
How-to use the Alcatel IK41 series LTE data sticks in RNDIS USB mode with always-on automated connection establishment and management
Solution
Both Windows and Linux systems can support RNDIS interface drivers for the Alcatel IK41 series LTE data sticks, this guide demonstrates how it can be done in a Linux environment.
There is a open source Linux in-kernel driver supporting RNDIS USB network interfaces called rndis_host.
Make sure to have the kernel config for rndis host driver support enabled.
Read more about the kernel configs in this FAQ:
Common Linux kernel modules and configs necessary for communicating with cellular modules over USB interface
By default the Alcatel IK41 series LTE data sticks are delivered with MBIM network interface USB mode enabled, so you will need to change the mode through a AT command on the Modem/AT serial port, exposed over the USB interface.
lsusb output can look like following:
Bus 001 Device 005: ID 1bbb:00b6 T & A Mobile Phones Mobilebroadband
usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1bbb ProdID=00b6 Rev=10.00
S: Manufacturer=Alcatel
S: Product=Mobilebroadband
S: SerialNumber=1234567890ABCDE
C: #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
Switch the module from USB PID 00b6 to USB PID 01aa mode for RNDIS interface throuh command:
AT+USBMODE=1
The module will now restart automatically and re-enumerate with a new USB ID.
Check dmesg or with lsusb that you have the Simcom SIM7600 module detected with VID: 1e0e PID: 9011
lsusb
Bus 001 Device 006: ID 1bbb:01aa T & A Mobile Phones Mobilebroadband
Verify with lsusb -t that the Linux in-kernel driver rndis_host driver is loaded correctly for interface 0 and 1.
It can look e.g. like this:
lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 480M
|__ Port 4: Dev 7, If 0, Class=Wireless, Driver=rndis_host, 480M
|__ Port 4: Dev 7, If 1, Class=CDC Data, Driver=rndis_host, 480M
|__ Port 4: Dev 7, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 7, If 3, Class=Vendor Specific Class, Driver=option, 480M
If your system do not load the option serial interfaces correctly, then they can be forcefully loaded as bellow: (not reboot persistent)
modprobe option
sh -c "echo '1bbb 01aa' > /sys/bus/usb-serial/drivers/option1/new_id"
Relate to the Alcatel IK41 Series Software Integration Guide for details on how to modify the usb serial option driver source code in order to auto load the option serial usb driver.
In order to enable the automatic network connection establishment, the SIM card should have PIN code check disabled. If it is not disabled, the Linux host system need to provide the PIN code over AT commands to module after each modem restart.
Refer to AT command: AT+CPIN=xxxx for further details.
The Access Point Name (APN) related to your cellular subscription needs to be configured once to the module so the automatic connection establishment can be established on the correct data bearer.
Defining an empty string as value on the AT+CGDCONT profile, will make the module try to subscribe for a APN, however this may not always work e.g. in roaming conditions, so best procedure is to always configure the correct APNs for the network and your subscription.
Check the currently configured APN profiles:
AT+CGDCONT?
If you do not know the correct APN for your network and subscription, you should at least have profile 1 defined to empty strings ("") so the module will try to subscribe for the correct APN details from network:
AT+CGDCONT=1,"IPV4V6",""
+CGDCONT Profile 1 is used for the cellular network registration process and will also be tied to the RNDIS network interface for the data connection to host system.
Define the APN profile according to the details you have obtained for your cellular subscription.
AT+CGDCONT=1,"IPV4V6","MY-SUBSCRIPTION-APN"
Some APN names require additional authentication also, please use the AT command: AT$QCPDPP in the AT commands guide for details on how to define auth details correctly.
Current auth configurations can be checked with AT command:
AT$QCPDPP?
AT$QCPDPP=apn_profile_index, auth_type, password, username
(Auth types: 0 None, 1 PAP, 2 CHAP)
Most often no auth details are needed for the profiles and they should be empty, profiles can be cleared by defining the profile number in question and zero in the second parameter:
AT$QCPDPP=1,0
If you have modified the APN information, username and passwords it is necessary to disconnect and reconnect to cellular network and packet data service to activate the new settings.
It can easily be done with toggling AT+CFUN=0 command followed by AT+CFUN=1 to switch modules operation mode (SIM card will also be re-initialized, so PIN code have to be given again if the PIN code check is activated).
The module will now try to establish and maintain the data connection automatically with the new settings.
Check that the RNDIS connection is toggled active through AT command:
AT+CONN?
Typically this reports 1 and is automatically active, but if not please set it by command:
AT+CONN=1
You should now have the cellular module correctly configured.
The Linux RNDIS host system drivers should have been detected now also and network interface available.
The interface name given can be checked e.g. from dmesg out:
dmesg | grep "RNDIS device"
rndis_host 1-4:1.0 usb0: register 'rndis_host' at usb-0000:00:15.0-4, RNDIS device, 16:c5:81:16:4a:b4
Typically it is named usb0 and might be disabled by default, activate the interface with command:
ip link set usb0 up
To acquire an NAT IP address from the module, please activate a dhcp client on the network interface (if not already running), example:
dhclient -v usb0
Listening on LPF/usb0/56:60:ac:31:fb:5f
Sending on LPF/usb0/56:60:ac:31:fb:5f
Sending on Socket/fallback
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 3 (xid=0x43893e46)
DHCPOFFER of 192.168.1.176 from 192.168.1.1
DHCPREQUEST for 192.168.1.176 on usb0 to 255.255.255.255 port 67 (xid=0x463e8943)
DHCPACK of 192.168.1.176 from 192.168.1.1 (xid=0x43893e46)
bound to 192.168.1.176 -- renewal in 3297 seconds.
If everything was configured correctly and the connection established successfully on the APN, the host system will have internet access on the RNDIS network interface now:
It can be tested e.g. by pinging a remote host over the RNDIS network interface:
ping -4 -I usb0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.225.46 usb0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=167 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=37.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=44.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=33.6 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 33.600/70.635/166.972/55.753 ms
If your APN supports IPV6 also, you can test it also by IPV6 ping:
ping -6 -I usb0 2600::
PING 2600::(2600::) from 2a02:aa1:1021:2c5e:552b:a8cb:532c:bcac usb0: 56 data bytes
64 bytes from 2600::: icmp_seq=1 ttl=51 time=179 ms
64 bytes from 2600::: icmp_seq=2 ttl=51 time=171 ms
64 bytes from 2600::: icmp_seq=3 ttl=51 time=171 ms
--- 2600:: ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 170.776/173.535/178.854/3.761 ms
Tested on:
Alcatel IK41 VE with firmware version IK41_01_02.00_01
Question
How-to guide for setting up a always on data connection over the Simcom SIM8202x-M2 series modules network interface when used in USB RNDIS mode
Solution
Both Windows and Linux systems can support RNDIS interface drivers for the SIM8202 series modules, this example demonstrates how it can be set up in a Linux environment.
There is a open source Linux in-kernel driver supporting RNDIS USB network interfaces called rndis_host.
Make sure to have the kernel config for rndis host driver support enabled.
Read more about the kernel configs in this FAQ:
Common Linux kernel modules and configs necessary for communicating with cellular modules over USB interface
By default the Simcom modules are delivered with QMI/RMNET network interface enabled, lsusb output can look like following:
Bus 002 Device 002: ID 1e0e:9001 Qualcomm / Option SDXPRAIRIE-MTP
So you will need to change the USB mode by sending a AT commands on the Modem/AT serial ports exposed over the USB interface, typically found as ttyUSB devices if option driver is loaded correctly.
E.g. minicom serial terminal tool can be used to open the USB serial interface and send AT commands to the module:
minicom -D /dev/ttyUSB2
Switch the module from USB PID 9001 to USB PID 9011 mode for RNDIS interface by sending below command followed by enter (CR LF):
AT+CUSBCFG=USBID,1E0E,9011
The module will now restart automatically and re-enumerate with a new USB ID.
Check dmesg or with lsusb that you have the Simcom SIM7600 module detected with VID: 1e0e PID: 9011
lsusb
Bus 002 Device 003: ID 1e0e:9011 Qualcomm / Option SDXPRAIRIE-MTP
Verify with lsusb -t that the Linux in-kernel driver rndis_host driver is loaded correctly for interface 0 and 1.
It can look e.g. like this:
lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 5000M
|__ Port 4: Dev 3, If 0, Class=Miscellaneous Device, Driver=rndis_host, 5000M
|__ Port 4: Dev 3, If 1, Class=CDC Data, Driver=rndis_host, 5000M
|__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 5000M
|__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 5000M
|__ Port 4: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 5000M
|__ Port 4: Dev 3, If 5, Class=Vendor Specific Class, Driver=option, 5000M
|__ Port 4: Dev 3, If 6, Class=Vendor Specific Class, Driver=option, 5000M
If your system don't load the option serial interfaces correctly, then they can be forcefully loaded as bellow (not reboot persistent):
modprobe option
echo 1e0e 9011 > /sys/bus/usb-serial/drivers/option1/new_id
Relate to the following Linux kernel commit for details on how to modify the usb serial option driver source code in order to auto load the drivers:
USB: serial: option: add support for Simcom SIM7500/SIM7600 RNDIS mode
In order to enable the automatic network connection establishment, the SIM card should have PIN code check disabled. If it isn't disabled, the Linux host system need to provide the PIN code over AT commands to module after each modem restart.
Refer to AT command: AT+CPIN=xxxx for further details.
The Access Point Name (APN) related to your cellular subscription needs to be configured once to the module so the automatic connection establishment can be established on the correct data bearer.
Defining an empty string as value on the AT+CGDCONT profile, will make the module try to subscribe for a APN, however this may not always work e.g. in roaming conditions, so best procedure is to always configure the correct APNs for the network and your subscription.
Check the currently configured APN profiles:
AT+CGDCONT?
If you do not know the correct APN for your network and subscription, you should at least have profile 1 and 6 defined to empty strings ("") so the module will try to subscribe for the correct APN details from network:
AT+CGDCONT=1,"IPV4V6",""
AT+CGDCONT=6,"IPV4V6",""
+CGDCONT Profile 1 is used for the cellular network registration process and APN at profile 6 will be tied to the RNDIS network interface for the data connection to host system.
Define both APN profiles according to the details you have obtained for your cellular subscription.
Most often the APN details are same for both network registration and the actual data connection, then you define same details to both profile 1 and 6:
AT+CGDCONT=1,"IPV4V6","MY-SUBSCRIPTION-APN"
AT+CGDCONT=6,"IPV4V6","MY-SUBSCRIPTION-APN"
Some APN names require additional authentication also, please refer to the AT command: AT+CGAUTH in the AT commands guide for details on how to define auth details correctly.
Current auth configurations can be checked with AT command:
AT+CGAUTH?
Typically no auth details are needed for the profiles and they should be empty, profiles can be cleared by defining the profile number in question and zero in the second parameter:
AT+CGAUTH=1,0
AT+CGAUTH=6,0
If you have modified the APN information, username and passwords it is necessary to disconnect and reconnect to cellular network and packet data service to activate the new settings.
It can easily be done with toggling AT+CFUN=0 command followed by AT+CFUN=1 to switch modules operation mode (SIM card will also be re-initialized, so PIN code have to be given again if the PIN code check is activated).
The module will now try to establish and maintain the data connection automatically with the new settings.
The cellular module is now configured. The Linux RNDIS host system drivers should also have been detected already and a network interface is available. The interface name given can be checked e.g. from dmesg out:
dmesg | grep "RNDIS device"
rndis_host 2-4:1.0 usb0: register 'rndis_host' at usb-0000:00:15.0-4, RNDIS device, b2:44:25:5d:21:86
Typically it is named usb0 and disabled by default, activate the interface with command:
ip link set usb0 up
To acquire an NAT IP address from the module, please activate a dhcp client on the network interface (if not already running), for example here using dhclient:
dhclient -v usb0
It will bind to a IP address if successful:
Listening on LPF/usb0/b2:44:25:5d:21:86
Sending on LPF/usb0/b2:44:25:5d:21:86
Sending on Socket/fallback
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 3 (xid=0x386d3770)
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 7 (xid=0x386d3770)
DHCPOFFER of 192.168.225.23 from 192.168.225.1
DHCPREQUEST for 192.168.225.23 on usb0 to 255.255.255.255 port 67 (xid=0x70376d38)
DHCPACK of 192.168.225.23 from 192.168.225.1 (xid=0x386d3770)
bound to 192.168.225.23 -- renewal in 20968 seconds.
If everything was configured correctly and the connection established successfully on the given APN, then the host system will have internet access on the RNDIS network interface now:
It can be tested e.g. by pinging a remote host over the RNDIS network interface:
ping -4 -I usb0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.225.46 usb0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=167 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=37.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=44.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=33.6 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 33.600/70.635/166.972/55.753 ms
ping -6 -I usb0 2600::
PING 2600::(2600::) from 2a02:aa1:1021:2c5e:552b:a8cb:532c:bcac usb0: 56 data bytes
64 bytes from 2600::: icmp_seq=1 ttl=51 time=179 ms
64 bytes from 2600::: icmp_seq=2 ttl=51 time=171 ms
64 bytes from 2600::: icmp_seq=3 ttl=51 time=171 ms
^C
--- 2600:: ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 170.776/173.535/178.854/3.761 ms
Tested on:
Simcom SIM8202G-M2 with firmware version LE13B02SIM8202M44A-M2
Question
Why does not our EM9190/EM9091/EM7690 appear in our system when connected to our host board?
Solution
The Sierra 5G (EM919x) modules and EM7690 has the PCIe host interface as default, as compared to the USB interface. This differs from most other modules on today's market and can be a reason as to why the module is not appearing in your system.
First, make sure that there are no pin-conflicts between the adapter/host board and the module. To avoid any incompatibilities we recommend the Sierra Wireless development Kit (11131)).
To change the host interface from PCIe to USB using the development kit please do the following;
Slide SW201 to the USB connector (CN204).
Change CN203 jumper from 2-3 to 1-2.
What happens when slide SW201 is switched is that pin #20 (PCIE_DIS) is set to high (1.8V) and selects USB as host interface. Changing the jumper on the CN203 sets pin #22 (VBUS_SENSE) to high (3.135 - 4.2 V) which is used to detect USB during USB connection.
This is further explained in the Sierra Development Kit User Guide and the EM919X-EM7690 Product Technical Specification. These documents are linked to this FAQ and can also be found on the product pages under the "technical documentation" tab.