I have recently updated my pi with the latest versions. Everything works fine but since the update, when I visualize node-red-log I get, every 30/40 seconds, the next output:
Failed to GET info from http://169.254.227.57:80/description.xml
{ Error: connect ETIMEDOUT 169.254.227.57:80
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1106:14)
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT',
syscall: 'connect',
address: '169.254.227.57',
port: 80 }
....
the same for
169.254.7.199:80/description.xml
...
169.254.208.210:80/description.xml
....
169.254.67.83:80/description.xml
......
169.254.223.226:80/description.xml
....
10.8.0.1:80/description.xml
.....
172.18.0.1:80/description.xml
......
......
169.254.215.60:80/description.xml
.....
.....
.....
.....
I don't have any node that accesses these IP addresses.
Some 12 odd years ago I got called in to fix a family member’s laptop because the wifi did something weird. Windows’ own DHCP connection thingy on Windows XP would turn the laptop into something akin access point mode when having trouble to connect to the wifi. Instead of assigning a local 192.168.x.x ip address, it would give you a 169.254.x.x address.
I have no clue what the relation is to them appearing on the pi however, nor can I remember how exactly I fixed it. I know it kept coming back several times, but only ever on that laptop.
The 10.x.x.x is in the local namespace too. But the 172.18.x.x doesn’t ring a bell at all.
Could you post your flow here? There might be a clue to some internal/local networking there.
I have checked and there is no flows referring to description.xml. The next step has been to remove all the flows and leave only a very simple flow, just one inject node a debug node, and the result is the same, I still get the same error messages in the log.
it's really very strange, I don't know if it could be related to the node-network installation.
Seeing how most of the addresses in that first post refer to local network addresses or even are related to DHCP, is your pi set up to use a static ip address, or a dynamic address through DHCP?
Do you have any nodes installed that try to communicate with devices on the local network?
All of those IP addresses, as @afelix says, are typically local network addresses rather than public addresses on the internet.
It looks very much like something is searching random IP addresses for things on your network. That could be 'normal' if its a node looking for devices of a particular type for it to control, but it could also be something bad trying to find vulnerabilities in your local network.
You say you have removed all your flows. Have you checked you have removed all configuration nodes as well? You can check by opening the configuration node sidebar panel in the editor.
You could also delete your flows file, or rename it so you don't lose it, and start with a completely blank workspace.
Some other random thoughts popping up... Can you get a clean settings.js file from here, save it in a new directory somewhere. Then launch NR again from that directory as node-red -s settings.js.
If the error messages appear again, something in your user directory (~/.node-red/) is causing it. If it’s gone instead, your settings.js file is likely causing it.
knolleary: the original flows communicate with a pair of wemo devices on the local network. I removed all flows and configuration nodes and I started with a completely blank space, but the results is the same.
dceejay: no I have not any hue node installed
afelix: mi pi uses dynamic address via DHCP. I started with a clean settings.js file with the same results?????
If you open the Palette Manager from the main menu, you can also disable node modules you have installed. You could disable the wemo module just to make sure it isn't trying to do something in the background.
I can’t say for sure what’s happening, but it definitely sounds like there’s leftovers of nodes/config nodes somewhere. Clean settings.js file rules out extra libraries in it loaded that way that could potentially cause it.
My gut feeling, but I’ve no way to prove it, is that your pi changed ip addresses a couple times because of DHCP, and these are all old addresses the pi is no longer being available on. Upgrading to a newer version, again speculating, changed logging levels/something in a third party node resulting in it now giving those errors visibly; as if beforehand they already happened but never showed this way.
For the future, to prevent this situation from happening again when it is solved, try to see if you can give the pi a static ip address.
Finally it seems that the problem is related to the wemo node. When I uninstalled it, the error ceased to occur.
I have started again and I have reinstalled it and again it has started to give the same errors.
Thank you very much to all of you for your comments and suggestions.
The truth is that I'm surprised because I don't quite understand what's going on. For the last three years I've been using node-red to manage the control of the heating of a house in the countryside that doesn't have internet access, through SMS messages using Gammu. In my last visit I brought the system in order to update it. I have updated node.js, node-red and wemo-node to the latest versions and since then have started problems with error messages when trying to access strange IP addresses. I even proceeded to uninstall the whole system and install it again, including a previous version of node-red-wemo (0.1.14). The surprising thing is that my flows work perfectly, I am able to control the wemo switches via SMS, read the temperature etc. but it is very surprising to constantly receive error messages because the system is trying to access a series of strange IP addresses. This does not affect the operation of my application but it is still a strange behavior. I honestly don't know what to do to avoid this behavior, although it doesn't really affect the functionality of my application.
Thanks hotNipi, clearly can be a vulnerability and be susceptible to attacks, but the issue is that it is the system itself wich that tries to access strange IP addresses, unsuccessful for certain time. In the final deployment the application will not have access to the internet, so I think it is not a threat. I do not know, I do not understand what may be happening, unless it is a problem of the wemo node itself.
Try a search for DHCP and connection problems. That’s where those IP addresses are popping up most of the time: local ip addresses, unable/hardly able to connect to other devices, assigned when setting up a connection didn’t go well and the local DHCP process on the device instead gave it one. I saw a topic about it on the raspberry pi site too when I checked after remembering this as a microsoft-only problem.
