To make (referring to) debugging a bit easer for those who do not have Node.js installed, I’ve set up a RunKit Endpoint for the nice:
See https://runkit.io/avbentem/lorawan-packet-decoder/branches/master and, e.g., https://runkit.io/avbentem/lorawan-packet-decoder/branches/master?data=ADFGUkFEshgAdAoAAACyGADXQ5rzpZs=
Hi,
I registered to the thing netwok
and NWKSKEY,APPSKEY,DEVADDR is defined next value.
NWKSKEY[16] = 99D58493D1205B43EFF938F0F66C339E
APPSKEY[16] = 0A501524F8EA5FCBF9BDB5AD7D126F75
DEVADDR = 260413AE;
LoRa Gate way server was transfered next encrypt data
QK4TBCaAAAABb4ldmIEHFOMmgpU=
Can I decrypt this data message?
Best regards,
yoshizu
The online version does did not check or decrypt anything (right now). So, you’ll need to use the library yourself. Note that the DevAddr is in the non-encrypted part of the message headers.
mkdir my-decoder-test
cd my-decoder-test
npm install lora-packet
node <<END
const lorapacket = require('lora-packet');
const nwkSKey = new Buffer('99D58493D1205B43EFF938F0F66C339E', 'hex');
const appSKey = new Buffer('0A501524F8EA5FCBF9BDB5AD7D126F75', 'hex');
const data = new Buffer('QK4TBCaAAAABb4ldmIEHFOMmgpU=', 'base64');
const packet = lorapacket.fromWire(data);
console.log(packet.toString());
// When the node's counter has exceeded 65,536, then use a recent FCnt value
// to supply its MSB in the call to verifyMIC:
// const recentFCnt = 476604;
// const msb = new Buffer(2);
// msb.writeUInt16LE(recentFCnt >> 16, 0);
// const valid = lorapacket.verifyMIC(packet, nwkSKey, null, msb);
const valid = lorapacket.verifyMIC(packet, nwkSKey);
console.log('MIC: ' + (valid ? 'OK' : 'FAIL'));
const payload = lorapacket.decrypt(packet, appSKey, nwkSKey);
// Assume plain ASCII text, which is bad, but works for your example...
console.log('Payload: ' + payload.toString());
END
…gives you:
Message Type = Data
PHYPayload = 40AE130426800000016F895D98810714E3268295
( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
MHDR = 40
MACPayload = AE130426800000016F895D98810714
MIC = E3268295
( MACPayload = FHDR | FPort | FRMPayload )
FHDR = AE130426800000
FPort = 01
FRMPayload = 6F895D98810714
( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
DevAddr = 260413AE (Big Endian)
FCtrl = 80
FCnt = 0000 (Big Endian)
FOpts =
Message Type = Unconfirmed Data Up
Direction = up
FCnt = 0
FCtrl.ACK = false
FCtrl.ADR = true
MIC: OK
Payload: abcdefg
(You should keep the session keys secret, as anyone can now send data to your application. Also, you should not send text.)
Dear arjanvanb
Thank you for all your help.
Your answer is what I was exactly requiring.
This is great!
Best regards,
yoshizu
Hello,
Anyone have LoRaWAN 1.1.x version packet decoder?
Please help me…!
Hi, How do we get this base64 encoded data physical payload from gateway (QK4TBCaAAAABb4ldmIEHFOMmgpU=). I am using RN2483 gateway from Semtech. I am able to connect to server which i am accessing via web interface. Here i see the lorawan frames (where all fields of physical payload are splitted). Is it possible to get entact physical payload?
Regards,
Rinto
Hi @kyosuke-yoshizu, you get it from the TTN web console on the traffic page. Click the down-arrow button to expand an uplink packet and you will be able to see the physical and Base64 payloads and copy them.
The RN2483 is a node not a gateway.
If you are trying to use it as a budget alternative to a gateway you are likely to run into a lot of issues. At any rate, to do so, you would need to have semi-custom software sitting between the radio and TTN. If you want to get raw packets, modifying that software to give them to you would be your best bet.
Hi @cslorabox, @cultsdotelecomatgmai Thanks for reply! Ofcourse gateway is also used along with RN2483.
https://www.microchip.com/developmenttools/ProductDetails/DV164140-1#additional-summary
The problem is i am not able to decrypt the FRMPAYLOAD which i receive it on Lora server web page.
Online packet decoder is present but its asking for full PHYPAYLOAD.
Lora server is personal. In case i have to get full PHYPAYLOAD from TTN, i have to route packets to TTN (have to find out what settings i should do for this 
)
Regards,
Rinto
Hi @rintoshukla, I understand. This is a TTN support forum so I don’t think that you’ll find any useful support for a “personal LoRa server”. It will be best to ask for support from the provider of the software that you use on your personal LoRa server. Good luck!
I have a small problem: how to get the original PHYPayload sent by end device.
I mean I can decode the received physical payload online, but in order to correct the error, I need to know the original payload sent by the sender.
The nature of the CRC checking would pre-suppose that errors aren’t replicated down the network stack and most gateways are set not to forward packets with CRC errors otherwise they’d try & send any & every LoRa transmission as well as badly receive LoRaWAN uplinks.
It is possible to capture the encrypted received packet on the gateway or see it in the TTN gateway console.
Overall it’s not really clear here what the problem you are trying to solve is, so perhaps a little more detail would help us to help you?
CRC is imperfect. But also keep in mind that there are two CRC’s - the hardware CRC done by the LoRa chip, and then the cryptographic Message Integrity Check (MIC) done by software (software in the node and server; but not the gateway)
most gateways are set not to forward packets with CRC errors
They are typically set not to forward hardware CRC errors, they have no knowledge of secrets or state on which they could determine if the MIC is correct or not.
As such, a packet the asker has obtained likely had a valid hardware CRC and was probably (though not with certainty) the same as transmitted. If there’s an issue (especially one which reliably persists over multiple packets) it would be with the MIC - or more likely than an error in the MIC, trying to validate it with the wrong network session key, or wrong guess for the upper 16 bits of the frame count.
otherwise they’d try & send any & every LoRa transmission
In fact they do send any non-LoRaWAN LoRa transmission that trips a preamble detect, decodes and passes hardware CRC! Gateways don’t know anything about LoRaWAN, beyond the code in later Semtech versions which naively assumes that part of the message is a device address worth printing in a debug log.
as well as badly receive LoRaWAN uplinks.
That happens sometimes, too, because not all errors invalidate the hardware CRC. If the CRC uniquely described the message, we could just send that instead of the message.
Overall it’s not really clear here what the problem you are trying to solve is, so perhaps a little more detail would help us to help you?
Absolutely
The only place you can actually get that with certainty is from the end device itself, eg, a serial debug log that hexdumps the actual bytes loaded into the radio for transmission (also often worth hexdumping the cleartext application payload before encryption, too)
But as pointed out above, you can readily get the original raw packet as received from the LoRa baseband chip in the gateway section of the TTN console. Unless there’s been corruption in the radio path, this would be the same.
In fact, I only enabled the option of forwarding packets that failed CRC check in the global.config at the Semtech UDP packet forwarder.
In this way, although I can receive the data packet in the console, it is not the original data packet of the sender, so I can’t compare the two and find out which bits have not passed the CRC check.
It’s part of a study that doesn’t matter if it doesn’t make sense for most people.
As in the earlier post, the only way you are going to get the original data packet without possibility of error is to obtain it directly from the node, probably by adding some debug output to the code that loads the packet into the radio.
Don’t forget about the 4/5 coding…
But note that your question really has nothing at all to do with this thread, since you are apparently interesting in seeing when a packet changed while going over the air, rather than trying to decode LoRaWAN contents of valid packets.
Hi, Can you please let me know if the code is in python language? Thank you
You requested something from a post from 4 years back … it may be quicker for you to port the code yourself.