Jump to content

New ISY-friendly Elk M1 firmware 5.2.2 release


simonw

Recommended Posts

Posted

Greetings

 

Elk has publicly released firmware versions 4.6.2 and 5.2.2 today.

 

Release note point 8: 8. Resolved a timer issue having to do with a Universal Devices “ISY-26/99†interface.

 

Release note point 12: 12. Found and fixed a problem that prevented external applications such as ElkRM, IPhone, and the M1XEP WebServer from

being able to arm to the STAY mode. This problem popped up in firmware 4.6.0 and 5.2.0, making it necessary to release these new version 4.6.2 and 5.2.2.

 

Simon

 

PS - I'm hoping this spurs the next steps for the ISY's Elk module development!

Posted

Thanks for sharing, Simon. I've had issues with timers myself and will be checking it out.

Posted

I upgraded my Elk to 4.6.0 and then 4.6.2 and it broke many IP related functions on the Elk. It no longer will talk to the ISY, it does not allow me to remotely arm the system. In fact, it appears that it causes the ISY to totally lock up. I have to reboot the ISY before I can browse to it.

 

Everything worked fine until I upgraded the Elk. I upgraded because it was suppose to help with the ISY integration.

 

I am running .15 on the ISY.

 

Anyone else having problems with the Elk after the upgrade?

Posted

My upgrade to 5.2.2 left me having to re-do some settings in the Elk too, notably the ISY's communication port 2101 needed turning back on.

 

I have had some ISY freezes necessitating power cycling the ISY to recover it, but that has been intermittent and always when I was simultaneoulsy connected with ElkRP.

 

There was also a new M1XEP Ethernet module upgrade that I tried but rolled back because that caused me a lot of communication problems.

 

A round of reboots and re-checking settings did seem necessary to make it work.

 

All this makes me really want to see some progress on smooth Elk/ISY integration with the much anticipated Elk module.

 

Michel - any news on the Elk module?

 

Simon

Posted

Hi,

 

My first goal is to send a link to this topic to our contacts at ELK. Perhaps they know something that we can use to fix the freezing issues since that takes precedence over everything else.

 

We are working on the ELK module ... we are much closer.

 

With kind regards,

Michel

Posted

What were you running prior to updating. I just updated all of my firwares about 2 months ago to 4.5.24 and 1.3.10 on the xep.

 

I see that they now have 4.6.2 for the m1g but the xep 1.3.10 is still the same.

 

I experienced no troubles at all with my upgrade. It did take about a half hour before everything got all happy together after the upgrade but have had no problems since.

 

So I don't think the xep firmware is, on its own, a problem, must be how it is playing with your new m1g firmware. I also have the most recent isy firmware.

Posted

Elk Products will be investigating this issue. Because it is so new, we don’t have much information yet. If anyone can provide details to help us replicate the problem consistently, that would be very beneficial. In the meantime, try simply rebooting the M1XEP alone or, if that doesn’t help, reboot the M1 and M1XEP simultaneously. Also, please verify that the M1XEP’s settings (IP address, port numbers, etc.) are correct in ElkRP and “SEND†them to the M1XEP again.

 

Thank you,

Don Lamb

ELK Products, Inc.

Posted

Don, Michel, apostolakisl,

 

Thanks for your input and tips.

 

Let me do some lengthy explaining so my setup and issues are documented for all to see and so we're on the same page. I just had to power cycle my ISY again (could not ping or anything), so I do have some issue here.

 

For the record, my ISY system is a 99i/IR/PRO (1050) running 2.7.15

I have Network and WeatherBug modules currently installed. I also have the TouchLinc web interface installed but I'm not using it right now and would be happy to uninstall it for debugging if I knew how.

 

My Elk system is:

System Type: M1G

Hardware Version 0.13

Boot Version 3.3.6

Firmware Version 5.2.2

Voice List Version 0.8

M1XEP firmware - where can I read this from?? My Elk installer tells me that he did go back an re-install the "latest" version after previously rolling it back to check some problems. Don't see where to grab the version info though, sorry.

 

The ISY is on IP x.y.z.112, the M1XEP on x.y.z.101 using the default ports (2601/2101) with the non-secure port enabled.

 

Both ISY and Elk successfully send me "heartbeat" emails each morning.

 

The M1XEP is set up to use a static IP address for some voodoo reasons of DHCP giving the correct IP/mask/gateway but wrong DNS server so I have to use static to be able to send test email messages or connect to NTP. I haven't played with this since updating the firmware but really I would like to make this work on DHCP. I already use a MAC address to reserve an IP for the Elk anyway. Seems like I have to enter my actual Comcast DNS IPs and not just the gateway address which seems to be fine for some devices.

 

Basically everything works well for automation and security and I have been pretty pleased with this setup, especially being able to use "turn on for x minutes" which I never could under Elk firmware 5.1.24 and earlier.

 

Not everything is perfect. Especially scary is the Elk date stamps: As far as I can tell my Elk system clock is 24 hours ahead of the true local time. Right now the newest log entry says Wednesday 5/26/2010 Time 21:38, when my local time (chosen city was San Carlos, California) is actually Tuesday 5/25 at 21:40. That's a whole day wrong - I had heard of problems with DST or time zone but not this. I just did an NTP test, passed so the clock is surely "right" as far the Elk is concerned.

 

I have the time server pointing to pool.ntp.org which is what works for the ISY and works for the Elk (at least as far as "test passed" messages coming up). This is actually what is recommended by ntp.org in their web pages _despite_ the Elk's documentation to the contrary. This is another area it would be good to clarify. Maybe the Elk could use the ISY as a time server?

 

Another weird M1XEP thing is that I can't "find" the M1XEP from the M1XEP setup window but all the IP address looks correct and I can "Connect" to the system over the network from the main ElkRP menu (Elk RP 2.06)

 

What goes wrong is that automation seems to stop - motion sensors no longer control switches etc. This is happening once every few days.

 

My ISY is not a happy camper either. Maybe this is because I have been adding switches and removing a lot of Insteon wireless devices during a re-wiring project. Some of the Insteon wireless stuff is probably still powered up but talking to nowhere since I have done "remove permanently from MyLIghting".

 

My ISY admin console (http://my.isy.ip/admin) sometimes stops responding and after a while a Java SocketTimeoutException comes up. This just happened again and I can't ping the ISY now. Another power cycle I guess ...

 

How can I best proceed to help troubleshoot these issues and move forward? I am prepared to wipe the ISY if it helps but of course I hope that's not necessary.

 

Cheers,

 

Simon

Posted

NTP update:

 

I sync'd my Elk clock with my PC clock and got it back to the right day. A subsequent test of the NTP connection was passed and the system reported updating the Elk's clock. But the day stayed the same (correct).

 

I guess this is good but it makes me wonder what is going on when the Elk says it passed the NTP setup test and updated the clock *but failed to correct the day*?

 

Bit strange. Does it make sense to someone who knows the Elk's workings? Does it just ignore NTP corrections if they are outside a certain range? Did my 24 hour discrepancy happen once manually by human error and not get corrected by NTP connection this way??

 

Cheers,

 

Simon

Posted

Hi Simon,

 

This must be quite frustrating ...

 

Would it be possible to disable ELK in ISY for a few days. This, at the least, isolates ELK/ISY integration as the issue.

 

With kind regards,

Michel

Posted

Simon,

 

M1XEP firmware - where can I read this from??

Connect to the M1 using ELK-RP and select the “Send/Rcv†-> “Enroll/Update Control and Devicesâ€. A window will pop up with the list of devices and version numbers.

 

The M1XEP is set up to use a static IP address …

I recommend that you keep the M1XEP assigned to a static IP; otherwise it might change if assigned DHCP. If that happened the ISY would not have the correct M1XEP IP address.

 

I have the time server pointing to pool.ntp.org which is what works for the ISY and works for the Elk (at least as far as "test passed" messages coming up).

The M1XEP does not support NTP pool protocol. There was an earlier version of the M1XEP firmware that incorrectly indicated the test passed even when it didn’t. I’d recommend updating the M1XEP to the latest but at the least select a Stratum II time server. The M1XEP only supports SNTP (Simple-NTP).

 

Another weird M1XEP thing is that I can't "find" the M1XEP from the M1XEP setup window but all the IP address looks correct and I can "Connect" to the system over the network from the main ElkRP menu (Elk RP 2.06)

We also would like to find out why you can’t find the M1XEP. Are you familiar with the PC network protocol analyzer program Wireshark? If you could capture the network data while performing the find procedure and email the screen capture to ELK Tech Support, it might help in troubleshooting.

 

What goes wrong is that automation seems to stop - motion sensors no longer control switches etc. This is happening once every few days.

Are the motion detectors you are referring to connected to the ELK or are they Insteon motions?

 

Regards,

Don Lamb

ELK Products, Inc.

Posted

Hello Don,

 

Thanks for taking a look at this.

 

My hardware/boot/firmware versions are;

 

M1XSP : 0.3 / 1.0.1 / 1.0.42

M1XEP : 1.0 / 1.1.4 / 1.3.10

 

Good enough or should I update these before going much further?

 

The broken automation is a lack of control of Insteon devices regardless of whether the trigger should have come from another Insteon device through the ISY or the from the Elk via rules and the Lighting configuration.

 

I will check into Wireshark and post again.

 

Cheers,

 

Simon

Posted

Don,

 

My failure to "find" my M1XEP turns out to be a Windows firewall thing.

 

I used Wireshark and saw some traffic coming back from the M1ZXEP's IP address to the PC's address and added thr port for that traffic to the firewall exceptions list (both TCP and UDP - which one is actually correct?)

 

That fixed it. Thanks.

 

To further help debugging I have blown away any Elk rules that reference Insteon devices. I have cleared all the lighting data too.

 

My NTP is now pointing to an open access stratum 2 server on the west coast and it passes the test.

 

That's pretty good progress. Can you advise on the software versiosn I should have?

 

Simon

Posted

Simon,

 

I'm glad to hear that you got the M1XEP's "find" and time server issues resolved. Both TCP and UDP are used between ELK-RP and the M1XEP. UDP is used for the "find" broadcast.

 

Your M1XEP has a boot firmware version of 1.1.4. Version 1.2.0 is available for download on the ELK M1 Dealers website. Two binary files are contained in the M1XEP_Update.exe download (boot and app). If you update the M1XEP's boot firmware you will then need to follow that by loading the application firmware.

 

Regards,

Don Lamb

ELK Products, Inc.

Posted

As a side note - I'm not sure it relates to ISY but I use the UltraM1G plug-in under homeseer. It communicates with the M1G via the M1XEP. The newest version of that failed without getting the updated boot and firmware for the M1G. Once that was updated all worked well.

 

mark

Posted

I've had a good week with my Elk and ISY-99i both working just fine independently.

I've updated my boot firmware as Don mentioned on the Elk so I'm all up to date with firmware on both Elk and ISY.

 

Fantastic, no flakiness for a week. So tonight I decided to re-introduce the two systems by entering the Elk's IP address and port 2101 into the configuration panel in the ISY's admin console. Checked "disable all on/off" and clicked "save". That was the last I heard from my ISY. Now it is totally unresponsive, can't telnet or even ping it.

 

Surely this is no coincidence. I was running the admin console from my Mac with the applet invocation (http://my.isy.ip/admin).

 

I am more convinced than ever there is something not rock-solid about my Elk/ISY interaction. Both systems have been sending me heartbeat emails and performing well on the network. The ISY has been running programs and letting me log into the admin console just fine. Right up until I entered the Elk's IP address ...

 

Obviously I'm going to have to power cycle the ISY, but what next?

 

Thanks in advance!

 

Simon

Posted

a few questions...

 

What happens when you enter http:\\elkipaddress in the browser? This is the easiest way to see if your Elk is indeed accessible at the IP you think it is.

 

I'm sure you know this but the IP for your Elk is an internal IP, right? like a 192.168.xxx.xxx or 10.xxx.xxx.xxx or 172.16.0.0 -> 172.31.255.255?

 

Does that IP in ISY config match the IP in the lower right corner of your ElkRP account details window?

 

Does it match the IP in the TCP/IP connection window of your M1XEP?

 

You wrote that your Elk is on static IP address - what is the address? (leave out the last digits if it makes you feel better)

 

Do you have any port forwards set up in your router that relate to the same IP as the Elk? ie are you forwarding requests destined to your Elk IP to somewhere else?

 

Do you have any firewall rules that may be blocking communication?

 

Is your DNS server entry valid in the M1XEP window?

 

Is 'Enable non-secure port' checked in the M1XEP window? - you checked this earlier - just confirm

 

I'm running hardware version .13 boot 3.3.6, firmware 5.2.2 - my m1xep is on hardware 1.0 boot 1.2.0 firmware 1.3.10. Prior to this firmware release I did not see my M1XEP firmware version shown in the status window - it was blank. With my combination of hardware, boot and firmware I'm running with no problems at all.

 

If you are having DNS issues then either your router is not set to take your ISP DNS server via DHCP or you have the address set incorrectly in a static situation. In a 'normal' situation your router will acquire an IP via DHCP from you ISP - it will also acquire a primary and secondary DNS server. Internally your network would normally use your router as the gateway AND as the DNS server. If you're running in a Domain environment then you may have your own DNS server but you haven't mentioned that so I'll assume it's not the case. In general, though, you would have your router IP as both the gateway and the DNS Server. You should NOT have to specify your ISP dns server unless for some reason your router was not forwarding DNS requests - which it normally would.

 

I wouldn't reserve an IP using the mac address - I would simply specify the IP as static. You may be creating some kind of access restriction based on mac address somewhere in your router and not even realize it - router firmware often has many pages of access restrictions, some of them based on mac address. Also - if you've inadvertently typed the mac address incorrectly then you will have reserved that IP for a non-existent device.

 

I would simplify matters to help troubleshoot. If you are running your router as, say, 192.168.0.1 then give your Elk a static IP of 192.168.0.100, with a DNS server and gateway address of 192.168.0.1. No secondary DNS server address is needed. If that resolves it then great - if not, at least you know it's 'something else'.

 

Finally, and again forgive me if this is 'obvious' but your ELk, your ISY, and your Router all share the same IP range and subnet masks, right? I've seen people have their router on 192.168.0.1 while their NAS is on 192.168.1.10. I've also seen people inadvertently leave the subnet mask on a device at 255.255.255.10 instead of 0. It's easy to make a typo and if something doesn't match then nothing talks and it's hard to figger out why. I've also seen (actually I did this myself but it's embarassing) one end of one network cable plugged into the ethernet port while a different end of a different cable was plugged into the wall. The little things are so often the 'gotchas'

 

mark

Posted

Hello Mark,

 

Thank you so much for troubling to reply and with so many good things to check.

 

Looks like I have all the same versions of firmware etc. that you mention.

 

The bit I'm least clear on is the router internals, partly because I'm using an Apple Time Capsule in that role and it's not as widely blogged or documented as some routers. I can well believe that some unintentional setting there has me hosed, although I note that most of the time things are fine. I am open to replacing the router with a "known good" wired model if there are any recommendations.

 

My Elk is at 172.16.1.101, the ISY at 172.16.1.112, my router at 172.16.1.1. And if I browse to the Elk's IP address I do indeed get the Elk panel Java applet come up after a short delay.

 

I am reserving the ISY's and the Elk's IP addresses by MAC address in the router. The ISY works on DHCP and gets the right reserved address every time, but on the Elk side it is simply set to "static". That means I have to set the mask and DNS server manually. I just re-use the 255.255.255.0 that I see on my other devices and hope this never changes. Is that going to be good enough?

 

For the DNS server entry on the M1XEP though I am using the IP address of the Comcast DNS server (67.78.x.y) which is indeed picked up by my router through DHCP. I am deliberately not using the router IP address (172.16.1.1) for the DNS setting because I can only send emails from my M1XEP if I give it the Comcast DNS server. I have not re-tested this with the latest M1XEP firmware, though. For testing I will go back to the router's 172.16.1.1 address.

 

I do have some port forwarding set up that should send incoming traffic on certain ports to the Elk. I can access the ISY like this but have never yet succeeded in accessing the Elk though. I will delete these port forwarding rules for testing the system.

 

Let's see how it goes. It already seems OK after rebooting the ISY, but I am concerned I'll be bitten again if I don't figure out what causes these "panic attacks" in the ISY.

 

Thanks again,

 

Simon

Posted

It sounds like everything you're doing is right and the fact that you can access the java applet on the Elk means you have the right port and subnet mask.

 

It shouldn't matter that you're using the comcast DNS server address in the M1XEP as that setting should only be used by the M1XEP for resolving time servers and email servers for outbound emails. For inbound communication no name resolution should be necessary so I don't see a problem there. It is interesting, though, and wonder why it is so. I have no experience with Apple products so I can't help there - but there's likely a setting for forwarding unresolved DNS queries in your router. Is this the same way your PC is set up? Do you have the DNS address from DHCP as the address of the ISP? If that's the case then perhaps you've statically sert the DHCP address in the router which is then serving it up via DHCP to clients? Regardless - I don't see why that would matter.

 

I'm afraid I'm at a loss. With no experience with Apple hopefully someone who does will chime in. It does sound like a firewall or forward setting that's not right.

 

Good luck. It does, indeed, work very well - and I have no doubt you'll find the right setting.

 

mark

Posted

Actually, one thing does jump out at me that may be significant.

 

You say that you can't access your Elk from an external IP despite your port forwards? That indicates an issue.

 

It looks to me like the Elk is running its web server on port 80 - which is the default for http. Could it be that you're forwarding port 80 requests to the ISY? or to some other device? Also make sure that you're not trying to forward port 80 more than once - you can't forward external port requests to more than one device even though your firmware will likely let you. You'll get unexpected results if you do.

 

UDI recommends that you not use port 80 for WAN communication - but rather the secure port they run on 443 so if you're using your ISY from the WAN you'll want to make sure that you're forwarding a port to the ISY on 443 and access it that way from remote. Forwards can get confusing so you have to make sure they're set right. The key thing is that when you just type http:\\myhomeipaddy your browser will attempt a connection on port 80. If your router is forwarding port 80 requests to, say, the ISY on 443 then that's what will open by default (though in this case it will open an https session)

 

If you want to access a device that IS serving on port 80 then you must forward incoming port 80 requests to that device. So your router would have a forward set up for 80 incoming from the WAN to be forwarded to port 80 on an internal IP address. This won't happen without you manually setting it up.

 

If you want to access your Elk from the WAN - and I'm not sure if it's using a secure port so forgive me if I'm only giving you an insecure port example - you would have to set up your port forward for a different port number - something like this:

 

Incoming port - 8000 (just an example - you can use any number other than like 25, 110, 80, 443 and a few others)

Forwarded IP - your Elk IP

Forwarded port - 80

 

Then when you want to access your Elk from externally you would type in

 

http:\\ElkIPAddy:8000 to get to it.

 

Anyways the point of this is that INTERNALLY - like with ElkRP - you'll be talking to it through 2101 or 2601 so the port forwards you have set up won't matter. But externally - like connecting from the internet - it matters very much. If you are running several devices that all have web servers on port 80 then you'll have to set up different forwards internally for each device and access them via different ports from the internet. To further complicate matters you have to make sure your ROUTER isn't taking port 80 for remote administration.

 

I have a bunch of these in my home - a DVR security camera system on port 80, the Elk on 80, the ISY on 443, my router on 8081, a web server on 80 and Homeseer on 80.

 

I have forwards set up so that it looks like

incoming port request/ internal ip/ internal port

8080 dvrip 80

8081 isyip 443

8082 routerip 80

8083 homeseerip 80

8084 webserver 80

 

so from remote I type in http:\\myipaddress:8080 for the dvr, 8081 for the isy, 8082 for the router, 8083 for homeseer, and 8084 for the webserver. The router forwards the traffic to the right device and I just have to remember the 8080-8084 range when I'm travelling.

 

mark

Posted

Mark,

 

That's really a very helpful detailed set of notes - thank you!

 

I can confirm now that my M1XEP email and NTP do work with the router's IP address entered as the DNS server. That's new to me in the 1.2.0 boot and/or 1.3.10 firmware. It still works with the Comcast DNS servers entered too, FYI, but it does not work if I leave the DNS entry blank.

 

This is some progress toward understanding the setup - with this new M1XEP firmware the DNS server entry at least looks the same as on all my various other devices. Only the router itself now has the Comcast DNS server IP addresses.

 

Can you clarify that I should be trying to access the Elk on local port 80 (not 2101 or 2601) when trying to get a browser to reach the control panel from outside my local network? i.e. the port forward should be

 

external.router.ip:8080 -> internal.elk.ip:80

 

Does it matter if I forward both TCP and UDP? It's not an exclusive on-or-the-other thing?

 

I notice the M1XEP panel in ElkRP says to forward port 2601 if you are accessing from outside the local network. Is that for using ElkRP as opposed to the web browser applet kind of connection? So that would be

externalip:2601 -> internalip:2601, but is that "as well as" the port 80?

 

Definitely getting somehere here!

 

Cheers,

 

Simon

Posted

Yes - it's just the way you said.

 

Devices like ISY and ElkRP software will communicate with the Elk on 2101 or 2601. The java applet seems to run on 80. I haven't confirmed this but if I simply enter the IP in my browser then it goes to the Elk which should only happen by default if the Elk is on 80.

 

I'm glad your DNS entry is now your router - that makes more sense. The reason it can't be blank is that when your device looks for an address like one of the S2 time servers for the Elk it needs to translate the name to an IP which is what a DNS server does. That's why the DNS IP must be specified - not a name here - as it's the 'go-to' guy of the DNS resolution process.

 

What you wrote here isn't really what you want

external.router.ip:8080 -> internal.elk.ip:80

 

The port forward shouldn't specify an external IP - it should be just blank - so that a request from any IP to port 8080 will forward to your internal.elk.ip:80. If you specify an external IP then the router will only forward the request if it comes FROM that IP. In your case you're specifying the IP of the router which is an internal IP address - so the router will never see that in an incoming packet and the forward will never happen. The reason for that being there is for security - say you want to Telnet into your network but ONLY from your office and not allow anyone else access to your system. You could set up your router to only forward port 23 telnet traffic to your telnet machine IF they come from your office - otherwise just drop them.

 

Likely you only need TCP and not UDP but it doesn't hurt to forward both

 

Get rid of any external IP's in your port forwards - that's your next issue.

 

mark

Posted

Hello Mark,

 

I think I have the port forwarding all working now; thanks very much for your patient help.

 

For me the biggest "oh! ...." moment was seeing that I need to forward two ports to the Elk to get this to work smoothly - 2601 _AND_ 80.

 

And it _almost_ works, too. The last problem may not even be port forwarding:

 

I can get through to the Elk, get asked for the M1XEP password, get the blue Elk applet "loading" screen but then I always get an error message after a long delay - it says "can't connect, another device may already be connected".

 

I am not aware of any other device that's connected. The ISY isn't. ElkRP isn't.

 

Curiously though my ISY doesn't want to acknowledge the Elk now either. If I enter the Elk's IP address and port 2101 on the ISY config page I'm not getting the alarm buttons pop up at the top of my ISY GUI like I should. And my ISY has gone into this mode where it won't show me programs ... a separate posting for MIchel but possibly related? That problem more likely Mac related, at least I hope so.

 

Any idea what to try and fix the final hurdle, the last-second can't connect failure?

 

Thank you so much!

 

Simon

Posted

hmmmm... I'm not sure what the can't connect could be. That sounds like a session open from somewhere else. Perhaps a task left running that you are unaware of?

 

In Windows you'd look at the Taskmanager and see if there are any processes running that may be using the Elk. I'm not sure what the equivalent would be on a Mac. I guess the easiest way to check this theory would be to shut everything off including the Elk, the ISY, and your PC then turn them on one by one. Elk first - then your PC. See if you can connect - then the ISY - see if you can still connect - and so on. You might even want to go so far as to disconnect the network cables from the router so you know what devices are talking at any given moment.

 

I'd also be tempted to doublecheck that you don't have port 80 forwarded to two different places as that could cause this confusion too. The packet handler in the router may get messed up.

 

Judging by your ISY's inability to communicate with the Elk I'd guess you still have some port forwarding issues. Did you remove the external IPs like I mentioned in my previous post?

 

The port forwarding table should look like this

protocol....source address... external port...internal port...internal address

TCP/UDP.. ............8080...............80................ElkIPAddress

TCP/UDP.. ............8081...............443..............ISYIPAddress

 

You should NOT be forwarding 2101 nor 2601 as you will only be accessing them internally not on the WAN. Remove any forwards for those ports. That's probably what's messing up your comm with ISY. I would think that unless you have some other devices - like security cameras - or if you have some remote administration software or a web server running then the above two lines will be about all you'll need in your port forwarding table. Most software uses UPnP so it doesn't need forwards set manually.

 

This will allow you to access your Elk by http:\\yourhomeipaddress:8080 and your ISY by http:\\yourhomeipaddress:8081. From inside your home you will be able to access your Elk simply by http:\\elkipaddress

 

Let me explain what forwarding is for - it will help you to get this set up, I'm sure.

 

Your router creates a virtual machine between your internal network and the internet. Requests for data flow around the web via data sent to IP addresses. Your Router presents an IP address to the web that is assigned by your ISP. Your internal machines all have internal IP adrdreses in the restricted private range. This serves an important purpose - noone outside of your router can directly access any of your machines - they can ONLY access your router.

 

Each IP address can handle data on 65,535 ports. Web servers send and receive their data on port 80 - which is why browsers all default to port 80. FTP data is sent on port 21, Telnet on 23, SMTP on 25, POP on 110 and so on.

 

So let's say you have something like ELK running on port 80. You type in http:\\homeip in your browser from a friends house. The request goes to your router - your router goes 'huh?' because it doesn't know what to do with a request for port 80. So it drops it.

 

Here's where port forwarding comes in. You set up a forward so that when your router sees a request from ANY ip looking for port 80 it will forward it to port 80 on address 192.168.0.1 (or whatever your internal elk ip is). Now when you type in http:\\homeip from your buddies house the router goes oh.. port 80? yeah - that goes over to the elk and sends the data to the Elk.

 

The even cooler part is that say you don't want anyone who knows your IP address to be able to even LOOK at your elk screen. You could set up a port forward instead so that port 8081 forwards to port 80. In that manner you could go to your friends house and type http:\\homeip:8081 and the request would go to your router which would see a request on 8081 and send it to your ElkRP but on port 80. It would continuously flip-flop the 80 and 8081 as necessary. If you typed in just plain old http:\\homeip it would send it to the router on port 80 and once again the router would say 'huh?' as it's not got a record for 80 - just for 8081.

 

The 'huh?' is because the address of your elk is NOT your homeip. It's an internal IP so the data is going wan -> routerip/port ->elkip/port and back again. There's no way for the wan to directly contact your elk because the address of the elk is not visible to the wan - the address is only visible to the router and the other machines on the same internal network and same IP range. Indeed there are probably millions of people with devices on 192.168.0.1 or 192.168.1.0 as these are defaults for D-link or netgear.

 

Note that ElkRP and your ISY are NOT outside your network. Their requests are NOT forwarded. Inside your network you will be addressing them directly via their port numbers.

 

So inside your network if you type http:\\elkip then the port 80 web server on the elk unit will pop up. It's the same as typing http:\\elkip:80. Likewise if you type http:\\isyip then the port 80 web server on the isy will pop up. Again, same as typing http:\\isyip:80. No forwarding involved here.

 

Don't be discouraged. Before routers were commonplace it was typical for a computer to be directly connected to the internet. You would flash up your PC and your network card would, via DHCP, get an IP address from your ISP. This would make your computer a direct connection to the internet. So if you ran a webserver you just ran it on that machine and users would directly connect to your PC.

 

The problem is that every idiot on the planet that wanted to probe your machine could do so. In the first few years you could go to your file explorer window and type http:\\yourfriendsip and shazam you'd be browsing their hard drive. It was fun, but only for you.

 

Routers are a cheap and easy solution to that problem. If you didn't initiate the data exchange or the data isn't forwarded to a port that will handle it then any attempts to talk to your system are simply ignored by the router. It's much safer.

 

Anyways, hope that helps. If you're still stuck then if you can post your entire port forwarding table I can probably help you get this nailed.

 

mark

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...