Ask Your Question

brett323's profile - activity

2020-12-23 22:46:04 +0000 commented question Nokia Siemens Network ASN.1 Specifications for MSS CDRs

Hi! If you're referring to Nokia DX-type MSS, we don't use ASN.1 for our CDRs - they're an internal binary format that

2020-12-23 22:45:50 +0000 commented question Nokia Siemens Network ASN.1 Specifications for MSS CDRs

Hi! If you're referring to Nokia DX-type MSS, we don't use ASN.1 for our CDRs - they're an internal binary format that

2020-12-23 22:37:39 +0000 marked best answer Capitalising hex strings in dissector field output?

Hello,

Is there a way to capitalise hex output in the field output like we can with the string formatter "0x%04X"?

I'm using that to add the details to the INFO column but not sure how to get similar formatting in the dissected fields:

PACKED_SIM_GROUP_M3UA_S (0xCFDC) from IPDU-3 to GISU-7 via EMB-0

For example, I have the field is being output like below:

DMX message number: PACKED_SIM_GROUP_M3UA_S (0xcfdc)

But I'd prefer to have the hex number printed as 0xCFDC (just makes it simpler for us to see the message number).

I am poking around the source for proto_tree_add_item to pin down where the actual hex digit printing occurs ... haven't figured it out yet.

In my dissector I'm doing this:

            static const value_string dmxMessageNumber[] = {
            ...
                { 0xCFDC, "PACKED_SIM_GROUP_M3UA_S" },
            ...
            };

             proto_tree_add_item(dmx_tree, hf_emb_msg_header_t_number, tvb, 
                                 offset, 2, ENC_LITTLE_ENDIAN);
        ...

            { &hf_emb_msg_header_t_number,
               {"DMX message number", "emb.dmx.number",
                   FT_UINT16, BASE_HEX, VALS(dmxMessageNumber), 
                   0x0, "DX message number (message_number_t)", HFILL}},

Thanks, Brett.

2020-12-23 22:29:13 +0000 answered a question Nokia Siemens Network ASN.1 Specifications for MSS CDRs

Hi! If you're referring to Nokia DX-type MSS, we don't use ASN.1 for our CDRs - they're an internal binary format that

2020-12-23 22:21:10 +0000 commented answer Windows10 compile of WS 3.4.2 fails due to Perl modules

Thanks for the info Graham, especially about forcing cmake to re-check. Yeah, I wasn't aware of that cygwin/perl issue.

2020-12-23 02:50:42 +0000 received badge  Rapid Responder (source)
2020-12-23 02:50:42 +0000 answered a question Windows10 compile of WS 3.4.2 fails due to Perl modules

Ahh, okay did more research (didn't have any luck earlier). Reinstalled Strawberry Perl and that didn't help. I've got

2020-12-23 00:16:13 +0000 asked a question Windows10 compile of WS 3.4.2 fails due to Perl modules

Windows10 compile of WS 3.4.2 fails due to Perl modules Hi, I'm having a bit of difficulty compiling 3.4.2 - I've compi

2020-07-13 19:40:26 +0000 marked best answer Inconsistent g_snprintf behaviour (Wireshark 3.2.5)

Hello,

I'm continuing working on my dissector and am stumped on this behaviour.

We have a timestamp field in a message that I've written a custom callback function for.

This is the structure of the timestamp, starting at octet 43 within this particular internal message (little endian):

  43  .cal_time                calendar_time_t    STRUCT              8
  43  ..hundredths_of_seconds  bcd_t              byte                 1
  44  ..seconds                bcd_t              byte                 1
  45  ..minutes                bcd_t              byte                 1
  46  ..hours                  bcd_t              byte                 1
  47  ..day                    bcd_t              byte                 1
  48  ..month                  bcd_t              byte                 1
  49  ..year                   long_bcd_t         word                 2

And this is the CF I wrote to output the timestamp correctly:

static void
print_cal_time(gchar *result, guint64 cal_time)
{
    guint16 cal_time_year = (cal_time >> 48);
    gint8 cal_time_month = (cal_time >> 40) & 0xFF;
    gint8 cal_time_day = (cal_time >> 32) & 0xFF;
    gint8 cal_time_hour = (cal_time >> 24) & 0xFF;
    gint8 cal_time_min = (cal_time >> 16) & 0xFF;
    gint8 cal_time_sec = (cal_time >> 8) & 0xFF;
    gint8 cal_time_100ths = cal_time & 0xFF;

    g_snprintf(result, ITEM_LABEL_LENGTH, "%4X-%02X-%02X %02X:%02X:%02X.%02X",
               cal_time_year,
               cal_time_month,
               cal_time_day,
               cal_time_hour,
               cal_time_min,
               cal_time_sec,
               cal_time_100ths);
}

The other relevant bits in my dissector:

proto_tree_add_item(dmx_tree, hf_emb_dx_FCC8_cal_time, payload_tvb, 43, 8, ENC_LITTLE_ENDIAN);

... and ...

{ &hf_emb_dx_FCC8_cal_time,
    {"FCC8 calendar time", "emb.dmx.fcc8.cal_time",
        FT_UINT64, BASE_CUSTOM, CF_FUNC(print_cal_time), 0x0,
        "Calender time of log", HFILL}},

This works most of the time, but sometimes it is giving a weird output for the 1/100s field.

Working okay:

FCC8 calendar time: 2020-06-18 11:47:58.64

0000   64 58 47 11 18 06 20 20

Not working:

FCC8 calendar time: 2020-06-18 11:47:59.FFFFFF96

0000   96 59 47 11 18 06 20 20

The 1/100s field is being output as a dword even though the variable is a single byte and the format string specifies %02X:

gint8 cal_time_100ths = cal_time & 0xFF;

What am I missing? I see the same behaviour in 64-bit 3.2.5 compiled on both Win10 and macOS.

2020-07-13 19:40:21 +0000 commented answer Inconsistent g_snprintf behaviour (Wireshark 3.2.5)

Dah! Of course! Much obliged Graham, thanks. I shouldn't be using gint8 at all, so have replaced them all (not just i

2020-07-13 11:39:14 +0000 edited question Inconsistent g_snprintf behaviour (Wireshark 3.2.5)

Inconsistent g_snprintf behaviour (Wireshark 3.2.5) Hello, I'm continuing working on my dissector and am stumped on thi

2020-07-13 11:33:06 +0000 asked a question Inconsistent g_snprintf behaviour (Wireshark 3.2.5)

Inconsistent g_snprintf behaviour (Wireshark 3.2.5) Hello, I'm continuing working on my dissector and am stumped on thi

2020-06-25 07:56:04 +0000 commented answer Capitalising hex strings in dissector field output?

I'd be happy with that. For me, I just find it instantly clearer to read 0xABCD rather than 0xabcd.

2020-06-25 06:05:07 +0000 commented answer Capitalising hex strings in dissector field output?

I had originally tried calling the val_to_str within the g_snprintf function but this caused Wireshark to crash when it

2020-06-25 06:03:30 +0000 commented answer Capitalising hex strings in dissector field output?

I had originally tried calling the val_to_str within the g_snprintf function but this caused Wireshark to crash when it

2020-06-25 05:55:20 +0000 commented answer Capitalising hex strings in dissector field output?

It also meant I could customise the output of the internal program block IDs we use - they're stored as a word value but

2020-06-25 05:54:31 +0000 received badge  Editor (source)
2020-06-25 05:54:31 +0000 edited answer Capitalising hex strings in dissector field output?

Thanks for the advice Chuck - using BASE_CUSTOM was exactly what I needed! A little convoluted but I found a good examp

2020-06-25 05:41:36 +0000 commented answer Capitalising hex strings in dissector field output?

It also meant I could customise the output of the internal program block IDs we use - they're stored as a word value but

2020-06-25 04:19:06 +0000 received badge  Rapid Responder (source)
2020-06-25 04:19:06 +0000 answered a question Capitalising hex strings in dissector field output?

Thanks for the advice Chuck - using BASE_CUSTOM was exactly what I needed! A little convoluted but I found a good examp

2020-06-24 21:16:08 +0000 commented question Capitalising hex strings in dissector field output?

Ha ha, indeed! It's also a good way to figure out how things work. I did consider BASE_CUSTOM when I came upon it in t

2020-06-24 21:15:47 +0000 commented question Capitalising hex strings in dissector field output?

Ha ha, indeed! It's also a good way to figure out how things work. I did consider BASE_CUSTOM when I came upon it in t

2020-06-24 08:19:41 +0000 commented answer Using SLL dissector output in own dissector?

I was thinking all day that "ditting" the modified file was something that had to be done on Windows so the build step w

2020-06-24 08:11:16 +0000 received badge  Commentator
2020-06-24 08:11:16 +0000 commented answer Using SLL dissector output in own dissector?

LOL, okay, no worries! Maybe I didn't do it right the first time - for my initial implementation, I'd been testing on m

2020-06-24 06:56:32 +0000 commented question Capitalising hex strings in dissector field output?

Nope and nope. I've modified in EPAN/PROTO.C and also a similar one I found in EPAN/PRINT.C and neither had any effect:

2020-06-24 06:42:42 +0000 commented question Capitalising hex strings in dissector field output?

Ah huh, in PROTO.C I think I've found where the actual formatting is done? So I could get it to print all hex strings c

2020-06-24 06:42:26 +0000 commented question Capitalising hex strings in dissector field output?

Ah huh, in PROTO.C I think I've found where the actual printing is done? So I could get it to print all hex strings cap

2020-06-24 06:26:36 +0000 commented question Capitalising hex strings in dissector field output?

I guess one workaround would be to simply use the column editing mode to copy the hex number in my dmxMessageNumber arra

2020-06-24 06:18:53 +0000 asked a question Capitalising hex strings in dissector field output?

Capitalising hex strings in dissector field output? Hello, Is there a way to capitalise hex output in the field output

2020-06-24 00:03:38 +0000 commented answer Using SLL dissector output in own dissector?

Okay, don't know if this is right but it seems to work well enough for me. I modified this line in CMakeLists.txt by

2020-06-23 23:27:08 +0000 commented answer Using SLL dissector output in own dissector?

Sorry Graham, you're going to have to explain how to "dit" my updated source file - I have searched but can't find any i

2020-06-20 00:21:19 +0000 commented answer Using SLL dissector output in own dissector?

Hi there Graham! Yep, followed them exactly and I got it compiled last night. I actually run my work Win10 machine as

2020-06-18 23:48:28 +0000 marked best answer Using SLL dissector output in own dissector?

Hello,

I've cobbled together my very first dissector today to decode an internal company protocol, identified by EtherType = 0x88aa.

We capture traffic in a Linux-derived computer unit using tcpdump and so the Wireshark trace includes "Linux cooked capture" of the first few octets.

I've worked around this and managed to get my dissector working on the "unicast to us (0)" packets just as I need:

0000   00 00 00 01 00 06 02 00 00 80 3b 30 00 00 88 aa
0010   01 3b 00 10 09 00 00 00 00 10 09 7b 00 00 05 00
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030   00 00 22 00 00 30 00 00 00 00 00 00 00 00 a0 90
0040   3b 00 02 00 00 01 3b 00 02 00 00 80 3b 20 02 00
0050   00 80 3b 30

Frame 9078: 84 bytes on wire (672 bits), 84 bytes captured (672 bits)
Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 1
    Link-layer address length: 6
    Source: 02:00:00:80:3b:30 (02:00:00:80:3b:30)
    Unused: 0000
    Protocol: Unknown (0x88aa)
Nokia EMB Protocol
    EMB header version: 0x01
    DMX message length: 34
    DMX computer: 0x00003000
    DMX family: OMU-0 (0x00000000)
    DMX message number: EPO_SYNC_MSG_S (0x000090a0)
    DMX phys_computer: GISU-1 (0x0000003b)

However I'd like to also decode the "sent by us (4)" packets too:

0000   00 04 00 01 00 06 02 00 00 80 73 30 00 00 88 aa
0010   02 00 00 80 00 30 02 00 00 80 73 30 88 aa 01 73
0020   00 d2 81 80 3b 20 02 63 86 68 00 00 05 00 00 00
0030   00 30 73 30 6b 06 00 00 00 80 00 00 e8 8d 73 00
0040   22 00 00 30 00 00 00 00 00 00 00 00 a0 90 73 00
0050   02 00 00 01 73 00 02 00 00 80 73 20 02 00 00 80
0060   73 30

Frame 9081: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Linux cooked capture
    Packet type: Sent by us (4)
    Link-layer address type: 1
    Link-layer address length: 6
    Source: 02:00:00:80:73:30 (02:00:00:80:73:30)
    Unused: 0000
    Protocol: Unknown (0x88aa)
Nokia EMB Protocol
    EMB header version: 0x02

My dissector really needs to start at octet 2 as this is the payload I want to decode.

So is there any way, in my dissector, I can check the sll.pkttype value that the SLL dissector generates? If it's LINUX_SLL_OUTGOING (0x0004) then my dissector can handle the rest of the message, but my dissector can only see from octet 16, after the SLL dissector has had its fill.

Will continue researching.

2020-06-18 23:48:28 +0000 received badge  Scholar (source)
2020-06-18 23:47:43 +0000 commented answer Using SLL dissector output in own dissector?

Ahhh, perfect, thanks Jaap! That works perfectly - and now I'm understanding more about how they work. Thanks to the

2020-06-18 09:25:39 +0000 commented question Using SLL dissector output in own dissector?

"I guess what I want to do, a bit of a kludge but as long as it works for solving faults, is decode from octet 2 onwards

2020-06-18 09:24:27 +0000 commented question Using SLL dissector output in own dissector?

"I guess what I want to do, a bit of a kludge but as long as it works for solving faults, is decode from octet 2 onwards

2020-06-18 09:08:21 +0000 commented question Using SLL dissector output in own dissector?

Thanks for your reply Guy. I'd like to decode our message from octet 2 of the hex output I included - when I view the f

2020-06-18 09:07:58 +0000 commented question Using SLL dissector output in own dissector?

Thanks for your reply Guy. I'd like to decode our message from octet 2 of the hex output I included - when I view the f

2020-06-18 07:32:36 +0000 asked a question Using SLL dissector output in own dissector?

Using SLL dissector output in own dissector? Hello, I've cobbled together my very first dissector today to decode an in