Re: Request for link layer header type

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

Hi all,

I was engaged in other activities lately, but would like to pick this up
again. Anything that I will have to address before a DLT can be assigned?
As stated in the last revision there is a field for syncword included that
will allow analyzers to parse the packets according to the correct protocol.
Later today I'll meet some LoRa related manufacturers and I want to ask
them if they're willing to support this encapsulation in their products for
debugging purposes.

Best regards,
Erik

On Thu, Mar 2, 2017 at 9:46 PM, Erik de Jong <erikdejong () gmail com> wrote:

> On Sat, Feb 18, 2017 at 10:25 PM, Erik de Jong <erikdejong () gmail com>
> wrote:
>
> > On Wed, Feb 15, 2017 at 6:04 PM, Michael Richardson <mcr () sandelman ca>
> > wrote:
> >
> > > Guy Harris <guy () alum mit edu> wrote:
> > >     >> 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.
> > >
> > >     > So what other protocols, if any, would be sent over LoRa radios?
> > >
> > >     > If there's more than one protocol, will any systems that are saving
> > >     > pcap or pcapng files containing LoRa packets know what protocol
> > > that
> > >     > is?  If so, perhaps there should be more than one link-layer header
> > >     > type, one for each protocol (even if they all share the same
> > >     > pseudo-header for radio information).
> > >
> > > Please plan for either subtypes, or multiple types.
> > > There will at least, I think, be incompatible revisions to LoRaWAN!
> > > (I've stopped paying attention to LoRA though)
> >
> >
> > I was thinking this over the past few days but I really can't find a good
> > way to deal with that on a link-layer type base. The only proper way would
> > be to define one LINKTYPE_LORATAP_RAW and another LINKTYPE_LORATAP_LORAWAN
> > where the latter one could be parsed by analyzers as being LoRaWAN type
> > traffic, this would imply for the capturing software to parse the data
> > first and discard any that don't have a valid MAC header and/or correct
> > MIC... There is of course the 'syncword' that is able to trigger an
> > interrupt on the Semtech chips but that's not working when using a
> > continuous reception mode which is what you'd use for making captures.
> > Actually, why no work on an even more generic linktype for RF packets?
> > That would work for this case as well.
> >
> > Also I think it will need channel and Rx strength containers.
> > > (In a pure pcap-ng situation, it would be nice to have generic headers
> > > for
> > > channel and signal strength...)
> >
> >
> > Good point! A container for channel would contain the bandwidth and
> > frequency. For RX strength I'd suggest two fields, the RSSI and max RSSI
> > like in Radiotap. While dissecting a basestation ('gateway') I've borrowed
> > I've noticed it also reporting the antenna that received the packet when
> > posting to the backend. However I think that might be something that's more
> > appropriate for the interface description block like in pcap-ng and not for
> > the captured packets. Having multiple antennas would basically just be the
> > same as having a capture from multiple sources.
>
>
> I have added containers for RSSI and Channel, also decided to introduce a
> byte for the sync word. Packet analyzers can use this field to determine
> which upper layer protocol to parse. Please find the latest revision over
> on github (https://github.com/eriknl/LoRaTap).
>
> Regards,
> Erik
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers