fgsect/scat

any way to read device_sec and device_usec?

Closed this issue · 2 comments

I notice that modem timestamp does get parsed and included into the gsmtap header:

device_sec,

However when i use wireshark to capture the gsmtap packet, the dissector of wireshark seems to fail to extract that timestamp. such field is not shown in their header definition:
https://github.com/wireshark/wireshark/blob/6396860fb907625ccb0eab1620b8b395b585ef94/epan/dissectors/packet-gsmtap.h#L144.

As a consequence, there is no such field like "device_sec" or "device_usec" in my tshark output. Is there anyway to let wireshark extract those value, or to say manually parsing the udp.payload is the only way. If so, how can i dissect the hex payload into these two values?

an example of the tshark captured packet (in json format):

{
    "_index": "packets-2023-07-25",
    "_type": "doc",
    "_score": null,
    "_source": {
      "layers": {
        "frame": {
          <some frame info>
        },
        "eth": {
          <eth header>
        },
        "ip": {
          <ip header>
        },
        "udp": {
          <udp header>
          "udp.payload": "03:07:0d:00:00:00:00:00:00:00:01:51:01:00:05:00:00:00:00:00:64:bf:58:ad:00:08:e7:96:4a:10"
        },
        "gsmtap": {
          "gsmtap.version": "3",
          "gsmtap.hdr_len": "28",
          "gsmtap.type": "13",
          "gsmtap.ts": "0",
          "gsmtap.arfcn": "0",
          "gsmtap.uplink": "0",
          "gsmtap.pcs_band": "0",
          "gsmtap.signal_dbm": "0",
          "gsmtap.snr_db": "0",
          "gsmtap.frame_nr": "337",
          "gsmtap.antenna": "0",
          "gsmtap.sub_slot": "5"
          <no such field like 'device_sec' or 'device_usec'>
        },
        "lte_rrc": {
          "lte_rrc": "LTE Radio Resource Control (RRC) protocol",
          "lte-rrc.DL_DCCH_Message_element": {
            "per.choice_index": "0",
            "lte-rrc.dL_DCCH_Message.message": "0",
            "lte-rrc.dL_DCCH_Message.message_tree": {
              "per.choice_index": "9",
              "lte-rrc.c1": "9",
              "lte-rrc.c1_tree": {
                "lte-rrc.ueInformationRequest_r9_element": {
                  "lte-rrc.rrc_TransactionIdentifier": "1",
                  "per.choice_index": "0",
                  "lte-rrc.criticalExtensions": "0",
                  "lte-rrc.criticalExtensions_tree": {
                    "per.choice_index": "0",
                    "lte-rrc.c1": "0",
                    "lte-rrc.c1_tree": {
                      "lte-rrc.ueInformationRequest_r9_element": {
                        "per.optional_field_bit": "0",
                        "lte-rrc.rach_ReportReq_r9": "1",
                        "lte-rrc.rlf_ReportReq_r9": "0"
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }

partially solved, for the above example, just hex to decimal "00:00:00:00:64:bf:58:ad" as sec, and "00:08:e7:96" as usec

Yes, what you've seen is correct. That is not a GSMTAP official definition, and also will be included in the GSMTAPv3 specification. In addition, as soon as GSMTAPv3 is finalized, I will also document the changes for the compatibility's sake.