On Jan 9, 2015, at 8:08 AM, Steve Karg <sk...@users.sourceforge.net> wrote:
> Yes, the Family codes are dependent on the hardware. The WattStopper > DLM hardware uses a USB interface: > http://www.wattstopper.com/products/digital-lighting-management/configuration-tools/dlm-computer-interface-tools-and-software.aspx > and also tunnels the DLM packets in BACnet messages. > > Another Family is CAD PLC, part of Open-NITOO, but I don't know the > hardware interface: > http://www.myopen-legrandgroup.com/cfs-filesystemfile.ashx/__key/telligent-evolution-components-attachments/00-212-01-00-00-03-46-60/U3838B_5F00_Specifications.pdf So that document says: Nitoo frames (see Reference 5 on page 16) are formed by a frame preamble, an header, two addresses, the payload and a final CRC check. In these fields are contained all information needed to build an OPEN message. Often in a particular field, information about how to interpret other frame sections are also contained. Table 1: Nitoo Frame +----------------+--------+----------+---------+----------+-----+ | FRAME PREAMBLE | HEADER | ADDRESS1 | PAYLOAD | ADDRESS2 | CRC | +----------------+--------+----------+---------+----------+-----+ The header contains further information about the addresses interpretation: Table 2: Nitoo Frame Header +-------------+--------------+--------------+ | FAMILY TYPE | ADDRESS MODE | ROUTING INFO | +-------------+--------------+--------------+ The only family type managed from OPEN is 0x011 (CAD PLC). I'm guessing that the "FRAME PREAMBLE" is, in that case, the same 0xAA 0xAA as in the DLM messages, and that the Nitoo Frame Header is the same 1-octet header as in the DLM messages. If so, should the new LINKTYPE_ value just specify +-------------------------+ | Dongle Code | | (1 Octet) | +-------------------------+ | Packet Delay | | (2 Octets) | +-------------------------+ | Preamble 1 | | (1 Octet | +-------------------------+ | Preamble 2 | | (1 Octet) | +-------------------------+ | Family/Address/IR | | (1 Octet) | +-------------------------+ with what follows that being described by other family-dependent specifications, so that this could be used for other families? Or would captures from other families be done by other mechanisms that might not supply the dongle code or packet delay? _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
