[tcpdump-workers] Request for new pcap/pcapng DLT Format

2013-05-18 Thread chris_bontje
Hi, I would like to request a custom DLT type for the Schweitzer 
Engineering Laboratories "RTAC" product.  Information on the 
product/purpose of the DLT is included below:

The RTAC product family (SEL-3530, SEL-2241, SEL-3505) is a Linux-based 
Automation Controller product that is capable of interfacing with SEL and 
3rd-party equipment using a variety of standard industrial protocols such 
as SEL FM, DNP3, Modbus, C37.118, Telegyr 8979 and others. Each protocol 
instance (master/client or slave/server) is configured to utilize either 
Ethernet or EIA-232/485 serial connectivity with protocol variations for 
each medium taken into account.  More information is available at 
www.selinc.com/sel-3530

The configuration software for the RTAC platform is named AcSELerator RTAC 
(SEL-5033) and is used to set up all communications and user logic for the 
controller as well as provide downloading and online debugging facilities. 
 One particularly useful aspect of the online debugging capabilities is a 
robust Communication Monitor tool that can show raw data streams from 
either serial or Ethernet interfaces.  Many similar products have this 
same capability but the RTAC software goes a step beyond by providing a 
"save-as" function to save all captured data into pcap format for further 
analysis in Wireshark.

All Ethernet-based capture files will have a packets with a "Linux Cooked 
Capture" Ethernet-header including the "source" MAC address of the device 
responsible for the generation of the message and the TCP/IP header(s) 
maintained from the original conversation.  The application data from the 
message will follow as per a standard Wireshark packet.

Serial-based pcap capture files are stored using "User 0" DLT type 147 to 
specify a user-defined dissector for pcap data and contain a standard 
12-byte serial data header followed by the application payload data from 
actual rx/tx activity on the line.  Some useful information can be 
retrieved from the 12-byte header information, such as conversation 
time-stamps, UART function and EIA-232 serial control line states at the 
time of the message.

The dissector is intended to be called from the DLT_USER preferences 
configuration with User 0 (DLT=147) set with a 'Header Size' of '12' and a 
'Header Protocol' of 'rtacser'. The 'Payload Protocol' can be configured 
to use whatever standardized industrial protocol is present on the line 
for attempted dissection (selfm, mbrtu, dnp3.udp, synphasor)

The general format of this 12-byte header is as follows:
+---+
| Relative TimeStamp (Left) |
|  (4 Bytes)|
+---+
| Relative TimeStamp (Right)|
|  (4 Bytes)|
+---+
| Serial Event Type |
|  (1 Byte) |
+---+
|  UART Control Line State  |
|  (1 Byte) |
+---+
|  Footer   |
| (2 Bytes) |
+---+
|  Payload  |
.   .
.   .
.   .

1) The relative timestamp is 8 bytes, the "left" and "right" components 
are 32-bit integers representing the left and right-hand side of the 
decimal point, respectively
2) The Serial Event type represents the type of packet entry in the pcap 
file:
{ 0x00,   "STATUS_CHANGE" },
{ 0x01,   "DATA_TX_START" },
{ 0x02,   "DATA_RX_START" },
{ 0x03,   "DATA_TX_END"   },
{ 0x04,   "DATA_RX_END"   },
{ 0x05,   "CAPTURE_DATA_LOST" },
{ 0x06,   "CAPTURE_COMPLETE"  },
{ 0x07,   "FRAMING_ERROR" },
{ 0x08,   "PARITY_ERROR"  },
{ 0x09,   "SERIAL_BREAK_EVENT"},
{ 0x0A,   "SERIAL_OVERFLOW_EVENT" },
3) The UART Control Line State is a masked-bit representation of the 
serial UART lines (asserted, de-asserted) at the time of the packet 
generation:
 CTS  0x01
 DCD  0x02
 DSR  0x04
 RTS  0x08
 DTR  0x10
 RING 0x20
 MBOK 0x40
4) The 2-byte footer is undefined and for future use.

The Wireshark code submission currently exists at: 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8644.  The current 
plan is to have a User Preference for the payload protocol decoding, 
selecting DNP3, Modbus, Synchrophasor or SELFM.

Let me know if any more details are needed.

Thanks,

Chris Bontje
Schweitzer Engineering Labs
Automation Application Specialist, SW Region
(509)334-5664
chris_bon...@selinc.com
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Request for new pcap/pcapng DLT Format

2013-05-20 Thread chris_bontje
Hi Guy,

Those names sound good to me for the RTAC serial captures.

After looking a little closer, I suspect that since the RTAC platform is 
Linux-based, the programmers used the libpcap library to perform captures 
and that library is responsible for the output of the SLL format.  I'll 
revise the comments section in the code header to clarify a little bit 
more on that point.

Regards,

Chris Bontje
Schweitzer Engineering Labs
Automation Application Specialist, SW Region
(509)334-5664
chris_bon...@selinc.com




From:   Guy Harris 
To: chris_bon...@selinc.com
Cc: tcpdump-workers@lists.tcpdump.org
Date:   05/20/2013 12:33 PM
Subject:Re: [tcpdump-workers] Request for new pcap/pcapng DLT 
Format




On May 13, 2013, at 1:04 PM, chris_bon...@selinc.com wrote:

> Hi, I would like to request a custom DLT type for the Schweitzer 
> Engineering Laboratories "RTAC" product.  Information on the 
> product/purpose of the DLT is included below:

Do LINKTYPE_RTAC_SERIAL/DLT_RTAC_SERIAL sound like good names?

> All Ethernet-based capture files will have a packets with a "Linux 
Cooked 
> Capture" Ethernet-header

That's not an Ethernet header:

 http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html

Any particular reason not to use LINKTYPE_ETHERNET/DLT_EN10MB, rather than 
LINKTYPE_LINUX_SLL/DLT_LINUX_SLL, for Ethernet captures?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers