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:
Line 288 in 24863ae
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.