"apigw.tuyaeu.com" is not reachable from many ISPs from Czech Republic, please help.

[AnunnakiNibiru]

Hi.

It seems, that to many Internet Service Providers (ISP) from Czech Republic (Central European Region), corresponding TUYA API address "apigw.tuyaeu.com" is not reachable.

Translation: Name: apigw.tuyaeu.com, Addresses: 18.193.166.37, 3.123.196.97

Tracing route to apigw.tuyaeu.com [18.193.166.37] over a maximum of 30 hops:

... 3 <1 ms 1 ms 1 ms 10.102.223.161 4 1 ms 2 ms 81.201.48.7 5 1 ms 1 ms 2 ms klfree-vl3804.nfx.cz [78.108.106.6] 6 2 ms 2 ms 2 ms asr9904-vl3999-nfx2.nfx.cz [81.201.48.158] 7 1 ms 1 ms 1 ms nix4.amazon.com [91.210.16.120] 8 2 ms 2 ms 7 ms 52.93.43.122 9 5 ms 1 ms 3 ms 52.93.43.125 10 Request timed out. 11 Request timed out. 12 Request timed out. (rest the same)

Via TCPDUMP I see, that SYN packet get send, but nothing returns. Somewhere at "amazon" communication get dropped, from unknown reason. Therefore many (maby all?) users of TUYA integrations from CzechRepublic (maby others too) are not working at all.

I already contacted "Neutral czFree eXchange" (https://nfx.cz) which is used by many Czech ISP providers as peering center, and they confirmed the same problem.

Do you know anyone who can investigate this further, create incident ticket at TUYA for that "apigw.tuyaeu.com", and investigate, why that address is not responding at all for many Czech ISPs?

Thank you for any help or information, you can provide. Have a nice day

[AnunnakiNibiru]

From what I understand so far, the problem is on TUYA side somewhere in AMAZON EU services, where they (TUYA) have filter for that "apifw.tuyaeu.com" IP's, to drop communication's from other than Central European countries. And they are missing some subnets/IP ranges from many Czech Republic ISP's, and perhaps also from other countries (Germany, with 212.79.0.0 at least).

No, no one has contacted me, and I don't have any information about who is responsible for fixing that problem.

All my devices are TUYA (some WIFI, some ZigBee). For me, Home Assistant is not working with Tuya at all, so is lying on the shelf. Wasted money.

[AnunnakiNibiru]

Anyone, who thinks that TUYA API "apigw.tuyaeu.com" is "dead" and not responding at all, should try to investigate it more. Then you should create a ticket here: https://service.console.tuya.com/8/3/list?source=support_center (you need to register there, if you don't have account already) "New general ticket" >>> "Cloud Development" And in parallel, open a ticket with your internet connection provider (ISP), on the same issue.

Below are some useful commands (for Windows 11 users) in PowerShell, which you can run, and COPY and PASTE outputs from commands below to a TXT file, and upload that TXT file to the ticket. It can help them to investigate and hopefully even solve the problem.

If you already have "PowerShell 7.4.5" and "nMap 7.80" apps installed, go straight to the test commands.

This command will start the update of the "winget" installer and then all other applications. You can run it from "CMD" or "PowerShell" or maybe even other shells, which you have on your Windows: winget update --verbose --force --include-unknown --all

If you don't have "powershell" 7.4.5 installed, install it with the command: winget install --id "Microsoft.PowerShell"

If you don't have "nmap" 7.80 installed (we need nping tool from it), install it with the command winget install --id "Insecure.Nmap"

After installation completed, than you need to close "Command line" or "PowerShell" or "Terminal", and start "PowerShell" again. Start PowerShell 7.4.5

Test commands: suitable for testing the functionality of the connection to the TUYA API:

This command will attempt to connect to the API using an HTTP|HTTPS query: Invoke-WebRequest -Uri "https://apigw.tuyaeu.com" -UseBasicParsing -TimeoutSec 29 -Verbose

This command attempts to establish a TCP connection to the API: Test-NetConnection -ComputerName "apigw.tuyaeu.com" -Port 443 -InformationLevel "Detailed"

This command tries to use TTL decrement to determine which IP address in the path to the API will respond last: Test-NetConnection -ComputerName "apigw.tuyaeu.com" -TraceRoute -Hops 30 -InformationLevel "Detailed"

This command does the same thing as above, just with TCP on port 443: nping --tcp --dest-port 443 --traceroute "apigw.tuyaeu.com" -v2

Alternatively, you can share the output of at least "nping" command, and your public IP here, and I will attach it to my ticket to fix it.

[AnunnakiNibiru]

TUYA support closed my ticket. According to them, they don't see incoming traffic from my public IP address in the logs when trying to access "apigw.tuyaeu.com". They only see my communication with "openapi.tuyaeu.com", but it works normally.

When I switch to ISP Vodafone CR, the connection to "apigw.tuyaeu.com" works normally.

I don't know how much I can trust TUYA support, what did they actually check and where (they wanted me to test things that are clear to a technically knowledgeable person that they can't work, but maybe it was a mandatory automatic exercise, they also can't know what kind of "idiot" is bothering them, which i understand ). In any case, they confirmed to me twice that they checked it with them at the input in the log records.

At the moment I'm back in the starting position. I opened a new ticket with my ISP and asked him to check from his various public subnets whether it would work for him at least from some addresses or not, and then let him solve it further with his ISP/peering center. I hope that we will gradually figure out who is responsible for the malfunction.

It would be good for HomeAssistant, instead of writing a nonsensical message/error, to clearly state that the "apigw.tuyaeu.com" API is not communicating at all, and for the user to check the network connection and contact their ISP.

I will inform you about the further development of the situation.

[AnunnakiNibiru]

I asked them exactly the same thing. And they confirmed to me that they don't block anything anywhere. I also wanted to know what exactly they verified it on, just to be sure, but they couldn't tell me even that, not a single technical detail that I could rely on, so I had minor "doubts" about the detail and conclusion of their investigation. But I believe that they are experts in their field, and for now I have no choice but to trust them. Nevertheless, I opened the ticket again and asked where they were checking it and what if they provided some technical details, and I informed them that I was waiting (for the second time) to check the status with my ISP (and above).

The only alternative for me is to change public IP, change internet provider, or for IoT stuff pay for a dedicated public VPN/anonymizer (through which it works, but costs extra money every month).

[AnunnakiNibiru]

A second check through my ISP revealed a problem on some FW down the road where some CVE-related protection was enabled ( "https://access.redhat.com/security/vulnerabilities/tcpsack" ). After a modification on their end it works now. They also confirmed to me that it affected several public subnets. The problem is now solved. I am closing this ticket. Have a nice day.