brett323's profile - activity

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

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

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.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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.

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

"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

"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