search

Somfy-Developer / Somfy-TaHoma-Developer-Mode

A collection of requests to use a local API with Somfy TaHoma gateways
147 stars 12 forks source link

curl: (7) Failed to connect to gateway-{pin}.local port 8443: Connection refused #71

Closed Michdo93 closed 8 months ago

Michdo93 commented 2 years ago

Hi,

I tried to access my local gateway but this does not work. Hope you can help me.

At first I activated the Developer made. Then I created my token using Postman. Here is the Postman Collection.

The gateway is on 192.168.0.37. I can ping it:

ping gateway-{pin}.local
PING gateway-{pin}.local (192.168.0.37) 56(84) bytes of data.
64 bytes from 192.168.0.37 (192.168.0.37): icmp_seq=1 ttl=64 time=0.268 ms
64 bytes from 192.168.0.37 (192.168.0.37): icmp_seq=2 ttl=64 time=0.289 ms
64 bytes from 192.168.0.37 (192.168.0.37): icmp_seq=3 ttl=64 time=0.265 ms
64 bytes from 192.168.0.37 (192.168.0.37): icmp_seq=4 ttl=64 time=0.269 ms

Then I tried nmap:

nmap gateway-{pin}.local
Starting Nmap 7.80 ( https://nmap.org ) at 2022-10-28 15:01 CEST
Nmap scan report for gateway-{pin}.local (192.168.0.37)
Host is up (0.0046s latency).
All 1000 scanned ports on gateway-{pin}.local (192.168.0.37) are closed

Nmap done: 1 IP address (1 host up) scanned in 0.56 seconds

In the cloud, you will see that the developer mode is enabled. However, I don't seem to have a port running on my TaHoma box.

So I want to try to use curl:

curl -X 'GET' 'https://gateway-{pin}.local:8443/enduser-mobile-web/1/enduserAPI/apiVersion' -H 'accept: application/json' -H "Authorization: Bearer {token}"

It does not work. I also can try it without the port 8443. Same result.

I will get the error:

curl: (7) Failed to connect to gateway-{pin}.local port 8443: Connection refused

What can I do? Thanks in advance.

Bolebo commented 2 years ago

Hello,

I have the exact same problem. Developer mode is activated, a token has been created but when I try to access the API, I have Connection Refused.

I can ping my Tahoma Box, but the 8443 port is not opened.

What should I do ?

Regards.

JanJaapKo commented 2 years ago

Try it with leaving the "gateway-" part out. so:

curl -X 'GET' 'https://{pin}.local:8443/enduser-mobile-web/1/enduserAPI/apiVersion' -H 'accept: application/json' -H "Authorization: Bearer {token}"

Michdo93 commented 2 years ago

Try it with leaving the "gateway-" part out. so:

curl -X 'GET' 'https://{pin}.local:8443/enduser-mobile-web/1/enduserAPI/apiVersion' -H 'accept: application/json' -H "Authorization: Bearer {token}"

Well, that this could not be the right solution you should also see above. If I try it, I will receive 'curl: (6) Could not resolve host:'.

If you look above 'ping gateway-{pin}.local' will work. So leaving out the gateway part is not right. The host name can be resolved.

If I use the ip address instead I will receive:

curl -X 'GET' 'https://192.168.0.37:8443/enduser-mobile-web/1/enduserAPI/apiVersion' -H 'accept
: application/json' -H "Authorization: Bearer {token}"
curl: (7) Failed to connect to 192.168.0.37 port 8443: Connection refused
JanJaapKo commented 2 years ago

I do not have a Somfy box or whatever, but I've made the plugin for Domoticz based on testwork of others. They indicated that this is the way to get it to work. Although they were adding it to there hosts file (see setup instructions).

Coko7 commented 1 year ago

After changing my internet router, I seem to be experiencing the same problem, even though it worked fine before. I have confirmed that the gateway is connected to my router and I can ping its IP, however, I can't ping it using gateway-{pin}.local. Also, the hostname of the gateway given by my router does not match the full gateway PIN. It's only a truncated version.

tomcomwinter commented 1 year ago

I too get a connection refused error when trying to access an internal API. All API calls to generate the Token and activate it were successful, also was able to ping the gateway-{pin}.local successfully. Any luck anyone?

Coko7 commented 1 year ago

@Tomcomwinter I have also tried posting on the forums to see if I get any farther with this problem. I will keep you updated if I find anything. Also, It seems Somfy will perform a maintenance to update Tahoma boxes today (I have seen a message on the forum website: https://forum.somfy.fr/) As I live in France, this maintenance might only apply to France, not sure.

tomcomwinter commented 1 year ago

Thanks! I hope the box update will open the ports.

On Tue, 11 Apr 2023 at 11:28 Coko @.***> wrote:

@Tomcomwinter https://github.com/Tomcomwinter I have also tried posting on the forums to see if I get any father with this problem. I will keep you updated if I find anything. Also, It seems Somfy will perform a maintenance to update Tahoma boxes today (I have seen a message on the forum website: https://forum.somfy.fr/) As I live in France, this maintenance might only apply to France, not sure.

— Reply to this email directly, view it on GitHub https://github.com/Somfy-Developer/Somfy-TaHoma-Developer-Mode/issues/71#issuecomment-1502902936, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5BGAEYLJIPLQBCBQX4PVZ3XAUIZBANCNFSM6AAAAAARRB3KPI . You are receiving this because you were mentioned.Message ID: @.*** com>

Eridani78 commented 1 year ago

@Coko7 I live in France. My device is a Somfy TaHoma box.

I encounter the same problem. The authentication is in place and everything works fine, I got a valid token. But, despite two long days of investigations, I cannot connect to my gateway. (In the following, my gateway pin is here replaced by 1234-1234-1234).

I was running TaHoma box firmware fw_version=2022.7.4-11. Today I installed the box firmware update and the firmware version is now fw_version=2023.1.4-7.

When I launch: sudo avahi-browse -art | less

the result is: = eth0 IPv4 gateway-1234-1234-1234 _kizboxdev._tcp local hostname = [gateway-1234-1234-1234.local] address = [192.168.1.180] port = [8443] txt = ["fw_version=2023.1.4-7" "gateway_pin=1234-1234-1234" "api_version=1"]

It seems that everything is correct and DNS is correctly resolved. But when I launch: sudo curl -X 'GET' 'https://1234-1234-1234.local:8443/enduser-mobile-web/1/enduserAPI/apiVersion' -H 'accept: application/json' the result is still: curl: (7) Failed to connect to 1234-1234-1234.local port 8443: Connection refused

I don't know what is going wrong. As we are very few users to raise this issue here, I suspect I am doing something incorrect but I wonder what ? Everything to help would be welcome ...

Coko7 commented 1 year ago

@Coko7 I live in France. My device is a Somfy TaHoma box.

I encounter the same problem. The authentication is in place and everything works fine, I got a valid token. But, despite two long days of investigations, I cannot connect to my gateway. (In the following, my gateway pin is here replaced by 1234-1234-1234).

I was running TaHoma box firmware fw_version=2022.7.4-11. Today I installed the box firmware update and the firmware version is now fw_version=2023.1.4-7.

When I launch: sudo avahi-browse -art | less

the result is: = eth0 IPv4 gateway-1234-1234-1234 _kizboxdev._tcp local hostname = [gateway-1234-1234-1234.local] address = [192.168.1.180] port = [8443] txt = ["fw_version=2023.1.4-7" "gateway_pin=1234-1234-1234" "api_version=1"]

It seems that everything is correct and DNS is correctly resolved. But when I launch: sudo curl -X 'GET' 'https://1234-1234-1234.local:8443/enduser-mobile-web/1/enduserAPI/apiVersion' -H 'accept: application/json' the result is still: curl: (7) Failed to connect to 1234-1234-1234.local port 8443: Connection refused

I don't know what is going wrong. As we are very few users to raise this issue here, I suspect I am doing something incorrect but I wonder what ? Everything to help would be welcome ...

Okay, I have just updated my TaHoma box and tried again. I still can't figure out whatever is going with the hostname, but I tried the API using ip addr directly and now this works (it did not work before): curl --insecure https://192.168.1.42:8443/enduser-mobile-web/1/enduserAPI/apiVersion -H "Authorization: Bearer XXXXX"

And I get the following answer from the API: {"protocolVersion":"2023.1.4-7"}

Did you try curl with IP instead @Eridani78 ?

Eridani78 commented 1 year ago

@Coko7 Thanks for your message.

Before update, using the IP address was not working for me either. Now, using the IP address on the curl bash command do not return an error anymore. but I am normally using a PHP routine using cURL and it is still not working (despite the SSL_VERIFYPEER option to false). Furthermore, I have to investigate ...

Your message is very usefull and bring one step further. Did you noticed that with the apiVersion request, the Authorization Bearer is normally not necessary ? Is it also working with a request using the Authorization Bearer ?

Thanks again

Coko7 commented 1 year ago

@Eridani78 Glad I could help a little.

Yes, you are right, the token is unneeded for API version.

Little update on my side: I managed to make it work using hostname. At first, it would only work when I tried accessing the API by hostname through my browser. I could curl the API using IP, but not hostname. I think the reason why it did not work using curl was because of my own configuration (I am using WSL atm and I had some VPN service still running).

Now, it seems to be working when I use curl with the hostname.

If it still does not work with hostname, try these different options:

In my particular case, I know that .local does not work, and I have always used .home to connect using hostname. I have had trouble in the past figuring this out, and I don't think this is documented anywhere in the docs.

Eridani78 commented 1 year ago

@Coko7 Thanks again for your comments. It is always very useful to know that it is working somewhere and as a consequence, the problem is a local configuration problem. I have to find out what is blocking me in my configuration to succeed to connect using the hostname. May be we keep in touch. Have a nice day.

Coko7 commented 1 year ago

Just wanted to say that everything is back to normal on my side. I have no more problem connecting to the API, and my Node.js automated script that connects to my TaHoma is working again.

This firmware update did solve the problem I was having in the end, and I am hoping that this very problem was fixed in the update and that it is not some weird bug that shows up from time to time.

For anyone who has yet to successfully query their local gateway API, here is what you can try:

  1. Make sure your device is running the latest firmware update (latest one was Apr 11, 2023 at the time I am writing this message)
  2. Ping your gateway by IP/hostname to make sure it is reachable on your LAN: 
    foo@bar:~$ ping 192.168.1.42 # or
foo@bar:~$ ping gateway-1111-2222-3333 # You may want to append the following suffix to your hostname: ".local" or ".home"
  3. Try a curl request or a browser request on the API (token not needed to get API version):

foo@bar:~$ curl -k "https://192.168.1.42:8443/enduser-mobile-web/1/enduserAPI/apiVersion" # using IP (did not work before but should work ever since the last update) foo@bar:~$ curl -k "https://gateway-1111-2222-3333.local:8443/enduser-mobile-web/1/enduserAPI/apiVersion" # using hostname (Using ".local" here but you may want to try without it or with ".home" instead)

I don't think port number can be changed, so make sure it is `8443` in your request.
If you are getting a response with the protocol version, then I believe everything else should work for you:
```json
{"protocolVersion":"2023.1.4-7"}

One last thing: I don't know if Somfy already does it, but it would be useful to have some kind of changelog for these firmware updates. The API itself has great capabilities, but it could benefit from some additional documentation, and again, having some kind of release notes for developers could help.

Eridani78 commented 1 year ago

@Coko7

Again, thanks a lot for your very beneficial information. Unfortunately for me and despite many tests and trials, I am still stucked and trying to address my gateway by any means lead always to the same message : curl: (7) Failed to connect to 1234-1234-1234.local port 8443: Connection refused

I suspect a bad configuration related to SSL security or reverse proxy configuration or DNS server configuration or Firewall configuration ???

What I do not understand is when I run the following nmap command: nmap 192.168.1.180 (gateway IP address is 192.168.1.180) The response is Starting Nmap 7.70 ( https://nmap.org ) at 2023-04-12 16:08 CEST Nmap scan report for 1234-1234-1234.local (192.168.1.180) Host is up (0.0032s latency). All 1000 scanned ports on 1234-1234-1234.local (192.168.1.180) are closed

If you perform the same operation on your network, could you please tell me if the nmap response indicates that all ports are closed or if port 8443 is available ?

Thanks in advance for your help.

My configuration

Coko7 commented 1 year ago

@Eridani78

I am sad to learn that you could not fix it on your end. I have just tried nmap on my gateway and I do get open ports:

foo@bar:~$ ping 192.168.1.42
Starting Nmap 7.80 ( https://nmap.org ) at 2023-04-12 17:13 CEST
Nmap scan report for gateway-1234-1234.home (192.168.1.42)
Host is up (0.0063s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
443/tcp  open  https
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 2.58 seconds

One weird thing I have noticed is that my gateway is reachable through gateway-1234-1234-1234.local (ping and curl both work) but when I run nmap, it says gateway-1234-1234.home which I believe is the name given by my network (it is missing the last 4 pin digits, no idea why). When I try to ping using the nmap hostname gateway-1234-1234.home, it does not say Name or service not known but this instead:

foo@bar:~$ ping gateway-1234-1234.home
PING gateway-1234-1234.home(gateway-1234-1234.home (00:25:96:FF:FE:12:34:56)) 56 data bytes
From pc-foobar.home (00:25:96:FF:FE:12:34:56) icmp_seq=1 Destination unreachable: Address unreachable
From pc-foobar.home (00:25:96:FF:FE:12:34:56) icmp_seq=2 Destination unreachable: Address unreachable
From pc-foobar.home (00:25:96:FF:FE:12:34:56) icmp_seq=3 Destination unreachable: Address unreachable
From pc-foobar.home (00:25:96:FF:FE:12:34:56) icmp_seq=4 Destination unreachable: Address unreachable

I still think that something is wrong with how my gateway is handled by my network, but it is working despite this issue. I don't get why my gateway has a hostname missing the last 4 pin digits, but can still be reachable using the full pin. Furthermore, I do not know much about networking, so if someone experienced can explain to me how this works, please do.

But back to you @Eridani78, it is weird that it does not show port 8443 or 443 as open, it should. This makes me think that this problem we are having has not been fixed by the firmware update, but instead appears randomly. It seems like sometimes ports 8443 and 443 are closed on the gateway, making its API unreachable, that's my guess. Did you try rebooting the gateway to see if anything changes?

Eridani78 commented 1 year ago

@Coko7

I tried many things including rebooting the Tahoma box but no success so far ...

So, concerning nmap command, your response showing that ports 443 & 8443 are open let me very questioning ? Of course, I would like to understand what is this situation in my network.

Regarding the truncated hostname in your nmap response, it is very strange too. Mine is as expected (1234-1234-1234.local) and it is a good point. Is your provider box a Livebox ? For your information, I tried to declare the Tahoma hostname in the DNS section of the Livebox to associate it with the IP address. I have noticed that I can not declare 1234-1234-1234 as when I click to save, the hostname is truncated to 1234-1234 ??? Also, on my side, I have never seen the .home but only the .local for hostname extension.

So the question remains for me: "Why are all the port of my Tahoma gateway closed ???"

If somebody can help ?

Coko7 commented 1 year ago

@Eridani78 This seems to be broken on my end, I haven't touched my script at all, but yesterday evening it could not access the API because the hostname did not resolve to the gateway, and today it works, but I haven't changed anything (neither in the network nor the name of my gateway)

You mentioned you had a livebox 5. I have also changed mine recently, and now I have the same livebox. At the beginning, I mentioned that this issue with my TaHoma gateway started happening right after I installed my new livebox.

I have tried using ping and nmap on a combination of hostnames, and I am lead to believe that this problem is caused by how the hostname of the gateway is resolved. I am still investigating this, my goal is to understand why that truncating problem happens on the network. Is it the livebox endlessly renaming the gateway for no reason? But why then?

Now that I think about it, when you used nmap on your gateway by specifying its IP directly, you could not see the open ports, which leads me to believe that you are getting a different problem than mine. My problem seems to be one with hostnames, but yours simply seems to be that ports are closed on your gateway (and you may suffer from the hostname problem as well).

Coko7 commented 1 year ago

I have made some more research, and there seems to be an issue with the hyphen/dash character "-" in hostname/DNS names in the newest livebox 5. If I head over to the admin interface of my livebox and try to save the hostname of my TaHoma a bunch of times, it removes the last -1234 each time I save. So if I input the full gateway-1234-1234-1234, when I save, it removes the last one. Try it and tell me if it happens on yours as well. If you try setting gateway-1234-1234-1234-1234, it will save it to gateway-1234-1234-1234. I went to the Orange forum and searched for a bit, and it seems that those hyphen "-" are a recurring problem:

It's not the same thing described in the messages on the forum, but they seem to have a similar problem, and it seems renaming their network and removing the hyphen in the name fixed it. I do have a hyphen in my network name, is it the same for you @Eridani78 ?

Eridani78 commented 1 year ago

Hi @Coko7

I confirm working with an Orange Livebox 5. For your information, just notice that I will be unavailable during a few days and I cannot help during this period.

But just for now: These discussions around the issues caused by hypen are very interesting. But if I am not wrong, the name of the Livebox is mainly the SSID name(s) of the WiFi. Yes, my SSID names do include hypen. This is something I will care about later when I come back. So far, I am working on my network over ethernet connections so I don't know if it can be related ?

Regarding the DNS configuration in the Livebox, I had the same behavior as when I tried to enter '1234-1234-1234' as a hostname, it removes the last '-1234'. Finally, I let this field empty for the moment.

So the last thing is when I launch: nmap -p- IPaddress or nmap -p- gatewayhostname which check ALL the ports of the gateway, I have the response:

Starting Nmap 7.70 ( https://nmap.org/ ) at 2023-04-13 10:48 CEST Nmap scan report for 1234-1234-1234.local (192.168.1.180) Host is up (0.0013s latency). Not shown: 65534 closed ports PORT STATE SERVICE 32xxx/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 5.92 seconds

which for me conclude that the port 8443 is definitively NOT OPEN in my TaHoma Box. Is it a firmware configuration issue in my TaHoma Box ??? Is my TaHoma Box hardware not compatible with this new functionality ???

Eridani78 commented 1 year ago

Hi @Coko7

Here is the follow-up ... After reseting ma TaHoma Box using the Reset button at the rear panel, I finally solved my problem. My ports 443 and 8443 are now open and I can succeed to send an https request.

tomcomwinter commented 1 year ago

Great update @Eridani78!

I'm still receiving the connection refused error, but it got me thinking if we're using the same device. I'm trying to integrate with a Tahoma Box, not a Tahoma switch. I don't have a reset button in the back. So I just want to confirm we're working on the same hardware. The firmware version I have is: 2023.1.4-9. image

Thanks!

Eridani78 commented 1 year ago

Hi @Tomcomwinter

I operate the same TaHoma box. I do confirm that there is a reset button (tiny hole) at the back of the box. Please, follow Somfy instructions on internet to perform the reset operation. After reset, personal settings are downloaded back to the box from the Somfy server. The current firmware version is 2023.1.4-9

For me, this solved the issue.

maschiach commented 1 year ago

@Eridani78

Hi @Tomcomwinter

I operate the same TaHoma box. I do confirm that there is a reset button (tiny hole) at the back of the box. Please, follow Somfy instructions on internet to perform the reset operation. After reset, personal settings are downloaded back to the box from the Somfy server. The current firmware version is 2023.1.4-9

For me, this solved the issue.

Thank you very much! I have had the exactly same issue with the closed ports resulting in a "connection refused". The reset (or better "resynchronisation") according to this video https://www.youtube.com/watch?v=CY0phXUOS8s did the trick. After having an additional restart, the resynchronisation took ~5-10min enabling a succesfull connection. Now its working with the Openhab 3.4.3 Somfy Tahoma Binding in "Developer Mode" 👍

tomcomwinter commented 1 year ago

Unfortunately I'm still have the issue (connection refused) I "resynced" the Tahoma box and still receive the connection refused error. I'm thinking maybe I'm not resyncing it right (I don't understand french) but I'm assuming the following (much is obvious):

  1. Disconnect from power source
  2. Press 'RST' button and hold (Is there a minimum amount of time)
  3. Reconnect power source
  4. Wait up to 15m

The tahoma comes back online but still with connection refused. I also attempted applying another restart (no reset) with no luck.

I'm curious whether I'm missing something.

Thank you

maschiach commented 1 year ago

@Tomcomwinter Important is that the RST button is pressed and hold continuously while reconnecting the power source (Step 2 and 3). After it is powered on and the internet connection successfully established (white LED) it takes about ~10min updating the box. You can check this process in the Somfy App or the Somfy web application, where there should be a popup message showing "Box updating" (or similar).

tomcomwinter commented 1 year ago

Thank you @maschiach for the quick response! I performed the reset at you guided, and saw the red light fade in and out (in different from how it worked for me until now), so I assume it did reset, but I'm still being refused.. Sorry for the step by step questions - is there an amount of time the Reset button should be held when connecting the power source? Running nmap also returns that all ports are ignored - conn-refused.

Thanks!

llavorel-somfy commented 1 year ago

Hi @Tomcomwinter Your product is facing a certificate issue, what is quite unexpected. I will let you know when it is fixed.

tomcomwinter commented 1 year ago

Hi,

Thanks for your reply! Is this fix specific to my box or is it a broader fix that will be rolled out? Would you happen to know when we should expect the fix?

Thank you!

-- Tom

On 7 Jul 2023 at 12:10:14, llavorel-somfy @.***> wrote:

Hi @Tomcomwinter https://github.com/Tomcomwinter Your product is facing a certificate issue, what is quite unexpected. I will let you know when it is fixed.

— Reply to this email directly, view it on GitHub https://github.com/Somfy-Developer/Somfy-TaHoma-Developer-Mode/issues/71#issuecomment-1625104661, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5BGAE3Q7PSW4UKR3YBEDWDXO7G7NANCNFSM6AAAAAARRB3KPI . You are receiving this because you were mentioned.Message ID: @.*** com>

Imaginous commented 1 year ago

I have the same issue with my Connexoon box running version 2023.3.4-5.

I also get connection refused. Somfy did a remote reset but it didn't help.

Any ideas?

llavorel-somfy commented 1 year ago

Hi @Tomcomwinter we have deployed new certificates. Would you be able to test again after rebooting your TaHoma ?

bobskee commented 11 months ago

My Connexoon gateway also refuses any local TCP connection. Developer mode is enabled and I am able to ping the device. Rebooting did not help. Any suggestions @llavorel-somfy ?

Beausoleil43600 commented 10 months ago

Similarly to your situation, I'm unable to connect locally. I have enabled the "developer" function, but when using nmap, I get the following result:

All 1000 scanned ports on 192.168.1.90 are in ignored states. Not shown: 1000 closed TCP ports (reset) MAC Address: F8:81:1A:03:85:DA (Overkiz)

With my PIN code 0805-0888-3872, I have tried your methods to connect locally, using the IP address and hostname, but to no avail. I don't understand. Could there be an issue with the Somfy box rather than my network?

EDIT: It’s OK, I have resolved my problem with a reinitialization of my Connexoon

bobskee commented 10 months ago

EDIT: It’s OK, I have resolved my problem with a reinitialization of my Connexoon

How did you manage to do that?

llavorel-somfy commented 9 months ago

Hi @bobskee

Have you succeeded to connect ?

bobskee commented 9 months ago

No, unfortunately nothing has changed. Any advice?

llavorel-somfy commented 9 months ago

Would you accept to share your gateway {pin} with me ?

bobskee commented 8 months ago

Would you accept to share your gateway {pin} with me ?

Sorry for my late reply. I think I missed the notification for it earlier. I do not mind sharing my gateway PIN with you but I do mind sharing it here publically. Is there another way I can contact you?

bobskee commented 8 months ago

Forcing a firmware reset (holding the RST while powering the Connexoon) seems to have fixed my issue. Now I can connect to the local API.