-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect loop in the DNS setup #37
Comments
Do you already have an idea how to figure out if the dns entry resolves to the proxy itself? Do you see any other/ better approach? |
It is really not simple. Until the user can have firewall rules, NAT, Hair-Pin-NAT etc, I would prefer to send a real packet to the well known port 5005 and 10000. So the question is how to mark this packet?
So version 3 and 4 are my vavorits. Your approach of using the HTTP endpoint is very good as we are independent of the inverter protocols. I'm not sure if a standard linux will send a packet for his own IP address to the gw or if it return inside the kernel. In the second case, the test package cannot be discarded externally, which would be great. |
Option 1Lets assume we do a request to logger.talent-monitoring:8127/-/ready
Option 2Lets assume we send a packet (option 3 or 4 or checksum i/o) to the cloud endpoint on either port 5000 or 10000
Idea: Checksum Workflow
|
If we have a loop, we will get a lot of new connections from the same endpoint with the same inverter serial number. That can be normal, if the inverter have detected a problem and establishes a new connection to solve this. I think that in this case the time between the two connection should be more than a seconds (Must be a timeout...) Detection:
What do you think about this approach? |
If the DNS name logger.talent-monitoring.com is resolved to itself by the proxy, then countless connections are established through this loop until the system crashes.
This is a misconfiguration of the DNS setup and should be recognized by the proxy and the outgoing connection should not be established. The proxy then runs and at least delivers the data to the MQTT broker.
The text was updated successfully, but these errors were encountered: