CrabeDeFrance / rtshark

Rust interface to tshark application
Other
33 stars 10 forks source link

NAS messages not decoded #14

Closed MakisChristou closed 11 months ago

MakisChristou commented 11 months ago

Hello, first of all thanks for this crate. I am using it to decode some LTE captures and in some cases I encounter an RRC message, specifically an lte-rrc.rrcConnectionSetupComplete_element that has NAS data encapsulated like so:

{"lte-rrc.dedicatedInfoNAS": "17:9e:5a:41:61:60:07:45:63:0b:f6:02:f8:01:80:e8:b8:fc:dc:96:25", "per.octet_string_length": "21", "lte-rrc.criticalExtensions": "0", "lte-rrc.selectedPLMN_Identity": "1", "lte-rrc.rrcConnectionSetupComplete_element": "", "lte-rrc.c1": "0", "per.choice_index": "0", "lte-rrc.rrc_TransactionIdentifier": "2", "lte-rrc.uL_DCCH_Message.message": "0", "lte-rrc.rrcConnectionSetupComplete_r8_element": "", "lte-rrc.UL_DCCH_Message_element": "", "per.optional_field_bit": "0"}

Is there a way to set rtshark to decode the lte-rrc.dedicatedInfoNAS as well? Is this a tshark limitation? Or in general can you point me to the right direction ?

MakisChristou commented 11 months ago

So it looks like tshark itself does decode the encapsulated NAS messages when supplying it the same pcap file. So I guess the issue is rtshark related? So it looks like the issue is in the parse_xml function but not sure where exactly. It seems like it omits the tshark output that includes the relevant info.

CrabeDeFrance commented 11 months ago

Hello and thanks for reporting this issue.

Most of the time, we miss information because the PDML output of tshark is not documented. The PDML parser of rtshark was developped after analyzing PDML reports of different packet captures.

In your case, I found on internet a LTE pcap file, and after tshark decoding it looks like :

<packet>
...
  <proto name="lte_rrc" showname="LTE Radio Resource Control (RRC) protocol" size="24" pos="44">
    <proto name="lte_rrc" showname="LTE Radio Resource Control (RRC) protocol" hide="yes" size="24" pos="44"/>
    <field name="lte-rrc.UL_DCCH_Message_element" showname="UL-DCCH-Message" size="23" pos="44" show="" value="">
      <field name="per.choice_index" showname="Choice Index: 0" hide="yes" size="1" pos="44" show="0" value="24"/>
      <field name="lte-rrc.uL_DCCH_Message.message" showname="message: c1 (0)" size="23" pos="44" show="0" value="24002a2f3cb482c2c00e8ac617ec05f00301d171f9b92c">
        <field name="per.choice_index" showname="Choice Index: 4" hide="yes" size="1" pos="44" show="4" value="24"/>
        <field name="lte-rrc.c1" showname="c1: rrcConnectionSetupComplete (4)" size="23" pos="44" show="4" value="24002a2f3cb482c2c00e8ac617ec05f00301d171f9b92c">
          <field name="lte-rrc.rrcConnectionSetupComplete_element" showname="rrcConnectionSetupComplete" size="23" pos="44" show="" value="">
            <field name="lte-rrc.rrc_TransactionIdentifier" showname="rrc-TransactionIdentifier: 2" size="1" pos="44" show="2" value="24"/>
            <field name="per.choice_index" showname="Choice Index: 0" hide="yes" size="1" pos="44" show="0" value="24"/>
            <field name="lte-rrc.criticalExtensions" showname="criticalExtensions: c1 (0)" size="23" pos="44" show="0" value="24002a2f3cb482c2c00e8ac617ec05f00301d171f9b92c">
              <field name="per.choice_index" showname="Choice Index: 0" hide="yes" size="1" pos="45" show="0" value="00"/>
              <field name="lte-rrc.c1" showname="c1: rrcConnectionSetupComplete-r8 (0)" size="22" pos="45" show="0" value="002a2f3cb482c2c00e8ac617ec05f00301d171f9b92c">
                <field name="lte-rrc.rrcConnectionSetupComplete_r8_element" showname="rrcConnectionSetupComplete-r8" size="22" pos="45" show="" value="">
                  <field name="per.optional_field_bit" showname="..0. .... Optional Field Bit: False (registeredMME is NOT present)" hide="yes" size="1" pos="45" show="0" value="0" unmaskedvalue="00"/>
                  <field name="per.optional_field_bit" showname="...0 .... Optional Field Bit: False (nonCriticalExtension is NOT present)" hide="yes" size="1" pos="45" show="0" value="0" unmaskedvalue="00"/>
                  <field name="lte-rrc.selectedPLMN_Identity" showname="selectedPLMN-Identity: 1" size="1" pos="45" show="1" value="00"/>
                  <field name="per.octet_string_length" showname="Octet String Length: 21" hide="yes" size="1" pos="45" show="21" value="00"/>
                  <field name="lte-rrc.dedicatedInfoNAS" showname="dedicatedInfoNAS: 179e5a4161600745630bf602f80180e8b8fcdc9625" size="21" pos="45" show="17:9e:5a:41:61:60:07:45:63:0b:f6:02:f8:01:80:e8:b8:fc:dc:96:25" value="179e5a4161600745630bf602f80180e8b8fcdc9625">

Do you confirm you want to decode this "lte-rrc.dedicatedInfoNAS" ?

If not, could you attach an example of a PDML file containing your use case ? You can create it using the following command : tshark -r mypcap.pcap -T pdml

Best regards

MakisChristou commented 11 months ago

Hello, after a bit more debugging I figured out that the issue was not decoding but rather rtshark (or tshark?) was splitting layers in an unexpected manner. For example the nas messages were included in a different layer than the lte-rrc layer even though they were encapsulated and there were in some cases multiple lte-rrc layers in one packet. I wrote my code around it to combine the layers with the same name so its not an issue for me atm.