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.

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 Trace Collector V2 Preview, scroll down to the “Converting a trace” window to check if you already have Wireshark installed, and find the Wireshark install link.

1.2 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 there trace file from the previous exercise.

Navigate to the trace file we took in Exercise 1 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 || nas-eps

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

ip

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

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

Forgot your password?
Enter your email address, and we will send a link to reset your password.