[tcpdump-workers] Fwd: Request for link layer header type
Hello all, 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/wireless-rf/rf-transceivers/sx1272/ My initial idea for the encapsulation header can be found at https://github.com/eriknl/LoRaTap Best regards, Erik ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for link layer header type
I've just noticed that this was not sent to the mailing list... On Thu, Feb 9, 2017 at 10:55 AM, Guy Harris wrote: > On Feb 8, 2017, at 10:38 PM, Erik de Jong 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. > > 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. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for link layer header type
On Thu, Feb 9, 2017 at 7:41 PM, Erik de Jong 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 wrote: > >> On Feb 8, 2017, at 10:38 PM, Erik de Jong 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
[tcpdump-workers] Fwd: Request for link layer header type
On Wed, Feb 15, 2017 at 8:12 AM, Guy Harris wrote: > On Feb 9, 2017, at 10:41 AM, Erik de Jong 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). The LoRa alliance propagates the LoRaWAN protocol as the protocol for LoRa radios. However there is no reason why there couldn't be other protocols on top, for research purposes etc. As there is no thing like the ethertype in the specs this would be something like using "decode as" in Wireshark for non IANA assigned port usage. The only thing we know for sure about anything in a pcap with this link layer type is that it was captured from a LoRa-compatible radio transmission. Obviously I'd recommend tools to default to a LoRaWAN payload. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Fwd: Request for link layer header type
On Wed, Feb 15, 2017 at 8:13 AM, Guy Harris wrote: > On Feb 9, 2017, at 11:44 AM, Erik de Jong wrote: > > > Please see the github link for an updated version with explanation and > > units for each field. > > So what does "last packet" mean in "RSSI of last packet" and "Estimation > of last packet SNR"? (BTW, there's a typo - the spec says "Espimation" > instead of "Estimation".) > "Last packet" means the last received packet, ie the payload following the header. The "estimation" is taken verbatim from the datasheet of the chip I used for capturing. Might be better to leave out the work 'estimation'. PS: I'm terribly sorry for my strange posting behaviour, looks like gmail has issues with this mailing list while working fine with other mailing lists ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for link layer header type
On Wed, Feb 15, 2017 at 6:04 PM, Michael Richardson
wrote:
>
> Guy Harris 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 [
> ] m...@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
Re: [tcpdump-workers] Request for link layer header type
On Sat, Feb 18, 2017 at 10:25 PM, Erik de Jong wrote:
>
>
> On Wed, Feb 15, 2017 at 6:04 PM, Michael Richardson
> wrote:
>
>>
>> Guy Harris 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
Re: [tcpdump-workers] Request for link layer header type
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 wrote:
>
>
> On Sat, Feb 18, 2017 at 10:25 PM, Erik de Jong
> wrote:
>
>>
>>
>> On Wed, Feb 15, 2017 at 6:04 PM, Michael Richardson
>> wrote:
>>
>>>
>>> Guy Harris 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
Re: [tcpdump-workers] Request for link layer header type
On Tue, Apr 11, 2017 at 3:55 PM, Michael Richardson wrote: > Erik de Jong wrote: > > 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. > > It's your consensus process, not ours. > As I'm requesting the type number from the project, I wouldn't want to annoy you with incomplete/rubbish requests. Hence my question ;-) > > We'd love to have a stable URL to point to, but we'll settle for your email > address :-) > > >> (https://github.com/eriknl/LoRaTap). > > This would be fine, if you put a git tag on it, since you might want to > revise it later on. > Here is the initial release tagged: https://github.com/eriknl/LoRaTap/releases/tag/v0.1 > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works| network > architect [ > ] m...@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
Re: [tcpdump-workers] Request for link layer header type
On Tue, Apr 11, 2017 at 9:23 PM, Erik de Jong wrote: > On Tue, Apr 11, 2017 at 3:55 PM, Michael Richardson > wrote: > >> Erik de Jong wrote: >> > 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. >> >> It's your consensus process, not ours. >> > > As I'm requesting the type number from the project, I wouldn't want to > annoy you with incomplete/rubbish requests. Hence my question ;-) > > >> >> We'd love to have a stable URL to point to, but we'll settle for your >> email >> address :-) >> >> >> (https://github.com/eriknl/LoRaTap). >> >> This would be fine, if you put a git tag on it, since you might want to >> revise it later on. >> > > Here is the initial release tagged: https://github.com/eriknl/ > LoRaTap/releases/tag/v0.1 > Hoping not to sound too ignorant, but I was wondering if there is anything else I am expected to do now as I didn't get a number assigned yet. Best regards, Erik ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for link layer header type
On Sat, Jun 3, 2017 at 1:11 AM, Michael Richardson wrote: > > Erik de Jong wrote: > >> On Tue, Apr 11, 2017 at 3:55 PM, Michael Richardson < > m...@sandelman.ca> > >> wrote: > >> > >>> Erik de Jong wrote: > 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. > >>> > >>> It's your consensus process, not ours. > >>> > >> > >> As I'm requesting the type number from the project, I wouldn't want > to > >> annoy you with incomplete/rubbish requests. Hence my question ;-) > >> > >> > >>> > >>> We'd love to have a stable URL to point to, but we'll settle for > your > >>> email address :-) > >>> > >>> >> (https://github.com/eriknl/LoRaTap). > >>> > >>> This would be fine, if you put a git tag on it, since you might > want > >>> to revise it later on. > >>> > >> > >> Here is the initial release tagged: https://github.com/eriknl/ > >> LoRaTap/releases/tag/v0.1 > >> > > > Hoping not to sound too ignorant, but I was wondering if there is > > anything else I am expected to do now as I didn't get a number > assigned > > yet. > > Just email overload. > > /* > * per: Erik de Jong for > * https://github.com/eriknl/LoRaTap/releases/tag/v0.1 > */ > #define DLT_LORATAP 270 > > > Thanks for your feedback Michael! > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works| network > architect [ > ] m...@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
