EEZ Studio TCPListen: Verify the Effective Bind Address and Connection Limit
A TCPListen address field is not sufficient evidence that an EEZ Dashboard is listening only on that address. The inspected v0.29.0 source contains two concrete property-wiring discrepancies: the configured IP address is not passed into the final listen call, and the maximum-connections value is evaluated from the port property.
The TCPListen guide describes the intended address and connection-limit controls. The findings below come from tcp.tsx at editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612. They are pinned-source observations, not a claim about every release or a verified exposure in a deployed product.
Do not open a public listener to investigate this. Establish the installed implementation first, and use an already isolated disposable environment for any runtime test.
Follow each property into the actual call
The action evaluates port and ipAddress, then constructs a TCPListenExecutionState containing them. However, the maximum-connections local value is obtained with evalProperty using the name port. That value is passed to the state and subsequently assigned to server.maxConnections.
The state stores ipAddress, but its start method calls server.listen with this.port alone. Reading and storing a property is therefore not proof that the property influences the socket bind operation.
These two observations answer different parts of one configuration audit. The connection limit must be traced to the value assigned to the server property. The bind address must be traced to the listen call's actual arguments. Neither can be established from the property's editor label.
An omitted host is not a loopback guarantee
The current Node TCP server documentation describes an omitted host as an unspecified-address listener, using IPv6 when available or IPv4 otherwise. It should not be interpreted as an implicit localhost restriction.
That documentation is useful for understanding why the missing argument matters. It does not establish the exact bundled Node version, operating-system behavior or effective network exposure of an arbitrary EEZ installation. Firewalls, interfaces and surrounding isolation can affect reachability independently of the application's bind request.
Inspect the actual socket binding in the test environment. A configured loopback string in the project is weaker evidence than the operating system's listening-address report. Stop the fixture if the effective binding does not meet the intended isolation boundary; do not continue by assuming that a local test client makes the listener private.
Test the limit with a distinguishable value
Choose a small intended connection limit that is clearly different from the test port number. A fixture that uses indistinguishable values cannot reveal the property-name error.
After the source path has been established, inspect the effective configuration and a small controlled number of local connections in the isolated environment. There is no need to generate a large load or attempt resource exhaustion. The purpose is to determine whether the selected limit is actually supplied to the runtime.
Record the runtime version before interpreting edge values such as zero. Node's documented maxConnections behavior has changed across versions, so this source discrepancy should not be turned into a universal explanation of every possible limit value.
Also distinguish starting the listener from accepting a client connection. A Flow continuation after setup is not itself evidence that the address and limit match the project settings. Those properties require their own observations.
Keep the remediation version-specific
If the installed build contains the inspected code, treat the two controls as unverified for the intended use until the implementation or supported integration is corrected and retested. Do not rely on changing the editor field repeatedly when the final call does not consume it as expected.
A later build may have different code. Compare its actual property lookup and listen arguments before carrying this finding forward. The relevant regression fixtures are small: a specific intended address and a small limit different from the port.
No TCP listener, client connection or exposure test was run for this article. The contribution is a source-to-runtime checklist grounded in two exact statements, with a bounded way to verify them. It does not assign a vulnerability classification or claim that a particular user's system is reachable.
