On Sat, Feb 18, 2017 at 10:25 PM, Erik de Jong <erikdej...@gmail.com> wrote:
>
>
> On Wed, Feb 15, 2017 at 6:04 PM, Michael Richardson <m...@sandelman.ca>
> wrote:
>
>>
>> Guy Harris <g...@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
