Re: [tcpdump-workers] [libpcap] New DLT value Request - Wattstopper DLM (#401)
Hi Denis, > Steve, if this time you are receiving this as a subscriber to the mailing > list, could you describe the encoding in a way similar to one used for > http://www.tcpdump.org/linktypes/ ? See below. Best Regards, Steve WattStopper DLM room bus protocol from LMCI USB dongle. +-+ |Dongle Code | |(1 Octet)| +-+ | Packet Delay | |(2 Octets) | +-+ |Preamble 1 | |(1 Octet | +-+ |Preamble 2 | |(1 Octet)| +-+ |Family/Address/IR| |(1 Octet)| +-+ | Sequence ID | |(1 Octet)| +-+ | Source MAC| | (4 Octets)| +-+ |Destination MAC | | (4 Octets)| +-+ |Opcode | | (1 Octets)| +-+ | Payload Length | | (1 Octets)| +-+ | Payload | . . . . . . | (0-18 Octets) | +-+ | LRC Checksum | | (1 Octet) | +-+ Description The Dongle Code field contains a value that is one of: [0] = "No Error", [1] = "Preamble 1 Error", [2] = "Preamble 2 Error", [3] = "Checksum Error", [4] = "Timeout Error", [8] = "Other Family Error" The Packet Delay field contains an integer value that is the number of milliseconds since the previous packet. The Preamble 1 and Preamble 2 fields should each contain 0xAA. The Family/Address/IR field contains 3-bits of family code, 2-bits of address mode, 2-bits of IR (infrared) routing, and 1-bit unused. The 8 Legrand NITOO families are 000=CAD Filaire, 001=TopDog, 010=CAD RF, 011=CAD PLC, 100=CAD IR, 101=DLM, 111=escape, and 111=DLM Bootloader). This document only describes the DLM family. The Address mode bits are defined as: (00=Broadcast, 01=multicast, 10=unicast, 11=anonymous unicast). The Sequence ID field contains an incrementing sequence number. The Source MAC is the 32-bit serial number of the originating device. The Destination MAC is the 32-bit serial number of the any unicast receiver, or various values for broadcast or multicast. The Opcode field contains the message command, which determines the Payload and Payload Length fields. The LRC Checksum excludes the Preamble octets. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] New DLT value Request - Wattstopper DLM (#401)
Hello Guy, >> The Family/Address/IR field contains 3-bits of family code, 2-bits of >> address mode, 2-bits of IR (infrared) routing, and 1-bit unused. >> The 8 Legrand NITOO families are 000=CAD Filaire, 001=TopDog, 010=CAD RF, >> 011=CAD PLC, 100=CAD IR, 101=DLM, 111=escape, and 111=DLM Bootloader). >> This document only describes the DLM family. > > Are the fields following the Family/Address/IR field dependent on the family > code? Or can the rest of the packet, with the possible exception of the > opcode and payload, be parsed the same way regardless of the family code? Yes, the fields following the Family code are dependent on the Family code. > Are the family codes dependent on the hardware being used? 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 >> The Opcode field contains the message command, which determines the Payload >> and Payload Length fields. > > Presumably the Payload Length field is the number of octets in the Payload > field. Yes, the Payload Length field is the number of octets in the Payload field. > Is there some other specification to which we can point for the values of the > Opcode field, and the corresponding payload, or can this be used for several > different families of opcodes (with the dissector presumably having to be > told which one to use)? (The spec doesn't have to itself describe the opcode > or payload values, although, if there's a spec or specs for them, references > to them might be useful.) I don't have a public specification for the Opcodes at the moment. Some are detailed in this Wireshark Lua dissector: http://kargs.net/captures/irb.lua >> The LRC Checksum excludes the Preamble octets. > > Does it cover the Dongle Code or Packet Delay field? The LRC does not cover the Dongle Code or Packet Delay or Preamble. Best Regards, Steve -- http://steve.kargs.net/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] New DLT value Request - Wattstopper DLM (#401)
Hello Guy, The Family/Address/IR field contains 3-bits of family code, 2-bits of address mode, 2-bits of IR (infrared) routing, and 1-bit unused. The 8 Legrand NITOO families are 000=CAD Filaire, 001=TopDog, 010=CAD RF, 011=CAD PLC, 100=CAD IR, 101=DLM, 111=escape, and 111=DLM Bootloader). This document only describes the DLM family. >>> >>> Are the fields following the Family/Address/IR field dependent on the >>> family code? Or can the rest of the packet, with the possible exception of >>> the opcode and payload, be parsed the same way regardless of the family >>> code? >> >> Yes, the fields following the Family code are dependent on the Family code. > > I.e., following the Family/Address/IR field, other families might not have > the Sequence ID, Source and Destination MAC addresses, Opcode, and Payload > Length followed by Payload? Yes, that is correct. > Is the checksum family-code independent or might packets with other family > codes not have it (or calculate the checksum differently)? I presume the checksum is family-code dependent (although by luck it might not be). > What I meant was that you said "The 8 Legrand NITOO families are ..." - is > this a protocol used only by Legrand, so that those are the only family codes > used, or are there other vendors who might have their own set of families and > family codes, different from the Legrand ones? This protocol is only used by Legrand and their subsidiary companies (i.e. WattStopper), as far as I know. >> The LRC does not cover the Dongle Code or Packet Delay or Preamble. > > I.e., it checksums packet data starting at the Family/Address/IR field and > continuing through the end of the Payload field? Yes, that is correct. Best Regards, Steve -- http://steve.kargs.net/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] New DLT value Request - Wattstopper DLM (#401)
Hello Guy, > 6 or 7 - escape > 7 or 6 - DLM Bootloader > > The information you quoted said "111=escape, and 111=DLM Bootloader"; I > assume one of those 111's is supposed to be 110. Which one of them should be > 110? 6 - unused 7 - escape and DLM Bootloader (unfortunately). The DLM Bootloader packet from LMCI USB dongle looks like this: +-+ |Dongle Code | |(1 Octet)| +-+ | Packet Delay | |(2 Octets) | +-+ |Preamble 1 | |(1 Octet | +-+ |Preamble 2 | |(1 Octet)| +-+ |Family/Address/IR| |Family=7 | |(1 Octet)| +-+ | Payload Length | | (1 Octets)| +-+ | Payload | . . . . . . | (0-32 Octets) | +-+ | LRC Checksum | | (1 Octet) | +-+ Best Regards, Steve -- http://steve.kargs.net/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] New DLT value Request - Wattstopper DLM (#401)
Hello, Is there anything pending before assigning a new DLT? I put a pull request into GitHub: https://github.com/the-tcpdump-group/libpcap/issues/401 Are there other files that I need to modify (i.e. HTML or documentation files)? Best Regards, Steve ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] New DLT value Request - Wattstopper DLM (#401)
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 wrote: > > On Jan 9, 2015, at 8:08 AM, Steve Karg 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
