Push events via IP protocol
Fov
Posts: 26
Hi there.
Is there any way to emulate BUTTON/CHANNEL events using IP protocol?
Netlinx master is able to be an IP server (~IP_SERVER_OPEN).
Have anyone tried that?
Is there any way to emulate BUTTON/CHANNEL events using IP protocol?
Netlinx master is able to be an IP server (~IP_SERVER_OPEN).
Have anyone tried that?
0
Comments
Then have the string handler for the data_event of the server parse out the channel number and do something like DO_PUSH or PULSE [vdvIpPanel,XXX] and code with CHANNEL_EVENTS.....
Another idea is to sneak a peek at the communication that is going on between Netlinx studio and a controller/touchpanel when 'control a device' is used. But so far i only get binary data that doesn't make much sense except for the ASCII representation of the time of the event.
Still working on it
If not emulate AMX protocol, why not to write my own?)
I'm having troubles with feedback.
Controlled device may (but shouldn't though) be able to report its state changes etc. I should return it back to my 'virtual panel' (I'm trying to emulate AMX Touchpanel) in such case.
So i must bring up both IP_Server (to receive commands) and IP_Client (to send feedback).
One more trouble on the way: IP_Server accepts incoming connection, accepts incoming strings, but shuts down upon client disconnect. How to keep server alive?
P.S. Thanks in advance. Sorry for my English
Both the server and client allow for two-way communication. So, you don't necessarily need two ports (one client and one server) going to make it work. Once you've set up a port you use SEND_STRING to send a message from the Netlinx master to the other device. Then use the DATA_EVENT to get messages back from the device.
I have found it best to make one or the other device responcible for maintaining the connection. When both devices are trying to reach each other, network slowness or glitches can send both units into fits.
Another good thing to do is build in a message que at both ends. There is going to be errors in any IP connection. You can drive yourself crazy trying to ensure a good connection. It's actually a lot easier and more reliable to just build in a good que system that will check incoming messages for accuracy and will patiently retry the send if somethign goes wrong.
I actually don't mind stopping and staring my IP connections. I have a program I wrote that stores all the channel names and numbers of Comcast, Time Warner Cable, Direct TV and Dishnet on a master here at my office. I call it the Mothership. All my client masters check with it regularly and see if their database is current. If not, the remote master will begin to download the new channel line-up. I set it up so that the masters only connect once for each cell of data. It goes a little slower, but the overall result is very accurate and doens't have to do a lot of overhead to check the data stream. If a cell fails, it just tries again until it gets it right.
You're situtation would probably require a constant connection for faster performance. But the principle should be the same. There are ways of knowing when the connection is dead. You can program one or the other to reestablish when it breaks. It would be important to know how both devices time out so you're not stomping on one or the other.
Well, that's enough advice from Captain Obvious...
Another stupid question)
STRING:
{
SEND_STRING 0, "'[!] SCTP Server is STRING: ', DATA.TEXT"
}
But when I telnet to server and send, for example, "Test", I get the following:
>[!] SCTP Server is STRING: T
>[!] SCTP Server is STRING: est
Why it is so and how to fix this to get '[!] SCTP Server is STRING: Test' instead?
The processor works faster than your fingers.
you need some kind of 'end of message' delimiter. That way the routine won't fire until you have the full message. A common end delimter is $0D (CR) or you can also add an $0A (LF)
So, your message could be " 'Test',$0D "
Then in your code something like..
IF(FIND_STRING(DATA.TEXT,$0D,1)) // we have the whole message
{
// NOW SEND THE STRING TO '0'
}
And one more thing:
Am I able to determine MAC and IP address of connected client?
MAC is preferrable
Yes,
if you highlight DATA_EVENT in Netlinx Studio and press F1, you'll be taken to the pertinent docs in the help files. Look for the DATA_EVENT event handlers. There's one for source IP. I don't know about incoming MAC address...
I think it's Data.SourceIP
But the question is still open: does anyone know how to get Client MAC-address?
I don't think so.
Now that you mention it, there should be no reason for not having it since it is coming in and is the part of the info coming in on the same layer as the originating IP address. You may have the makings of a good feature request for the next firmware version for NI masters.
MAC addresses can be spoofed. But it would be a great way to make very secure connections.
I'd like to get'em from Netlinx and in runtime ^^
The source MAC address in a TCP packet is not always from the other end of the connection, it's the previous hop on the connection. If your connection goes between subnets, the source MAC address will just be your nearest router.
What sorts of connections are you trying to secure?
Clients from same local subnet are connecting to a Server.
I want to implement some sort of MAC Filter, just like Wi-Fi APs do
An extremely simplified version would use XOR as an example -- when the server sends a challenge, the client must reply with the challenge XORd with the shared secret, say 997. So a challenge of 11243 gets a response of 10254. The server can verify this is the correct response without sending the actual secret across the network. An intruder sniffing the traffic has not obtained your password, and cannot send 10254 as the response to make his own connection to the server, since he will get a different challenge he does not know the answer to.
XOR is a poor algorithm because an intruder sniffing enough challenge/response pairs might guess at the algorithm, and then would be able to obtain the shared secret very simply. A secure protocol would use a cryptographic (1-way) hash, such as MD5 or SHA1 to create the responses. If the challenge was "abc" and the secret was "secret", the client's response might be md5("abc" + "secret"). Seeing only the challenge/response pairs on the network, even if the intruder knows the algorithm being used, he would not be able to obtain the secret without guessing -- trying literally trillions of possible combinations for the secret phrase until he comes up with the same answer. Of course, knowing the secret is sufficient to generate his own correct answers to any challenge, so the secret must be protected.
Of course, if you control the protocol, you can simply hope that it is sufficiently obscure enough that other people won't mess around with it, and in most cases you'll be right, unless you're in a university setting with bored CompSci students.
Since it's not possible or too difficult (without some hacks?..) with Netlinx, i'll be using
challenge-response mechanism
Thanks for the help