I suspect the following; the end device does not have factory preset frequencies configured in The Things Stack while it boots with The Things Network’s frequency plan and/or “resets frame counter” is off. These are independent issues leading to the same behavior, namely that frames are dropped:
When the end device transmits on a frequency that the Network Server did not expect, the frame is discarded. This is per LoRaWAN spec. So when the end device resets, and transmits on 867.7 MHz for instance, and you did not configure factory preset frequencies, the frame is dropped. As soon as the end device uses one of the mandatory channels (868.1, .3 and .5), the Network Server will process the message and will start scheduling MAC commands to configure the other 5 channels. Therefore, ABP devices that are personalized with a channel plan must have factory preset frequencies set.
When the ABP device resets its frame counters (which is not LoRaWAN compliant since 1.0.3) and the Network Server does not know that, it will only process frames with a frame counter higher than the previous.
Misconfiguration of both settings lead to similar issues. Not enabling frame counter resets leads to waiting for the end device to reach the previous FCnt. However, the session is not reset in the NS, meaning that the end device’s session and the NS session is out of sync. Not having factory preset frequencies configured lead to the NS rejecting frames.
BTW, only if frame counter resets are enabled, the factory preset frequencies are applied to the reset session (or when the device is first seen).
Note that ABP devices from LoRaWAN 1.0.3 are required to have persistent state. They must store not only frame counters but the entire MAC state. This whole “resets frame counter” feature is not LoRaWAN compliant since 1.0.3 and strongly discouraged since the first LoRaWAN versions. If a session reset is necessary, NS needs to know exactly what the end device knows, including but not limited to frequencies.
So if you want a device to just start sending data, you can also use OTAA because you need persistent memory anyway. Just activate the device when you have coverage and every time, save the state to persistent memory.