EyezOn Forum

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.

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."

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.

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

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.

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.

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.

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.

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...

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.