Request for new DLT/LINKTYPE (plain text)

[kayoub5]

Hi,

I would like to request a new DLT/LINKTYPE: PLAIN TEXT

Use cases:

• Logging serial communication from /dev/ttyS0
• Putting plain text user information in PCAPNG file (user made some manual user operations and would like to add them as extra info in the PCAP)
  • commands executed in shell
  • Manual interventions made (like unplug cable on an interface)

Simply put the bytes of the packet data will be interpreted as text to be displayed in visualization tools like Wireshark.

I would have opened a PR already, but I see there are two PRs already for linktype 297 and I would like to avoid conflicts if possible.

[guyharris]

Putting plain text user information in PCAPNG file (user made some manual user operations and would like to add them as extra info in the PCAP)

That should be done with new block types, rather than adding a fake interface and showing notes as "packets" on that interface.

[kayoub5]

Putting plain text user information in PCAPNG file (user made some manual user operations and would like to add them as extra info in the PCAP)

That should be done with new block types, rather than adding a fake interface and showing notes as "packets" on that interface.

I think so too, but there is no such block type yet.

Can we still get this "generic" TEXT DLT for at least serial communication?

[infrastation]

For serial port communications something like LINKTYPE_RTAC_SERIAL would match the problem space better. One of the other 4 DLTs already allocated for serial data could be an even better match, but it is difficult to tell because they don't seem to be documented.

[kayoub5]

@infrastation LINKTYPE_RTAC_SERIAL states that

The payload is one of: DNP3, Modbus, IEEE C37.118 Synchrophasor or SELFM

I am looking for plain old text.

[mcr]

Additionally, serial ports, have two directions, and so would need some kind of indication of which direction the data is flowing. They also have exceptional conditions including signal changes (DTR, RTS, CTS, DCD, break detected) which one might want to capture. I'd also want the baud rate logged.

Finally, we probably need an orderly transition to the IANA.

[guyharris]

I am looking for plain old text.

Presumably meaning that no sniffer program will ever do anything with the data other than presenting it as raw uninterpreted text.

[guyharris]

They also have exceptional conditions including signal changes (DTR, RTS, CTS, DCD, break detected) which one might want to capture. I'd also want the baud rate logged.

If the baud rate is constant, pcapng could handle it using the if_speed option for the Interface Description Block, treating the baud rate as bits-per-second. (Baud rates are in symbols/second, but what the host on each end of a serial port sees is the bit rate; the encoding of a bit stream over an asynchronous serial line is either trivial, so that the two rates are the same, or not trivial, in which case the baud rate is what goes over the wire and the bit rate is what goes into and out of the host.)

They also have exceptional conditions including signal changes (DTR, RTS, CTS, DCD, break detected)

Those could be done with a new block type or types in pcapng, as with other indications for non-data events on a line (carrier up/down, etc.).

[kayoub5]

I am looking for plain old text.

Presumably meaning that no sniffer program will ever do anything with the data other than presenting it as raw uninterpreted text.

yes, that's exactly what I am looking for.

a bit of context: data logging equipment have a serial line where they log events, similar to a web server logs or LINKTYPE_ETW.

we would like to have those events included in the same pcapng file for easier analysis.

It's true they are not "packets", but they do fall in the same category as LINKTYPE_ETW.