I seem to recall intentionally mis-setting this in the past as an experiment and still getting a moderate amount of traffic through
While you’re not wrong, the console logs of the current Semtech packet forwarder repo assume they can extract a device address from messages, too.
One can’t read too much credibility into these things, but they can be handy for debugging when you see something you were expecting to.
Also note that LoRaWAN should always use coding rate 4/5.
That’s probably the most important point, and I’ll readily admit I’d previously overlooked it. When filtering to only CR 4/5 messages, the log gets a lot shorter. But I suspect it does still show some valid traffic.
Although I’ve heard of radios getting into a mode (likely a mis-set internal bit) where they simply invent CRC error packets and never receive any good ones, I’ve not given up on suspicion of a software protocol or IP networking issue. But we’re operating on limited information.
Getting some raw information from the packet capture would be great. Not only would this expose networking issues, it should be possible to take a message from a known node seen in the packet capture, and compare it to the raw message seen by another gateway, or that the node was known to transmit (ie, the post-encryption buffer actually loaded into the node’s radio).