Admitted Newbie.
I seem to have the gateway working well except it drops from TTN after every hour
My gateway Wifi signal seems strong. Perhaps I’m missing some setting or there is an authentication timeout? Any insight you could share would be appreciated!
Thanks
You ca test your connection to AWS, I know the EU one is in Ireland (if I recall correctly), go run the ping test from the same network the gateway is on.
Do I see this correctly, does it sent only 1 status message and becomes quiet ? It could be your firewall terminating the connectivity due to inactivity - what gateway model are you using ?
Which packet forwarder have you configured for use with TTN?
Its a Laird RG191 (RG1xx).
I don’t notice any connectivity issues to AWS… LNS Server wss://nam1.cloud.thethings.network:8887
I can check the firewall logs…
| RG1xx2943B1 | lora | user.notice | Apr 11 13:21:14 | 2022-04-11 13:21:14.738 [SYN:VERB] Time sync rejected: quality=426 threshold=362 |
|---|---|---|---|---|
| RG1xx2943B1 | lora | user.notice | Apr 11 13:21:12 | 2022-04-11 13:21:12.636 [SYN:VERB] Time sync rejected: quality=477 threshold=362 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:21:07 | 2022-04-11 13:21:06.985 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:21:07 | 2022-04-11 13:21:06.985 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:55 | 2022-04-11 13:20:55.820 [SYN:INFO] Time sync qualities: min=157 q90=362 max=483 (previous q90=258) |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:48 | 2022-04-11 13:20:48.462 [SYN:VERB] Time sync rejected: quality=284 threshold=258 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:46 | 2022-04-11 13:20:46.360 [SYN:INFO] Mean MCU drift vs SX130X#0: -0.5ppm |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:46 | 2022-04-11 13:20:46.360 [SYN:INFO] MCU/SX130X drift stats: min: +0.0ppm q50: -5.5ppm q80: +9.5ppm max: -10.9ppm - threshold q90: +10.5ppm |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:44 | 2022-04-11 13:20:44.258 [SYN:VERB] Time sync rejected: quality=324 threshold=258 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:40 | 2022-04-11 13:20:40.054 [SYN:VERB] Time sync rejected: quality=260 threshold=258 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:38 | 2022-04-11 13:20:37.952 [SYN:VERB] Time sync rejected: quality=299 threshold=258 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:37 | 2022-04-11 13:20:37.085 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:37 | 2022-04-11 13:20:37.084 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:14 | 2022-04-11 13:20:14.830 [SYN:VERB] Time sync rejected: quality=409 threshold=258 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:08 | 2022-04-11 13:20:08.524 [SYN:VERB] Time sync rejected: quality=362 threshold=258 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:07 | 2022-04-11 13:20:07.187 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:07 | 2022-04-11 13:20:07.187 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:20:02 | 2022-04-11 13:20:02.218 [SYN:VERB] Time sync rejected: quality=483 threshold=258 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:53 | 2022-04-11 13:19:53.809 [SYN:INFO] Time sync qualities: min=158 q90=258 max=590 (previous q90=363) |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:51 | 2022-04-11 13:19:51.707 [SYN:INFO] Mean MCU drift vs SX130X#0: -0.6ppm |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:51 | 2022-04-11 13:19:51.707 [SYN:INFO] MCU/SX130X drift stats: min: -0.5ppm q50: -1.7ppm q80: -5.4ppm max: +12.4ppm - threshold q90: +11.4ppm |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:42 | 2022-04-11 13:19:42.248 [SYN:VERB] Time sync rejected: quality=385 threshold=363 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:38 | 2022-04-11 13:19:38.044 [SYN:VERB] Time sync rejected: quality=590 threshold=363 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:37 | 2022-04-11 13:19:37.267 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:37 | 2022-04-11 13:19:37.267 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:34 | 2022-04-11 13:19:34.351 [AIO:XDEB] [3 |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:08 | 2022-04-11 13:19:08.605 [SYN:INFO] Mean MCU drift vs SX130X#0: -0.8ppm |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:08 | 2022-04-11 13:19:08.605 [SYN:INFO] MCU/SX130X drift stats: min: +0.0ppm q50: -1.4ppm q80: +4.3ppm max: -6.9ppm - threshold q90: +6.2ppm |
| RG1xx2943B1 | lora | user.notice | Apr 11 13:19:08 | 2022-04-11 13:19:08.316 [any:XDEB] Dropped frame without CRC or with broken CRC |
No real issues with PING/ICMP that I can tell of. Especially with it dropping on the hour.
I checked the firewall logs. I don’t see anything specific to that host (DHCP expiration, etc). None of my other devices drop at 1 hour increments. Certainly strange.
I don’t think this is a firewall timeout issue.
I had a couple of packets flow through – and then 8-9 mins later it dropped on schedule
I seem to have gateways that have a similar issue but in my case they are using MQTT protocol.
Both websocket and MQTT protocols typically operate over a TCP connection, which may need occasional keepalive packets to keep something in the chain from dropping them or forging droppery.
It might be interesting to try to connect the gateway through a router where you can run packet dump software like tshark or tcpdump; if secure sessions the actual content will be opaque, but the outer TCP connection state is open to see and you might be able to see who hung up.
This would be particularly suspect if the time duration from connection initiation to failure tends to be similar.
Logs since March 13, there have been a few MQTT disconnect, but it looks pretty stable
Mar 15 01:37:40 w4e-1424ar-002 start[9525]: 01:37:40 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Mar 23 21:50:25 w4e-1424ar-002 start[9525]: 21:50:25 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Mar 24 07:45:36 w4e-1424ar-002 start[9525]: 07:45:36 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Mar 25 15:03:06 w4e-1424ar-002 start[9525]: 15:03:06 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Mar 27 10:11:40 w4e-1424ar-002 start[9525]: 10:11:40 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Mar 28 10:15:10 w4e-1424ar-002 start[9525]: 10:15:10 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Apr 1 02:49:51 w4e-1424ar-002 start[9525]: 02:49:51 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Apr 1 18:40:57 w4e-1424ar-002 start[9525]: 18:40:57 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Apr 1 19:40:21 w4e-1424ar-002 start[9525]: 19:40:21 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Apr 2 22:00:50 w4e-1424ar-002 start[9525]: 22:00:50 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Apr 2 22:18:21 w4e-1424ar-002 start[9525]: 22:18:21 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Apr 11 06:32:38 w4e-1424ar-002 start[9525]: 06:32:38 INFO: [TTN] Reconnecting eu1.cloud.thethings.network
Who’s logs are they? I don’t think mine. Are you looking at a different gateway?
@cslorabox
Agree. I’ll look into a capture but saw where there was active traffic just a few minutes before a recent disconnect. If thats the case, there should be some variability in the drop schedule specific to idle time, no?
The station log does not indicate a disconnect event. The message on broken CRC is just informative to indicate the reception of a non-LoRaWAN compliant LoRa frame.
Try to capture the station log during a disconnect/reconnect. That should contain a reason for the disconnect.
@bei Thanks for the response.
I’m not sure I understand the ask. I did supply the gateway logs in the first post. Is that what you are referring to? These are clearly labeled as gateway disconnects. There is no real reason shown on the disconnect
Your first post only has screenshots from the TTN console, no gateway logs - gateway logs are from the gateway’s perspective, not the server’s.
The gateway log you posted didn’t span the time of a disconnection event.
It only showed the receipt of a corrupted packet with bad CRC (or as likely an imagined non-packet), which has nothing to do with the interaction of the gateway and network server.
Hi, I have a similar observation with a gateway that uses MQTT protobuf protocol. Until now I have not been able to identify the source of the issue. I tend to think that TTNV3 is contributing to the issue by some “too tight” timeout timer.