TTIG connects to Wi-Fi but is always flashing green

Gateways TTIG - The Things Indoor Gateway
102

I’m not familiar with network tools at all, but “I’ve seen them, so I know they exist”.
So in sheer desperation to find out if the problem is on “my side” or on “the other side”, I tried something, here is one of them:
sudo tcpdump -n -v host 192.168.80.142
sudo tcpdump -n -v host 192.168.80.141
And then power cycled the TTIG’s.
192.168.80.141 is the good TTIG
192.168.80.142 is the bad TTIG
It seems to me like they start out exactly the same.
Maybe som one “familiar with networkin tools” can sugest commands that can really tel what goes on…
Here is what I saw:

$ sudo tcpdump -n -v host 192.168.80.142
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:57:25.951002 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
23:57:26.148334 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
23:57:26.660309 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
23:57:27.581911 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
00:27:38.032768 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
00:27:38.230374 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
00:27:38.742387 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
00:27:39.664207 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
00:57:49.804160 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
00:57:50.005190 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
00:57:50.414885 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
00:57:51.339020 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
01:28:01.685793 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
01:28:01.882607 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
01:28:02.402992 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
01:28:03.319368 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
01:58:15.407493 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
01:58:15.822315 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
...
07:30:37.843365 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
07:30:38.040823 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
07:30:38.552847 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
07:30:39.474578 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
08:00:50.026879 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
08:00:50.224184 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
08:00:50.736196 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
08:00:51.658065 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
08:31:11.428093 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
08:31:11.939725 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
08:31:12.444772 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
08:31:13.264094 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
08:31:13.366394 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
09:01:26.370819 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
09:01:27.292617 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38
09:31:39.993482 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
09:31:40.399403 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 0.0.0.0, length 38
09:31:40.911461 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.142 tell 192.168.80.142, length 38
09:31:41.833007 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.142, length 38

$ sudo tcpdump -n -v host 192.168.80.141
[sudo] password for joe:
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:05:58.866126 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.141 tell 0.0.0.0, length 38
10:05:59.167380 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.141 tell 0.0.0.0, length 38
10:05:59.677619 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.141 tell 192.168.80.141, length 38
10:06:00.292034 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.80.1 tell 192.168.80.141, length 38
103

Stop fishing, if only for your own sake - we can see the difference in the TTIG logs - network traffic will only reflect the activity you see in the TTIG logs you’ve provided. The best person to evaluate that information is @KrishnaIyerEaswaran2 who should be able to look at it when he’s available.

The other alternatives are to return the TTIG to the vendor (seller) under their terms of warranty / return or to subscribe to a TTI support plan so that you can officially access TTI staff directly.

104

Ok, understand it so that it is nothing more I can do, I will just wait. Thank you anyway.

105

This is the key line for me. 0052 is most likely a DNS resolution failure as per MbedTLS. Since there’s a gateway from the same network that is able to connect in your case, my conclusion is that this is a hardware issue.
Unfortunately, I don’t have a resolution step other than returning this gateway in favour of a new one.

1 Like