And a bit more from Slack, for future reference, so you know what to expect. Note that for V2 the problem seems to have started when V2 gateways were recently bridged through V3:
Note that this issue is for v3. In v3 we let users register the antenna gain of their gateway. V3 serves config files without the antenna gain field, and subtracts the gain for each downlink.
It would not matter if the antenna gain is entered in the gateway’s config file or the V3 server. Take for example a 6dBi antenna and 2dB of cable loss. The net gain is 4dBi. If this entered in either place, when the server wants to transmit at +27dBm (eirp), the gateway will be requested to send at +24dBm. This power does not exist in the Tx_lut table and the packet will be dropped.
The UDP packet forwarder is compiled from two pieces of code. The first the Packet Forwarder takes UDP packets from the internet and places them on an internal queue. There is a test to check there is a 100% match with one of the 16 entries in the Tx_lut table. The second piece of code, the SX1301 HAL takes the packet from the queue and searches the Tx_lut table (again) for the next lowest power. So in effect the test is performed twice and using different criteria in each case. You can simply remove the first test in the Packet Forwarder and recompile, By the way, there is no error checking and the whole system is incorrect if someone fails to put the Tx_lut entries in increasing order. My revised UDP packet forwarder fixes both problems
The problem does not exist in the packet forwarder for the new SX1302 base band receiver, here the logic is correct from the first release
@TonySmith, not my cup of tea, but it seems some of the above would be good input on Downlinks rejected by gateways for certain TX powers · Issue #2106 · TheThingsNetwork/lorawan-stack · GitHub as well, if only to ensure @KrishnaIyerEaswaran2 sees it too?