tcpdump mailing list archives

Re: [libpcap] New DLT value Request - Wattstopper DLM (#401)


From: Guy Harris <guy () alum mit edu>
Date: Tue, 20 Jan 2015 10:30:00 -0800


On Jan 9, 2015, at 8:08 AM, Steve Karg <skarg () 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


Current thread: