Understanding captured LoRaWAN packets

I’m trying to understand the content of LoRa packets received on my GW (before they are forwarded to a NW server). I simply want to understand the packet format in order to be able to optimize some stuff.

The data is structured on this format:
“gateway ID”,“node MAC”,“UTC timestamp”,“us count”,“frequency”,“RF chain”,“RX chain”,“status”,“size”,“modulation”,“bandwidth”,“datarate”,“coderate”,“RSSI”,“SNR”,“payload”

An example packet could look like this:
“AA555A0000000101”,"",“2018-05-06 19:32:15.430Z”,2059465484, 867500000,0, 5,“CRC_BAD”, 64,“LORA”,125000,“SF7” ,“4/5”,-121,-11.5,“FEE0647E-EEAD8513-F58AE125-494847C3-B7592387-A12D74E6-B3D1D248-08288A50-42194348-DB9D520F-0BB47112-DD9FDCFC-2B603142-12D2284E-6ACB2418-F634D971”

Pretty straight forward, but I wonder if someone knows if the following data could be extracted somehow:

  1. Network ID
  2. Sender (the MAC is not present in any packet so I don’t know who it’s from)
  3. Any kind of retransmission flag

All this information would be useful when I troubleshoot my network.

Found an online packet decoder at https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh. It takes most of the payloads and I’m able to read out DevEUI and AppEUI along with the packet type. However, I still can’t see if it’s a retransmission and I don’t see the NW ID.

You’ll only see DevEUI and AppEUI for an OTAA Join Request. For “regular” uplinks, you’ll not see those, but will see the DevAddr instead. The DevAddr is not unique; the server needs to know the secret NwkSKey for each device with that DevAddr, to pick one by comparing the MIC.

The Network ID can be derived from the DevAddr.

I don’t think that there’s any retransmission flag; a node just sends a new OTAA Join Request if it did not receive any Join Accept, or retransmits the same uplink if it did not receive an acknowledgement for confirmed uplinks. See the specification (where TTN uses LoRaWAN 1.0 at the moment).

Finally: beware that you might be receiving plain LoRa packets, which are not encoded using LoRaWAN. You cannot tell until you validate the MIC, for which you need to know the secret NwkSKey. The online decoder will happily show you all kind of details which are basically bogus if it’s not even LoRaWAN to start with. See its example that specifies the secrets, and then play with the payload (like boldly change the first byte into 00) or play with those secrets.