PowerPmacServer: Port 8086 Is the Server, Not Port 23

Telnet connects to 192.168.0.222 on port 23, but GPAsciiConnect to port 8086 fails from both VB and the sample C# projects. Treat this as a service-endpoint problem first. A working Telnet session proves that the controller is reachable and that port 23 accepts connections; it says nothing about the listener, filtering, or application protocol on port 8086.

Port and endpoint separation

1. Record the controller address as 192.168.0.222.
2. Record the intended PowerPmacServer endpoint as port 8086.
3. Confirm Telnet separately on port 23. Do not use that result as the acceptance test for port 8086.
4. Test port 8086 directly from the same PC running the VB or C# application. Do not move on until the test reports accepted, refused, or timed out.

Controller address check

Before anything else, confirm that the application PC is reaching the same controller used for the successful Telnet test. Duplicate addresses, multiple adapters, virtual network interfaces, and stale address-resolution entries can direct two tests along different paths even when both display 192.168.0.222.

1. Run the Telnet and port-8086 tests from the same PC and network interface used by the application.
2. Confirm that the controller identity shown through the working management session matches the intended demo rack.
3. Check the local route and active adapter selected for 192.168.0.222. If more than one adapter can reach that subnet, disable the ambiguity or bind the test to the intended interface.
4. Retest port 8086. If it still refuses or times out, continue with the listener check. If it accepts, skip to the application-session check.

The successful C# and VB failures narrow the fault domain. Two independent clients reaching the same result make VB syntax or language-specific interop less likely; the shared controller endpoint, service state, credentials, and network path remain common.

Port 8086 socket check

Use a TCP connection test or socket inspection tool that reports the outcome for the exact pair 192.168.0.222:8086. A generic reachability test is not enough because it does not verify a listening application socket.

1. Test 192.168.0.222:8086 from the application PC.
2. If the result is refused, inspect the controller locally for a listening socket on 8086. No listener directs the investigation to PowerPmacServer startup or configuration.
3. If the result times out, repeat from a host on the controller's local network segment. Acceptance locally but timeout from the application PC identifies an intervening firewall, filter, or route.
4. If the socket accepts, close the raw test connection and run GPAsciiConnect. TCP acceptance confirms only the transport layer; it does not validate the application handshake or login.

A listening socket must also be bound to an interface reachable from the application PC. A service bound only to a local interface can appear active on the controller while refusing remote clients. Read the controller's socket table to identify both the port and bound address.

PowerPmacServer process check

Inspect the controller through its available local administration interface. Check both process state and socket state; a process name in a task list does not prove that it completed initialization or opened port 8086.

1. Find the PowerPmacServer process or its managed service entry.
2. Read its state and recent startup diagnostics. Look for termination, repeated restart, address-binding failure, configuration rejection, or dependency failure.
3. Inspect the listening-socket table for port 8086. Record the owning process and bound interface.
4. If PowerPmacServer is stopped, start it through the controller's normal service-management mechanism. If it starts but opens no listener, correct the startup or endpoint configuration indicated by its diagnostics.
5. Retest 192.168.0.222:8086 remotely. Do not move on until the socket accepts from the application PC.

Do not substitute a successful port-23 login for these checks. Telnet and PowerPmacServer are separate processes with separate listeners, initialization paths, and application protocols. One can remain available while the other is stopped or inaccessible.

Application session check

Once port 8086 accepts TCP connections, compare the smallest possible API call across VB and the supplied C# sample. Keep the address, port, username, password, client architecture, and referenced library version identical between tests.

bIsConnected = objPPMac.GPAsciiConnect("192.168.0.222", 8086, "<user>", "<password>")

1. Create a new client object and make one GPAsciiConnect call. Capture the returned bIsConnected value and any exception or library diagnostic.
2. Enter the same credential pair that succeeds for the intended account, without copying surrounding whitespace. A Telnet login does not by itself prove that the server on 8086 uses the same authentication path.
3. Run the unchanged C# sample against the same endpoint. Failure in both clients after TCP acceptance directs the next check to authentication, application protocol, or client/server compatibility.
4. Confirm that the application loads the intended client library and architecture. A stale or mismatched library can fail before or during the protocol handshake even when the socket is open.
5. Correlate the client attempt with the server diagnostics. No server-side connection entry indicates that the application did not reach the service; an accepted session followed by rejection identifies handshake or authentication processing.

Recovery and acceptance procedure

1. Set the application target to 192.168.0.222 and port 8086. Confirm that no code path substitutes Telnet port 23.
2. Start or restore PowerPmacServer on the controller. Confirm that its process remains running and owns a listening socket on 8086.
3. Open the required network path between the application PC and that listener. Confirm that a direct TCP test from the application PC is accepted rather than refused or timed out.
4. Run the minimal C# sample with the selected account. Confirm a successful connection before adding application logic.
5. Run the equivalent VB call and require bIsConnected to report success. If C# passes while VB fails, compare library reference, process architecture, argument types, and exception details.
6. Close the test session, create a fresh client object, reconnect, and issue a harmless read-only ASCII query supported by the controller configuration. Accept the repair only when the application receives a valid response and the server diagnostics show a normally opened and closed session.

FAQ