Re: Request for link layer header type

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

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.


--
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr () sandelman ca  http://www.sandelman.ca/        |   ruby on
> rails    [
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers