Is it enough to block outbound dns

[atv2016]

Is it enough to block dns outbound anywhere (internet and local) to stop it from communicating and going into zombie mode?

[crazikPL]

For me: SP-111 works with internet access. After disabling NAT and blocking local DNS access - stopped working.

But P1 Power Strip - works in both configurations.

Both vendors - Gosund.

[shtrom]

FWIW, it seems that you need to DROP packets, rather than REJECT them.

[vinhdizzo]

FWIW, it seems that you need to DROP packets, rather than REJECT them.

What tools are folks using to "block" or "drop" packets/requests instead of "reject"? I have AdGuard installed as a plugin in Home Assistant, and when I tried localtuya about a year ago, the devices stopped working. I'd like to give this another shot since the README suggests that things are resolved now.

Thanks!

[shtrom]

On Sat 08 Jan 2022 at 21:38:17 -0800, Vinh Nguyen wrote:

FWIW, it seems that you need to DROP packets, rather than REJECT them. What tools are folks using to "block" or "drop" packets/requests instead of "reject"? I have AdGuard installed as a plugin in Home Assistant, and when I tried localtuya about a year ago, the devices stopped working. I'd like to give this another shot since the README suggests that things are resolved now.

I DROP/REJECT the light bulbs' packets to the Internet directly in the router firewall.

-- Olivier Mehani @.***> PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted.

[vinhdizzo]

I DROP/REJECT the light bulbs' packets to the Internet directly in the router firewall.

@shtrom Would you be able to post a screenshot? I'd like to replicate your work. Doing this doesn't lead the devices into a zombie mode? Thanks.

[shtrom]

How to do it would depend on your router. I have a Mikrotik device, running routerOS. I created a list of (one) local IP address of Tuya devices, and specific rules to DROP traffic between any device in this list, and the WAN, as well as any DNS traffic to the router (TCP/UDP port 53)

[admin@router] > /ip firewall address-list print where name=Tuya                                                 
Flags: X - disabled, D - dynamic 
 #   LIST                                                         ADDRESS                                                                           CREATION-TIME        TIMEOUT              
 0   Tuya                                                         192.168.110.196                                                                   nov/04/2021 22:09:59 
[admin@router] > /ip firewall filter print where action=drop       
Flags: X - disabled, I - invalid, D - dynamic 
[...]
 2    ;;; Block WAN traffic and DNS from Tuya devices
      chain=forward action=drop src-address-list=Tuya out-interface-list=WAN log=no log-prefix="tuya out" 
 3    chain=forward action=drop dst-address-list=Tuya in-interface-list=WAN log=no log-prefix="tuya in" 
 4    chain=input action=drop protocol=tcp src-address-list=Tuya port=53 log=no log-prefix="tuya dns tcp" 
 5    chain=input action=drop protocol=udp src-address-list=Tuya port=53 log=no log-prefix="tuya dns udp" 

[shtrom]

I think this is sufficient to avoid Zombie mode. I'm not 100% as I'm still running my own patched version of localtuya https://github.com/shtrom/localtuya, which I don't think is needed, but as it ain't broke...

Another thing that I noticed, and that I mentioned before, is that despite the DNS block, the globe seemed to be able to resolve some IP addresses and keep trying to connect to them for a few days after the block was in place. As long as the device did this, it remained in zombie mode. Since then, this behaviour stopped, and the globe has been reliably working with localtuya and no Internet access.

[vinhdizzo]

Thanks @shtrom . Doesn't look like my TP-Link router has this feature :( Need to shop for a new router

[atv2016]

@shtrom What is different about your fork?

So in summary in order to successfully separate any tuya light i need to: -Block (drop) all in and outbound traffic by dropping it to the tuya ip address (i can get from iot tuya). -Also block (drop) all dns traffic? That seems redundant as per the first ?

I guess if it's still trying to access something it must be hardcoded in the firmware to still go to some addresses.

Last stupid question (to which i guess i already know the answer), once i put in these blocks, i cannot use the tuya app anymore right ? At least not for the devices that i blocked. I find the app quite handy sometimes but i guess i can't have everything, i can use the HA app instead which would be a fine tradeoff.

Thanks all. PS how do you all find the state sensors updating? With IOT it's horrendous, is it instant with local tuya? Like when a device is switched off/on?

[shtrom]

@shtrom What is different about your fork?

It's just merging a few PRs from around here, to test if the dezombification worked any better.

So in summary in order to successfully separate any tuya light i need to: -Block (drop) all in and outbound traffic by dropping it to the tuya ip address (i can get from iot tuya). -Also block (drop) all dns traffic? That seems redundant as per the first ?

All traffic to/from the Internet is blocked, but also to the local DNS running on the server, otherwise, the devices can resolve the Tuya cloud's address, but cannot then reach it because of the other block. This is what seems to be triggering the zombie mode.

I guess if it's still trying to access something it must be hardcoded in the firmware to still go to some addresses.

Yes, but it stops after a while, so I suspect a multi-day cache in flash somewhere.

Last stupid question (to which i guess i already know the answer), once i put in these blocks, i cannot use the tuya app anymore right ? At least not for the devices that i blocked. I find the app quite handy sometimes but i guess i can't have everything, i can use the HA app instead which would be a fine tradeoff.

Yeah, nah. That wouldn't work. I'd say it's the whole point of using localtuya. Otherwise there's a Tuya integration that talks to their cloud system. But I like my lights to keep turning off and on even if there is an outage in us-east-1.

Thanks all. PS how do you all find the state sensors updating? With IOT it's horrendous, is it instant with local tuya? Like when a device is switched off/on?

It's pretty quick. Couple of seconds, max.

[atv2016]

So i did this in the asus router. Must be a better way, can't imagine for such a good router this is the only way to do it but ok. Should this do the trick? Outbound for dns to router blocked and the default route blocked as well.

[atv2016]

So far the original tuya entities are still updating their state, so clearly something is not working yet :-)

[shtrom]

Can you put all the devices on a separate wlan/subnet, and block the whole range? Something like a (very limited) guest network. -- Olivier Mehani @.***> Sent from my mobile, please excuse my brevity.

[atv2016]

@shtrom Ugh that would be a lot of reconfiguring. What if i don't block, obviously i would be dependent on the cloud but would localtuya still be faster? Because i just realised that alexa is also dependent on the tuya skill which means i couldn't easily use voice control for lights in room anymore.

[shtrom]

You could remove the block and test.

That said, IMO, the whole point of localtuya is to be able to segregate devices away from the internet.

I'm not sure about the reactivity. In my quick early tests, the Tuya cloud might have been very slightly slower. I'm not sure this would be worth the hassle of bypassing it if it's still available and functional. -- Olivier Mehani @.***> Sent from my mobile, please excuse my brevity.

[atv2016]

Cheers, good points.

[hiagocosta]

sorry for opening this issue again, but I think that the whole point of blocking connections, is for avoid lost pairing of tuya devices on your tuya app account too, that changes the local key everytime you re-pair the device.

I have some tuya devices (light bulbs) that lost pairing time to time, needing to pair to the app and take on tuya iot site the new local key to use inside home assistant, whats is a bit annoying...

Am I right?

[daxcore]

I think this is sufficient to avoid Zombie mode. I'm not 100% as I'm still running my own patched version of localtuya https://github.com/shtrom/localtuya, which I don't think is needed, but as it ain't broke...

Another thing that I noticed, and that I mentioned before, is that despite the DNS block, the globe seemed to be able to resolve some IP addresses and keep trying to connect to them for a few days after the block was in place. As long as the device did this, it remained in zombie mode. Since then, this behaviour stopped, and the globe has been reliably working with localtuya and no Internet access.

wow this fix seems to work pretty well... why we shouldn't reintegrate this to upstream?

[shtrom]

There's been additional work on master to address the issue. I've been back on it for a while with no unsolvable zombie.

Every now and then, I still need to force recreate the DPs, but it works fine otherwise. -- Olivier Mehani @.***> Sent from my mobile, please excuse my brevity.

[daxcore]

i guess this is fixed with version 5 now.

only my tuya bulb can't reached automatically if it was powerless.