Open
Cruzxia
opened this issue 8 months ago
•
17 comments
I have just updated my hardware to a PI5, running Node Red version 4.0.9 and the pi is running Debian GNU/Linux 12.
(The system was working well on Node Red version 3 software)
I can enter the user and password, then deploy. I can see the server connection flash every few seconds, but it won't connect.
I have tried the following:
using a different user account. (set it up tested and then deleted when it also did not work.)
Deleted and re installed the node-red-contrib-googlehome node.
Tried installing via the pi terminal, which gave some NPM warnings.
Something must have changed with either the latest version of Node red or when the moved to the version 12 of Debian.
There is not much more I can check on my end. Please see if you can find the issue.
NPM WARNINGS
pi5@raspberrypi:~/.node-red $ npm install node-red-contrib-googlehome
npm warn deprecated [email protected]: this library is no longer supported
npm warn deprecated [email protected]: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details.
npm warn deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm audit
3 moderate severity vulnerabilities
Some issues need review, and may require choosing
a different dependency.
Run npm audit for details.
pi5@raspberrypi:~/.node-red $ npm audit
# npm audit report
request *
Severity: moderate
Server-Side Request Forgery in Request - https://github.com/advisories/GHSA-p8p7-x288-28g6
Depends on vulnerable versions of tough-cookie
No fix available
node_modules/request
node-red-contrib-googlehome *
Depends on vulnerable versions of request
node_modules/node-red-contrib-googlehome
tough-cookie <4.1.3
Severity: moderate
tough-cookie Prototype Pollution vulnerability - https://github.com/advisories/GHSA-72xf-g2v4-qvf3
No fix available
node_modules/tough-cookie
3 moderate severity vulnerabilities
The logged errors imply you might have a network problem, it would be useful to see a longer section of logs, because the node is setup to try and connect on port 8883 and then 1883 and the entries you've shared show it trying on IPv4 and then IPv6 to connect to 8883 but nothing about trying 1883.
The MQTT broker that is the node uses to does listen on both ports, but the timeout errors implies that you may have a firewall dropping packets to those ports (If you are getting the list of devices in the node and can reach the website, then port 443 is still open)
The unreachable error implies that you do not have IPv6 setup on your local network.
In the diagnostic log, it try’s twice on 8883, the once on 1883 and then just keeps looping.
I set up HiveMQ today which also uses port 8883 and that worked without issue. So I think that port is not blocked.
I rebooted my old PI4 to test that my router and gateway were not blocking, and it connected to your server immediately without any issue.
Maybe something has changed in the latest version of Debian that is preventing it connection.
As far as I know, Port 8883 is TLS so perhaps it is some sort of certificate issue, considering I can use NSlookup with no issue.
I am a bit stuck as to what to try next. If we come up with a solution I will post it on the git hub page as I am sure you will get more inquiries about this problem.
Cheers
Andrew
From: Ben Hardill @.***
Sent: Saturday, 12 April 2025 5:13 PM
To: hardillb/node-red-contrib-googlehome
Cc: Cruzxia; Author
Subject: Re: [hardillb/node-red-contrib-googlehome] Cannot connect to server. (Issue #32)
The logged errors imply you might have a network problem, it would be useful to see a longer section of logs, because the node is setup to try and connect on port 8883 and then 1883 and the entries you've shared show it trying on IPv4 and then IPv6 to connect to 8883 but nothing about trying 1883.
The MQTT broker that is the node uses to does listen on both ports, but the timeout errors implies that you may have a firewall dropping packets to those ports (If you are getting the list of devices in the node and can reach the website, then port 443 is still open)
The unreachable error implies that you do not have IPv6 setup on your local network.
The logged errors imply you might have a network problem, it would be useful to see a longer section of logs, because the node is setup to try and connect on port 8883 and then 1883 and the entries you've shared show it trying on IPv4 and then IPv6 to connect to 8883 but nothing about trying 1883.
The MQTT broker that is the node uses to does listen on both ports, but the timeout errors implies that you may have a firewall dropping packets to those ports (If you are getting the list of devices in the node and can reach the website, then port 443 is still open)
The unreachable error implies that you do not have IPv6 setup on your local network.
It wouldn't be a timeout error if there was a certificate problem (the certs are issued by letsencrypt so should be trusted by pretty much everywhere) and are the same certs as used for the website.
The nslookup is just checking that the pi can convert the hostname to the respective IP addresses.
The next step would be to run the following from the Pi
The ping proves there is actually a route to the AWS machine it's all hosted on. Curl double checks the pi can actually reach it via https.
But I've not has any other reports of something similar that haven't ended up being DNS problems (which is not the case here as the pi is definitely resolving the hostname)
to allow Node-RED as a collection of smart home devices
Please make sure you read the docs carefully
<img style="width: 80%" src="/images/flow.png">
From: Ben Hardill @.***
Sent: Sunday, 13 April 2025 6:05 PM
To: hardillb/node-red-contrib-googlehome
Cc: Cruzxia; Author
Subject: Re: [hardillb/node-red-contrib-googlehome] Cannot connect to server. (Issue #32)
It wouldn't be a timeout error if there was a certificate problem (the certs are issued by letsencrypt so should be trusted by pretty much everywhere) and are the same certs as used for the website.
The nslookup is just checking that the pi can convert the hostname to the respective IP addresses.
The next step would be to run the following from the Pi
The ping proves there is actually a route to the AWS machine it's all hosted on. Curl double checks the pi can actually reach it via https.
But I've not has any other reports of something similar that haven't ended up being DNS problems (which is not the case here as the pi is definitely resolving the hostname)
It wouldn't be a timeout error if there was a certificate problem (the certs are issued by letsencrypt so should be trusted by pretty much everywhere) and are the same certs as used for the website.
The nslookup is just checking that the pi can convert the hostname to the respective IP addresses.
The next step would be to run the following from the Pi
The ping proves there is actually a route to the AWS machine it's all hosted on. Curl double checks the pi can actually reach it via https.
But I've not has any other reports of something similar that haven't ended up being DNS problems (which is not the case here as the pi is definitely resolving the hostname)
OK,I've just created a new test user and spun this all up on the latest docker container (which matches the nodejs/npm/node-red version)
And it all connects properly.
The host is a Intel Ubuntu 22.04 machine at the moment, I'll try a debian VM when I get a moment.
Do you have anything like Pi Hole on your network? Are the old/new system connected differently e.g. wifi vs wired?
I'm at a loss at the moment, this feels like it has to be something in your environment as I've not had any other reports and the same versions are running normally for me.
I do have pi hole on my network, but it is not blocking, my old system connects to your server just fine.
I have tried wired and Wi-Fi connections with no difference. Old system connects on both. New one does not connect.
I setup a MQTT OUT node to test the connection on Port 1883. Old system connects, New one does not.
I setup the same MQTT OUT node to connect to Hive Mq (no user or password) and it connects on the new system. So I don’t think it is a port blocking issue.
I will leave the node trying to connect to the server. Please check the server log to see if you can see it trying to connect.
Cheers
From: Ben Hardill @.***
Sent: Friday, 18 April 2025 6:23 PM
To: hardillb/node-red-contrib-googlehome
Cc: Cruzxia; Author
Subject: Re: [hardillb/node-red-contrib-googlehome] Cannot connect to server. (Issue #32)
OK,I've just created a new test user and spun this all up on the latest docker container (which matches the nodejs/npm/node-red version)
And it all connects properly.
The host is a Intel Ubuntu 22.04 machine at the moment, I'll try a debian VM when I get a moment.
Do you have anything like Pi Hole on your network? Are the old/new system connected differently e.g. wifi vs wired?
I'm at a loss at the moment, this feels like it has to be something in your environment as I've not had any other reports and the same versions are running normally for me.
OK,I've just created a new test user and spun this all up on the latest docker container (which matches the nodejs/npm/node-red version)
And it all connects properly.
The host is a Intel Ubuntu 22.04 machine at the moment, I'll try a debian VM when I get a moment.
Do you have anything like Pi Hole on your network? Are the old/new system connected differently e.g. wifi vs wired?
I'm at a loss at the moment, this feels like it has to be something in your environment as I've not had any other reports and the same versions are running normally for me.
I setup a MQTT OUT node to test the connection on Port 1883. Old system connects, New one does not.
This is with the service username/password and googlehome.hardill.me.uk?
Also just double checking you have totally stopped Node-RED on the old device while testing all this? You can not have 2 instances of Node-RED connected at the same time as the Google Home nodes force using the username as the client id to ensure only a single instance can be online at a time.
I will leave the node trying to connect to the server. Please check the server log to see if you can see it trying to connect.
I don't see anything in the broker logs for today (since midnight UTC) but I do see connections for yesterday (I assume from the old machine and from MQTTExplorer and basic Node-RED). If it was 2 instance running at once I would expect to see them both kicking each other off the broker every 30 seconds.
I've installed a fresh Debian 12 VM and a fresh Node-RED install with a test account and all is connecting fine, so it doesn't appear to be a software versions thing (the VM was on AMD64)
I just tested one system at a time.
I have left the new pi with it trying to connect to
googlehome.hardill.me.uk
With my user name and password.
It will be on for the next 8 hours. Then I will disable it.
I also tested a new user name and paw just incase it was something to do
with it being tied to the Mac address of my old pi.
If you can't see the logon requests,
Then somehow my system is not allowing access to your server.
I am not certain what to do next.
On Mon, 21 Apr 2025, 9:15 pm Ben Hardill, @.***> wrote:
I setup a MQTT OUT node to test the connection on Port 1883. Old system
connects, New one does not.
This is with the service username/password and googlehome.hardill.me.uk?
Also just double checking you have totally stopped Node-RED on the old
device while testing all this? You can not have 2 instances of Node-RED
connected at the same time as the Google Home nodes force using the
username as the client id to ensure only a single instance can be online at
a time.
I will leave the node trying to connect to the server. Please check the
server log to see if you can see it trying to connect.
I don't see anything in the broker logs for today (since midnight UTC) but
I do see connections for yesterday (I assume from the old machine and from
MQTTExplorer and basic Node-RED). If it was 2 instance running at once I
would expect to see them both kicking each other off the broker every 30
seconds.
I've installed a fresh Debian 12 VM and a fresh Node-RED install with a
test account and all is connecting fine, so it doesn't appear to be a
software versions thing (the VM was on AMD64)
I setup a MQTT OUT node to test the connection on Port 1883. Old system
connects, New one does not.
This is with the service username/password and googlehome.hardill.me.uk?
Also just double checking you have totally stopped Node-RED on the old
device while testing all this? You can not have 2 instances of Node-RED
connected at the same time as the Google Home nodes force using the
username as the client id to ensure only a single instance can be online at
a time.
I will leave the node trying to connect to the server. Please check the
server log to see if you can see it trying to connect.
I don't see anything in the broker logs for today (since midnight UTC) but
I do see connections for yesterday (I assume from the old machine and from
MQTTExplorer and basic Node-RED). If it was 2 instance running at once I
would expect to see them both kicking each other off the broker every 30
seconds.
I've installed a fresh Debian 12 VM and a fresh Node-RED install with a
test account and all is connecting fine, so it doesn't appear to be a
software versions thing (the VM was on AMD64)
Just double checking, both Pi's are on a RFC1918 (private IP range) behind the same NAT gateway (so requests should show up as coming from the same external public IP address).
I'm just trying to rule out anything else.
But I am also at a loss here, the timeout implies something along the route between the 2 machines is dropping the packets, but I can't see where.
My only off the wall suggestion is assuming your router is handing out the same IP address to the new Pi, try seeing if you can force it to hand out a different address.
I tried changing ip addresses, switched between wired and wifi. Rebooted all modems and Pi none of this made a difference.
Then I thought maybe the old pi did not log out of your server. So I powered it up, It connected right up. I then deleted the password. This prevented it connecting to your server. Hopefully forcing a disconnect. After shutting down the old pi I setup the connection on the new pi and it still would not connect.
The only thing I can think of now is to setup the old pi to run the google home bit and send its on/off requests to the new pi on the local server. It is a bit messy if I have to use this method.
The only other Idea I had, is perhaps your server has something stored that relates to the old pi. Possibly if you reboot the server it may resolve the issue, by clearing the memory.
From: Ben Hardill @.***
Sent: Monday, 21 April 2025 11:44 PM
To: hardillb/node-red-contrib-googlehome
Cc: Cruzxia; Author
Subject: Re: [hardillb/node-red-contrib-googlehome] Cannot connect to server. (Issue #32)
Just double checking, both Pi's are on a RFC1918 (private IP range) behind the same NAT gateway (so requests should show up as coming from the same external public IP address).
I'm just trying to rule out anything else.
But I am also at a loss here, the timeout implies something along the route between the 2 machines is dropping the packets, but I can't see where.
My only off the wall suggestion is assuming your router is handing out the same IP address to the new Pi, try seeing if you can force it to hand out a different address.
Just double checking, both Pi's are on a RFC1918 (private IP range) behind the same NAT gateway (so requests should show up as coming from the same external public IP address).
I'm just trying to rule out anything else.
But I am also at a loss here, the timeout implies something along the route between the 2 machines is dropping the packets, but I can't see where.
My only off the wall suggestion is assuming your router is handing out the same IP address to the new Pi, try seeing if you can force it to hand out a different address.
I think the issue is that I am running Bookworm OS on the PI and that the current release of Node Red only supports Bullseye OS
Surfing the net I have found some other users with the odd Node Red item that won’t work on Bookworm.
I will just have to wait for an update to Node Red that supports Bookworm.
I will let you know if it resolves when there is an update.
Cheers
Andrew
From: Ben Hardill @.***
Sent: Monday, 21 April 2025 11:44 PM
To: hardillb/node-red-contrib-googlehome
Cc: Cruzxia; Author
Subject: Re: [hardillb/node-red-contrib-googlehome] Cannot connect to server. (Issue #32)
Just double checking, both Pi's are on a RFC1918 (private IP range) behind the same NAT gateway (so requests should show up as coming from the same external public IP address).
I'm just trying to rule out anything else.
But I am also at a loss here, the timeout implies something along the route between the 2 machines is dropping the packets, but I can't see where.
My only off the wall suggestion is assuming your router is handing out the same IP address to the new Pi, try seeing if you can force it to hand out a different address.
Just double checking, both Pi's are on a RFC1918 (private IP range) behind the same NAT gateway (so requests should show up as coming from the same external public IP address).
I'm just trying to rule out anything else.
But I am also at a loss here, the timeout implies something along the route between the 2 machines is dropping the packets, but I can't see where.
My only off the wall suggestion is assuming your router is handing out the same IP address to the new Pi, try seeing if you can force it to hand out a different address.