1
votes

I am polling a remote oscilloscope and the answer is "almost" pure ASCII:

image_packet

"Almost" because the 4-byte header 80 00 00 15 (15 is the length of the ASCII message, in this case 21 bytes) doesn't let me decode the payload as ASCII in the column Data (neither when set as Custom/data.data nor Custom/data.text):

image_column_appearance

Edit > Preferences > Protocols > Data has been already set as Show data as text

I would like to read the ASCII text as in Follow TCP Stream, where it is decoded correctly and the invalid ASCII codes changed to .:

enter image description here

Is there a way to remove the first 4 bytes without writing a dissector? I have no knowledge of Lua and no idea about how to write the dissector anyway: 10.3. Example: Dissector written in Lua is well above my understanding. Any pointer to a published solution that I can easily adapt is welcome.

Thank you

1
What is the format and meaning of those first 4 bytes? It can't be a straight length value; otherwise the first byte, the 0x80 would alter the length. Maybe you could supply a small capture file somewhere (Dropbox, Drive, ...)? - Christopher Maynard
You could maybe take a look at the guide I wrote on how to create Lua dissectors for Wireshark. I also found the official documentation a bit hard to understand, which is why I wrote the guide. I don't know whether there is an easier way or not to do it. - Mika Sundland
@ChristopherMaynard, 80 00 00 XX is the beginning of payload. I never found a message longer than 54 bytes. I am reverse engineering the communication and only assume 80 00 00 is fixed. It could be a status of any kind, but I am interested only in the ASCII string. - Alex Poca
@MikaS, great guide, thank you. - Alex Poca
@AlexPoca, the length field could be a single byte field but it might also be a multi-byte field, 2, 3 or even 4 bytes with the exception of the most-significant bit of the 1st byte. It's fine to assume it's a single byte, but you might want to just keep in mind that it could be a multi-byte field. Maybe there's more information available about the message format from the manufacturer? If not from their published documents then maybe through a support request? - Christopher Maynard

1 Answers

1
votes

Following MikaS tutorial (very easy and well made!) I wrote this LUA dissector:

    yokogawa_protocol = Proto("YokogawaWT3000",  "Yokogawa WT3000 Protocol")

    message_header0 = ProtoField.int32("yokogawa_protocol.message_header0", "messageHeader0", base.DEC)
    message_header1 = ProtoField.int32("yokogawa_protocol.message_header1", "messageHeader1", base.DEC)
    message_header2 = ProtoField.int32("yokogawa_protocol.message_header2", "messageHeader2", base.DEC)
    message_length = ProtoField.int32("yokogawa_protocol.message_length", "messageLength", base.DEC)
    message_ascii  = ProtoField.string("yokogawa_protocol.message_ascii", "messageAscii", base.ASCII)

    yokogawa_protocol.fields = { message_header0, message_header1, message_header2, message_length, message_ascii }

    function yokogawa_protocol.dissector(buffer, pinfo, tree)
      length = buffer:len()
      if length == 0 then return end

      pinfo.cols.protocol = yokogawa_protocol.name

      local subtree = tree:add(yokogawa_protocol, buffer(), "Yokogawa WT3000 Protocol Data")

      subtree:add(message_header0, buffer(0,1)) -- fixed h80
      subtree:add(message_header1, buffer(1,1)) -- fixed h00
      subtree:add(message_header2, buffer(2,1)) -- fixed h00
      subtree:add(message_length, buffer(3,1))  -- ascii length
      subtree:add(message_ascii, buffer(4, length-4)) -- ascii text
    end

    local tcp_port = DissectorTable.get("tcp.port")
    tcp_port:add(10001, yokogawa_protocol)

Right-click on messageAscii, then "Apply as Column", let me see the decoded value for each message in a new column.

Thanks everybody