Can you find the ACK from TTN in TCPDUMP data when enable auto data recovery ?
Honestly I think the problem is the truncated JSON. TTN likely discard the PUSH data because it can’t parse the json, and then also does not ack it.
I can see acks being received, but only for the PULL requests, not for the PUSH data. Likely from what I said above.
root@RAK7258:~# tcpdump -AUq port 1700 -i any
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
08:24:56.076745 IP 192.168.2.16.48240 > 52.169.76.203.1700: UDP, length 12
E..(D.@[email protected].....(....`....v.Q
08:24:56.257494 IP 52.169.76.203.1700 > 192.168.2.16.48240: UDP, length 4
....E.. .}@.0.:#4.L........p../................
.]
08:24:56.257508 IP 52.169.76.203.1700 > 192.168.2.16.48240: UDP, length 4
E.. .}@.0.:#4.L........p../................
.]
08:24:56.549523 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...D. [email protected]../..........`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
08:24:57.549506 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...D. .@..$....4.L../....%W.T..`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
08:24:58.549520 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...E. [email protected]../..........`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
08:24:59.549510 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...Ec [email protected]../.....6.tA.`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
08:25:00.549446 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...E. [email protected]../.......!=.`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
08:25:01.256745 IP 192.168.2.16.48240 > 52.169.76.203.1700: UDP, length 12
E..(E.@[email protected].....`....v.Q
08:25:01.437193 IP 52.169.76.203.1700 > 192.168.2.16.48240: UDP, length 4
....E.. [email protected](4.L........p..n................
.]
08:25:01.437210 IP 52.169.76.203.1700 > 192.168.2.16.48240: UDP, length 4
E.. [email protected](4.L........p..n................
.]
08:25:01.549541 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...E. [email protected]../....M:.p..`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
08:25:02.549488 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...E. [email protected]../.....l.>..`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
08:25:03.549467 IP 192.168.2.16.50991 > 52.169.76.203.1700: UDP, length 1532
E...E. [email protected]../....Ui.A..`....v.Q{"rxpk":[{"tmst":3243051915,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":13,"data":"QEEpASaACwABnG79aQ=="},{"tmst":3331874651,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.8,"rssi":-40,"size":26,"data":"gJIhASaCNgADBwG2XpY6ELEPxLdT0C0dl0Q="},{"tmst":3339848827,"chan":2,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.3,"rssi":-7,"size":13,"data":"QEEpASaADQAB2oOVAQ=="},{"tmst":3376684547,"chan":3,"rfch":0,"freq":867.700000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":53,"data":"QEEpASaADgAB9eqdEEzFGgaLNePoK/VjDpu5F5g1IyZZy5dUFbHW7u6ksgUMk7599eLWOUs="},{"tmst":3473367476,"chan":5,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":11.0,"rssi":-10,"size":50,"data":"QEEpASaAEAAB3ElYXW/LaiUY6gMjj08fMgzVQODtEIzXQsqGSre7IcwAbSXnIJSVCgM="},{"tmst":677100403,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-43,"size":24,"data":"gJIhASaAUQABt73cwWdq7O0Z3fo4pKm/"},{"tmst":683275347,"chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-7,"size":13,"data":"QEEpASaALwABtOUNFg=="},{"tmst":864273227,"chan":0,"rfch":0,"freq":867.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi
^C
14 packets captured
15 packets received by filter
0 packets dropped by kernel
It seems that TTN not response ACK when packet forwarder send the cached data in time.
There is 7 uplink pkt and only 2 ack in 7 seconds.
Should I consider sending cached packets only once to prevent similar problems?
It seems that TTN not response ACK when packet forwarder send the cached data in time.
I think they are not acking the cached data because it is truncated. Look carefully. The json is cut off at the end.
TTN doesn’t check the time of packets being forwarded.
Oh! Packet forwarder send 8 cached pkts in one UDP packet. It seems that the total lenght was out of the max size of UDP packet. I will fix this problem.
well. I think this is the reason of the problem.
Yes, I think so too. That’;s what I’ve been trying to tell you - the packets are TRUNCATED.
Aha. You are right! I have not got your point.
Much appreciated. I will fix it asap.
@jpmeijers I capture the UDP data via Wireshark. It seems that the json was not truncated.
The max UDP payload size defined in packet forwarder is 4640 byte. (max 8 uplink lora packet). The sizeof the captured pkt is 4424 which is less then the max size. But the TTN not send ACK for it.
Maybe the Max UDP payload size defined in TTN is less then 4420.
Tcpdump in gateway cannot print too long message. So it looks to be truncated. But in fact not.
Ahh ok, interesting result.
Could it be that we are hitting the MTU size of the network, and that fragmentation is causing an issue?
Perhaps it is because the network delay is too large to tolerate fragmentation. Or the UDP payload size defined by TTN is too small.
When I reduce the UDP payload size (less then the MTU), it works fine.
I’m reading up on this and some people say it is going to be an issue, as UDP does not re-assemble and re-order the fragments like TCP does:
https://info.stack8.com/blog/udp-fragmentation-why-should-you-avoid-it
Specifically:
However, on the other hand, UDP being a message oriented protocol, it does not have a built-in reordering or retransmitting mechanism, so fragmentation should be avoided. Further, when your traffic flows through devices that you have no control over nor visibility on such as sending traffic over the internet, then this should be avoided at all cost.
Maybe we should be safe and only send a single uplink message per UDP packet? And not put more than one inside a UDP packet. We have no idea what the MTUs are of all the hops of the network. It could be very small if some VPNs are used inside eachother. Best is to remain on the safe side and stay far below the standard 1500byte MTU.
Emm. Two uplink message per UDP packet is also safe. The max sizeof per uplink message is 540. But this will cause a decrease in efficiency. Not every message has 540 bytes. Most messages are only a few dozen bytes.
I will try to dynamically adjust the number of messages in each UDP packet to ensure that the total length is less than the MTU.
Perfect!
Path MTU discovery in practice says the following:
The minimal required MTU for all IPv6 hosts is 1,280, which is fair. Unfortunately for IPv4 the value is 576 bytes. On the other hand RFC4821 suggests that it’s “probably safe enough” to assume minimal MTU of 1,024.
So maybe use 1024?
Important thing to keep in mind is that the MTU you see on the gateway is not the minimum MTU of all the links on the path taken by the IP packets. It’s only the MTU for the first hop from the gateway to the first router.
Another problem is that the packet forwarder only send the next UDP packet after receive the ACK of the last one. If loragateway receives multiple long messages at once, it must be sent multiple times. If the network delay is large, the packets sent later may miss Rx1Window.
Good one! Definitely one of the issues with using the UDP packet forwarder. Basic Station should solve this.
But at this point Data Recovery is anyway very old data that missed the RX windows long time ago. So it’s fine to go on as we are.
I will try to send all udp pkt before collect the ACK.
Hi @yutao. Are you succeeding to make the changes to the packet forwarder? Let me know if you have anything I can test.