First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

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

  • retag add tags

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++]    = radioType;
   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;

    /* Actual Payload */
    statBuffer[bufOffset++] = MAC_NR_PAYLOAD_TAG;


    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 .???

Akhila's avatar
3
Akhila
asked 2019-07-25 06:45:07 +0000
grahamb's avatar
23.8k
grahamb
updated 2019-07-25 08:16:15 +0000
edit flag offensive 0 remove flag close merge delete

Comments

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.

cmaynard's avatar cmaynard (2019-07-25 15:05:25 +0000) edit

Please find the capture here https://drive.google.com/open?id=1Dxi...

Akhila's avatar Akhila (2019-07-26 12:01:51 +0000) edit
add a comment see more comments

2 Answers

0

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.

Jaap's avatar
13.7k
Jaap
answered 2019-07-26 18:48:12 +0000
edit flag offensive 0 remove flag delete link

Comments

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.

Pascal Quantin's avatar Pascal Quantin (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.

Jaap's avatar Jaap (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).

Pascal Quantin's avatar Pascal Quantin (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.

Jaap's avatar Jaap (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..

MIB over mac-lte https://drive.google.com/open?id=1zc8...

Akhila's avatar Akhila (2019-07-29 05:20:46 +0000) edit
add a comment see more comments
0

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.

Pascal Quantin's avatar
5.8k
Pascal Quantin
answered 2019-08-17 17:16:54 +0000, updated 2019-08-17 17:17:19 +0000
edit flag offensive 0 remove flag delete link

Comments

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

Akhila's avatar Akhila (2019-08-21 04:58:01 +0000) edit

You are welcome. Please consider accepting my answer.

Pascal Quantin's avatar Pascal Quantin (2019-08-21 15:37:23 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer