# wireshark not dissecting the entire context of mac-nr sent over udp

To get the mac-nr decoded buffer, the context part was filled and data was sent over udp port. Wanted to decode the sf-sfn in the context part , so sent the data as below over udp

UDP data -

6d 61 63 2d 6e 72 01 01 00 02 00 00 03 00 01 04
14 20 01 29 01 84


Decoded fields

1. 6d 61 63 2d 6e 72 - mac-nr
2. 01 01 00 - mandatory fields are decoded fine
3. 02 00 00 - rnti, since it is 0 i dont see in the capture
4. 03 00 01 - ueId - header , value is 2 bytes and gets decoded as 1
5. 04 14 20 -subframe header tag, sf/sfn info IS NOT GETTING DECODED at wireshark
6. 01 29 01 84 - payload also is decoded fine

UDP data is filled as below

 /* MAC Packet Info fileds */
statBuffer[bufOffset++]    = direction;
statBuffer[bufOffset++]    = rntiType;

/* RNTI */
statBuffer[bufOffset++] = MAC_NR_RNTI_TAG;
tmp16 = htons(rnti);
memcpy(statBuffer+bufOffset, &tmp16, 2);
bufOffset+= 2;

/* UEId */
statBuffer[bufOffset++] = MAC_NR_UEID_TAG;
tmp16 = htons(ueid);
memcpy(statBuffer+bufOffset, &tmp16, 2);
bufOffset+= 2;

U16 subFrameSfn = (sfn << 4)|subframe;

/* Subframe number */
statBuffer[bufOffset++] = MAC_NR_SUBFRAME_TAG;
tmp16 = htons(subFrameSfn);
memcpy(statBuffer+bufOffset, &tmp16, 2);
bufOffset+= 2;

SCpyMsgFix(mBuf, (MsgLen)0, (MsgLen)len,
(Data*) (statBuffer+bufOffset), (MsgLen*)&cLen);
bufOffset += len;


The wireshark version used here to decode is 3.00, i see only till ueid the context gets decoded and the payload as well The subframe header tag seems to be fine as per the findings. Could any one help as to why it is not getting decoded or anything missing from my end .???

edit retag close merge delete

Please provide a capture file of this data exchange and someone may be able to tell you what's going on. You'll have to post the file somewhere else unfortunately, so maybe try Google Drive, DropBox, etc.

( 2019-07-25 15:05:25 +0000 )edit

( 2019-07-26 12:01:51 +0000 )edit

Sort by » oldest newest most voted

Starting from Wireshark v3.1.1rc0-156-gb709c7ccc7d3 nightly build, the time information is now present in the MAC NR context as it is in MAC LTE context. Note that the use of MAC_NR_FRAME_SUBFRAME_TAG tag is now deprecated: having a subframe granularity is not sufficient for NR. It is instead replaced by MAC_NR_FRAME_SLOT_TAG tag so as to have the SFN/Slot number, whatever the sub-carrier spacing used.

more

Thanks for the update .. and thanks a lot for the fix :)

( 2019-08-21 04:58:01 +0000 )edit

( 2019-08-21 15:37:23 +0000 )edit

It seems that the dissector, in this case heuristic, sets up a context for the actual MAC-NR dissector. This dissector, in this case (NO_RNTI), has no use for sysFrameNumber and subFrameNumber. Therefore it is not shown.

Personally I don't like this design. Yes, the context for the MAC-NR dissector must be setup, but the interpretation of the header must be shown as actual values, not generated (between square brackets).

So, the proper way to handle this is to create a bug report and report all this (including the capture file!!, not a screenshot), so it can be properly fixed.

more

Those fields do not belong to the PDU, but from a context coming from loyer layers (or the framing protocol over UDP). I purposely displayed those with brackets and would prefer if it stayed like this. Same thing for the FN/SFN.

( 2019-07-26 20:30:41 +0000 )edit

They are however actual contents of the UDP payload, so in this particular case (not in others) they should be non-bracketed, and all should be dissected and reference the bytes in the UDP payload. Exactly for the reasons of this report.

( 2019-07-27 08:56:02 +0000 )edit

In most cases they are not part of the UDP payload, but come from the DCT2000 dissector. The framing is a convenience for very few users (like me) and changing its format now would break my own tools and create a discrepancy with LTE dissectors. Please do not change a behavior existing since years. The main usage of those dissectors (LTE and NR MAC/RLC/PDCP) is through DCT2000 (where those header bytes seen in the UDP framing are not present) and they are not natively designed for this UDP encapsulation (thus the display that is not as good as you would like).

( 2019-07-27 16:49:34 +0000 )edit

"In most cases they are not part of the UDP payload,", so indeed in most cases it should be show as is. But in this case (mac-nr over UDP) it should be dissected normally because it is part of the UDP payload, IMHO.

( 2019-07-28 00:57:40 +0000 )edit

Thanks for the info provided !!!..but am curious why is the behavior is kept different for mac-nr from mac-lte because i dont see the issue there... the mac-lte over UDP context gets dissected as is..

( 2019-07-29 05:20:46 +0000 )edit