Add new NR RRC OTA packet version 0x13, 0x17 + SCell version 0x30003 + MM State version 0x30000 to support S23 Ultra and S24 Ultra #96
Conversation
Also add new MCCH RRC Message type for version 0x17.
|
Thanks for your contribution. Judging from the previous experiences and the description, one or two bytes might be an extension, more than three might be a new field. I will take a look later on. If you don't mind, could you please also include some of raw payloads (please don't use any RRC/NAS message which contains your personal or location information, also you can edit some raw PDU bytes to mask them) on |
Also add tests for diagltelogparser for new version.
|
Thank you @peremen. I have included some test payloads for the new NR SCell and NR MM versions. Also, I realized LTE RRC messages were also giving these errors with the S24 Ultra:
So I printed out the LTE RRC packet version and body, and found out it's a new version 0x1e with new 3 byte padding (or maybe new field?).
I added the new version to the LTE RRC parser and also added a test payload to the unit test. After that, I can see the correct LTE RRC messages in the generated packet capture file. But like before, I don't know if this is a new padding, field, or what because I don't have the documentation for this header. Please review this new padding/field as well so we can fix the code correctly for both NR and LTE RRC packets. Thanks! |
|
Hi @peacey |
|
@alexjiao2021, see this gist to see how to do it with wireshark. |
|
@peremen, sorry one last commit, I noticed I was getting "Type: 36" messages on NR version 0x17 (S24U) with this body: I checked my S23U and S22U and saw this is the exact same payload I get for nr-RadioBearerConfig type on both devices. So I have adjusted the type ID to 36 for nr-RadioBearerConfig on version 0x17. I'm pretty sure this is correct, but please correct me if it's not. |
|
Thanks. Unfortunately I don't have devices for further testing, and have merged as-is. |
Hello,
This PR adds new qualcomm parser packet versions for RRC OTA, SCell, and MM state packets to support printing 5G info and RRC packets for newer Samsung phones like Samsung Galaxy S23 Ultra and Galaxy S24 Ultra.
From the debug messages shown below, you can see that the S23 Ultra uses NR RRC OTA packet version 0x13, and S24 Ultra uses version 0x17. From examining the hexdump of these messages, you can see that padding has been added between the message length field and the message payload (which is different than previous versions that didn't seem to have any padding after the length). For version 0x13 there is extra one byte padding, and for 0x17 there is extra four byte padding. I added this padding in struct.unpack and offset the message start index for these versions to account for this padding.
Here is the debug output of an RRC OTA message (UECapabilityEnquiry) from my S23 Ultra. You can see the message length is 0x0019 (25) and that there is a single byte padding after the length (padding is bolded below).
Here is the same message from my S24 Ultra. You can see the message length is 0x0019 (25) again but this time there is a four byte padding after the length field (padding is bolded below).
Also for version 0x17, a new MCCH message type was added as shown in the protocol here. So I added that as well, or else my messages for 0x17 had wrong types.
After the above changes, scat is outputting the correct Body and type for RRC OTA packets on my S23U and S24U as shown in this attached output log, and I am able to successfully parse the Body to a RRC packet using Wireshark dissector of the correct type (e.g.: UL_DCCH, etc) as shown in this picture.
Disclaimer: Even though the above padding seems to work, I could not find information for this header in the protocol documentation, so I have no idea whether this padding is just new padding or a new header field. I also do not have a background in telecommunications so I am not sure where to look for this information exactly. If you could please review and confirm whether this is correct (or suggest how to do this correctly if not correct), that would be great.
As for 5G SCell and 5G MM messages, I was getting this error in the logs for S24 Ultra only:
After adding these versions without any other modifications, I am able to see the correct info as shown below. So I think that's all that's needed for this. But again, I did not look to see if the updated protocol has added anything more to these packet versions that needs to be addressed, so please review.