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 <erikdej...@gmail.com> wrote:
>
>
> 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
