Chirpstack network server is not sending push_data ack as shown in the picture. I’m using the semtech packet forwarder and the ports have been set correctly.
This seems like a confusion of terms.
A “push data ack” is not a “downlink” but rather merely a UDP packet within the aged UDP protocol that can be used between a packet forwarder and a network server.
Push data acks would not show up in a logging screen like that, actually the chirpstack network server doesn’t even speak the protocol in which they are used, it is only used between the gateway bridge and the packet forwarders.
So either what you are missing is something other than a push data ack.
Or you are looking in the wrong place for them - you’d only see their presence/absence in the packet forwarder logs or in a local network monitoring tool running on the gateway or gateway bridge host.
Or else if there is an actual issue, it’s one with the gateway bridge and not the network server. Since the gateway bridge is known to work, dropped traffic would be more likely an issue with infrastructure between the gateway and gateway bridge, especially some old NAT implementation. Really the gateway bridge should be run on the gateway, or on a box physically co-located with it before an Internet routing gets into the picture.
Thanks for the reply. I also think maybe the issue with the unconfirmed frames lies with the chirpstack-gateway-bridge not being installed in the gateway host (the rapsberry) itself. But is there some way this could be solved without installing it there? The raspbian jessie OS that came preinstalled in the RPI3 is outdated and I’ve run through a lot of issues installing any new packages there.
I’m currently just forwarding the udp packets sent by the packet forwarder to my other pc running ubuntu where I’ve installed the chirpstack gateway bridge as well as the network and application servers.
What “issue” would that be?
You’ve provided no evidence that there is any actual problem in the sense of anything operating other than the way it is designed to.
Unconfirmed frames are frames that do not request any response.
These are what you should normally be using, as the topology of LoRaWAN is fundamentally “uplink mostly” with downlinks needing to be a rarity.
If you believe there's an actual problem, you need to be very specific about what you expect to be happening, what you've done to cause that to happen, and what evidence you believe indicates that it is not happening.