Home AMX User Forum AMXForums Archive Threads AMX Applications and Solutions

Remote or local connection - how to get this info?

Hello everybody,
I have this problem - iPad is connecting to central controller from local network and also from remote network. I need to know, from where is actually connected - to allow or disallow some functions. There is a GET_IP_ADDRESS(dvTPDealer, MyIPAddress) command, but there is a problem: when iPad is in some remote network, which has the same local setting like my local network with connected NI unit, there is no chance to find out with GET_IP_ADDRESS command, if TP is connecting from local or remote network (I know that probability is very small, but there is some).

See this:
my local network : 192.168.0.1-255, SM:255.255.255.0, TP has IP 192.168.0.2, connecting to NI unit on 192.168.0.1 - then GET_IP_ADDRESS give me:
host: test-ipad, addr: 192.168.0.2, mask: 255.255.255.0

local network of my friend - the same settings: 192.168.0.1-255, SM:255.255.255.0, TP has also IP 192.168.0.2, but connecting remotely to NI unit on public IP Address, let's say 188.243.x.y - then GET_IP_ADDRESS give me:
host: test-ipad, addr: 192.168.0.2, mask: 255.255.255.0

So, there is no difference and I do not know, if TP is connected from local or remote network...

But, when I look into Diagnostics window during both try - I can see, that there is difference when I disconnect:
In first case (locally connected) I receive massage: CICSPTCP Rx connection to 192.168.0.2 has been closed locally or by peer
In second case (remotely connected) I receive message: CICSPTCP Rx connection to 188.243.x.y has been closed locally or by peer

This is exactly what I need to know! So, is there any way how to get this info? Like I said, GET_IP_ADDRESS does not work....

Thanks for any suggestions...

Comments

  • You could consider using a different IP range for your local network like 192.168.201.x

    Therefore the GET_IP_ADDRESS command can work the other way by looking for a local match and then excluding all other combinations of IP address.

    192.168.0.x isn't exclusively the default setup for routers, I've seen 192.168.1.x, 192.168.61.x 10.0.0.x as default setups for various brands.
  • Thanks for reply!

    Yes, you are right, but as you also for sure feel, it is not clear solution, especially when I have not rights to change that setting (for exam: it is a big company network with own network administrator and my system is only small part of it)

    And in this moment I found out another problem:
    GET_IP_ADDRESS is NOT working properly when is used with iPad and iRidium software - has anybody the same experience? (TPControl and natural AMX panels are working with GET_IP_ADDRESS properly).
  • DHawthorneDHawthorne Posts: 4,584
    The only way I can think to do it isn't trivial. Have the master open a telnet connection to itself and look for that message, then parse it to see if it's an outside IP or not. The telnet connection would have to be open all the time, and once connected, you would have to issue a "msg on" command to make sure you get all the messages.
  • Two other ways come to mind.
    1) install a router/gateway that you can communicate with via terminal or other method and get all info about current connections.

    2) have the first page on the app show a welcome screen with a 'Select Location' option. One button for remote, one for in-house. This puts the connection option in the hands of the user.
  • Hello everybody, thank you very much for your answers. As I can see, there are only very difficult solutions - so, I have to offer them to my customer and I will see, what will his option...

    And what about iRidium and GET_IPADDRESS? Any ideas, experiences?
  • Would using DHCP with a reserved scope for the MAC address of the panel work?

    So on one network, it'll always get one IP address and when connecting to the other it'll get another IP address? Then you can determine where it is.
  • dchristodchristo Posts: 177
    You could try looking at Data.SourceIP in the Data_Event:Online handler for your panel. This works for IP sockets, but I'm not sure if it works with panels. Worth a shot, though.

    --D
  • You could go old school and add an AMX WAP250g just for the Ipad on local LAN. Open telnet to it, issue the 'get station' command to see if the panel is connected to the LAN. Assuming that if it is not connected to the LAN, it is WAN.

    Below is an example from a WAP250g

    AP login: Admin
    Password: *******

    ACCTON Access Point Rev v1.0.6.0
    wlan[0,0] -> get station
    *************************************************
    00:22:5f:60:c0:9d, State: associated, AID: 1, Virtual AP: 0
    Authentication Type: Open-System
    WLAN Mode: 2.4GHz 54Mbps (802.11g), nonERP present: NO, nonERP protected: NO
    Encryption: ON Keyflags = <dynamic,locked> framekey=0 pPriv =0x80c92760 WEP hwIn
    dex 12
    Ciphers: NONE(unicast), NONE(multicast), NONE
    Compression: OFF
    Power Save Mode: OFF
    WMM: Disabled
    Rx Data Rate: 54, RxSignalStrength: 48, AckSignalStrength: 46
    MSDU Data Mcast Mgmt Ctrl Errors
    Rx 170 170 0 2 0 0
    Tx 412 410 0 2 0 0

    *************************************************
    00:22:69:4e:9e:4f, State: associated, AID: 2, Virtual AP: 0
    Authentication Type: Open-System
    WLAN Mode: 2.4GHz 54Mbps (802.11g), nonERP present: NO, nonERP protected: NO
    Encryption: ON Keyflags = <dynamic,locked> framekey=0 pPriv =0x80c92950 WEP hwIn
    dex 13
    Ciphers: NONE(unicast), NONE(multicast), NONE
    Compression: OFF
    Power Save Mode: OFF
    WMM: Enabled
    Rx Data Rate: 54, RxSignalStrength: 35, AckSignalStrength: 38
    MSDU Data Mcast Mgmt Ctrl Errors
    Rx 120 165 89 2 0 0
    Tx 42 40 0 2 0 0

    wlan[0,0] ->

    You could do the same with any other WAP that supports telnet sessions. Do the look-up as part of the panel online event.
  • regallion wrote: »
    Would using DHCP with a reserved scope for the MAC address of the panel work?

    So on one network, it'll always get one IP address and when connecting to the other it'll get another IP address? Then you can determine where it is.

    Yes, but this is still not clear, because there should be the same address... It's a very small probability, but it is some... But thank you for reply...
  • dchristo wrote: »
    You could try looking at Data.SourceIP in the Data_Event:Online handler for your panel. This works for IP sockets, but I'm not sure if it works with panels. Worth a shot, though.

    --D

    It seems like a good idea. I really will try it... Thanks for suggestion.
  • PHSJason wrote: »
    You could go old school and add an AMX WAP250g just for the Ipad on local LAN. Open telnet to it, issue the 'get station' command to see if the panel is connected to the LAN. Assuming that if it is not connected to the LAN, it is WAN.

    Below is an example from a WAP250g

    AP login: Admin
    Password: *******

    ACCTON Access Point Rev v1.0.6.0
    wlan[0,0] -> get station
    *************************************************
    00:22:5f:60:c0:9d, State: associated, AID: 1, Virtual AP: 0
    Authentication Type: Open-System
    WLAN Mode: 2.4GHz 54Mbps (802.11g), nonERP present: NO, nonERP protected: NO
    Encryption: ON Keyflags = <dynamic,locked> framekey=0 pPriv =0x80c92760 WEP hwIn
    dex 12
    Ciphers: NONE(unicast), NONE(multicast), NONE
    Compression: OFF
    Power Save Mode: OFF
    WMM: Disabled
    Rx Data Rate: 54, RxSignalStrength: 48, AckSignalStrength: 46
    MSDU Data Mcast Mgmt Ctrl Errors
    Rx 170 170 0 2 0 0
    Tx 412 410 0 2 0 0

    *************************************************
    00:22:69:4e:9e:4f, State: associated, AID: 2, Virtual AP: 0
    Authentication Type: Open-System
    WLAN Mode: 2.4GHz 54Mbps (802.11g), nonERP present: NO, nonERP protected: NO
    Encryption: ON Keyflags = <dynamic,locked> framekey=0 pPriv =0x80c92950 WEP hwIn
    dex 13
    Ciphers: NONE(unicast), NONE(multicast), NONE
    Compression: OFF
    Power Save Mode: OFF
    WMM: Enabled
    Rx Data Rate: 54, RxSignalStrength: 35, AckSignalStrength: 38
    MSDU Data Mcast Mgmt Ctrl Errors
    Rx 120 165 89 2 0 0
    Tx 42 40 0 2 0 0

    wlan[0,0] ->

    You could do the same with any other WAP that supports telnet sessions. Do the look-up as part of the panel online event.

    Thank you for suggestion - I beleive it should be helpful, when I do not find some another way - there on that installation I have only problem, that there are several wifi points and due to it I take some time to ask all of them...

    But it's a good idea, thank you for it....
  • rcervenan wrote: »
    Yes, but this is still not clear, because there should be the same address... It's a very small probability, but it is some... But thank you for reply...

    No, that's the point. You can reserve a specific address for the client. You just need to make sure that each site has a different address reserved for it.
  • regallion wrote: »
    No, that's the point. You can reserve a specific address for the client. You just need to make sure that each site has a different address reserved for it.
    Sorry, but there is a problem - inside your network you can reserve what you need, but customer's iPad should connect to the system from remote networks, where you can not guarantee anything. It means, there is a possibility, that in remote network iPad get the same address like in your local network.
  • Ok I assumed you might have some control over the configuration in the remote location.

    Are there many remote locations with different network configurations?
  • regallion wrote: »
    Ok I assumed you might have some control over the configuration in the remote location.

    Are there many remote locations with different network configurations?

    Yes, customer is businessman and he is all the time travelling...

    But, in summary - I think the best-one 100% perfect- solution is here already mentioned above - use in my local network router with telnet enabled (or similar service) and ask it, if panel is connected to it - when panel is not there, then it must be connected from remote network...

    Anyway, regallion, without this router it is possible to make it like you wrote, it will be working for almost every situation.

    I make some tests today and I found out, that in ONLINE event DATA.SOURCEIP is working with iPad (iRidium) without problems, so in combination with MAC-IP addressing and not often used local range (for exam: 192.168.254.xxx) in my local network I will minimize potencial-conflict IP- problem to very small percent and in case the customer will still have problem I can offer him the solution with special router...

    So, thank you guys for every suggestions, it was very helpfull...
  • jweatherjweather Posts: 320
    rcervenan wrote: »
    I make some tests today and I found out, that in ONLINE event DATA.SOURCEIP is working with iPad (iRidium) without problems, so in combination with MAC-IP addressing and not often used local range (for exam: 192.168.254.xxx) in my local network I will minimize potencial-conflict IP- problem to very small percent and in case the customer will still have problem I can offer him the solution with special router...

    I would think the source IP would be your router IP in the case of an iPad connecting remotely. DATA.SOURCEIP is not supposed to be the TP's IP address on the LAN, it should be the source of the actual TCP packets coming in. As far as I can tell, this should completely solve your problem.
  • jweather wrote: »
    I would think the source IP would be your router IP in the case of an iPad connecting remotely. DATA.SOURCEIP is not supposed to be the TP's IP address on the LAN, it should be the source of the actual TCP packets coming in. As far as I can tell, this should completely solve your problem.

    Yes, that's what I was thinking too - BUT, UNFORTUNATELLY, IT IS NOT TRUE :(

    DATA.SOURCEIP returns definitelly IP Address of panel in network where is connected, and, I think, that this is a bug - in my opinion it should be like you wrote overhere... But, if it is like you described, this thread never began :)
  • viningvining Posts: 4,368
    rcervenan wrote: »
    Yes, that's what I was thinking too - BUT, UNFORTUNATELLY, IT IS NOT TRUE :(

    DATA.SOURCEIP returns definitelly IP Address of panel in network where is connected, and, I think, that this is a bug - in my opinion it should be like you wrote overhere... But, if it is like you described, this thread never began :)
    How are you remotely connecting, through a VPN or port forwarding? If the remote system is on the same LAN address then I assume you're port forwarding since VPNs need to be on different LAN addresses to connect.
  • vining wrote: »
    How are you remotely connecting, through a VPN or port forwarding? If the remote system is on the same LAN address then I assume you're port forwarding since VPNs need to be on different LAN addresses to connect.

    There I'm connecting using port forwarding on that installation... Look at following info:

    1. panel is inside local network with NI master unit:
    IP Address of panel: 192.168.88.187
    DATA.SOURCEIP returns: 192.168.88.187
    When I power off the panel I receive this message in diagnostic windows:
    CICSPTCP Rx connection to 192.168.88.187 has been closed locally or by peer

    2. panel is inside remote network without NI master unit - and it is connecting to master through port forwarding :
    IP Address of panel in that remote network: 192.168.105.14
    DATA.SOURCEIP returns: 192.168.105.14 (!!!!!?????)
    When I power off the panel I receive this message in diagnostic windows:
    CICSPTCP Rx connection to 188.243.x.y has been closed locally or by peer - it means the right one IP Address

    So, in my opinion, this is a bug, because I suppose DATA.SOURCEIP should return in second case 188.243.x.y, not 192.168.105.14. But, it does not, so, I have to solve it another way...
  • You may have to just bite the bullet and send a user prompt when the panel comes online: "Are you connected remotely?"
  • John NagyJohn Nagy Posts: 1,742
    You said in the original post,
    "But, when I look into Diagnostics window during both try - I can see, that there is difference when I disconnect:
    In first case (locally connected) I receive massage: CICSPTCP Rx connection to 192.168.0.2 has been closed locally or by peer
    In second case (remotely connected) I receive message: CICSPTCP Rx connection to 188.243.x.y has been closed locally or by peer"

    So the information you want can determined when the connection closes. Have you considered trying to programatically induce the closing of the connection and noting the message, then reopening and acting on what you found by parsing the connection closed message?

    Also, elsewhere on the forum, The TPC folk recently posted how to get various setup info that would ordinarily be on the setup pages that they don't render. One of those bits of info would be the actual IP address of the current connection. There's a chance if you ask them directly, they could help you form a query of the emulated panel that would return the information you seek.

    They might even have a status you could query to determine which connection the app is using... local or remote. I suggest you open a ticket at the Touch Panel Control website. It's worth the effort on the chance they can help. remember, they don't comb THIS site looking for opportunities to do unsolicited support outreach. Go to them.
  • John Nagy wrote: »
    So the information you want can determined when the connection closes. Have you considered trying to programatically induce the closing of the connection and noting the message, then reopening and acting on what you found by parsing the connection closed message?

    I have no idea, how to programmatically force panel to close connection and then from closed connection force panel to reconnect... So exists any guide how to do it?
    John Nagy wrote: »
    Also, elsewhere on the forum, The TPC folk recently posted how to get various setup info that would ordinarily be on the setup pages that they don't render. One of those bits of info would be the actual IP address of the current connection. There's a chance if you ask them directly, they could help you form a query of the emulated panel that would return the information you seek.

    They might even have a status you could query to determine which connection the app is using... local or remote. I suggest you open a ticket at the Touch Panel Control website. It's worth the effort on the chance they can help. remember, they don't comb THIS site looking for opportunities to do unsolicited support outreach. Go to them.

    Thanks for suggestion, I really will do it, when I will use TPC, but here in this installation we are using iRidium...
    And - I already asked iRidium team - unfortunatelly still without helpfull answer...
  • viningvining Posts: 4,368
    What if when the TP comes online you do DATA.SOURCEIP to get the TP's IP address and then through code connect to the master and ping that address. If the TP is on the local LAN it will respond but if not it won't.
  • Damn I've spent too much time messing with this!

    I've been playing with using Dynamic Images - now bare with me!

    I set up a panel with a dynamic image pointing to my master. I FTP'd a bitmap to the master and put the details into my panel's resources and created a button pointing the dynamic image.

    When the panel came online, the dynamic image was FTP'd off the master and showed on the panel.

    I then tried to query the button's bitmap details using ?BMP and CUSTOM_EVENTS but this is where I hit a brick wall as the ?BMP command returns an empty string with dynamic images it seems.

    My idea was that if the panel was local to the master, it would download the image from the master and then querying the button's image would determine if you were local or not. If you were remote (and assuming you were NOT port forwarding FTP), then the image wouldn't load and when you queried it you'd see it was blank and therefore remote.

    I don't know if anyone else can develop this concept further?
  • vining wrote: »
    What if when the TP comes online you do DATA.SOURCEIP to get the TP's IP address and then through code connect to the master and ping that address. If the TP is on the local LAN it will respond but if not it won't.

    Yes, at one moment I had the same idea, but problem is, that on local network should be (and for sure is) a lot of another equipments - so to ping should answer one of them... But yes, in case I receive IP address from the same range like my local network has, it should narrow possible problem...
  • viningvining Posts: 4,368
    rcervenan wrote: »
    Yes, at one moment I had the same idea, but problem is, that on local network should be (and for sure is) a lot of another equipments - so to ping should answer one of them... But yes, in case I receive IP address from the same range like my local network has, it should narrow possible problem...
    yeah that is true, there is a chance a local device could be on that IP so if you do recieve a ping response see if you can telnet into it or better yet when it comes online forget the ping altogether and go directly to telnet to see if you get the "Welcome to Modero....." from that IP. If you do get the "Welcome to Modero...." you got a local TP but if you get nothing or something else it's not a local TP that just connected on that IP.
  • vining wrote: »
    yeah that is true, there is a chance a local device could be on that IP so if you do recieve a ping response see if you can telnet into it or better yet when it comes online forget the ping altogether and go directly to telnet to see if you get the "Welcome to Modero....." from that IP. If you do get the "Welcome to Modero...." you got a local TP but if you get nothing or something else it's not a local TP that just connected on that IP.

    Yes, it should works, thanks for suggestions...
  • the8thstthe8thst Posts: 470
    rcervenan wrote: »
    Yes, it should works, thanks for suggestions...

    He mentioned this was for an iPad running TPControl, so there is no telnet functionality.

    I tested that yesterday because that was my idea for a solution as well.
  • Don't know about other software, but with TPControl it has an open port for transfers (port 10700). You can actually connect to this even though you probably can't do much with it.

    But making that connection alone should generate an online event you can use to determine if you've connected.

    I've only tried this with PC based telnet command so not tested with Netlinx / Online event, but the theory is sound.

    You'd probably want to sever the connection straight away afterwards otherwise you may prevent TPTransfer from working!
Sign In or Register to comment.