Re: Request for link layer header type

[Erik de Jong <erikdejong () gmail com>]

On Thu, Feb 9, 2017 at 7:41 PM, Erik de Jong <erikdejong () 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 <guy () alum mit edu> wrote:
>
> > On Feb 8, 2017, at 10:38 PM, Erik de Jong <erikdejong () 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