Cellular IoT Fundamentals

Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Click or drag files to this area to upload. You can upload up to 2 files.
RegisterLog in

Exercise 2

Decoding the modem trace

In this exercise, we will look at some of the things we can do with a modem trace, and some of the information we can learn from it.

The exercise uses a trace taken from the application in Lesson 7 Exercise 1 and can be found here: lesson7/cellfund_less7_exer2.pcapng, of whichever version directory you are using (v2.2.0-v2.3.0 or v2.4.0).

However, you should be able to follow the exercise with a trace you have taken yourself as well. Just be aware that packet numbers and the content of some of the packets will be different from what we show here.

Exercise Steps

1. Install Wireshark.

For this exercise, you will need Wireshark installed on your computer.

1.1 In Cellular Monitor, enable the “Open in Wireshark” option under Trace Options. This will prompt the app to check if you already have Wireshark installed, and if you don’t, it will provide the Wireshark install link.

1.2 Click on Install Wireshark and select the download link for your OS.

1.3 Follow the instructions on the screen to download Wireshark with all the default settings.

Make sure the box “Associate trace file extensions with Wireshark” is checked.

2. Open the trace file from the previous exercise in Wireshark.

2.1 In Cellular Monitor, disconnect from your device by selecting the little icon next to the device name in the upper left hand corner.

2.2 Under File Actions, click on Open trace file in Wireshark… and select the trace file we took in the previous exercise. It will be the one most recently modified and with the most recent time stamp in its name. Then select Open.

This will convert the trace into a PCAP file and open it in Wireshark.

In the main window, you will see a list of lines, which are all the packets captured in the modem trace.

If you click on one of the packets, you can see more details about the packet, the fields in the packet, and the payload in the window at the bottom of the screen.

Modem trace in Wireshark

Scrolling through the trace, we can observe that are roughly split into three categories: AT commands, LTE traffic, and IP traffic. All three packet types are useful, but if you are debugging a problem with the IP traffic for instance, the rest can be a distraction, as you can get a lot of LTE packets between the IP packets we are interested in.

3. Use the filter function to show only LTE traffic packets.

In the filter toolbar, located over the list of packets, type in

lte_rrc indicates the packets that are sent between the eNB and the modem, while nas-eps represents the packets sent between the modem and the core network (EPC), beyond the eNB. For example, the attach request sent by the UE to initiate the attach procedure is an example of such a message.

Notice that as you start typing, you will get suggestions on what categories you can filter by.

4. Identify the packets sent during the network attach procedure.

One of the interesting parts of the LTE traffic is when the device connects to the eNB. The trace starts with an Attach request from the UE of type NAS-EPS and ends with an Attach complete from the UE of type NAS-EPS.

In the trace shown here, the network attach is found in packets 53 to 78.

5. Investigate the packet containing the Attach request.

Click on the “Attach request”, in this case packet 53, to see more details about the packet in the packet window below. By expanding some of the fields, we see that the device requests PSM with a Periodic TAU of 8 hours, and an Active Time of 16 seconds, as well as eDRX with an eDRX Cycle of 163.84 seconds.

6. Investigate the packet containing the Attach accept.

If we now look at the “Attach accept”, in this case packet 78, which is sent from the core network to the UE, we can see the result of the network attach. One thing to notice here is that we don’t see the PSM and eDRX related fields we had in the Attach request. This means that we got neither PSM nor eDRX granted by the network. Other useful information we can find in the “Attach accept” packet is the APN the device is connected to, and the IP address it is allocated.

7. Use the filter function to show only the IP traffic.

In the filter toolbar, located over the list of packets, type in

8. Identify the DNS lookup, DTLS handshake and the encrypted application data

In this trace, the IP traffic can be split into 3 parts:

  • DNS lookup (packets 83-89)
  • DTLS handshake (packets 90-95)
  • Encrypted application data (packets 114-161).

We also have another way of finding the IP address of the device: We know that the DNS query and the Client Hello DTLS packet are sent from the device. So the source address in those packets will be the IP address of the device. If we compare this address (10.160.59.56) with the one we found in the Attach accept packet, we see that they match.

Looking at these three scenarios is very useful when debugging issues where the device is not able to connect to a server. And often, the most interesting packet is the Client Hello packet (90). This is the first packet sent from the device to the server, and includes a lot of details about what the device supports. In our case, we see that it is using PSK as the authentication and encryption method, and that it wants to connect to the server called callifornium.eclipseprojects.io.

10. Decode further by providing Wireshark with the pre-shared key (PSK).

The DTLS handshake ends with an “Encrypted Handshake Message” in packet 95, and after that, we only see encrypted application data. However, by providing the PSK used in the DTLS connection to Wireshark, we can decode the traffic.

More on this

It is only possible to decrypt the traffic in the trace when using PSK-based cipher suites. When using a cipher suite using asymmetric keys, a symmetric key is generated and shared using a Diffie-Hellman exchange. Because the modem does not output the symmetric key used, it is not possible to decrypt the traffic

10.1 Right-click on any of the DTLS packets, then select Protocol Preferences -> Datagram Transport Layer Security -> Pre-Shared Key.

10.2 You now have a new toolbar below the filter toolbar, where you can enter the PSK.

Copy the PSK from the Kconfig in the application, COAP_SERVER_PSK. Enter it in the Pre-Shared key bar that appeared in press OK.

11. Observe the unencrypted application data packets

Make sure to Log in or Register to save your progress

Back
Next
Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.