Envisalink - TPI Documentation

Information and support for EnvisaLink modules.

Moderators: EyezOnRich, GrandWizard

mikep
Posts: 122
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: 122
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: 100
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: 122
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: 19
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.


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

Who is online

Users browsing this forum: No registered users and 12 guests