Re: [tcpdump-workers] Request for link layer header type
On Feb 8, 2017, at 10:38 PM, Erik de Jong wrote: > I would like to request a link layer header type for encapsulation of LoRa > packets. It will be used to encapsulate raw packets as logged directly from > the air. As usage of this link layer header type will be similar to the > radiotap header, I've picked the name LoRaTap for the encapsulation. > > LoRa is a protocol for IoT, it's a proprietary protocol by Semtech. Specs > can be found at http://www.semtech.com/wireless-rf/rf-transceivers/sx1272/ Specs can be found there, but I couldn't find many specs relevant to assigning a link-layer header type; all I saw there was a bunch of PHY-layer stuff, and that doesn't show up in captures - it's typically the MAC layer. A *useful* spec can be found at https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf Presumably the packets in the capture will look like what's specified in section 4, with the first octet being the 1-octet MAC header field (bit 0 is the low-order bit of an octet and bit 7 is the high-order bit of an octet, right?), followed by the MAC payload, possibly followed by the Message Integrity Code - will packets have the MIC or not? > My initial idea for the encapsulation header can be found at > https://github.com/eriknl/LoRaTap So that header will be at the beginning of the packet, followed immediately by the packet data, beginning with the MAC header field? Are the multi-byte fields in that header big-endian, little-endian, or host-endian? What are the units of the RSSIs? dBm? What is the difference between "packet RSSI" and "receiver RSSI"? Is the signal/noise ration given as a percentage, some form of floating-point value, or something else? What are the units of the frequency field? Hz? KHz? Something else? What is the "SF"? One of the Semtech specs that might be relevant here is http://www.semtech.com/images/datasheet/an1200.22.pdf which says "SF = spreading factor (7..12)" - is that the "SF"? Why is there a length field? A pcap or pcapng file already *has* a packet length, which would be the sum of the length of the LoRa metadata header (16, in the example on your site) plus 1 for the MAC header plus the length of the MAC payload plus 4 if the MIC is included. Wouldn't that make a packet length field redundant? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for link layer header type
I've just noticed that this was not sent to the mailing list... On Thu, Feb 9, 2017 at 10:55 AM, Guy Harris wrote: > On Feb 8, 2017, at 10:38 PM, Erik de Jong wrote: > > > I would like to request a link layer header type for encapsulation of > LoRa > > packets. It will be used to encapsulate raw packets as logged directly > from > > the air. As usage of this link layer header type will be similar to the > > radiotap header, I've picked the name LoRaTap for the encapsulation. > > > > LoRa is a protocol for IoT, it's a proprietary protocol by Semtech. Specs > > can be found at http://www.semtech.com/wireles > s-rf/rf-transceivers/sx1272/ > > Specs can be found there, but I couldn't find many specs relevant to > assigning a link-layer header type; all I saw there was a bunch of > PHY-layer stuff, and that doesn't show up in captures - it's typically the > MAC layer. > > A *useful* spec can be found at > > https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Spec > ification%201R0.pdf > > Presumably the packets in the capture will look like what's specified in > section 4, with the first octet being the 1-octet MAC header field (bit 0 > is the low-order bit of an octet and bit 7 is the high-order bit of an > octet, right?), followed by the MAC payload, possibly followed by the > Message Integrity Code - will packets have the MIC or not? > You are correct, the packets encapsulated by the LoRaTap format will be those from the PHYPayload as listed in section 4. This document details the LoRaWan protocol which is something that can run on top of the LoRa radio phy layer. The LoRaTap could be of the LoRaWAN protocol or anything else one might want to send over LoRa radios. > My initial idea for the encapsulation header can be found at > > https://github.com/eriknl/LoRaTap > > So that header will be at the beginning of the packet, followed > immediately by the packet data, beginning with the MAC header field? > Correct, see above. > > Are the multi-byte fields in that header big-endian, little-endian, or > host-endian? > I am leaning towards host-endianess, I think pcap is able to distinguish host-endianess but I am not sure if other formats work with that. I'll need to do some further research. > > What are the units of the RSSIs? dBm? What is the difference between > "packet RSSI" and "receiver RSSI"? > > Is the signal/noise ration given as a percentage, some form of > floating-point value, or something else? > > What are the units of the frequency field? Hz? KHz? Something else? > > What is the "SF"? One of the Semtech specs that might be relevant here is > > http://www.semtech.com/images/datasheet/an1200.22.pdf > > which says "SF = spreading factor (7..12)" - is that the "SF"? > > I'll work on documenting those parameters. The header I published yesterday is just to get an initial idea. > Why is there a length field? A pcap or pcapng file already *has* a packet > length, which would be the sum of the length of the LoRa metadata header > (16, in the example on your site) plus 1 for the MAC header plus the length > of the MAC payload plus 4 if the MIC is included. Wouldn't that make a > packet length field redundant? Good point, I think it might be appropriate to remove it. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for link layer header type
On Thu, Feb 9, 2017 at 7:41 PM, Erik de Jong wrote: > I've just noticed that this was not sent to the mailing list... > > On Thu, Feb 9, 2017 at 10:55 AM, Guy Harris wrote: > >> On Feb 8, 2017, at 10:38 PM, Erik de Jong wrote: >> >> > I would like to request a link layer header type for encapsulation of >> LoRa >> > packets. It will be used to encapsulate raw packets as logged directly >> from >> > the air. As usage of this link layer header type will be similar to the >> > radiotap header, I've picked the name LoRaTap for the encapsulation. >> > >> > LoRa is a protocol for IoT, it's a proprietary protocol by Semtech. >> Specs >> > can be found at http://www.semtech.com/wireles >> s-rf/rf-transceivers/sx1272/ >> >> Specs can be found there, but I couldn't find many specs relevant to >> assigning a link-layer header type; all I saw there was a bunch of >> PHY-layer stuff, and that doesn't show up in captures - it's typically the >> MAC layer. >> >> A *useful* spec can be found at >> >> https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Spec >> ification%201R0.pdf >> >> Presumably the packets in the capture will look like what's specified in >> section 4, with the first octet being the 1-octet MAC header field (bit 0 >> is the low-order bit of an octet and bit 7 is the high-order bit of an >> octet, right?), followed by the MAC payload, possibly followed by the >> Message Integrity Code - will packets have the MIC or not? >> > > You are correct, the packets encapsulated by the LoRaTap format will be > those from the PHYPayload as listed in section 4. This document details the > LoRaWan protocol which is something that can run on top of the LoRa radio > phy layer. The LoRaTap could be of the LoRaWAN protocol or anything else > one might want to send over LoRa radios. > > > My initial idea for the encapsulation header can be found at >> > https://github.com/eriknl/LoRaTap >> >> So that header will be at the beginning of the packet, followed >> immediately by the packet data, beginning with the MAC header field? >> > > Correct, see above. > >> >> Are the multi-byte fields in that header big-endian, little-endian, or >> host-endian? >> > I am leaning towards host-endianess, I think pcap is able to distinguish > host-endianess but I am not sure if other formats work with that. I'll need > to do some further research. > I've decided to stick with big-endianess. > >> What are the units of the RSSIs? dBm? What is the difference between >> "packet RSSI" and "receiver RSSI"? >> > >> Is the signal/noise ration given as a percentage, some form of >> floating-point value, or something else? >> >> What are the units of the frequency field? Hz? KHz? Something else? >> >> What is the "SF"? One of the Semtech specs that might be relevant here is >> >> http://www.semtech.com/images/datasheet/an1200.22.pdf >> >> which says "SF = spreading factor (7..12)" - is that the "SF"? >> >> I'll work on documenting those parameters. The header I published > yesterday is just to get an initial idea. > >> Why is there a length field? A pcap or pcapng file already *has* a >> packet length, which would be the sum of the length of the LoRa metadata >> header (16, in the example on your site) plus 1 for the MAC header plus the >> length of the MAC payload plus 4 if the MIC is included. Wouldn't that >> make a packet length field redundant? > > Good point, I think it might be appropriate to remove it. > > Please see the github link for an updated version with explanation and units for each field. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
