Hello, guys. I work with packet-forwarder and wonder about structure of payload here:
struct lgw_pkt_rx_s {
uint32_t freq_hz; /*!> central frequency of the IF chain */
uint8_t if_chain; /*!> by which IF chain was packet received */
uint8_t status; /*!> status of the received packet */
uint32_t count_us; /*!> internal concentrator counter for timestamping, 1 microsecond resolution */
uint8_t rf_chain; /*!> through which RF chain the packet was received */
uint8_t modulation; /*!> modulation used by the packet */
uint8_t bandwidth; /*!> modulation bandwidth (LoRa only) */
uint32_t datarate; /*!> RX datarate of the packet (SF for LoRa) */
uint8_t coderate; /*!> error-correcting code of the packet (LoRa only) */
float rssi; /*!> average packet RSSI in dB */
float snr; /*!> average packet SNR, in dB (LoRa only) */
float snr_min; /*!> minimum packet SNR, in dB (LoRa only) */
float snr_max; /*!> maximum packet SNR, in dB (LoRa only) */
uint16_t crc; /*!> CRC that was received in the payload */
uint16_t size; /*!> payload size in bytes */
uint8_t payload[256]; /*!> buffer containing the payload */
};
My question: where is the DevEUI and AppKey inside payload of struct lgw_pkt_rx_s ?
The packet forwarder does not know (and does not need to know) any of those items. The DevEUI and AppKey are stored at the join server which is part of the central Network Server.
Dear @kersing , so how network-server get to know which DevEUI match device, if packet-forwarder doesn’t restranslate DevEUI and AppKey from device to network-server?
Because you register the device in the LNS back end - not on the GW/PF… that info is held there… the GW is just a transparent media converter - LoRa Packets to IP Packets, with no intervention or interpretation just the addition of signal/message related metadata (channel, RSSI, SNR, etc.)
LoRa/LoRaWAN is not like WiFi - you join the network not the access point (Gateway in this case). Another wrinkle in thinking is with WiFi your device holds the details of the AP, not the otherway around either - your AP doesnt need you to register its details in the AP either - it just handles valid messages with the right ‘network’ keys etc. LoRaWAN is a broadcast system where all GW’s in range see the message from your device and then simply send on to ‘their’ associated LNS - where packet is reviewed to see if from a registered device, in which case it is processed, if not it is dropped (or if part of a roaming agreement or e.g. the PacketBroker it is sent for other networks to evaluate…)
Dear @Jeff-UK , It’s still not clear. From this device activation I see device transmit DevEUI through gateway packet-forwarder for activation on network-server… Am I wrong?
I can watch inside packet-forwarder received frames from device. I suspect all device frames are inside payload of struct lgw_pkt_rx_s. Is it correct?
In the payload byte array - there are a few layers - Physical layer which has the PHY Payload - then in that there is the MAC Payload which starts with the Frame Header. The first 32 bits of the FH is the DevAddr. Headers aren’t encrypted.
The LNS will then look to match the DevAddr and try the keys it finds to see what decrypts.
The AppKey is never sent over the air - it is used by the LNS to encrypt the join keys for the Join Accept.
The data structure you are looking at is for the transfer of a radio message from electromagnetic radiation to an IP data packet - it has meta data added - but as above, the gateway doesn’t need to know about what it heard as long as the CRC is OK (a feature you should have turned on) then it will pass it on to the LNS.
I just use them 