Envisalink Socket error

[devoir]

I keep getting this error and can't seem to find out what is causing this.

EnvisaLink
ERROR Receiver::Run() A socket error has occured: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.


Would certainly appreciate your thoughts or guidance.


Devoir

[devoir]

It's really strange the Envisa system see's the network card "Online"






Not sure here what went wrong...... went to the IP settings page and resubmitted IP






Now there are no longer Errors' every second hammering the log file.


Many thanks and hope this helps if someone has trouble.


Devoir

[Bmurph213]

am getting the same error after upgrading the plugin to v3.0.0.41 I added a firewall rule to deny all hosts access to the envisalink device as I had a similar issue with an old connection causing this. If you enable debug, I assume you will see the following error.

Nov-02 16:30:40 INFO Connection Lost, will try to reconnect in 10 seconds
Nov-02 16:30:51 INFO Trying to reconnect to: XXX.XXX.XXX.XXX:4025
Nov-02 16:30:51 INFO Reconnection OK
Nov-02 16:30:51 ERROR Receiver::Run() A socket error has occured: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Nov-02 16:30:51 DEBUG Stack: at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at EnvisaLink.Communications.Reciever.Run()
Nov-02 16:30:51 INFO Connection Lost, will try to reconnect in 10 seconds

I am not sure why this is happening all of a sudden as adding the firewall rule did not help the issue at all. Even rebooted the envisalink and homeseer too. Same errors.

Attached is a screenshot. I even denied access to the EyezOn server as well. Even though that never caused an issue.

On the firewall I only show a closed connection and never an open connection from the HS4 server

[LikeAutomation]

I am having the same issue on a brand new HomeTroller Pi (migrating from a PC). Any solutions?

[baudfather]

I've also been getting this error since upgrading to HS4 (worked flawlessly in HS3). The errors stop when I re-start the DSC plugin, but they start again when HS4 restarts.

[baudfather]

Here's the error I'm getting after the socket error in the HS log w/debug on:

DEBUG Stack: at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at EnvisaLink.Communications.Reciever.Run()

(Using EVL4)

[baudfather]

Any suggestions on this, spud ?

[scorp508]

I am also getting this error. I have been running HS4 for a long time (upgraded from HS3), but only recently noticed the error when the plug-in was no longer working after a system restart. The only big change I can think of was switching HS4 to run as a service which only became available in 4.7.0. I now have to disable/enable the Envisalink plugin for it to work after a system restart.

[baudfather]

This seems to be an issue (one of several I've encountered) when running HS4 as a service, and I can only assume it has to do with system executable permissions. Rather than try and figure it (and the other issues) out, I've gone back to running HS4.exe as an app at logon and all the issues are gone.

[tucker]

Seeing the same issue, HS on Pi

Linux HTPiHubG1 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux

Confirmed UDP connectivity to Envisalink with nc, though don't know the envisalink protocol to test beyond that to validate potential issues at the other end:

root@HTPiHubG1:~# nc -z -v -u 192.168.100.157 4025
Connection to 192.168.100.157 4025 port [udp/*] succeeded!

[tucker]

Quick follow up: I'm not even seeing the UDP connection opened from the homeseer system. wireshark shows no UDP connections originating from the Pi when the plugin attempts to connect to the Envisalink device.

$ tshark -a duration:20 -f "udp and host 192.168.100.157"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
0 packets captured

If it helps any, version of mono is:

$ mono --version
Mono JIT compiler version 6.10.0.104 (tarball Fri Jun 26 19:59:14 UTC 2020)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: normal
Notifications: epoll
Architecture: armel,vfp+hard
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: yes(610)
Suspend: preemptive
GC: sgen (concurrent by default)

[spud]

Quick follow up: I'm not even seeing the UDP connection opened from the homeseer system. wireshark shows no UDP connections originating from the Pi when the plugin attempts to connect to the Envisalink device.

The EnvisaLink plugin doesn't use UDP, it uses TCP on port 4025

[tucker]

The EnvisaLink plugin doesn't use UDP, it uses TCP on port 4025

Well that might explain why I ddn't see any UDP traffic ;-)

Re-ran with the right protocol; 192.168.10.45 is the homeseer box, 192.168.100.157 is the envisalink. Looks like the envisalink sends back a reset packet after the initial handshake:

# tshark -a duration:20 -f "host 192.168.100.157"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
1 0.000000000 192.168.10.45 → 192.168.100.157 TCP 74 57682 → 4025 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3308365437 TSecr=0 WS=128
2 0.000822759 192.168.100.157 → 192.168.10.45 TCP 60 4025 → 57682 [SYN, ACK] Seq=0 Ack=1 Win=1300 Len=0 MSS=1260
3 0.000890989 192.168.10.45 → 192.168.100.157 TCP 54 57682 → 4025 [ACK] Seq=1 Ack=1 Win=64240 Len=0
4 0.001656925 192.168.100.157 → 192.168.10.45 TCP 60 4025 → 57682 [RST, ACK] Seq=1 Ack=1 Win=1300 Len=0
4 packets captured

Not sure if that helps much with debugging; afraid my networking skills are a little rusty (if that's not already obvious...). Happy to share more / run additional diagnostics if it helps.

[baudfather]

I've reverted my HS4 setup to running as an executable at startup rather than as a service, haven't had the issue since. I also had issues executing external scripts when HS4 was running as a service (Windows 10 Pro).

[tucker]

Quick update from my end, apologies for not updating sooner: the issue turned out to be a local problem. It’s been a while, but if I remember correctly the problem was that the envisalink will not allow TCP connections if you have not changed the default password: mine was still set to user/user. When I updated to a new password (username always remains as “user”) everything promptly started working. The behavior from the envisalink is exactly as described above, in that if the password is the default password it will reset the TCP connection and refuse to open a connection.

Hope that helps someone else who gets stuck here like I did!