Debugging source of packet loss

Hello,

I have a bunch of Shelly devices (small IoT devices with the ESP8266 chip) that all exhibit packet loss when connecting to WiFi (a power line adapter running OpenWRT).

What I know so far:
• All shelly devices I have exhibit this (it's not a faulty device)
• Packet loss occurs with and without encryption on the WiFi network
• Packet loss also occurred with stock firmware on this powerline adapter
• Connecting these devices to an Ad-Hoc WiFi network on my Mac (or to my main router's WiFi) there's no packet loss
• Connecting my Mac or iPhone to the power line's WiFi network also works with no packet loss

Pinging from OpenWRT (or from any other device on my network) to the Shelly device yields:

119 packets transmitted, 60 packets received, 49% packet loss
round-trip min/avg/max = 1.661/3.110/9.780 ms

Is there some way I can debug the reason behind this packet loss? logread on OpenWRT isn't stating anything relevant.

Here's rc_status for that device but I don't know how to interpret that:

# cat /sys/kernel/debug/ieee80211/phy1/netdev\:wlan1/stations/50\:02\:91\:f0\:89\:ed/rc_stats

best   __________rate_________    ____statistics___    ____last_____    ______sum-of________
rate  [name idx airtime max_tp]  [avg(tp) avg(prob)]  [retry|suc|att]  [#success | #attempts]
        1     0    9738    0.0       0.0      88.0       1     0 0             6   7
        2     1    4922    0.0       0.0     100.0       1     0 0             1   1
        5.5   2    1858    0.0       0.0       0.0       2     0 0             0   0
       11     3     982    0.0       0.0       0.0       4     0 0             0   0
        6     4    1648    4.8       4.8     100.0       3     0 0            10   10
   DP   9     5    1112    7.3       7.3     100.0       4     0 0             1   1
       12     6     844    0.0       0.0       0.0       5     0 0             0   0
  C    18     7     576   14.6       9.7      67.2       5     0 0             3   5
       24     8     440   19.5       7.3      32.9       6     1 6             8   25
 B     36     9     308   26.8      12.2      40.7       6     0 0             8   25
A      48    10     240   36.6      19.5      51.0       6     2 7           149   280
       54    11     216    0.0       0.0       0.0       6     0 2             0   4

Total packet count::    ideal 166      lookaround 19

Any help is appreciated.

Regards,
Paulo

Start a tcpdump on the access point, verify if you see all the packets sent, if you send back replies, and the response times.

I don't have enough free space on powerline connector (PLC) to install tcpdump (or the mini version for that matter). So I'm pinging from a device (connected via wire) to the shelly:

$ ping 192.168.144.9
PING 192.168.144.9 (192.168.144.9): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 192.168.144.9: icmp_seq=4 ttl=255 time=2.891 ms
64 bytes from 192.168.144.9: icmp_seq=5 ttl=255 time=3.669 ms
64 bytes from 192.168.144.9: icmp_seq=6 ttl=255 time=2.363 ms
64 bytes from 192.168.144.9: icmp_seq=7 ttl=255 time=7.981 ms
64 bytes from 192.168.144.9: icmp_seq=8 ttl=255 time=7.145 ms
64 bytes from 192.168.144.9: icmp_seq=9 ttl=255 time=2.331 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
64 bytes from 192.168.144.9: icmp_seq=12 ttl=255 time=2.361 ms
64 bytes from 192.168.144.9: icmp_seq=13 ttl=255 time=2.958 ms
64 bytes from 192.168.144.9: icmp_seq=14 ttl=255 time=2.200 ms
64 bytes from 192.168.144.9: icmp_seq=15 ttl=255 time=3.450 ms
64 bytes from 192.168.144.9: icmp_seq=16 ttl=255 time=3.937 ms
64 bytes from 192.168.144.9: icmp_seq=17 ttl=255 time=1.903 ms
64 bytes from 192.168.144.9: icmp_seq=18 ttl=255 time=2.675 ms
64 bytes from 192.168.144.9: icmp_seq=19 ttl=255 time=3.002 ms
64 bytes from 192.168.144.9: icmp_seq=20 ttl=255 time=3.942 ms
^C
--- 192.168.144.9 ping statistics ---
21 packets transmitted, 15 packets received, 28.6% packet loss
round-trip min/avg/max/stddev = 1.903/3.521/7.981/1.704 ms
$ sudo tcpdump -i en0 icmp and host 192.168.144.9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:26:17.689468 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 0, length 64
15:26:18.694361 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 1, length 64
15:26:19.695280 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 2, length 64
15:26:20.696652 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 3, length 64
15:26:21.697971 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 4, length 64
15:26:21.700657 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 4, length 64
15:26:22.701896 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 5, length 64
15:26:22.705428 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 5, length 64
15:26:23.706092 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 6, length 64
15:26:23.708198 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 6, length 64
15:26:24.709641 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 7, length 64
15:26:24.717383 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 7, length 64
15:26:25.709975 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 8, length 64
15:26:25.717016 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 8, length 64
15:26:26.715227 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 9, length 64
15:26:26.717347 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 9, length 64
15:26:27.718769 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 10, length 64
15:26:28.720156 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 11, length 64
15:26:29.721524 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 12, length 64
15:26:29.723698 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 12, length 64
15:26:30.725195 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 13, length 64
15:26:30.727896 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 13, length 64
15:26:31.729302 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 14, length 64
15:26:31.731319 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 14, length 64
15:26:32.732731 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 15, length 64
15:26:32.735997 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 15, length 64
15:26:33.737433 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 16, length 64
15:26:33.741132 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 16, length 64
15:26:34.742555 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 17, length 64
15:26:34.744247 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 17, length 64
15:26:35.745669 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 18, length 64
15:26:35.748157 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 18, length 64
15:26:36.749571 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 19, length 64
15:26:36.752377 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 19, length 64
15:26:37.753820 IP 192.168.144.3 > shelly1-500291f089ed.home: ICMP echo request, id 62481, seq 20, length 64
15:26:37.757552 IP shelly1-500291f089ed.home > 192.168.144.3: ICMP echo reply, id 62481, seq 20, length 64

You can see a bunch of imp request that did not get a reply. Not sure what else I can make of this data.

Not much you can extract from that, since ping and tcpdump is running on the same side.

But that will always be the case no? I can't run anything on the Shelly, so even if I figure out a way to install tcpdump on the PLC, I'll be pinging and dumping on the same side right?

Can't you ping from the PLC?

I can yes, but I can't run tcpdump on the Shelly. What I can do is ping from the PLC to my Mac via WiFi:

$ sudo tcpdump  -n -i en1 icmp and host 192.168.144.252
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:44:44.211909 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 0, length 64
16:44:44.215228 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 0, length 64
16:44:45.252987 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 1, length 64
16:44:45.253056 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 1, length 64
16:44:46.254803 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 2, length 64
16:44:46.254869 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 2, length 64
16:44:47.278590 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 3, length 64
16:44:47.278641 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 3, length 64
16:44:48.310137 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 4, length 64
16:44:48.310214 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 4, length 64
16:44:49.326383 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 5, length 64
16:44:49.326452 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 5, length 64
16:44:50.150900 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 6, length 64
16:44:50.150969 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 6, length 64
16:44:51.170370 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 7, length 64
16:44:51.170435 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 7, length 64
16:44:52.193868 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 8, length 64
16:44:52.193947 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 8, length 64
16:44:53.222322 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 9, length 64
16:44:53.222388 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 9, length 64
16:44:54.241875 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 10, length 64
16:44:54.241949 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 10, length 64
16:44:55.267518 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 11, length 64
16:44:55.267583 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 11, length 64
16:44:56.290404 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 12, length 64
16:44:56.290470 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 12, length 64
16:44:57.314571 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 13, length 64
16:44:57.314647 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 13, length 64
16:44:58.133127 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 14, length 64
16:44:58.133206 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 14, length 64
16:44:59.161756 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 15, length 64
16:44:59.161821 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 15, length 64
16:45:00.180272 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 16, length 64
16:45:00.180319 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 16, length 64
16:45:01.205028 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 17, length 64
16:45:01.205106 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 17, length 64
16:45:02.233906 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 18, length 64
16:45:02.233974 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 18, length 64
16:45:03.253060 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 19, length 64
16:45:03.253129 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 19, length 64
16:45:04.277179 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 20, length 64
16:45:04.277237 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 20, length 64
16:45:05.322609 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 21, length 64
16:45:05.322686 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 21, length 64
16:45:06.325824 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 22, length 64
16:45:06.325891 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 22, length 64
16:45:07.145179 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 23, length 64
16:45:07.145266 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 23, length 64
16:45:08.172993 IP 192.168.144.252 > 192.168.144.93: ICMP echo request, id 7897, seq 24, length 64
16:45:08.173054 IP 192.168.144.93 > 192.168.144.252: ICMP echo reply, id 7897, seq 24, length 64
root@OpenWrt:~# ping -c 90 192.168.144.93
PING 192.168.144.93 (192.168.144.93): 56 data bytes
64 bytes from 192.168.144.93: seq=0 ttl=64 time=103.662 ms
64 bytes from 192.168.144.93: seq=1 ttl=64 time=153.478 ms
64 bytes from 192.168.144.93: seq=2 ttl=64 time=142.726 ms
64 bytes from 192.168.144.93: seq=3 ttl=64 time=166.303 ms
64 bytes from 192.168.144.93: seq=4 ttl=64 time=199.909 ms
64 bytes from 192.168.144.93: seq=5 ttl=64 time=213.869 ms
64 bytes from 192.168.144.93: seq=6 ttl=64 time=38.032 ms
64 bytes from 192.168.144.93: seq=7 ttl=64 time=57.369 ms
64 bytes from 192.168.144.93: seq=8 ttl=64 time=80.663 ms
64 bytes from 192.168.144.93: seq=9 ttl=64 time=108.865 ms
64 bytes from 192.168.144.93: seq=10 ttl=64 time=128.677 ms
64 bytes from 192.168.144.93: seq=11 ttl=64 time=153.657 ms
64 bytes from 192.168.144.93: seq=12 ttl=64 time=176.352 ms
64 bytes from 192.168.144.93: seq=13 ttl=64 time=200.344 ms
64 bytes from 192.168.144.93: seq=14 ttl=64 time=18.694 ms
64 bytes from 192.168.144.93: seq=15 ttl=64 time=47.163 ms
64 bytes from 192.168.144.93: seq=16 ttl=64 time=65.432 ms
64 bytes from 192.168.144.93: seq=17 ttl=64 time=90.504 ms
64 bytes from 192.168.144.93: seq=18 ttl=64 time=118.696 ms
64 bytes from 192.168.144.93: seq=19 ttl=64 time=137.657 ms
64 bytes from 192.168.144.93: seq=20 ttl=64 time=161.587 ms
64 bytes from 192.168.144.93: seq=21 ttl=64 time=206.840 ms
64 bytes from 192.168.144.93: seq=22 ttl=64 time=210.547 ms
64 bytes from 192.168.144.93: seq=23 ttl=64 time=29.024 ms
64 bytes from 192.168.144.93: seq=24 ttl=64 time=56.615 ms
^C
--- 192.168.144.93 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max = 18.694/122.666/213.869 ms

There's no packet loss, although that latency seems very high (I don't get that high latency when pinging the shelly).

ubus call system board ?

# ubus call system board
{
	"kernel": "5.4.74",
	"hostname": "OpenWrt",
	"system": "Qualcomm Atheros QCA956X ver 1 rev 0",
	"model": "TP-Link WPA8630P v2.0 (EU)",
	"board_name": "tplink,tl-wpa8630p-v2.0-eu",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"revision": "r14868-dd651e54cc",
		"target": "ath79/generic",
		"description": "OpenWrt SNAPSHOT r14868-dd651e54cc"
	}
}

I might also try and sniff the wifi from my Mac while the PLC pings the Shelly. Not sure if I'll be successful, since I need to be able to get my Mac's wifi in monitor mode and get Wireshark to decrypt the packets. Will try later today.

Edit: Just remembered the issue also happens with an open network. I'll try sniffing with no encryption. Should be easier.

For what it's worth, since the device is still not supported in stable version, there can always be some issues.

It shouldn't make any difference as long as the mac is connected to the access point with the key.

I don't think not using a stable version is related. The issue was present even before installing OpenWRT. That was one of the reasons I wanted to install OpenWRT in the first place, so I could get some more options to try and fix the issue.

I've did my sniffing while the PLC (192.168.144.252) was pinging the Shelly (192.168.144.9):

--- 192.168.144.9 ping statistics ---
50 packets transmitted, 29 packets received, 42% packet loss
round-trip min/avg/max = 1.573/3.898/9.488 ms

And here is the sniff filtered by ip.addr == 192.168.144.9 (the shelly).

90	1.190512	192.168.144.9	224.0.0.251	MDNS	486	Standard query response 0x0000 PTR shelly1-500291F089ED._http._tcp.local SRV, cache flush 0 0 80 shelly1-500291F089ED.local TXT, cache flush A, cache flush 192.168.144.9 NSEC, cache flush shelly1-500291F089ED.local
92	1.194882	192.168.144.9	224.0.0.251	MDNS	486	Standard query response 0x0000 PTR shelly1-500291F089ED._http._tcp.local SRV, cache flush 0 0 80 shelly1-500291F089ED.local TXT, cache flush A, cache flush 192.168.144.9 NSEC, cache flush shelly1-500291F089ED.local
267	4.627660	192.168.144.3	192.168.144.9	TCP	125	49720 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=397018169 TSecr=0 SACK_PERM=1
268	4.628999	192.168.144.3	192.168.144.9	TCP	125	[TCP Out-Of-Order] 49720 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=397018169 TSecr=0 SACK_PERM=1
270	4.630623	192.168.144.9	192.168.144.3	TCP	109	80 → 49720 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 SACK_PERM=1
271	4.630680	192.168.144.9	192.168.144.3	TCP	109	[TCP Out-Of-Order] 80 → 49720 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 SACK_PERM=1
272	4.631621	192.168.144.9	192.168.144.3	TCP	109	[TCP Out-Of-Order] 80 → 49720 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 SACK_PERM=1
274	4.632875	192.168.144.3	192.168.144.9	TCP	107	49720 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0
276	4.633225	192.168.144.3	192.168.144.9	HTTP	493	GET /status HTTP/1.1 
277	4.633582	192.168.144.3	192.168.144.9	TCP	493	[TCP Retransmission] 49720 → 80 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=392
282	4.680503	192.168.144.9	192.168.144.3	TCP	637	80 → 49720 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536 [TCP segment of a reassembled PDU]
284	4.681275	192.168.144.3	192.168.144.9	TCP	107	49720 → 80 [ACK] Seq=393 Ack=537 Win=65535 Len=0
285	4.682826	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 284#1] 49720 → 80 [ACK] Seq=393 Ack=537 Win=65535 Len=0
286	4.683575	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 284#2] 49720 → 80 [ACK] Seq=393 Ack=537 Win=65535 Len=0
288	4.686350	192.168.144.9	192.168.144.3	HTTP/JSON	429	HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
290	4.687003	192.168.144.3	192.168.144.9	TCP	107	49720 → 80 [ACK] Seq=393 Ack=865 Win=65535 Len=0
291	4.689037	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 290#1] 49720 → 80 [ACK] Seq=393 Ack=865 Win=65535 Len=0
292	4.690231	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 290#2] 49720 → 80 [ACK] Seq=393 Ack=865 Win=65535 Len=0
294	4.690275	192.168.144.3	192.168.144.9	TCP	107	49720 → 80 [FIN, ACK] Seq=393 Ack=865 Win=65535 Len=0
296	4.691829	192.168.144.9	192.168.144.3	TCP	101	80 → 49720 [ACK] Seq=865 Ack=394 Win=1751 Len=0
298	4.692084	192.168.144.9	192.168.144.3	TCP	101	[TCP Dup ACK 296#1] 80 → 49720 [ACK] Seq=865 Ack=394 Win=1751 Len=0
299	4.692866	192.168.144.9	192.168.144.3	TCP	101	[TCP Dup ACK 296#2] 80 → 49720 [ACK] Seq=865 Ack=394 Win=1751 Len=0
305	4.701931	192.168.144.9	192.168.144.3	TCP	101	[TCP Dup ACK 296#3] 80 → 49720 [ACK] Seq=865 Ack=394 Win=1751 Len=0
307	4.702443	192.168.144.9	192.168.144.3	TCP	101	80 → 49720 [FIN, ACK] Seq=865 Ack=394 Win=1751 Len=0
309	4.703204	192.168.144.3	192.168.144.9	TCP	107	49720 → 80 [ACK] Seq=394 Ack=866 Win=65535 Len=0
310	4.703769	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 309#1] 49720 → 80 [ACK] Seq=394 Ack=866 Win=65535 Len=0
312	4.707824	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 309#2] 49720 → 80 [ACK] Seq=394 Ack=866 Win=65535 Len=0
368	5.963839	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=0/0, ttl=64 (reply in 375)
375	5.967554	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=0/0, ttl=255 (request in 368)
424	6.963816	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=1/256, ttl=64 (reply in 426)
426	6.965039	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=1/256, ttl=255 (request in 424)
468	7.960033	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=2/512, ttl=64 (no response found!)
469	7.961409	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=2/512, ttl=64 (reply in 471)
471	7.962604	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=2/512, ttl=255 (request in 469)
479	8.049918	192.168.144.9	192.168.144.3	TCP	109	63507 → 2001 [SYN] Seq=0 Win=2144 Len=0 MSS=536 SACK_PERM=1
481	8.062402	192.168.144.3	192.168.144.9	TCP	107	2001 → 63507 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
498	8.387168	192.168.144.9	192.168.144.254	DNS	123	Standard query 0xa300 A api.shelly.cloud
500	8.390446	192.168.144.254	192.168.144.9	DNS	139	Standard query response 0xa300 A api.shelly.cloud A 23.251.142.183
502	8.393559	192.168.144.9	23.251.142.183	TCP	109	50560 → 80 [SYN] Seq=0 Win=2144 Len=0 MSS=536 SACK_PERM=1
505	8.425866	23.251.142.183	192.168.144.9	TCP	109	80 → 50560 [SYN, ACK] Seq=0 Ack=1 Win=28400 Len=0 MSS=1420 SACK_PERM=1
507	8.427449	192.168.144.9	23.251.142.183	TCP	101	50560 → 80 [ACK] Seq=1 Ack=1 Win=2144 Len=0
513	8.434763	192.168.144.9	23.251.142.183	HTTP	255	GET /files/firmware?type=SHSW-1&device=shelly1-500291F089ED&fw=20210115-102904%2fv1.9.4%40e2732e05 HTTP/1.1 
516	8.466905	23.251.142.183	192.168.144.9	TCP	107	80 → 50560 [ACK] Seq=1 Ack=155 Win=28944 Len=0
523	8.631830	23.251.142.183	192.168.144.9	TCP	637	80 → 50560 [ACK] Seq=1 Ack=155 Win=28944 Len=536 [TCP segment of a reassembled PDU]
524	8.632797	23.251.142.183	192.168.144.9	TCP	637	[TCP Retransmission] 80 → 50560 [ACK] Seq=1 Ack=155 Win=28944 Len=536
528	8.637602	192.168.144.9	23.251.142.183	TCP	101	[TCP ACKed unseen segment] 50560 → 80 [ACK] Seq=155 Ack=615 Win=1530 Len=0
530	8.643591	192.168.144.9	23.251.142.183	TCP	101	[TCP Window Update] [TCP ACKed unseen segment] 50560 → 80 [ACK] Seq=155 Ack=615 Win=2144 Len=0
532	8.643793	192.168.144.9	23.251.142.183	TCP	101	[TCP Dup ACK 528#1] [TCP ACKed unseen segment] 50560 → 80 [ACK] Seq=155 Ack=615 Win=2144 Len=0
534	8.644039	192.168.144.9	23.251.142.183	TCP	101	[TCP ACKed unseen segment] 50560 → 80 [FIN, ACK] Seq=155 Ack=615 Win=2144 Len=0
535	8.644334	192.168.144.9	23.251.142.183	TCP	101	[TCP ACKed unseen segment] [TCP Out-Of-Order] 50560 → 80 [FIN, ACK] Seq=155 Ack=615 Win=2144 Len=0
536	8.644677	192.168.144.9	23.251.142.183	TCP	101	[TCP ACKed unseen segment] [TCP Out-Of-Order] 50560 → 80 [FIN, ACK] Seq=155 Ack=615 Win=2144 Len=0
539	8.677839	23.251.142.183	192.168.144.9	TCP	107	[TCP Previous segment not captured] 80 → 50560 [FIN, ACK] Seq=615 Ack=156 Win=28944 Len=0
541	8.679414	192.168.144.9	23.251.142.183	TCP	101	[TCP ACKed unseen segment] 50560 → 80 [ACK] Seq=156 Ack=616 Win=2143 Len=0
557	8.959580	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=3/768, ttl=64 (reply in 559)
559	8.960593	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=3/768, ttl=255 (request in 557)
586	9.641183	192.168.144.3	192.168.144.9	TCP	125	49721 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=397023155 TSecr=0 SACK_PERM=1
588	9.642543	192.168.144.9	192.168.144.3	TCP	109	80 → 49721 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 SACK_PERM=1
589	9.642851	192.168.144.9	192.168.144.3	TCP	109	[TCP Out-Of-Order] 80 → 49721 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 SACK_PERM=1
592	9.656575	192.168.144.3	192.168.144.9	TCP	107	49721 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0
595	9.660977	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 592#1] 49721 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0
597	9.662746	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 592#2] 49721 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0
599	9.663310	192.168.144.3	192.168.144.9	HTTP	493	GET /status HTTP/1.1 
600	9.663960	192.168.144.3	192.168.144.9	TCP	493	[TCP Retransmission] 49721 → 80 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=392
601	9.665377	192.168.144.3	192.168.144.9	TCP	493	[TCP Retransmission] 49721 → 80 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=392
604	9.717130	192.168.144.9	192.168.144.3	TCP	637	80 → 49721 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536 [TCP segment of a reassembled PDU]
605	9.717519	192.168.144.9	192.168.144.3	TCP	637	[TCP Retransmission] 80 → 49721 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536
606	9.718155	192.168.144.9	192.168.144.3	TCP	637	[TCP Retransmission] 80 → 49721 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536
612	9.725016	192.168.144.9	192.168.144.3	TCP	637	[TCP Retransmission] 80 → 49721 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536
615	9.728279	192.168.144.3	192.168.144.9	TCP	107	49721 → 80 [ACK] Seq=393 Ack=537 Win=65535 Len=0
616	9.729200	192.168.144.3	192.168.144.9	TCP	107	[TCP Dup ACK 615#1] 49721 → 80 [ACK] Seq=393 Ack=537 Win=65535 Len=0
618	9.732100	192.168.144.9	192.168.144.3	HTTP/JSON	457	HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
619	9.732460	192.168.144.9	192.168.144.3	TCP	457	[TCP Retransmission] 80 → 49721 [PSH, ACK] Seq=537 Ack=393 Win=1752 Len=356
620	9.732904	192.168.144.9	192.168.144.3	TCP	457	[TCP Retransmission] 80 → 49721 [PSH, ACK] Seq=537 Ack=393 Win=1752 Len=356
626	9.741117	192.168.144.9	192.168.144.3	TCP	457	[TCP Retransmission] 80 → 49721 [PSH, ACK] Seq=537 Ack=393 Win=1752 Len=356
628	9.742486	192.168.144.3	192.168.144.9	TCP	107	49721 → 80 [ACK] Seq=393 Ack=893 Win=65535 Len=0
630	9.744878	192.168.144.9	192.168.144.3	TCP	101	80 → 49721 [FIN, ACK] Seq=893 Ack=393 Win=1752 Len=0
631	9.745283	192.168.144.9	192.168.144.3	TCP	101	[TCP Out-Of-Order] 80 → 49721 [FIN, ACK] Seq=893 Ack=393 Win=1752 Len=0
632	9.746004	192.168.144.9	192.168.144.3	TCP	101	[TCP Out-Of-Order] 80 → 49721 [FIN, ACK] Seq=893 Ack=393 Win=1752 Len=0
637	9.750992	192.168.144.3	192.168.144.9	TCP	107	49721 → 80 [FIN, ACK] Seq=393 Ack=893 Win=65535 Len=0
638	9.752772	192.168.144.3	192.168.144.9	TCP	107	[TCP Out-Of-Order] 49721 → 80 [FIN, ACK] Seq=393 Ack=893 Win=65535 Len=0
644	9.766269	192.168.144.9	192.168.144.3	TCP	101	[TCP Retransmission] 80 → 49721 [FIN, ACK] Seq=893 Ack=393 Win=1752 Len=0
646	9.766763	192.168.144.9	192.168.144.3	TCP	101	80 → 49721 [ACK] Seq=894 Ack=394 Win=1751 Len=0
648	9.767061	192.168.144.3	192.168.144.9	TCP	107	[TCP Retransmission] 49721 → 80 [FIN, ACK] Seq=393 Ack=894 Win=65535 Len=0
650	9.768289	192.168.144.9	192.168.144.3	TCP	101	[TCP Dup ACK 646#1] 80 → 49721 [ACK] Seq=894 Ack=394 Win=1751 Len=0
660	9.962310	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=4/1024, ttl=64 (reply in 662)
662	9.963391	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=4/1024, ttl=255 (request in 660)
670	10.049484	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47424, Unknown 30, /cit/s
671	10.049601	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47424, Unknown 30, /cit/s
672	10.050492	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47424, Unknown 30, /cit/s
674	10.052516	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47424, Unknown 30, /cit/s
677	10.053336	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47424, Unknown 30, /cit/s
679	10.056401	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47424, Unknown 30, /cit/s
1191	20.965361	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=15/3840, ttl=64 (reply in 1193)
1193	20.966061	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=15/3840, ttl=255 (request in 1191)
1239	21.963049	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=16/4096, ttl=64 (no response found!)
1240	21.965138	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=16/4096, ttl=64 (no response found!)
1241	21.966253	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=16/4096, ttl=64 (no response found!)
1242	21.966883	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=16/4096, ttl=64 (reply in 1244)
1244	21.967903	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=16/4096, ttl=255 (request in 1242)
1292	22.966596	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=17/4352, ttl=64 (reply in 1294)
1294	22.967513	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=17/4352, ttl=255 (request in 1292)
1356	23.963600	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=18/4608, ttl=64 (no response found!)
1357	23.964074	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=18/4608, ttl=64 (reply in 1364)
1364	23.970920	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=18/4608, ttl=255 (request in 1357)
1414	24.963852	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=19/4864, ttl=64 (no response found!)
1415	24.964150	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=19/4864, ttl=64 (reply in 1417)
1417	24.965202	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=19/4864, ttl=255 (request in 1415)
1421	25.067123	192.168.144.9	224.0.1.187	UDP	195	38496 → 10132 [BAD UDP LENGTH 3442 > IP PAYLOAD LENGTH] Len=3434
1423	25.069110	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47425, Unknown 30, /cit/s
1424	25.072518	192.168.144.9	224.0.1.187	CoAP	195	NON, MID:47425, Unknown 30, /cit/s
1498	26.035633	192.168.144.9	192.168.144.3	TCP	109	61600 → 2001 [SYN] Seq=0 Win=2144 Len=0 MSS=536 SACK_PERM=1
1500	26.036465	192.168.144.3	192.168.144.9	TCP	107	2001 → 61600 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
1547	26.967636	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=21/5376, ttl=64 (reply in 1549)
1549	26.968777	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=21/5376, ttl=255 (request in 1547)
1550	26.968815	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=21/5376, ttl=255
1551	26.969245	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=21/5376, ttl=255
1616	27.964571	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=22/5632, ttl=64 (no response found!)
1618	27.965502	192.168.144.9	192.168.192.77	ICMP	145	Unknown ICMP (obsolete or malformed?)
1670	28.966742	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=23/5888, ttl=64 (reply in 1673)
1672	28.967715	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x8b80, seq=52237/3532, ttl=255
1673	28.967992	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=23/5888, ttl=255 (request in 1670)
1674	28.968580	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=23/5888, ttl=255
1726	29.965297	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=24/6144, ttl=64 (reply in 1728)
1728	29.966197	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=24/6144, ttl=255 (request in 1726)
1791	30.965614	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=25/6400, ttl=64 (no response found!)
1792	30.965990	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=25/6400, ttl=64 (no response found!)
1794	30.966993	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x890d, seq=18513/20808, ttl=255
1795	30.967125	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x9e59, seq=33895/26500, ttl=255
1840	31.965671	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=26/6656, ttl=64 (reply in 1842)
1842	31.966589	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=26/6656, ttl=255 (request in 1840)
1887	32.966189	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=27/6912, ttl=64 (no response found!)
1944	33.666129	192.168.144.3	192.168.144.9	TCP	125	49722 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=397047149 TSecr=0 SACK_PERM=1
1947	33.667823	192.168.144.9	192.168.144.3	TCP	109	80 → 49722 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 SACK_PERM=1
1949	33.668681	192.168.144.3	192.168.144.9	TCP	107	49722 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0
1951	33.669291	192.168.144.3	192.168.144.9	HTTP	493	GET /status HTTP/1.1 
1955	33.717879	192.168.144.9	192.168.144.3	TCP	637	80 → 49722 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536 [TCP segment of a reassembled PDU]
1956	33.718324	192.168.144.9	192.168.144.3	TCP	637	[TCP Retransmission] 80 → 49722 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536
1957	33.718722	192.168.144.9	192.168.144.3	TCP	637	[TCP Retransmission] 80 → 49722 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536
1959	33.719647	192.168.144.3	192.168.144.9	TCP	107	49722 → 80 [ACK] Seq=393 Ack=537 Win=65535 Len=0
1965	33.733058	192.168.144.9	192.168.144.3	HTTP/JSON	457	HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
1967	33.735782	192.168.144.3	192.168.144.9	TCP	107	49722 → 80 [ACK] Seq=393 Ack=893 Win=65535 Len=0
1969	33.736648	192.168.144.3	192.168.144.9	TCP	107	49722 → 80 [FIN, ACK] Seq=393 Ack=893 Win=65535 Len=0
1971	33.737633	192.168.144.9	192.168.144.3	TCP	101	[TCP Port numbers reused] 80 → 49722 [SYN, RST, PSH, URG, ECN] Seq=7448 Win=17596 Urg=52233[Malformed Packet]
1973	33.738985	192.168.144.9	192.168.144.3	TCP	101	80 → 49722 [FIN, ACK] Seq=1 Ack=1 Win=1751 Len=0
1975	33.739601	192.168.144.3	192.168.144.9	TCP	107	[TCP ACKed unseen segment] 49722 → 80 [ACK] Seq=394 Ack=894 Win=65535 Len=0
1993	33.966139	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=28/7168, ttl=64 (reply in 1995)
1995	33.967185	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=28/7168, ttl=255 (request in 1993)
1996	33.967402	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=28/7168, ttl=255
2038	34.636070	192.168.144.3	192.168.144.9	TCP	125	49723 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=397048113 TSecr=0 SACK_PERM=1
2040	34.637576	192.168.144.9	192.168.144.3	TCP	109	80 → 49723 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 SACK_PERM=1
2042	34.639099	192.168.144.3	192.168.144.9	TCP	107	49723 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0
2044	34.639612	192.168.144.3	192.168.144.9	HTTP	493	GET /status HTTP/1.1 
2049	34.687038	192.168.144.9	192.248.1.142	TCP	637	80 → 49723 [PSH, ACK] Seq=1 Ack=1 Win=1752 Len=536 [TCP segment of a reassembled PDU]
2050	34.687165	192.168.144.9	192.168.144.3	TCP	637	80 → 49723 [PSH, ACK] Seq=1 Ack=393 Win=1752 Len=536 [TCP segment of a reassembled PDU]
2052	34.688009	192.168.144.3	192.168.144.9	TCP	107	49723 → 80 [ACK] Seq=393 Ack=537 Win=65535 Len=0
2054	34.690306	192.168.144.9	192.168.144.3	TCP	457	80 → 49723 [PSH, ACK] Seq=537 Ack=393 Win=1752 Len=356 [TCP segment of a reassembled PDU]
2056	34.691123	192.168.144.3	192.168.144.9	TCP	107	49723 → 80 [ACK] Seq=393 Ack=893 Win=65535 Len=0
2058	34.691466	192.168.144.3	192.168.144.9	TCP	107	49723 → 80 [FIN, ACK] Seq=393 Ack=893 Win=65535 Len=0
2060	34.692855	192.168.144.9	192.168.144.3	TCP	101	80 → 49723 [ACK] Seq=893 Ack=394 Win=1751 Len=0
2061	34.693255	192.168.144.9	192.168.144.3	TCP	101	[TCP Dup ACK 2060#1] 80 → 49723 [ACK] Seq=893 Ack=394 Win=1751 Len=0
2063	34.694217	192.168.144.9	192.168.144.3	HTTP/JSON	101	HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
2065	34.695115	192.168.144.3	192.168.144.9	TCP	107	49723 → 80 [ACK] Seq=394 Ack=894 Win=65535 Len=0
2078	34.966475	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=29/7424, ttl=64 (no response found!)
2079	34.966485	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=29/7424, ttl=64 (no response found!)
2080	34.966744	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=29/7424, ttl=64 (no response found!)
2081	34.967419	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=29/7424, ttl=64 (reply in 2084)
2084	34.968571	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=29/7424, ttl=255 (request in 2081)
2085	34.969426	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=29/7424, ttl=255
2142	35.967214	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=30/7680, ttl=64 (no response found!)
2145	35.968649	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x3dd4, seq=30/7680, ttl=255
2204	36.966979	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=31/7936, ttl=64 (no response found!)
2205	36.967547	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=31/7936, ttl=64 (no response found!)
2206	36.968307	192.168.144.252	192.168.144.9	ICMP	145	Echo (ping) request  id=0x09d4, seq=31/7936, ttl=64 (reply in 2208)
2208	36.969306	192.168.144.9	192.168.144.252	ICMP	145	Echo (ping) reply    id=0x09d4, seq=31/7936, ttl=255 (request in 2206)

And I've uploaded the entire .cap file here.

Now the very high pings I noticed while pinging my Mac via WiFi, although there was no packet loss, is also very strange. I'm starting to think the 2.4 Ghz radio on this unit is simply defective. Pinging the same Mac connected to the 5Ghz radio produces sub-second pings and also no packet loss.

PS: Shellies can't use 5ghz WiFi, only 2.4.

Judging by the amount of retransmissions and packet loss there is maybe some interference in the 2,4GHz band.
Have you scanned the channels to verify that?

1 Like

Is it WiFi or Powerline?

  • Where is the WiFi config for the OpenWrt?
  • I'm still trying to understand how powerline is involved here
  • If there is powerline, is everything on the same circuit?

It sounds like a powerline wifi combo device with wifi AP and a powerline backhaul to somewhere else (presumably a router)

2 Likes

Indeed the PLC is one of those that has WiFi and Ethernet ports. The "Powerline" component should have no influence here. Here's a diagram:

router <-ethernet-> plc1 <-powerline-> plc2 (OpenWRT) <-wifi-> shellies

When I'm testing, my Mac is always connected via wire to PLC2 to make sure the powerline segment is not involved in any way.

The config is:

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ahb/18100000.wmac'
	option channel 'auto'
	option htmode 'HT20'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option wmm '0'
	option ssid 'Garage1011'
	option encryption 'none'
	option disassoc_low_ack '0'

Currently I have encryption set to none while testing.

Here's a scan of the WiFi signals the device is detecting:

Signal		SSID		Channel	Mode	BSSID	Encryption	
 -52 dBm	TP-Link_9354	1	Master	70:4F:57:A6:93:54	mixed WPA/WPA2 PSK (CCMP)	
 -68 dBm	NOS-B0CB		11	Master	7C:DB:98:CB:B0:CB	WPA2 PSK (CCMP)	
 -79 dBm	Vodafone-9119EF	7	Master	48:D5:39:91:19:F8	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -79 dBm	GatoAzul		11	Master	00:06:91:EA:97:00	WPA2 PSK (CCMP)	
 -80 dBm	MEO-WiFi		11	Master	00:06:91:EA:97:02	None	
 -81 dBm	Luna&Zyna		1	Master	00:06:91:80:85:20	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -82 dBm	MEO-WiFi		1	Master	00:06:91:80:85:22	None	
 -83 dBm	VistaEscritorio	7	Master	8C:BE:BE:31:60:02	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -86 dBm	NOS_Wi-Fi_Hotspots	5	Master	00:05:CA:CD:22:79	None	
 -86 dBm	ZON-2270		5	Master	00:05:CA:CD:22:78	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -86 dBm	TP-Link_D162	10	Master	D8:0D:17:89:D1:62	mixed WPA/WPA2 PSK (CCMP)	
 -86 dBm	NOS-4EA5		11	Master	44:34:A7:0A:4E:A5	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -86 dBm	Vodafone-F4EB5B	11	Master	A4:B1:E9:F4:EB:5B	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -87 dBm	NOS-2563		1	Master	7C:DB:98:C9:25:63	WPA2 PSK (CCMP)	
 -87 dBm	COSY ROOMS		11	Master	00:06:91:A7:04:10	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -87 dBm	MEO-WiFi		11	Master	00:06:91:A7:04:12	None	
 -88 dBm	MEO-8564C0		1	Master	00:06:91:85:64:C0	mixed WPA/WPA2 PSK (TKIP, CCMP)	
 -88 dBm	MEO-WiFi		1	Master	00:06:91:85:64:C2	None	
 -88 dBm	PS4-BAE9CAA8D8D9	6	Master	B0:05:94:4B:7B:B9	WPA2 PSK (CCMP)	
 -88 dBm	NOS-34C8		10	Master	08:B0:55:01:34:C8	WPA2 PSK (CCMP)	
 -89 dBm	Bem Vindos Amigos	9	Master	A0:F4:79:BE:56:39	mixed WPA/WPA2 PSK (TKIP, CCMP)

Btw, PLC2 is in my garage (if that wasn't clear by the SSID :wink: ) and I only have one outlet there. But I'll bring an extension and try to move it somewhere else to see if that improves anything.

What channel is it choosing? My understanding was OpenWrt used to simply always choose the lowest available channel so auto was equivalent to 1 which has a super strong interfering signal.

I recommend you manually choose channel 6 and get your neighbor to stop using channel 7 and switch to 6 if possible :slight_smile:

1 Like

So… here's an update on this saga. I tried all the suggestions and then some.

Then I dusted off a very old router I had and tried connecting the shellies there. I set it up as a bridge and set the WiFi to the same config I had on the PLC:

router <-ethernet-> plc1 <-powerline-> plc2 (OpenWRT) <-ethernet-> Old Router <- wifi -> shellies

The problem persists. Finally, I tried just disconnecting the "Old Router" router from my home network and the problem is gone… My Mac is still connected to the Old Router's WiFi and so is the shelly. I don't have internet access (obviously) but I can still ping it. And it's super stable (around 2.5ms) and no packet loss after 100 pings.

So right now I'm thinking there's absolutely nothing wrong with the WiFi after all. There must be something on my network that's "hurting" the shellies in a way that they start dropping packets. Since these are such small IoT devices there's either too much traffic[^1] causing buffers to overflow or maxing their CPUs.

Right now, I've no idea where to start regarding debugging this. I'm so frustrated that I'm not thinking clearly. Suggestions are very welcome!

[^1]: I don't think this is the case since I sniffed the WiFi previously and nothing jumped at me.

Could you have too much multicast traffic? Wifi sends multicast at low rates and can starve the available airtime.

So I sniffed the network again, looking specifically at multicast/broadcast traffic. Although there's some traffic there (mDNS, COAP, ARP, etc) Nothing that I'd consider harmful.

I ended up putting all my IoT devices in the garage in a separate VLAN. Luckily I'm using a Synology NAS to control these devices that's connected via wire to the PLC. So I just made sure that ethernet port on the PLC is tagged on both VLANs ("home" and "IoT") and configured the device accordingly. This way the Synology has a "foot" in both VLANs and can serve as a bridge.

Pings are now super stable, and switching the IoT devices on or off feels instantaneous.

I still have no ideia what traffic was causing the shellies to drop packets. But the problem is solved!

1 Like