v5.13 software controller, issue with Terminal establishment?
After updating to v5.13, and underlying devices to latest, I am unable to establish a terminal session (new feature with latest software) to either:
- EAP615-wall v1.2.3
- SG2210P v5.20
Both start with a 'Succeeded' message, and then in the log window: connecting, and after 30s or so, then report connection timeout:
I am running the Linux Controller v5.13.22 in a Docker container (host networking) on a Pi4 Clone. The container has an IP on the same subnet as the devices. I can't think of any reason why the controller wouldn't be able to establish communications with the devices it manages. Am I being stupid, or is there a problem here?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Ok, firewall it is, I just tried from a fresh Mac and terminal establishment went fine.
That said, why is the terminal session established direct between the enduser device and the network device, the whole point of having a controller is to abstract the need for one to have direct network access to the device. It should be enough for the controller to have access, and then relay/proxy the IN/OUT traffic from the terminal source to the end user browser window, it is just text afterall!
I don't think FW and/or ACL should be allowed to interfere with a Controller based tool, otherwise what's the point? I'll file a feature request with a little more detail shortly.
- Copy Link
- Report Inappropriate Content
Hi @d0ugmac1,
Thanks for reporting this issue to TP-Link community!
Did you have any ACL settings? Please check whether there is a Firewall or the anti-virus software blocking the traffic.
Please tell us the firmware version of your switch. And the Terminal feature has been added from controller v5.9, may I confirm whether the issue you reported occurred after upgrading to v5.13?
- Copy Link
- Report Inappropriate Content
Did you have any ACL settings? -- ONLY BETWEEN SSID VLAN/SUBNETS. NOTHING ON VLAN1. COMMUNICATION IS BETWEEN DEVICE AND CONTROLLER RIGHT?
Please check whether there is a Firewall or the anti-virus software blocking the traffic.-- AS ABOVE, EVEN IF LAPTOP HAD FIREWALL, I AM VIEWING OUTPUT VIA A BROWSER TO THE CONTROLLER WHICH CLEARLY WORKS, SO FW OR AV IRRELEVANT?
Please tell us the firmware version of your switch. -- SEE ABOVE IMAGE
And the Terminal feature has been added from controller v5.9, may I confirm whether the issue you reported occurred after upgrading to v5.13? -- V5.9 DID NOT OFFER THE NEW FIRMWARE UPGRADE OPTION. IT ONLY APPEARED WITH 5.13, SO I DID NOT TEST WITH PREVIOUS CONTROLLER VERSION.
- Copy Link
- Report Inappropriate Content
Hi @d0ugmac1,
d0ugmac1 wrote
Please check whether there is a Firewall or the anti-virus software blocking the traffic.-- AS ABOVE, EVEN IF LAPTOP HAD FIREWALL, I AM VIEWING OUTPUT VIA A BROWSER TO THE CONTROLLER WHICH CLEARLY WORKS, SO FW OR AV IRRELEVANT?
Please turn off the firewall just for testing, let's get this most likely factor out of the way first.
Could you capture the packets of the Laptop that installed the Controller when this issue occurs next time?
- Copy Link
- Report Inappropriate Content
Ok, firewall it is, I just tried from a fresh Mac and terminal establishment went fine.
That said, why is the terminal session established direct between the enduser device and the network device, the whole point of having a controller is to abstract the need for one to have direct network access to the device. It should be enough for the controller to have access, and then relay/proxy the IN/OUT traffic from the terminal source to the end user browser window, it is just text afterall!
I don't think FW and/or ACL should be allowed to interfere with a Controller based tool, otherwise what's the point? I'll file a feature request with a little more detail shortly.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 422
Replies: 4
Voters 0
No one has voted for it yet.