Any Way for Elk to work with a Mac?

[Madcodger]

I've raised this issue in the past, but have received no answers from our friends at Elk (which, frankly, really surprises me so here I go again...):

I CANNOT ACCESS MY ELK VIA THE M1XEP USING MY MAC.

When I try, I'm told the control is busy (it is not). It works just fine with both an XP or Vista Windows machine from either within the network or from remote locations, and I can access it well using eKeypad Plus on my iPhone. But it simply isn't accessible with my preferred computer, a Macbook. I've tried using both Safari and Firefox, and I get the same problem. Others have reported the same, but no one seems to have an answer. So, I'm asking our friends at Elk or anyone on the board if perhaps they have an answer to this. It seems odd that with the increasing popularity of Macs and a well-established, existing user base that Elk can't or won't resolve this issue. Thanks in advance for addressing this.

Joe

 

[nov0798]

HMM, I just type in the IPp address of the M1XEP, and it goes straight there, using Firefox, and Safari??

 

[wuench]

HMM, I just type in the IPp address of the M1XEP, and it goes straight there, using Firefox, and Safari??

And after you login with your passcode what happens?

I am seeing the same behavior, Control Not Responding... I tried to take a sniffer trace to get to the bottom of it. It looks like the browser(firefox) is talking to the control ok. So it doesn't appear to be a firewall issue. Unfortunately that's as far as I can get because it is all SSL encrypted. The last packet I see is from the PC to the control, so it could be a timeout of some kind.

If someone know of a way to force the java calls to use the unencrypted port, I could probably narrow it down further...

 

[Madcodger]

You make a very good point, Wuench. In the past it's been recommended that we just set our login and pw so that they are not needed, but that's not a reasonable solution, IMO. I mean, it's a security system, so I don't want the keypad code to be the only thing that prevents someone from accessing the system; that would be like leaving your doors open and just setting the motion detectors inside the house - a very bad idea.

I can also get as far as the point where the access code has to be entered, and then I get the "control busy" message. Gotta be a way for Elk to address this easily, I'd think.

Joe

 

[wuench]

You make a very good point, Wuench. In the past it's been recommended that we just set our login and pw so that they are not needed, but that's not a reasonable solution, IMO. I mean, it's a security system, so I don't want the keypad code to be the only thing that prevents someone from accessing the system; that would be like leaving your doors open and just setting the motion detectors inside the house - a very bad idea.

I can also get as far as the point where the access code has to be entered, and then I get the "control busy" message. Gotta be a way for Elk to address this easily, I'd think.

Joe

It has to be an issue within the Java client they use since the behavior is common to both browsers. I updated my Java to the latest and enabled the logging console. All the logging ends after the applet launches, which ends in Success. There is no info logged after that, like when you enter your code. I can't think of anything else to try. It looks like it is something that ELK or some savvy java programmer would need to debug. These days with how easy it is to build a hackintosh, they should be able to get this working w/o investing any money in an actual Mac.

I gotta say, I friggin HATE java. It's supposed to be universal, but there are constant versioning and platform issues. I am sure this can probably be chalked up to that.

 

[signal15]

If you disable the 401 authentication, it works fine on Mac. Of course, it wouldn't take much to bruteforce the passcode if that was the only authentication with it exposed to the internet. A 6 digit code would take a maximum of 56 hours to brute force, and a 4 digit code would only take a maximum of 34 minutes. If you have multiple codes, divide each of those times by the number of codes you have configured for access.

I disabled mine, but it's not exposed to the internet. I have to VPN into my network to gain access to it. This is a more secure solution anyway. Depending on what equipment you have, you should be able to set up a VPN server and use certificates to keep your iphone connected to your internal network when you are not at home. A standard linux box should be able to act as a VPN server, I use a Juniper SRX.

Another option would be to create a reverse proxy, and use certificate authentication to gain access to it. Then you just load the certificate on your laptops and iphone that you'll be using to access it. Here's an old document on how to do it. Method is similar for later versions of Apache:
http://www.impetus.us/~rjmooney/projects/m...ntcertauth.html

You could go one step further and use mod_security for another level of protection.

I found a bunch of M1's exposed to the net using a creative google search. The Allegro RomPager web server software running on it has had some vulnerabilities in the past, and mine happens to be running version 4.01. 4.34 seems to be the latest. I don't think I would expose it to the net directly.

 

[wuench]

If you disable the 401 authentication, it works fine on Mac. Of course, it wouldn't take much to bruteforce the passcode if that was the only authentication with it exposed to the internet. A 6 digit code would take a maximum of 56 hours to brute force, and a 4 digit code would only take a maximum of 34 minutes. If you have multiple codes, divide each of those times by the number of codes you have configured for access.

I disabled mine, but it's not exposed to the internet. I have to VPN into my network to gain access to it. This is a more secure solution anyway. Depending on what equipment you have, you should be able to set up a VPN server and use certificates to keep your iphone connected to your internal network when you are not at home. A standard linux box should be able to act as a VPN server, I use a Juniper SRX.

Another option would be to create a reverse proxy, and use certificate authentication to gain access to it. Then you just load the certificate on your laptops and iphone that you'll be using to access it. Here's an old document on how to do it. Method is similar for later versions of Apache:
http://www.impetus.us/~rjmooney/projects/m...ntcertauth.html

You could go one step further and use mod_security for another level of protection.

I found a bunch of M1's exposed to the net using a creative google search. The Allegro RomPager web server software running on it has had some vulnerabilities in the past, and mine happens to be running version 4.01. 4.34 seems to be the latest. I don't think I would expose it to the net directly.

Yeah, it's not a good idea to expose any embedded web server these days. It's strange that the authorization would cause the issue, maybe the auth info isn't getting passed through to the Java app. I know if you tunnel to 2601 it is pretty much the same as 2101 except it prompts for the username/password (and it's encrypted). If you have the non-secure port open (2101), then you lose nothing in turning off authentication on the secure port.

But it would probably be best if Elk fixed it at some point, and did some cross platform (linux,winders,OSX) testing in the future. Users shouldn't have to worry about stuff like this.

 

[signal15]

If you disable the 401 authentication, it works fine on Mac. Of course, it wouldn't take much to bruteforce the passcode if that was the only authentication with it exposed to the internet. A 6 digit code would take a maximum of 56 hours to brute force, and a 4 digit code would only take a maximum of 34 minutes. If you have multiple codes, divide each of those times by the number of codes you have configured for access.

I disabled mine, but it's not exposed to the internet. I have to VPN into my network to gain access to it. This is a more secure solution anyway. Depending on what equipment you have, you should be able to set up a VPN server and use certificates to keep your iphone connected to your internal network when you are not at home. A standard linux box should be able to act as a VPN server, I use a Juniper SRX.

Another option would be to create a reverse proxy, and use certificate authentication to gain access to it. Then you just load the certificate on your laptops and iphone that you'll be using to access it. Here's an old document on how to do it. Method is similar for later versions of Apache:
http://www.impetus.us/~rjmooney/projects/m...ntcertauth.html

You could go one step further and use mod_security for another level of protection.

I found a bunch of M1's exposed to the net using a creative google search. The Allegro RomPager web server software running on it has had some vulnerabilities in the past, and mine happens to be running version 4.01. 4.34 seems to be the latest. I don't think I would expose it to the net directly.

Yeah, it's not a good idea to expose any embedded web server these days. It's strange that the authorization would cause the issue, maybe the auth info isn't getting passed through to the Java app. I know if you tunnel to 2601 it is pretty much the same as 2101 except it prompts for the username/password (and it's encrypted). If you have the non-secure port open (2101), then you lose nothing in turning off authentication on the secure port.

But it would probably be best if Elk fixed it at some point, and did some cross platform (linux,winders,OSX) testing in the future. Users shouldn't have to worry about stuff like this.

They should just open-source the code for the applet. It hasn't been updated forever, and this way they'd get some free development. It's not like anything that it does is some proprietary secret, all of functionality is documented.

 

[apostolakisl]

You could remote desktop into a pc from your mac and run it that way. It's not the most elegant solution but I am sure it would work.

 

[mustangcoupe]

They should just open-source the code for the applet. It hasn't been updated forever, and this way they'd get some free development. It's not like anything that it does is some proprietary secret, all of functionality is documented.

The only thing not documented is the secure port information and the encryption.

 

[signal15]

They should just open-source the code for the applet. It hasn't been updated forever, and this way they'd get some free development. It's not like anything that it does is some proprietary secret, all of functionality is documented.

The only thing not documented is the secure port information and the encryption.

It's standard SSL. The port acts exactly the same as 2101 after you negotiate.

 

[Madcodger]

I went back into the Elk forum and found that in August, they "acknowledged the reported problem" and reminded me that the interface was never tested on a Mac. They also noted that the Java interface for the Elk was going to be replaced. No timeline was given, though. So, we appear to be stuck unless someone can figure out a way around this other than disabling online security. Very disappointing for those of us who prefer Apple products, and frankly, very un-Elk-like, IMO. I've always been a raving fan, but this has me concerned.

 

[mseicshn]

This thread is a year old and the issue seems to remain. I cannot access this ip on my network from my iphone or ipad. Tell me that isn't true!

 

[signal15]

This thread is a year old and the issue seems to remain. I cannot access this ip on my network from my iphone or ipad. Tell me that isn't true!

It works with a mac if you disable user/pass authentication on the XEP. It will still have the passcode auth.

It will not work with the iPhone/iPad since it's a Java applet. I'm pretty sure that Apple won't allow a JRE on those platforms. Look into the ELK M1 program for the iPhone/iPad. It's like $40 for the cheap version and works great.

 

[Madcodger]

In other words, the issue remains. Really disappointing...