On Thu, Feb 9, 2017 at 7:41 PM, Erik de Jong <erikdej...@gmail.com> 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 <g...@alum.mit.edu> wrote: > >> On Feb 8, 2017, at 10:38 PM, Erik de Jong <erikdej...@gmail.com> 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
