Error

Messages of type error are intended to notify the AS about critical errors during LoRaWAN message processing.

These messages are generated in case the NS was not able to complete LoRaWAN message processing for some reasons: bad MIC, CRC or other...

On the diagram below, you can see an example of such an error: the device is trying to perform OTAA using the dev_nonce that was already used before.

The sequence in that example looks as follows:

• The Device initiates the OTAA and sends a join_request to the NS.
• The NS processes the join_request, creates a join_accept and sends it back to the device.
• The Device is trying to perform the OTAA again using the sameDEV_NONCE, creates a join_request and sends it to the NS.
• The NS identifies an error and sends an error message to the AS.

Params

Example

{
    "meta": {
        "network": "a0842237",
        "packet_hash": "451d26187b5dbc94e12d040ae094b5e2",
        "application": "b3a1067cf7085309",
        "time": 1504638860.752536,
        "device": "8c30dd074be218cb",
        "packet_id": "9b34f5f1bf8a38ccff7589e30312bf67",
        "gateway": "f5791b767ff5cf7a"
    },
    "type": "error",
    "params": {
        "message": "Join request rejected. The same DEV_NONCE was processed before. Possible replay attack"
    }
}

List of Errors

• Requesting downlink message failed due to network server error: <reason>.
• Could not encrypt data from application. Application returned decrypted payload, but did not provide APP_SESSION_KEY for encryption.
• Application returned payload with bad format. Expected base64 string
• Join request rejected: device <dev_eui> attempts to send data to wrong AppEUI (<app_eui>)
• Join request rejected. The same DEV_NONCE was processed before. Possible replay attack
• Join request MIC check failed for DEV_EUI
• Join failed: application request timeout. Please check application availability
• Join failed due to network server error: <reasone>.
• Data message MIC check failed. Seems counters are not synchronized. Core will try to recover counters
• Device counters are not synchronized and it is not possible to recover them
• Device uplink counter is less or equal than the last known uplink counter. Possible replay attack.
• Sending 'status' message failed: application request timeout. Please check application availability.
• Sending 'status' message failed due to network server error: <reason>.