| Posted: Monday Oct 24th, 2011 12:47 pm |
|
21st Post |
xAPPO
Member
| Joined: | Thursday Jul 22nd, 2010 |
| Location: | |
| Posts: | 13 |
| Status: |
Offline
|
back to top
|
Any new TCP socket connection would require a login so that it's access level could be checked so any client should always be validated. If the last remaining socket at any given logon level disconnected then the associated UCM would logout also.
Having two UCM's would allow them to be pooled still so any number of users with two different passwords would always be connected, some using one UCM and some the other. My original PS comment would allow multiple levels to be achieved using a single UCM.
If the EM500 capabilities might allow such an arrangement to be coded in firmware it sounds very sensible and I don't think it causes any security problems.
Kevin
|
| Posted: Monday Oct 24th, 2011 02:12 pm |
|
22nd Post |
Ingo
UCM Pi Users
| Joined: | Sunday Jan 21st, 2007 |
| Location: | South Africa |
| Posts: | 560 |
| Status: |
Offline
|
back to top
|
Just something to think about.... You need to be able to decode the passwords in the CCLX file to be able to restrict/grant certain levels of access. The encryption method is not available to the public.
Ingo
|
| Posted: Monday Oct 24th, 2011 02:45 pm |
|
23rd Post |
xAPPO
Member
| Joined: | Thursday Jul 22nd, 2010 |
| Location: | |
| Posts: | 13 |
| Status: |
Offline
|
back to top
|
I don't really need to know the passwords though.... The first connection I would know the password that was used to logon to the UCM (and I would remember it) and subsequent TCP connections I would check passwords and they would have to be the same or I would enlist another UCM. If there is any useable standardised form of TCP socket security/encryption available I could offer the same.
For my 'PS' approach ... I dont actually need to know the passwords but I do need to know the level of the access that was granted , and hence my question as to whether the UCM can advise me of this (?). This is so I could ensure that passwords that have lesser levels can't send commands above their level. I would logon to the UCM at the highest level of the connected clients. This would require a few logon tests to validate each password and also to establish which was the highest level.
Alternatively I could create a set of my own passwords just for users (eg iPhone clients) that went via my proxy device. They might be the same as the Comfort passwords but they could be different and mapped by some configuration (web page/telnet) to a suitable Comfort UCM password.
It would be much better if this was a Cytech implemented feature within the Ethernet UCM of course.
K
Last edited on Monday Oct 24th, 2011 02:52 pm by xAPPO
|
| Posted: Tuesday Oct 25th, 2011 09:07 am |
|
24th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5495 |
| Status: |
Offline
|
back to top
|
When a user logs in sucessfully, the UCM will reply LUnn where nn is the user number. You should be able to use this to map a code with a user
To know the authorisations of each user, you would need to have access to the cclx file for Security > User codes
|
| Posted: Tuesday Oct 25th, 2011 09:21 pm |
|
25th Post |
wexfordman
UCM Pi Users
| Joined: | Monday Jan 1st, 2007 |
| Location: | Cork, Ireland |
| Posts: | 546 |
| Status: |
Offline
|
back to top
|
So, to clarify, is this new hardware, or something that can be intefrated in to the ethernet modules ?
|
| Posted: Tuesday Jul 24th, 2012 05:59 pm |
|
26th Post |
andrew
Member
| Joined: | Friday Sep 26th, 2008 |
| Location: | United Kingdom |
| Posts: | 8 |
| Status: |
Offline
|
back to top
|
My Comfort system predated the availability of the ethernet module. I have an RS232 UCM which is connected to a unix server. I wrote a deamon which runs on the server to handle this (and some other subsystems related to home automation such as temperature monitoring and heating control, but separate from Comfort).
The daemon has two operating modes. In Master mode, it attaches to the serial port (direct connection to the UCM), issues UCM commands and picks up responses and status reports. It will accept any number of incoming TCP connections. The TCP connections operate almost exactly the same command protocol as the UCM RS232 interface. Commands, responses and status reports are broadcast to all TCP connections, so all can be aware of everything which is going on.
In slave mode, it makes a TCP connection to a Master mode daemon rather than a direct serial port connection, and doesn't accept TCP connections from other slaves, but is otherwise identical to operating in Master mode.
In both modes, it can either log all commands, responses, and status reports, or it can provide an interactive command window which presents the same info, but also allows you to issue commands to the UCM (e.g. to turn lights on and off, perform actions or responses, change security mode, etc). It can also be used to upload and download the filesystem image. Periodically, I take a backup image of the filesystem on the server. Once, I had to use a backup when the EEPROM mysteriously erased itself, and I got the system back up and running very quickly (once slychiu had diagnosed that the problem was a corrupt filesystem, and when I looked at it, every byte had been set to 255).
I use this with a daemon permanently running in Master mode on the local unix server which logs everything and enables Slaves to attach. Off-site, I have a Slave daemon which connects across the Internet and also logs all activity in realtime off-site, so that even wrecking everything on-site will not lose logs leading up to such an event.
Anyway, maybe this gives you some ideas.
|
| Posted: Thursday Jul 26th, 2012 02:32 am |
|
27th Post |
ident
Administrator
| Joined: | Wednesday Aug 9th, 2006 |
| Location: | Singapore |
| Posts: | 3493 |
| Status: |
Offline
|
back to top
|
Thanks for the information. That is quite impressive
|
| Current time is 01:51 am | Page:   1 2 |
|
