HAI Omni IIe
- Thread starter nexus99
- Start date
HAI_fjh
Active Member
You can't and it shouldn't be necessary necessary. The Omni only replies to messages sent to it. The Omni uses the inbound routing information in the packet to determine the return route and therefore does not need to know things like the subnet mask or default gateway of the network. It is however important that the IP address you assign to the Omni is valid for the subnet.
Most of the time when I hear this question someone is having difficulty setting up port forwarding, and as stated above this is not the problem.
What are you trying to accomplish and why do you think you need to set the default gateway?
Most of the time when I hear this question someone is having difficulty setting up port forwarding, and as stated above this is not the problem.
What are you trying to accomplish and why do you think you need to set the default gateway?
This is interesting... so, if I have three different subnets, how would I access the Omni if it is on a separate subnet? Bridging would probably work here, but is that the suggested way?
HAI_fjh
Active Member
If the subnets are set up correctly the router should handle it.
Networking 101: I want to send a packet to some address. I use the subnet mask to determine if the address is local, i.e. on my subnet. If it is I send the packet to the recipient. If the address is not on my subnet, I send it to the default gateway (router). The router then figures out where the packet needs to go next. In this case the delivery is dependant on the router configuration.
The Omni never sends a packet that is not a response to an incoming packet. The Omni never has to look at an address and figure out if it is local or not, because is has the routing info from the incoming packet. It uses this information and sends it back along the same path.
If you have multiple subnets, are they connected by a real router and is the router properly configured? By "real router" I mean not a < $100 home gateway type router. These are simplified routers that are designed to route between the Internet and one internal network. Most can not route between multiple internal subnets.
The other question I have, just out of curiosity, is why do you have multiple subnets. Are we talking about a condo or assisted living center with multiple units?
Networking 101: I want to send a packet to some address. I use the subnet mask to determine if the address is local, i.e. on my subnet. If it is I send the packet to the recipient. If the address is not on my subnet, I send it to the default gateway (router). The router then figures out where the packet needs to go next. In this case the delivery is dependant on the router configuration.
The Omni never sends a packet that is not a response to an incoming packet. The Omni never has to look at an address and figure out if it is local or not, because is has the routing info from the incoming packet. It uses this information and sends it back along the same path.
If you have multiple subnets, are they connected by a real router and is the router properly configured? By "real router" I mean not a < $100 home gateway type router. These are simplified routers that are designed to route between the Internet and one internal network. Most can not route between multiple internal subnets.
The other question I have, just out of curiosity, is why do you have multiple subnets. Are we talking about a condo or assisted living center with multiple units?
That's what this thread is about, how do you configure the default gateway?
I personally have multiple subnets, 1 for wireless (which is totally locked down), 1 for video, 1 for regular LAN use, and I am planning on adding another one for home automation appliances.
There are also people who have vacation homes, and configure an IPSEC tunnel between the 2 homes in order to be able to monitor their vacation home while at their regular home.
In an IP network, each device only needs to figure out the "next-hop" problem: "if this isn't my packet, which directly connected host can I give it to so that it makes progress towards its destination?" The Networking 101 describes the usual operation of a source-and-sink network host: that is, a host that both accepts connections from other hosts and opens new connections to other hosts. In the case of opening new connections, the originating host must figure out a way to get network packets to the destination host. A default gateway tells the originating host what a good next-hop destination is. That next-hop is usually a router, who's job is to connect two logically distinct networks -- at appears as a local host on both networks. (This is not always the case -- I use a "choke and gate" technique to ensure very high security in some networks).
In the case that a host never opens new connections to other hosts, a default gateway isn't needed. This is because that host will always be a destination for the first packet from some originating host. That packet will have either come directly to it (because the originating host is on the same network, that is a local host) -- in this case no gateways are needed at all. If that originating packet came from a host on a logically distinct network, it must have come through some local host (probably a router). In that case, the OmniIIe assumes that the router who passed the initial packet onto the network can also pass the reply packets back. So a gateway is kept for each connection, derived from the initial packet for each connection. Hence, no default gateway is needed.
Although I recognize the advantages of this strategy:
- programming the network stack is (arguably) simpler and less error-prone
- if offers greater obscurity (and potentially security) because the originating host needs to know in advance that the OmniIIe exists and what it's address is
- the OmniIIe cannot transmit status messages all by itself (e.g. email) except to an already-connected host
- if the routing host fails, Omni cannot work around the failure: already-connected hosts are dropped, and must reconnect on their own
- if your network is asymmetric (ie. the router can't actually send the reply packets back to the originating host) then you're dead in the water (fortunately this is rare outside of telecomm internal infrastructure and other TS/SCI cases)
In an IPSEC environment, the remote system must connect via the tunnel to the OmniIIe and constantly check the connection. Then the IPSEC tunnel setup will make the securely transmitted packets appear on the OmniIIe's local network from the IPSEC router, and the OmniIIe will reply through the IPSEC router who will get the replies back to the originating host. The OmniIIe can never tell the originating host that the connection failed, except through a dead-man communication pattern: the OmniIIe would have to regularly generate a message, and if the originating host ever stopped getting them it would know the connection (or the OmniIIe) died.
Chris Dutchyn
can connect, it also offers some disadvantages.
aard3
Active Member
Dan,
Forgive me ahead of time for this explanation...my network theory is a little rusty... :wacko: :wacko:
As Fred said "The Omni never has to look at an address and figure out if it is local or not, because is has the routing info from the incoming packet.".
When the Omni receives the packet, it receives the IP address of the device that originally sent it, AND the MAC Address of the actual device on the network Omni's network that sent it...in this case... the "default gateway". This is all part of the ethernet header and IP header in the packet.
When the Omni responds, it uses the Clients IP Address as the Destination IP, and uses the "default gateway" or router's MAC Address as the destination.
What happens is that the "default gateway" or router sees that the packet is addressed to his MAC address. So he grabs the packet, and takes over from there on figuring out where to send it (to the other subnet, off to the internet, etc).
Now **IF** the Omni was INITIATING a connection with a PC that was on a different subnet, he would HAVE to know the Address of the "default gateway" ahead of time, so he would know who to send the packet to, but since the Omni never initiates a connection, it always gets that information from the actual packet it received.
Hope that helps.
Aaron
EDIT: I just saw Chris's excellent post, he pretty much hit the nail on the head, and much more eloquently than I. Everyone goes read his post.
Dan,
Forgive me ahead of time for this explanation...my network theory is a little rusty... :wacko: :wacko:
As Fred said "The Omni never has to look at an address and figure out if it is local or not, because is has the routing info from the incoming packet.".
When the Omni receives the packet, it receives the IP address of the device that originally sent it, AND the MAC Address of the actual device on the network Omni's network that sent it...in this case... the "default gateway". This is all part of the ethernet header and IP header in the packet.
When the Omni responds, it uses the Clients IP Address as the Destination IP, and uses the "default gateway" or router's MAC Address as the destination.
What happens is that the "default gateway" or router sees that the packet is addressed to his MAC address. So he grabs the packet, and takes over from there on figuring out where to send it (to the other subnet, off to the internet, etc).
Now **IF** the Omni was INITIATING a connection with a PC that was on a different subnet, he would HAVE to know the Address of the "default gateway" ahead of time, so he would know who to send the packet to, but since the Omni never initiates a connection, it always gets that information from the actual packet it received.
Hope that helps.
Aaron
EDIT: I just saw Chris's excellent post, he pretty much hit the nail on the head, and much more eloquently than I. Everyone goes read his post.
I am indeed working on getting port forwarding set up for Snaplink.
My network is a simple 192.168.1.x class C and the HAI is static on .201. I assumed that the IP config might be wrong on the HAI... but if all you do is set the IP then...
I have several other port forwardings set up that all work. For whatever reason the TSP forwarding I have for the HAI isn't working. I have verified that snaplink can access the HAI panel from the internal LAN with no problems.
Any suggestions?
Nexxus99-
There are 2 quick tips that may help resolve your problem that I do not see emphasized in any of the preceeding posts (I am old and don't read that quickly so I apologize for missing anything above):
1. Connection Type - when you set up port forwarding, the connection type "must" be either UDP or TCP/UDP. Most modern router want to defauly to TCP (only), which will not work with the current versions of Snap-Link and PC Access.
2. Public IP Address - when attempting remote acces, you are using your public IP Address and not using your controller IP Address in the Snap-Link file, correct? This kept biting me initially. I finally created two different files - one for local access and another for remote access.
There are 2 quick tips that may help resolve your problem that I do not see emphasized in any of the preceeding posts (I am old and don't read that quickly so I apologize for missing anything above):
1. Connection Type - when you set up port forwarding, the connection type "must" be either UDP or TCP/UDP. Most modern router want to defauly to TCP (only), which will not work with the current versions of Snap-Link and PC Access.
2. Public IP Address - when attempting remote acces, you are using your public IP Address and not using your controller IP Address in the Snap-Link file, correct? This kept biting me initially. I finally created two different files - one for local access and another for remote access.
I was able to work out the issue with the port forwarding on my router finally
Snaplink is now quite snappy indeed.