I operate two gateways (1 matchX, 1 DIY RPi) and was wondering why one gateway does not receive downlink data. Took me a while to find out that the second gateway cannot receive data from TTN server via port 1700, becaue the router (Fritzbox 7490) routes incoming traffic on port 1700 to the other gateway.
I have only 1 external IP-Adress (DynDNS / DSL). Is there a solution for this use case, e.g. connecting the second gateway to TTN server via other port than 1700?
It seems Can more than one ic880a gateway run behind a typical home firewall? says all is fine:
And UDP ports and firewalling explains:
So, it seems you don’t need to (or: should not) set up any port forwarding at all; the Semtech UDP protocol should already fix this by opening connections, assuming these do not time out (and do not happen to choose the same random port numbers…) and then NAT will just take care of everything.
And indeed, I’ve been using two gateways using a FRITZ!Box 7360, without configuring anything (only one was receiving commands from TTN, but that was handled by the router automatically).
If UDP does not work for you, then maybe using the “new” TTN packet forwarder protocol, which is using TCP/IP, might fix this. (Even when using that on both gateways.)
Note that TTN will select only one gateway for downlinks. It might also detect single-channel gateways that do not support downlinks, and then discard those.
That is strange as the data travels to port 1700 at TTN but should use from a randomly assigned port at your gateway. So the Fritzbox should be getting reply data to the random port at you location, not to port 1700.
Do you see poll response packets in the logging on both gateways?
The MatchX works up and down, no forwarding in fritzbox router 7490 set.
The DIY RPi with dualchannel forwarder from this source https://github.com/bokse001/dual_chan_pkt_fwd is in the same subnet behind the router and works up but not down. Checking UDP packets on port 1700 of the RPi show rxpk, but not txpk. TTN console also shows no downlink traffic.
To ensure TTN routes downlink via the RPi and not the other gateway i switched it off. There is no other gw in range of node, so i expect TTN to use the RPi for downlink, but no txpk on port 1700 of RPi.
Well, that solves it 
Like I wrote: TTN might discard gateways for downlinks if it thinks it might not be fully compliant. First thing to ensure is that TTN Console indeed shows downlinks.
Also, the master branch of GitHub - bokse001/dual_chan_pkt_fwd: Dual Channel LoRaWAN Gateway Up and Downlink does not even seem to support downlinks:
Not (yet) supported:
PACKET_PUSH_ACK processing
SF7BW250 modulation
FSK modulation
downstream messages (tx)
But the GitHub - bokse001/dual_chan_pkt_fwd at dual_chan_pkt_fwd_up_down branch might.
Thanks for the hints. I did use the correct branch which includes the downlink code, so this cannot be the root cause.
Today i tried to delete the gateway on TTN and created a new gateway with the same EIU. My expectation was that TTN would “forget” the attributes of the gateway, but it didn’t. After the new gateway with same EIU was created, the old counter for received packets was displayed in console. So i think the TTN backend remembered all the attributes of the old gateway. Still no txpk on port 1700 
I don’t know how TTN determines if a gateway supports downlinks. I’ve used single-channel gateways with downlinks just fine, so I’d assume it’s not looking at how many channels the gateway is listening at. (But then: I might have changed the frequencies a few times as well.)
As for:
Do you even see PULL_DATA messages going from the gateway to TTN?
With tcpdump -Aq port 1700 is see only messages of types “stat” and “rxpk”, no PUSH / PULL messages at all.
Maybe the packet forwarder is crap…
It now works! Shame on me, i installed wrong branch, nevertheless i was sure to got the right one…
If you use this github repository, be sure to clone it this way:
git clone -b dual_chan_pkt_fwd_up_down https://github.com/bokse001/dual_chan_pkt_fwd
(Don’t omit the “-b” part!)