4G Hat

[Damo_C]

Hi,

I've got a Pi model 3 B, and I've purchased the following 4G hat, however I'm unsure how to actually establish an internet connection through it.. so hoping for a little assistance, or peoples suggestions.

2G/3G/4G GSM GPRS GNSS SIM GPS Extension Board for Raspberry Pi 2 3B B+ ZeroW GM

I can query the card using minicom -D /dev/ttyS0 and see that its got signal, query the carrier etc. However I'm unsure how to go about setting it up as either a modem or other network device to access the internet.

I've also tried using the USB port (not the one labelled UART), and I get a wwan0 adapter, however it only get a self-assigned IP. Upon connecting it to my Windows computer through the same USB port, I get several devices install, one of which is a network adapter but it shows that the cable is 'unplugged' - I haven't really tried anything further through Windows as this stage.

What I would like to achieve is have the Pi connected to the internet via the 4G hat, and be able to query the GPS part of the card to get the location - I'm not fussed if thats just by command line. I'd like to have it connected via the GPIO pins, but not fussed if it also needs to be connected via USB as well (the manual didn't seem to show how it should be connected unless I missed something?)

here is a link to the manual: Waveshare Wiki

[plugwash]

A quick search for "SIM7600 linux" found https://techship.com/faq/how-to-use-sim ... -over-usb/ which looks like it may be helpful.

[Damo_C]

Cheers - thanks for that.. I hadn't seen that one..

I have gotten it working, possibly a little easier than what those instructions said, probably not 100% ideal but it works.


I've got it connected via the GPIO pins + the USB connection..

On boot I've got a script running which initialises the card via the GPIO. The 4G modem then appears as a "mobile broadband" connection in Network manager.

I've started work on the GPS chip, which is enabled with minicom -D /dev/ttyS0 and then the command AT+CGPS =1 then running minicom -D /dev/ttyUSB1 you can see the GPS data scrolling through. I'm just looking at my options now to see how (if) I can go about getting the latitude + longitude from the GPS in terminal.

[Damo_C]

Update on my last post.. it wasn't 100% working. I had been able to see the mobile broadband device, it was reading the provider from the sim card, and was showing signal strength however it would fail immediately when I tried to connect.

I've gone through and followed the instructions from the link and another page which said how to pull the IP info, and manually assign it to the wwan0 interface, however it doesn't give me a connection to the internet. I've got two sim cards with different providers, and I've checked the APNs as well..

I did read an article that said it could be a driver issue, but the only driver for linux I've found has Chinese installation instructions.

[jmfalcon]

Hello Damo_C

I am at the moment starting my IoT project, using the same both devices as you: Raspberry Pi 3B+, plus the SIM7600 4G HAT (which I did not receive yet). Great that your project is also running almost simultaneously, in order to share support between us.

Up to this moment, I would like to ask you about the tool https://techship.com/faq/how-to-use-sim ... -over-usb/ you implemented.

Did you get it to implement it 100% ?
I do not understand which advantage this offers, over my original idea: just sending AT commands to the HAT device through UART (RPi GPIOs). Could you please roughly describe it to me?

Thanks in advance.

[Lsureal83]

Hello,

was there any progress with this. Were you able to use the sim7600 as a modem through USB connection on the pi and if so how did you achive this I am having simular issues with.

Thanks.

[MyLittlePony]

Hi
Am having similar issues with the SIM 7600.
Have worked through the Waveshare manual, the files seem to deploy ok
Concerning minicom, all it says is "Starting up" ....... then nothing
Any help with commands to interrogate the hat appreciated
Thanks

[vulcan25]

A word of advice for anyone in the UK thinking of buying this. I found a very similar one branded 'Waveshare' on Amazon that looks identical to the one in this ebay link, and has a 4 star review with a comment:

Unfortunately I did not properly check the specifications and information about the LTE types. This device uses LTE M which isn't the standard 4G/LTE network. It will fall back to 2G, but some networks - such as 3 in the UK won't support this and therefore this device is incompatible with them.

[dobova86]

I'm going to test Waveshare board and 4G (Vodafone network) ...
Be aware that SIM7600E has "-H" and "-T" chip. DON'T buy "-T" chip, it is for China.

Example chip for Europe:

71UlR5CbSxL._SL1438_.jpg (127.22 KiB) Viewed 228093 times

[Vincent14]

Did anyone have any success with this kit?

[aford88]

Any updates on this? Trying to get it working at the moment - SMS, phone calls and GPS are all working - I just can't get the 4g connection established.

[mkrzysztofowicz]

I've spent the whole evening today and couldn't get it to even see the network.

@aford88 - could you share with me what exactly did you do to get it to work with SMS and phone calls? I got the GPS part working OK.

Thanks!

[mkrzysztofowicz]

OK, I've got this working fully now!

For those of you who are still struggling, here's the required steps:

1. Install required software

Code: Select all

pi:~$ sudo apt-get update && sudo apt-get install libqmi-utils udhcpc

2. This one is important - when you reboot the pi, the SIM7600 module's cellular radio is OFF and needs to be turned ON before you can see the mobile network. One way is to use a script which pulls the GPIO pin 4 LOW for a second or two (as per this post: https://lb.raspberrypi.org/forums/viewt ... 1#p1368015), but a more elegant way I think is to use the newly installed qmi utils:

Code: Select all

pi:~$ sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

Note, you can verify if your radio needs to be turned on by using the following commands:

Code: Select all

qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength
qmicli -d /dev/cdc-wdm0 --nas-get-home-network

If the first command shows in its output 'Low Power' or anything other than 'online' it means your radio is off and needs to be turned on.
The last of those commands should return the LTE network ID if your device successfully connected.

3. Reconfigure the network interface for raw-ip protocol

The qmi-wwan kernel driver creates the wwan0 network interface for you when it detects the SIM7600 module connected to your Raspberry Pi. By default that interface is set to 802-3 protocol, however it seems the correct protocol should be raw-ip. The qmi-network script tries to set that up for you, but it will most likely fail. To make the change, do the following:

Code: Select all

pi:~$ sudo qmicli -d /dev/cdc-wdm0 -w		# this confirms the name of the network interface, typically wwan0
pi:~$ sudo ip link set wwan0 down		# change the wwan0 to the one returned above if different
pi:~$ echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
pi:~$ sudo ip link set wwan0 up

4. Connect to the mobile network.

After having done all the above, when trying to use qmicli to connect, I was getting the following error: error: "couldn't start network: QMI protocol error (64): '(null)'. .

There have apparently been some changes to qmi utils in Stretch and most of the documentation I saw over the last days is almost correct but missing one vital detail - you need to add ip-type=4 to other parameters for qmicli -d /dev/cdc-wdm0 --wds-start-network= as below.

Code: Select all

pi:~$ qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='YOUR_APN',username='YOUR_USERNAME',password='YOUR_PASSWORD',ip-type=4" --client-no-release-cid
[/dev/cdc-wdm0] Network started
	Packet data handle: '2264328160'
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '20'

5. Finally, configure the IP address and the default route with udhcpc:

Code: Select all

pi:~$ sudo udhcpc -i wwan0
udhcpc (v1.22.1) started
No resolv.conf for interface wwan0.udhcpc
Sending discover...
Sending select for 10.65.52.178...
Lease of 10.65.52.178 obtained, lease time 7200
cat: /run/resolvconf/lock/pid: No such file or directory
/sbin/resolvconf: 733: kill: Illegal number:
clearing stale lock pid
Too few arguments.
Too few arguments.

As you can see, this spits out a number of errors, but they relate to configuration of DNS servers in your resolv.conf file, but otherwise this works and I can now get the connection via the mobile network:

Code: Select all

pi:~ $ ip a s wwan0
3: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/none
    inet 10.65.52.178/30 scope global wwan0
       valid_lft forever preferred_lft forever

pi:~ $ ip r s
default via 10.65.52.177 dev wwan0
10.65.52.176/30 dev wwan0 proto kernel scope link src 10.65.52.178
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.5 metric 202

pi:~ $ ping -4 www.google.com
PING www.google.com (74.125.193.147) 56(84) bytes of data.
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=1 ttl=50 time=732 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=2 ttl=50 time=79.4 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=3 ttl=50 time=80.3 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=4 ttl=50 time=79.4 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 79.447/242.945/732.530/282.662 ms

You can take a look at this article: http://www.embeddedpi.com/documentation ... face-setup for a way to tidy things up a bit. It refers to a different 3G/4G modem (Sierra Wireless) but the way they set interfaces up and everything else still applies.

Good luck!

[aford88]

@mkrzysztofowicz - this is awesome, thanks!!

Works for me on the UK's EE network with the following details: apn: everywhere username: eesecure password: secure

[smokeyjoe123]

@mkrzysztofowicz Thanks for your detailed post. How does you connection work ? Do you still go through the serial port or do you connect a usb cable from the pi to the USb port on the HAT ? /dev/cdc-wdm0 does not exist but I assume its because I am not going through the serial port.

[mkrzysztofowicz]

@smokeyjoe123

My setup uses the serial port only for control (i.e. sending the AT commands). The actual data connection goes via the USB port on the HAT. Make sure you have the jumpers (A/B/C) set correctly - I think, from memory. they are both set to A on my HAT. Also, make sure you use the correct USB port - on my HAT I use the micro USB port on the opposite edge of the HAT than the 40-pin header (i.e. NOT the one labeled USB TO UART).

When I have all that connected as above, I see in dmesg that the USB connection is detected (in fact, 5 USB devices are now visible):

Code: Select all

[Tue Apr 16 12:22:00 2019] usbcore: registered new interface driver usbserial
[Tue Apr 16 12:22:00 2019] usbcore: registered new interface driver usbserial_generic
[Tue Apr 16 12:22:00 2019] usbserial: USB Serial support registered for generic
[Tue Apr 16 12:22:00 2019] usbcore: registered new interface driver cdc_wdm
[Tue Apr 16 12:22:00 2019] usbcore: registered new interface driver option
[Tue Apr 16 12:22:00 2019] usbserial: USB Serial support registered for GSM modem (1-port)
[Tue Apr 16 12:22:00 2019] option 1-1.2:1.0: GSM modem (1-port) converter detected
[Tue Apr 16 12:22:00 2019] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0
[Tue Apr 16 12:22:00 2019] option 1-1.2:1.1: GSM modem (1-port) converter detected
[Tue Apr 16 12:22:00 2019] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1
[Tue Apr 16 12:22:00 2019] option 1-1.2:1.2: GSM modem (1-port) converter detected
[Tue Apr 16 12:22:00 2019] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2
[Tue Apr 16 12:22:00 2019] option 1-1.2:1.3: GSM modem (1-port) converter detected
[Tue Apr 16 12:22:00 2019] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB3
[Tue Apr 16 12:22:00 2019] option 1-1.2:1.4: GSM modem (1-port) converter detected
[Tue Apr 16 12:22:00 2019] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB4
[Tue Apr 16 12:22:00 2019] qmi_wwan 1-1.2:1.5: cdc-wdm0: USB WDM device
[Tue Apr 16 12:22:00 2019] qmi_wwan 1-1.2:1.5 wwan0: register 'qmi_wwan' at usb-3f980000.usb-1.2, WWAN/QMI device, 06:2e:a8:00:b1:b8
[Tue Apr 16 12:22:00 2019] usbcore: registered new interface driver qmi_wwan

As you can tell, one of those is the qmi_wwan device, which creates the wwan0 interface, as below:

Code: Select all

pi:~ $ ifconfig wwan0
wwan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet X.X.X.X  netmask 255.255.255.248  destination X.X.X.X
        inet6 fe80::X:X:X:X:X:X  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 65467  bytes 28590388 (27.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 82425  bytes 12802817 (12.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[smokeyjoe123]

Thanks Mate I got it working.

[openevo]

@mkrzysztofowicz

Brilliant!! Got my setup working 100%.

[szabofrigocargo1]

Hy Guys,
For those who using waveshare Sim7600EH modul I have a couple of remarks:
I would like to ask you to confirm my remarks.

1. This Waveshare modul is faulty if you use data communication in 2G network because the power supply of it. If you send and receive data through 2G network please measure voltage on the leg of Vbat Simcom chip via oscilloscope. According to the SimCom recommendation the voltage drop is should not be more than 300mV, but on this modul you an experience bigger voltage drop then 300mV, that is why the chip is keep restarting sometimes. We tried every input what can be used for powering, but the fault remains the same.(Rapsberry Pi used with its own original power supply 2,5 A) On LTE network this fault does not come up.

2. Let’s open 2 Terminals using Rapsberry Pi with display what is connected by HDMI Cable, not LAN cable through SSH:
Terminal 1: (ALT+F1) We bring up the AT port of GSM device, and use the following commands:

Code: Select all

sudo screen /dev/ttyUSB2

Thereafter in this port we type in the below:

Code: Select all

AT+CGPSNMES=2
AT+CGPS=1

IMPORTANT we do not close this port.

Terminal 2:(ALT+F2) In separated window we bring up the GPS Port of GSM device:

Code: Select all

sudo screen /dev/ttyUSB1

In this port we can see the live NMEA datas.

Thereafter we go back to Terminal 1 and we use the next command:

Code: Select all

AT+CFUN=1,1

After using the AT+CFUN=1,1 command the Rapsberry Pi get frozen. It does not cause fully system freezing it looks like 3 of the cores stop. In the Syslog file the fault is not logged/visible.
If we close the Terminal2 before use the AT+CFUN=1,1 command we experience the same issue randomly BUT if Terminal's is not closed it get frozen every single time.

So far I was only able to take 2 screenshots of the faults. After reboot it did not appeared in Syslog.(2 picture attached).



In the future when we have the use the final, fully working device we will need to restart the GSM moduls sometimes. In our tests it proved that if we close all the ports in the Python software (close the PYserial connection), however the Raspberry Pi still get frozen.

The easiest way to reproduce the fault that if we open the 2 Terminals and use AT+CFUN=1,1 command. According to this we deduce that the fault is not related to the PYserial.

Very important remarks:
- If we reach the Rapsberry Pi through SSH and LAN network (e.g.: Putty) the Fault NEVER EXPERIENCED. We can open any port, use AT+CFUN=1,1 command the Pi does not freeze.

- If we type dwc_otg.speed=1 command to the /boot/cmdline.txt file the Fault NEVER EXPERIENCED.

Our opinion:
It could be some kind of kernel fault. Before the freeze the USB disconnect messages do not appear in Syslog file.


Thanks you for reading my message! Would you be able to help me please?

[DerMeister123]

Hi,

My HAT is connected same as yours. Commands via pins but connection via USB. I cant seem to get my Pi to get internet via the usb wwan0. It definitely has internet, tested this by plunging it into my pc. I am doing config via VNC, I have no screen. When my wifi and lan are disconnected VNC wont come back online (VNC connected via account not IP) so I assume the pi is not getting internet. See screenshot. Not sure what else to so. Whent through the whole setup twice. Any help would be much appreciated.

[DerMeister123]

OK, got it working by reloading Rasbian and used steps provided by mkrzysztofowicz only. Thanks

[kikusin]

Hi everyone!

New here and fighting with SIM7600 as well.
Thanks for all the info in the thread. It was very useful but I got stuck in the very very last step.

I get everything ok and start the network:

Code: Select all

pi@raspberrypi:~ $ sudo qmicli -p  -d /dev/cdc-wdm0 --device-open-"net=net-raw-ip|net-no-qos-header" --wds-start-network="apn='internet', ip-type=4" --client-no-release-cid
[/dev/cdc-wdm0] Network started
	Packet data handle: '2263292848'
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '20'

And connected to the serial I can get an IP:

Code: Select all

AT+CPSI?
+CPSI: LTE,Online,214-04,0xB799,120324198,31,EUTRAN-BAND3,1675,4,4,-90,-937,-656

OK
AT+CREG?
+CREG: 0,1

OK
AT+IPADDR                                                                       
+IPADDR: 10.224.160.74                                                          
                                                                                
OK   

But I am totally unable to get an IP by udhcpc:

Code: Select all

wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::8aa6:f469:d9f8:fc8e  prefixlen 64  scopeid 0x20<link>
        ether c6:8f:78:e3:5c:44  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 51  bytes 12170 (11.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@raspberrypi:~ $ sudo udhcpc -i wwan0
udhcpc (v1.22.1) started
No resolv.conf for interface wwan0.udhcpc
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...

I really do not know what else to try, but I am pretty sure it has to be a very stupid thing.

Any ideas?

Thanks a lot!

[fanfette]

Hi guys !

when I try to start network I get an error:
error: couldn't start network: QMI protocol error (14): 'CallFailed'

Code: Select all

sudo qmicli -p  -d /dev/cdc-wdm0 --device-open-"net=net-raw-ip|net-no-qos-header" --wds-start-network="apn='orange',username='orange',password='orange' --client-no-release-cid
error: couldn't start network: QMI protocol error (14): 'CallFailed'
call end reason (3): generic-no-service
verbose call end reason (3,2500): [cm] (null)
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '20'

I'm completely desperate ! I don't know 'How' and 'Where' I can find the solution.
Can someone help me ?

[kikusin]

Be sure you followed step 2) of main post:

2. This one is important - when you reboot the pi, the SIM7600 module's cellular radio is OFF and needs to be turned ON before you can see the mobile network. One way is to use a script which pulls the GPIO pin 4 LOW for a second or two (as per this post: viewt ... 1#p1368015),

If you do not success doing this, the hat may stay in low power status.

You can check this status by console with:

AT+CPSI?
AT+CREG?

[fanfette]

Thanks @kikusin for your reply

Cellular radio seems to be ON, I can see in my network manager :
wwan0: Associated with
wwan0: configured 169.###.##.88/16

for that I execute an sh script (like descibe in your post) on each reboot.

I'm not exactly sure about what I change in my configuration but now I get this message :

error: couldn't start network: QMI protocol error (26): 'NoEffect'

Code: Select all

sudo qmicli -p  -d /dev/cdc-wdm0 --device-open-"net=net-raw-ip|net-no-qos-header" --wds-start-network="apn=orange,username=orange,password=orange,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: '23'

with more details (--verbose)

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Opening device with flags 'net-raw-ip, net-no-qos-header, proxy'...
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<< length = 28
<<<<<< data = 01:1B:00:00:00:00:00:01:00:FF:10:00:01:0D:00:2F:64:65:76:2F:63:64:63:2D:77:64:6D:30

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< QMUX:
<<<<<< length = 27
<<<<<< flags = 0x00
<<<<<< service = "ctl"
<<<<<< client = 0
<<<<<< QMI:
<<<<<< flags = "none"
<<<<<< transaction = 1
<<<<<< tlv_length = 16
<<<<<< message = "Internal Proxy Open" (0xFF00)
<<<<<< TLV:
<<<<<< type = "Device Path" (0x01)
<<<<<< length = 13
<<<<<< value = 2F:64:65:76:2F:63:64:63:2D:77:64:6D:30
<<<<<< translated = /dev/cdc-wdm0

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>> length = 19
>>>>>> data = 01:12:00:00:00:00:01:01:00:FF:07:00:02:04:00:00:00:00:00

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message (translated)...
>>>>>> QMUX:
>>>>>> length = 18
>>>>>> flags = 0x00
>>>>>> service = "ctl"
>>>>>> client = 0
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 1
>>>>>> tlv_length = 7
>>>>>> message = "Internal Proxy Open" (0xFF00)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = SUCCESS

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Setting network port data format...
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<< length = 21
<<<<<< data = 01:14:00:00:00:00:00:02:26:00:09:00:10:02:00:02:00:01:01:00:00

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< QMUX:
<<<<<< length = 20
<<<<<< flags = 0x00
<<<<<< service = "ctl"
<<<<<< client = 0
<<<<<< QMI:
<<<<<< flags = "none"
<<<<<< transaction = 2
<<<<<< tlv_length = 9
<<<<<< message = "Set Data Format" (0x0026)
<<<<<< TLV:
<<<<<< type = "Protocol" (0x10)
<<<<<< length = 2
<<<<<< value = 02:00
<<<<<< translated = raw-ip
<<<<<< TLV:
<<<<<< type = "Format" (0x01)
<<<<<< length = 1
<<<<<< value = 00
<<<<<< translated = absent

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>> length = 28
>>>>>> data = 01:1B:00:80:00:00:01:02:26:00:10:00:02:04:00:00:00:00:00:12:01:00:00:10:02:00:02:00

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message (translated)...
>>>>>> QMUX:
>>>>>> length = 27
>>>>>> flags = 0x80
>>>>>> service = "ctl"
>>>>>> client = 0
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 2
>>>>>> tlv_length = 16
>>>>>> message = "Set Data Format" (0x0026)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = SUCCESS
>>>>>> TLV:
>>>>>> type = 0x12
>>>>>> length = 1
>>>>>> value = 00
>>>>>> TLV:
>>>>>> type = "Protocol" (0x10)
>>>>>> length = 2
>>>>>> value = 02:00
>>>>>> translated = raw-ip

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Network port data format operation finished
[27 juin 2019, 16:48:38] [Debug] QMI Device at '/dev/cdc-wdm0' ready
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Assuming service 'wds' is supported...
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Allocating new client ID...
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<< length = 16
<<<<<< data = 01:0F:00:00:00:00:00:03:22:00:04:00:01:01:00:01

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< QMUX:
<<<<<< length = 15
<<<<<< flags = 0x00
<<<<<< service = "ctl"
<<<<<< client = 0
<<<<<< QMI:
<<<<<< flags = "none"
<<<<<< transaction = 3
<<<<<< tlv_length = 4
<<<<<< message = "Allocate CID" (0x0022)
<<<<<< TLV:
<<<<<< type = "Service" (0x01)
<<<<<< length = 1
<<<<<< value = 01
<<<<<< translated = wds

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>> length = 24
>>>>>> data = 01:17:00:80:00:00:01:03:22:00:0C:00:02:04:00:00:00:00:00:01:02:00:01:18

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message (translated)...
>>>>>> QMUX:
>>>>>> length = 23
>>>>>> flags = 0x80
>>>>>> service = "ctl"
>>>>>> client = 0
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 3
>>>>>> tlv_length = 12
>>>>>> message = "Allocate CID" (0x0022)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = SUCCESS
>>>>>> TLV:
>>>>>> type = "Allocation Info" (0x01)
>>>>>> length = 2
>>>>>> value = 01:18
>>>>>> translated = [ service = 'wds' cid = '24' ]

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Registered 'wds' (version unknown) client with ID '24'
[27 juin 2019, 16:48:38] [Debug] Network start parameters set (apn: 'orange', 3gpp_profile: '0', 3gpp2_profile: '0', auth: 'unspecified', username: 'orange', password: 'orange', autoconnect: 'unspecified')
[27 juin 2019, 16:48:38] [Debug] Asynchronously starting network...
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<< length = 44
<<<<<< data = 01:2B:00:00:01:18:00:01:00:20:00:1F:00:19:01:00:04:18:06:00:6F:72:61:6E:67:65:17:06:00:6F:72:61:6E:67:65:14:06:00:6F:72:61:6E:67:65

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< QMUX:
<<<<<< length = 43
<<<<<< flags = 0x00
<<<<<< service = "wds"
<<<<<< client = 24
<<<<<< QMI:
<<<<<< flags = "none"
<<<<<< transaction = 1
<<<<<< tlv_length = 31
<<<<<< message = "Start Network" (0x0020)
<<<<<< TLV:
<<<<<< type = "IP Family Preference" (0x19)
<<<<<< length = 1
<<<<<< value = 04
<<<<<< translated = ipv4
<<<<<< TLV:
<<<<<< type = "Password" (0x18)
<<<<<< length = 6
<<<<<< value = 6F:72:61:6E:67:65
<<<<<< translated = orange
<<<<<< TLV:
<<<<<< type = "Username" (0x17)
<<<<<< length = 6
<<<<<< value = 6F:72:61:6E:67:65
<<<<<< translated = orange
<<<<<< TLV:
<<<<<< type = "APN" (0x14)
<<<<<< length = 6
<<<<<< value = 6F:72:61:6E:67:65
<<<<<< translated = orange

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>> length = 27
>>>>>> data = 01:1A:00:80:01:18:02:01:00:20:00:0E:00:02:04:00:01:00:1A:00:01:04:00:00:00:00:00

[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Received message (translated)...
>>>>>> QMUX:
>>>>>> length = 26
>>>>>> flags = 0x80
>>>>>> service = "wds"
>>>>>> client = 24
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 1
>>>>>> tlv_length = 14
>>>>>> message = "Start Network" (0x0020)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 01:00:1A:00
>>>>>> translated = FAILURE: NoEffect
>>>>>> TLV:
>>>>>> type = "Packet Data Handle" (0x01)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = 0

error: couldn't start network: QMI protocol error (26): 'NoEffect'
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '24'
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Releasing 'wds' client with flags 'none'...
[27 juin 2019, 16:48:38] [Debug] [/dev/cdc-wdm0] Unregistered 'wds' client with ID '24'
[27 juin 2019, 16:48:38] [Debug] Client released

I'm not sure it's a good news...
A big thanks to take time to help me !