Jump to content

Network Resource Problem


wrj0

Recommended Posts

Those were my tired old eyes. Prowl's still working fine, thanks.

 

I wasn't referring to Prowl actually. From your post I got the impression (wrongly?) that the admin console for the newer devices (994i vs my 99i) includes an option in the networking module to verify the ssl certificate. You had (I thought) disabled this in order to get the network module to talk to Prowl, I was asking if you tried disabling the same setting when you attempt to have your unit talk to itself (since this feels SSL/cert related)...

Link to comment

Hello everyone,

 

Finally managed to recreate this issue. The problem is that the default certificate that comes with ISY cannot be parsed by ISY!!! (i.e. in this case, ISY is both the client and the server). This is a 994 issue with firmware above 3.2.6.

 

In addition, there's a bug in BouncyCastle whereby invalid certificates can indeed be generated. Put a workaround so, please go to http://www.universal-devices.com/99i/3. ... board.jnlp and regenerate your certificate.

 

Default certificate has also been updated so, in case you don't want to touch your configuration, you can simply upgrade to 3.3.9 to be out very shortly.

 

With kind regards,

Michel

Link to comment

Michel,

 

Many thanks for investigating and addressing this problem. Your support for the ISY products is truly outstanding.

 

Unfortunately, after upgrading to 3.3.9, I did not experience the same success as TJF1960 and continue to have the same results as before, both before and after creating new self-signed server and client certificates. Since others have been successful, I'll continue to work on the certificates to see if I can find a configuration that will work for me.

 

TJF1960: Glad to hear its working for you - gives me a glimmer of hope that I'll eventually find the cause of my problem.

Link to comment

I'm still unsure of why it never stopped working for me. I do remember creating a new certificate somewhere back in the early 3.3.x series and possibly that is related.

 

Hang in there wrj0 - I think your gettin close!

 

-Xathros

Link to comment

With some outstanding support from Michel (does he provide anything else?), my Internet Test Network Resource is finally working again. Something was amiss with my certificates, and my attempts to find a working solution failed until Michel got involved. In short, his recommendations were the following:

Client and server negotiate on the ciphersuites that can be used during the session. Your level for the server is low and the level for client is medium. If you look at http://www.universal-devices.com/docs/I ... 0Guide.pdf, you'll note that the intersection of ciphersuites that can be used between low and medium is ZERO:

Low Strength:

TLS_RSA_WITH_RC4_128_MD5

Medium Strength:

TLS_RSA_WITH_AES_128_SHA

TLS_RSA_WITH_AES_256_SHA

TLS_RSA_WITH_RC4_128_SHA

Please either use the same level or use levels that have one or more ciphersuites in common.

I had previously tried various combinations of Strengths for both Client and Server, but per Michel's suggestion, set both Server and Client Strengths to the same level (Medium or better Client setting is needed for Elk support). Additionally, Server Protocol was set to TLS 1.2, and Client Protocol to TLS 1.0.

 

There remained an issue with one of the Self Signed certificates, likely the Client certificate as it seemed it was not being validated by the ISY Server. So Michel recommended:

1. Make sure you clear your Java cache before you go to http://isy.universal-devices.com/99i/3. ... board.jnlp ... this is very important

2. Generate a self signed server certificate of 1024

3. Generate a self signed client certificate of 1024

I may not have been diligent at performing step 1. during my testing. So, Michel's instructions were followed explicitly, and after a couple of reboots the Network Resource is once again working properly, able to set or clear a variable.

 

Here's a BIG THANK YOU to Michel for revolving this issue and my frustration.

Thanks also to Xanthros and TJF1960 for their input and keeping me going on this.

Link to comment

wrj0, So glad you got it working!

 

I messed my cert. up a few months ago and was out of town before I realized I couldn't access the ISY thru Mobilink or Conductor. Once I got back Michel walked me thru deleting it..been afraid to mess with it since!

 

Very happy to hear, thanks for posting back.

Tim

Link to comment
  • 2 months later...

Well…I’ve managed to break the Internet Test network resource again. Argh!

This time, it’s my own doing – decided to upgrade my old router and install a Linksys E2500 with DD-WRT firmware. With the new router in place, the ISY-994 works fine, except it cannot set a variable using Xanthos’ Network Resource technique described previously in this thread. DD-WRT has more extensive configuration capability than that of the old router (as well as my ability!), so, I’m hoping someone can help with the configuration in the new router.

 

With the old router in place, the network resource works fine, so the ISY certificates seem to be OK.

ISY DNS is set to the ISP’s recommended DNS server; nslookup returns that URL.

 

With the new router in place (setup where possible to match the old router’s configuration),

Network Resource returns: “Error: Request failed.†and "N/A" in the Resource Response window.

ISY Event Viewer, Level 3 shows: “Network Resource: Failed connecting to my.dyndns.orgâ€

 

Using REST to set the same variable works fine from an outside PC, so port forwarding seems to be OK (setup same as in the old router).

ISY NTP and outbound email functions work fine with the new router in place. Other Network Resource functions (e.g. prowl notifications) also work properly.

Remote access to the ISY works fine from an outside web connection and from MobiLinc.

Except for this one Network Resource, everything else seems to be working fine.

 

I’ve tried changing several parameters in the new router, including turning off SPI and putting the ISY into a DMZ to see if there was a port problem – same result.

 

The new router is running firmware: DD-WRT v24-sp2 (06/08/12) mini - build 19342

DNSMasq is disabled.

 

Running the Network Resource and capturing the router log returns:

root@DD-WRT:~# cat /var/log/messages | grep 30.100

 

Mar 22 10:55:06 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=vlan2 SRC=192.168.30.100 DST=54.234.34.59 LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=27770 PROTO=TCP SPT=34720 DPT=48201 SEQ=4073191765 ACK=2888464856 WINDOW=4256 RES=0x00 ACK URGP=0

 

Mar 22 10:56:08 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=vlan2 SRC=192.168.30.100 DST=24.25.5.61 LEN=60 TOS=0x00 PREC=0x00 TTL=59 ID=27825 PROTO=UDP SPT=53 DPT=53 LEN=40

 

Mar 22 10:56:08 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=br0 SRC=192.168.30.100 DST=192.168.30.100 LEN=48 TOS=0x00 PREC=0x00 TTL=59 ID=27826 PROTO=TCP SPT=34743 DPT=443 SEQ=556354701 ACK=0 WINDOW=4644 RES=0x00 SYN URGP=0 OPT (0402010101010100)

 

Mar 22 10:56:10 DD-WRT kern.warn kernel: ACCEPT IN=br0 OUT=br0 SRC=192.168.30.100 DST=192.168.30.100 LEN=48 TOS=0x00 PREC=0x00 TTL=59 ID=27828 PROTO=TCP SPT=34743 DPT=443 SEQ=556354701 ACK=0 WINDOW=4644 RES=0x00 SYN URGP=0 OPT (0402010101010100)

 

Where, vlan2 is the router’s WAN connection to the cable modem, br0 is a bridge from eth1 to vlan1 (the LAN ports on the router), 192.168.30.100 is the ISY address, and 24.25.5.61 is my ISP’s DNS server.

 

So, after lots of head scratching and changing lots of router settings, I just can’t seem to find what’s wrong with the new router configuration to support this Network Resource in the ISY. It seems there’s something going on in the new router that prevents the ISY from sending the REST command and then looking for it’s own response. Perhaps an appropriate entry in the router’s iptables would do the job, but I’m at a loss and could use some help from the linux guru’s here.

 

Wonder if anyone else is using DD-WRT and has this Network Resource working?

 

Any suggestions will be greatly appreciated. Thanks.

Link to comment

Sure, Michel. Thanks. Will send the info via a PM.

Sorry for the delayed reply; changed to a new cable modem yesterday and it took almost a full day for the ISP to get it properly provisioned. (Tier 1 support said to wait 72 hours, check, then call back. Tier 3 this morning got it provisioned in less than 15 minutes.)

Link to comment

After a lot of reading about iptables, setting up forwarding rules and logs to track traffic, and putting way more time into Wireshark and WallWatcher than I should have this week, I could not discover anything wrong with the iptables commands or the router configuration. So, after resetting and rebuilding the router (twice), I finally tried flashing it with one of the new beta releases of dd-wrt. Bingo - the ISY resource that has given so much grief for the past week is once again working. (the ddwrt wiki-recommended build 19342 was problematic; build 21061 seems to be working fine)

 

Thanks again to Michel for reviewing my Wireshark capture and offering suggestions.

Link to comment

wrj0,

 

Thanks so very much for the update. It would still be interesting to know what actually caused the issue. Is there a list of things that were fixed in the new firmware?

 

The reason I ask is that lately we have had so many router related issues especially with exotic things like DD-WRT, Juniper, and Cisco ASxxx. Rebooting the router would fix the issue but only temporarily ... perhaps there's a common thread through all or perhaps I am just grasping at straws.

 

Anyway, thanks again for posting back.

 

With kind regards,

Michel

Link to comment

Michel,

There were several beta releases between the versions that I tested. I'm not sure exactly what change(s) corrected my routing problem, but will poke around in the dd-wrt forum to see if something stands out and will post back if something seems applicable.

Link to comment

Archived

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


×
×
  • Create New...