I missed that both screenshots show Type being Rx for all entries. So, I’d say that the Join Accept and the other downlink are not things that have been transmitted by your very gateway, but have been received by your gateway, just like the uplinks.
Like I wrote above, usually LoRaWAN gateways won’t hear each other’s downlinks. So, either I’m wrong and this gateway receives downlinks too (and there’s some other LoRaWAN network in your neighbourhood). Or it’s weird that the screenshot shows Join Accepts† and other downlinks.
I’d guess that the CRC errors are indeed true errors. If true, then the decoded details (such as message type and DevAddr) are just bogus, and that Join Request seemingly being followed by a Join Accept after 5 seconds is just a coincidence.
Assuming that the CRC errors are indeed true errors, then the packet that you got forwarded to TTN (due to using forward=crc-valid,crc-error
) is not valid either. TTN cannot know that, as the DevAddr (as far as one can extract that from an invalid packet) is not known to TTN, so it cannot validate the Message Integrity Code (MIC) and will just discard the message, thinking it’s from some other LoRaWAN network (or not even LoRaWAN).
In other words: using forward=crc-valid,crc-error
surely will make TTN Console show things, but it’s probably all invalid (or not even LoRa?). But at least you now know that the gateway is connected to TTN. Next, I’d change the setting to use forward=crc-valid
.
You’ll have to wait for your LoRaWAN nodes to arrive, to be able to tell if you still get CRC errors then.
† Especially that Join Request followed by the Join Accept after about 5 seconds is suspect. Other entries might simply not be LoRaWAN at all, even though the logging on the screenshot assumes they are: the gateway does not know the secrets to be able to validate the MIC, so all it can do is assume it’s a valid LoRaWAN packet where some unencrypted bytes have some specific meaning. And that’s what it shows, even if it’s not LoRaWAN. However, for that Join Request and Join Accept the 5 seconds difference happens to match the OTAA RX1 timing, like I wrote above, and I figured that’s not very likely to happen by coincidence. But maybe it did.