Ask Your Question
0

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

asked 2019-07-25 06:45:07 +0000

Akhila gravatar image

updated 2019-07-25 08:16:15 +0000

grahamb gravatar image

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

edit retag flag offensive 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 gravatar imagecmaynard ( 2019-07-25 15:05:25 +0000 )edit

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

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

2 Answers

Sort by ยป oldest newest most voted
0

answered 2019-08-17 17:16:54 +0000

Pascal Quantin gravatar image

updated 2019-08-17 17:17:19 +0000

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.

edit flag offensive delete link more

Comments

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

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

You are welcome. Please consider accepting my answer.

Pascal Quantin gravatar imagePascal Quantin ( 2019-08-21 15:37:23 +0000 )edit
0

answered 2019-07-26 18:48:12 +0000

Jaap gravatar image

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.

edit flag offensive delete link more

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 gravatar imagePascal 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 gravatar imageJaap ( 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 gravatar imagePascal 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 gravatar imageJaap ( 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 gravatar imageAkhila ( 2019-07-29 05:20:46 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2019-07-25 06:45:07 +0000

Seen: 1,950 times

Last updated: Aug 17 '19