Hello Guy, It would certainly make sense to try and make it generic so that the LINKTYPE could be used by multiple families. If the other families don't have a dongle code and packet delay, they could fill them in with some consistent values (i.e. match the DLM values, have zero packet delay) if they want to store their data in this format.
Best Regards, Steve On Tue, Jan 20, 2015 at 12:30 PM, Guy Harris <g...@alum.mit.edu> wrote: > > 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? -- http://steve.kargs.net/ _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
