I have requested (and received) a link layer type identifier for libpcap. This is a magic number that can be used as a link layer type in pcap traces to identify the pcap as containing LoRa captures from the air. This link layer type is to be used with an encapsulation which I’ve drafted myself: LoRaTap (https://github.com/eriknl/LoRaTap), recently the dissector for LoRaTap has been merged into the Wireshark master branch. This means you’ll be able to open LoRaTap pcap files with the nightly builds.
At the moment I’m working on the LoRaWAN dissector that will be able to dissect the actual data in a LoRa frame with the LoRaWAN syncword. Please stay tuned while I’m working on this, I’m expecting to submit an early version to gerrit this week.
Meanwhile it’s time to get TTN as well as manufacturers started on logging their radio data to pcap using the LoRaTap encapsulation so we can use it in Wireshark
And LoRaWAN dissector has been merged as well, should be in the daily Wireshark build tomorrow.
I’ll see about getting a gateway at home to use with TTN software so I can get started on getting pcap logging working. I do have a Kerlink gateway at work, but that’s not connected to TTN
@ErikdeJong, Do you have any tutorial about how to use it? Like do I need an extra hardware? is connecting LoRa module via USB Serial Interface enough to start using the plugin on wireshark?
I am trying to analyze my LoRa packet (not LoRaWAN).
I don’t know if there are any compatible USB/serial enabled modules that will do this for you.
You might want to take a look at gr-lora which is a set of gnuradio blocks that will allow you to read LoRa frames through SDR devices like the popular RTL-SDR dongles.
There is a tutorial over at the wiki.
I have been experimenting with extcap in Wireshark to enable capturing directly from Wireshark with the appropriate linklayer type, but due to lack of time it’s not finished yet
It would be useful to the community if this effort could be applied to decode of LoRaWAN messaging transported over the BasicStation LNS interface. Has anyone tried Wireshark for decode of the LNS protocol and contained LoRaWAN messaging?
My question is in context with the Alliance certification test bed and end-device developer test bench. BasicStation LNS encryption would need to be disabled (I believe that option exists) and the network session key would be needed by Wireshark for the device under test. Fine to leave security enabled for the application payload.
When I read the LNS protocol specs on https://doc.sm.tc/station/tcproto.html it looks like the “LoRaWAN Data Frames” packets already contain all the information you’re looking for.
Encryption is done on the HTTP(S) level, so you could decrypt that in Wireshark if you had the appropriate data or you could use a proxy like Fiddler to get the contents.
If you wanted to decrypt the LoRaWAN payload in the LNS packets then we’d have a bigger challenge on our hands, but if there is really a need for this and somebody can supply me a pcap I’ll be happy to take a look.
Hello! I am trying to utilize Wireshark to interpret my LoRaWan traffic. I had some questions and would really appreciate the help!
How exactly do I utilize the LoRaTap pcap file to encapsulate my LoRaWan traffic? How do I use the .h file to encapsulate the data, and how does can I use that to use the LoRaWan dissector? I cannot seem to find any documentation, and am not sure what the process is for encapsulate the data.
Another thing I am trying to do: I have a BasicStation gateway configured. Given that I am able to decrypt the traffic sent by the gateway to the network server, is there a way to use the LoRaWAN dissector to dissect the payload of that traffic and analyze it as LoRaWAN traffic?
Thank you for the help
The wireshark dissector referred to in the original postings has been written way before BasicStation became available. Unless there have been more recent updates it will not work for BasicStation data frames.
Thanks for the response! If that’s the case, then what traffic does the dissector work for? From my understanding, the traffic has to be encapsulated on the LoRaTap format. Exactly how do I do that? And which traffic do I encapsulate? The radio traffic caught by the gateway? I can’t seem to find much documentation.
Thanks for your help!
The LoRaWAN dissector works for both packets encapsulated in LoRaTap (so you have radio information from the PHY) and as the payload of a UDP packet (no PHY info here because LoRaWAN does not work on the physical layer)
The dissector is really aimed at people trying to implement or troubleshoot LoRaWAN software stacks, things like verifying information in packet fields or why payload is not properly decrypted. Unless you are developing your own gateway or endpoint software it is probably not something you will need for traffic inspection or troubleshooting.
Thanks for the help! I am attempting to use Wireshark’s capabilities such as pcap_open_dump to add a LoRaTap header, but am running into some issues. Would you happen to have any examples of how to encapsulate the radio information from the PHY in LoRaTap?
The radio information must be supplied by the gateway or receiver that you use. Most fields are made up of information that is configured in the receiver chipsets. Apart from the radio information the LoRaTap header was created so other protocols (ie using a different syncword) could be put in a pcap and then handled by their respective dissectors.
If you don’t have this information it doesn’t make a lot of sense to manually add it since you can just put the received message in the payload of a UDP packet and use the “decode as” option in Wireshark to make it parse the packet payload as LoRaWAN.
If you don’t want to go the UDP payload way then you can always write up some C code to use the LoRaTap header to write pcap files like in this example loratap-example.c · GitHub
I was working with gr-lora project by rpp for demodulating and decoding the lora packets from sx1262 at SF 5.
But I have not been able to do it successfully. Due to following gaps in knowledge:-
- SF 5 has a different preamble Len than SF 7 to 12
- How do I know whether to use implicit or explicit header
- How to use gr-lora for SF5. Presently I have just forced the value 5 which gives some output which I assume is wrong
That project is not related to the subject of this topic and it is not LoRaWAN related so seems not a good subject for a discussion on this forum. Please find a Lora, not LoRaWAN forum or one related to GNU radio.