Envisalink - TPI Documentation

Information and support for EnvisaLink modules.

Moderators: EyezOnRich, GrandWizard

mikep
Posts: 133
Joined: Wed May 30, 2012 1:49 pm
Contact:

Re: Envisalink - TPI Documentation

Postby mikep » Wed Oct 18, 2017 9:23 pm

I guess. Bit academic though - doesn't matter if it's invalid 'cause it's short or invalid 'cause it's a bad checksum, I discard it in either case. What I'm trying to sort out is whether the envisalink itself has sent an invalid message or it's been corrupted while traversing the network. Which is back to the original question - does the envisalink's firewall send anything back when it blocks, and if so what? Do I tell my user to fix his network, or to change the password? Based on K-Man's answer of a connect-reset with no data (so no EOL), it seems to be the network.

rct
Posts: 41
Joined: Mon Dec 21, 2015 6:24 pm

Re: Envisalink - TPI Documentation

Postby rct » Thu Oct 19, 2017 10:50 am

mikep wrote:I guess. Bit academic though - doesn't matter if it's invalid 'cause it's short or invalid 'cause it's a bad checksum, I discard it in either case. What I'm trying to sort out is whether the envisalink itself has sent an invalid message or it's been corrupted while traversing the network. Which is back to the original question - does the envisalink's firewall send anything back when it blocks, and if so what? Do I tell my user to fix his network, or to change the password? Based on K-Man's answer of a connect-reset with no data (so no EOL), it seems to be the network.


First -- Yes, tell your user(s) to change the default password.

If the network were corrupting packets in transit, your app wouldn't(*) receive them unless something is very wrong with the client OS. The TPI connection is a TCP stream, there are checksums, sequence numbers, etc. that are designed to ensure a reliable data stream. Lost/corrupted/duplicated packets at the physical layers of the network are expected to occur.

(*) Sure, there is a probability that the checksum could yield a false positive, but the probability is low or all the software we use over TCP like SMTP, HTTP would all have additional error detection as a matter of course. (One paper mentions, "After an analysis we conclude that the checksum will fail to detect errors for roughly 1 in 16 million to 10 billion packets."

mikep
Posts: 133
Joined: Wed May 30, 2012 1:49 pm
Contact:

Re: Envisalink - TPI Documentation

Postby mikep » Thu Oct 19, 2017 11:35 am

Geez, now it seems very academic...

First -- Yes, tell your user(s) to change the default password.

I tell my users to NEVER expose their envisalink TPI port outside of an encrypted network. Changing the password does not make the TPI secure. Whether they change their password for internal use is their own business (krack aside).

If the network were corrupting packets in transit, your app wouldn't(*) receive them unless something is very wrong with the client OS. The TPI connection is a TCP stream, there are checksums, sequence numbers, etc. that are designed to ensure a reliable data stream. Lost/corrupted/duplicated packets at the physical layers of the network are expected to occur.

I don't disagree, but I'm not sure I understand your point. Perhaps you're directing this to k-man, telling him the TPI doesn't need the checksum? If so I'll leave that to you and he to sort out. I haven't touched that code for years.

If you're suggesting k-man is wrong and he does send an EOL before the connect-reset that's probably something that's easier just to test than discuss. It would be useful to mention in a FAQ.

K-Man
Posts: 123
Joined: Fri Jun 01, 2012 1:08 pm

Re: Envisalink - TPI Documentation

Postby K-Man » Tue Oct 24, 2017 10:13 am

Sorry Guys, missed this conversation.

Yes, the TPI checksum is completely useless and I don't even check it on my test apps. The TPI protocol comes from the DSC PC5401 module which our company manufactured for DSC before I even graduated from school. It was used over an RS-232 interface which indeed could be affected by noise and corrupt the packets but this can't happen way up at the application layer. So the checksum is really just there to make it easier for existing applications to port over to the Envisalink's TPI.

As for the TCP disconnect, yeah I think rct is correct, the TPI resets the socket after connect (SYN-ACK), not after SYN. This is really just a big hammer to tell users that if you're going to be reckless with your LAN security and let the world have access to your Envisalink, at least change the default password. Sheesh.

K

mikep
Posts: 133
Joined: Wed May 30, 2012 1:49 pm
Contact:

Re: Envisalink - TPI Documentation

Postby mikep » Wed Oct 25, 2017 3:57 pm

This is really just a big hammer to tell users that if you're going to be reckless with your LAN security and let the world have access to your Envisalink, at least change the default password. Sheesh.


IMHO (and fully realizing no one asked) the hammer isn't big enough. It's a disservice as it suggests they only need to change their password and they will safely expose the TPI (it's not enough to say in the docs it's still not safe or they'd already know and a firewall wouldn't be needed).

My experience is that many do not understand plain TCP vs SSL, and why an unprotected login API is dangerous. If I were the architect of that API I'd use the firewall to prevent ANY access outside of the local subnet regardless of the password.

BTW, the intent of my original question was whether an EOL marker (finishing that input buffer and preparing the next) was sent before the RST. In the log was an EOL which of course my app discarded, but I was puzzled as to why it was there. In that situation (which did turn out to be from outside of the local subnet) I was expecting to only see the RST caused EOF byte.

proo
Posts: 1
Joined: Tue Apr 10, 2018 7:05 pm

Re: Envisalink - TPI Documentation

Postby proo » Wed Apr 11, 2018 9:01 am

This may be a dumb question, but I'm trying to write a simple python script to STAY-arm the system with the intention to potentially connect it to IFTTT or some other trigger. It's working, but if the system is already in AWAY-arm, it will downgrade it to STAY-arm, which I don't want as this is an obvious security hole. Is there a simple way to check the current partition status, short of running as an always-on server and keeping track at all times? Am I missing any other security concerns this would present?

Maybe someday I'll take a real look at what alarmserver does but it seems like a bit of overkill at this point.

lonewolf
Posts: 22
Joined: Mon Aug 04, 2014 6:03 am

Re: Envisalink - TPI Documentation

Postby lonewolf » Fri Jun 29, 2018 3:20 am

proo wrote:Is there a simple way to check the current partition status, short of running as an always-on server and keeping track at all times?
Send a 001 "status report" and one of the things you'll get back is a 65x - a 650 or 653 means it's ready but not armed while a 652 is already armed.

BuxtonCalvin
Posts: 4
Joined: Wed Sep 16, 2015 12:20 am

Re: Envisalink - TPI Documentation

Postby BuxtonCalvin » Sun Jan 27, 2019 8:08 pm

I use an application that accesses the TPI. The app can run for days without error, however, if the connection drops (for any reason except a hard reboot of the EVL 3), I am unable to re-establish a connection from the given app, even with a restart of the app (this is not always the case though as sometimes an app restart will work). If after I see a failed connection from the app ( I get a notice when the connection goes down), if I subsequently login to the evl from putty, and then after I close that putty connection, my app will happily login straightaway after a restart.

Can someone shed some light on the TCP negotiation that is occurring here that might cause such behavior. Is this a matter of the EVL rejecting a TCP socket identifier of some sort that was previously used and closed? And then a new TCP identifier is allowed access (the putty login is from a different IP)---resetting the EVL and allowing for a new connection from the app. Is there anyway for me to test or trap for error conditions at work here, that I can then program around?? Using LUA socket BTW.

lonewolf
Posts: 22
Joined: Mon Aug 04, 2014 6:03 am

Re: Envisalink - TPI Documentation

Postby lonewolf » Sun Jan 27, 2019 8:22 pm

My first response is, what does a tcpdump/wireshark packet capture show?

I've used LUA a couple times but never with sockets. Is it re-using the source port? If so, can you fix it so it uses a random source port for each connection?

This should probably be a new thread...

BuxtonCalvin
Posts: 4
Joined: Wed Sep 16, 2015 12:20 am

Re: Envisalink - TPI Documentation

Postby BuxtonCalvin » Tue Jan 29, 2019 7:34 pm

I tried a wireshark capture, but as I'm running the app on an Ubuntu server (CLI, SSH only), the text file capture is fairly garbled. I'm trying to load a monitor to look at the data through the wireshark gui, but there are some complications in that the server is in a rack without monitor access.

The TCP connection is reusing the source port. I'll try to use a different port and see what happens.

I posted to this thread as there isn't anything that I could see in the TPI documentation that addresses this problem.


Return to “EnvisaLink ( IP100D, IP170D, 2DS, 3, 4)”

Who is online

Users browsing this forum: No registered users and 10 guests