Closed OToussaint closed 1 year ago
This feels to me like a network issue, especially with the From 192.168.0.100 icmp_seq=2 Redirect Host(New nexthop: 192.168.0.44)
and 9 packets transmitted, 8 received, +1 errors, 11.1111% packet loss
. Is the RPi on the same network as the device? Is there a firewall in there somewhere?
Yes, the 2 devices are in the same network, there is no firewall in between.
The reason why From 192.168.0.100 icmp_seq=2 Redirect Host(New nexthop: 192.168.0.44)
is because the RPi is hosting Pi-Hole and it was looping to itself, so I added a route especially for the tuya device, maybe it is wrong, and it is the cause of the issue (192.168.0.100 is my gateway, my internet box)
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.100 0.0.0.0 UG 600 0 0 wlan0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
192.168.0.44 192.168.0.100 255.255.255.255 UGH 0 0 0 wlan0
As a consequence, there is always 1 packet drop, it is the one redirecting to 192.168.0.100. Without the route, I was not even able to ping the device. All packets were dropped.
If it really is on the same network then it should not be going to/through a gateway. ip route add 192.168.0.44/32 dev wlan0
would be the way to tell it it's directly attached, however that feels like a band-aid; the better question is: why is it looping? AFAIK Pi-hole is not a transparent firewall/proxy, so how/why are packets getting looped back to it?
Ok, I removed the route. It was still working and tinytuya was working too, until it failed again. But I think I found the reason, the tuya plug is advertising itself with the name of my wlan interface, and not the name in the Smart Life App weirdly enough. My Ubuntu is not using wifi, only a lan interface.
arp | grep fc:67:1f:cb:12:58
wlan0.lan ether fc:67:1f:cb:12:58 C wlan0
I edited the /etc/hosts file and added
192.168.0.44 ab3961c448d2979e55sean
And it is working now.
And it failed again. The plug is back in my arp table as wlan0.lan and ping is not working. Again.
nslookup 192.168.0.44
44.0.168.192.in-addr.arpa name = wlan0.lan.
I can ping any other devices
pi@hassbian:/usr/bin $ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=51.6 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=54.6 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=8.64 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=32.5 ms
^C
--- 192.168.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 8.642/36.814/54.578/18.343 ms
But not the tuya plug
pi@hassbian:/usr/bin $ ping 192.168.0.44
PING 192.168.0.44 (192.168.0.44) 56(84) bytes of data.
^C
--- 192.168.0.44 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8339ms
Running a tshark while ping is like that
pi@hassbian:/home/pi $ sudo tshark -i wlan0 -f "host 192.168.0.44" -f "icmp"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
1 0.000000000 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=6/1536, ttl=64
2 1.040043499 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=7/1792, ttl=64
3 2.080053454 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=8/2048, ttl=64
4 3.120040125 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=9/2304, ttl=64
5 4.160030649 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=10/2560, ttl=64
6 5.200063827 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=11/2816, ttl=64
7 6.240062420 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=12/3072, ttl=64
8 7.280055125 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=13/3328, ttl=64
9 8.320066109 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=14/3584, ttl=64
10 9.360099540 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request id=0x1a61, seq=15/3840, ttl=64
Request, no reply. There is absolutely no firewall, from my ubuntu, the ping is no issue
olivier@olivier-ubuntu:~$ ping 192.168.0.44
PING 192.168.0.44 (192.168.0.44) 56(84) bytes of data.
64 octets de 192.168.0.44 : icmp_seq=1 ttl=255 temps=42.5 ms
64 octets de 192.168.0.44 : icmp_seq=2 ttl=255 temps=261 ms
64 octets de 192.168.0.44 : icmp_seq=3 ttl=255 temps=98.1 ms
64 octets de 192.168.0.44 : icmp_seq=4 ttl=255 temps=99.5 ms
64 octets de 192.168.0.44 : icmp_seq=5 ttl=255 temps=25.6 ms
64 octets de 192.168.0.44 : icmp_seq=6 ttl=255 temps=33.4 ms
64 octets de 192.168.0.44 : icmp_seq=7 ttl=255 temps=75.9 ms
^C
--- statistiques ping 192.168.0.44 ---
7 paquets transmis, 7 reçus, 0 % paquets perdus, temps 6011 ms
rtt min/moy/max/mdev = 25,610/90,896/261,282/74,920 ms
Thanks for sharing all these details @OToussaint . I have several RPi's of different hardware versions and OS, and have never seen this issue. You could try to disable PiHole and see if that is what is poisoning your arp:
# Disable Pi-hole for 30 seconds
pihole disable 10m
# Or more drastic
sudo systemctl stop pihole-FTL
sudo systemctl disable pihole-FTL
I would also try to hardwire to the network (if not already) to see if that makes a difference. If not, I would just re-image the Pi (new SD) and see if it is a hardware issue vs config issue.
No, no change, not even with a brand new SD Card. My work-around, working for 14 hours now, is awful:
I'd like a real solution but I'm hopeless.
P.S.: I realise that it is not a tinytuya issue anymore. Sorry about that.
Hi @OToussaint , I can understand the frustration. It still seems like this is an issue with the RPi configuration if your ubuntu host works. What OS are you using on your RPi? For my working units, I'm using Debian version: 11 (bullseye)
here: https://www.raspberrypi.com/software/operating-systems/
The same, Debian 11 (bullseye)
uname -a
Linux hassbian 5.15.84-v7+ #1613 SMP Thu Jan 5 11:59:48 GMT 2023 armv7l GNU/Linux
pi@hassbian:~ $ hostnamectl
Static hostname: hassbian
Icon name: computer
Machine ID: 880c5857b62e440f9bf62c65361b7f13
Boot ID: 8c0e3d95002d4298adb951eea80cad2d
Operating System: Raspbian GNU/Linux 11 (bullseye)
Kernel: Linux 5.15.84-v7+
Architecture: arm
For now, my terrible workaround is working ...
Well, at least, congrats on getting the workaround to work! Unfortunately, I have no ideas or other suggestions for you.
Issue with the workaround is that if ping is skipped, I might go back to step 1: recreate the route, and everything after. In theory, I could do a script with
ip route add 192.168.0.44 via 192.168.0.100 dev wlan0
ping -c 10 192.168.0.44
ip route del 192.168.0.44 via 192.168.0.100 dev wlan0
ping -c 10 192.168.0.44
cron with root every minute but seems like overkill.
Let me close that issue here, I'll try to find help in the appropriate forum. Thank you for your help.
Good luck, @OToussaint ! It will probably be a simple thing on your network or setup that will be easy to fix once you finally sort it. If you find it, please report back in case someone is following your steps. 🙏
Posted on SuperUser for a few days but everyone is struggling as much as I do ...
Hello,
I'm facing a weird beaviour and I'm pretty sure that I missed something. Running the command
python -m tinytuya scan
on my Ubuntu machine is fine (but the machine is not up 24/7)olivier@olivier-ubuntu:~$ python3 -m tinytuya scan
Running the same from my RPi (which is up 24/7), it fails (tinytuya) pi@hassbian:/etc/tinytuya $ python -m tinytuya scan
What I already did:
Connection closed by foreign host.
(tinytuya) pi@hassbian:/etc/tinytuya $ python Python 3.11.2 (main, Mar 4 2023, 12:59:45) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information.