Need assistance with a long term network issue

Community Playground General Discussions
21

Setting up a VLAN seems like a rather heavy-handed approach to this problem, and not one all users can implement.

I’d much rather see an option in Vera to disable this behavior. I will never ever need it, and don’t want it cluttering up the network or logs with misguided attempts to contact the same non-servers over and over.
Specifically, this:

01      12/24/12 16:21:26.722   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/get_log.cgi <0x2c21f680>
01      12/24/12 16:21:26.738   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/get_log.cgi <0x2c21f680>
01      12/24/12 16:21:26.858   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/top.htm <0x2c21f680>
01      12/24/12 16:21:26.879   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/top.htm <0x2c21f680>
01      12/24/12 16:21:26.972   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/top.htm <0x2c21f680>
01      12/24/12 16:21:27.229   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/top.htm <0x2c21f680>
01      12/24/12 16:21:27.253   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/top.htm <0x2c21f680>
01      12/24/12 16:21:27.347   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/top.htm <0x2c21f680>
01      12/24/12 16:21:27.365   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/get_status.cgi <0x2c21f680>
01      12/24/12 16:21:27.378   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/get_status.cgi <0x2c21f680>
01      12/24/12 16:21:27.467   FileUtils::ReadURL 0/resp:404 size 0 http://192.168.42.145/get_status.cgi <0x2c21f680>
01      12/24/12 16:21:35.028   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/CgiTagMenu?page=Top&Language=0 <0x2c21f680>
02      12/24/12 16:21:36.103   ZW_Send_Data node 25 USING ROUTE 255.48.59.214 <0x2c41f680>
01      12/24/12 16:21:38.038   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/CgiTagMenu?page=Top&Language=0 <0x2c21f680>
01      12/24/12 16:21:41.048   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/CgiTagMenu?page=Top&Language=0 <0x2c21f680>
01      12/24/12 16:21:44.058   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/get_log.cgi <0x2c21f680>
01      12/24/12 16:21:47.068   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/get_log.cgi <0x2c21f680>
01      12/24/12 16:21:50.078   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/get_log.cgi <0x2c21f680>
01      12/24/12 16:21:53.088   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/top.htm <0x2c21f680>
01      12/24/12 16:21:56.098   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/top.htm <0x2c21f680>
01      12/24/12 16:21:59.108   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/top.htm <0x2c21f680>
01      12/24/12 16:22:02.118   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/index.html <0x2c21f680>
01      12/24/12 16:22:05.128   FileUtils::ReadURL 7/resp:0 size 0 http://192.168.42.38/index.html <0x2c21f680>
02      12/24/12 16:22:06.103   ZW_Send_Data node 26 USING ROUTE 255.120.116.214 <0x2c41f680>
22

I made a change that fixes this problem on my VeraLite.

In /etc/cmh is the file “network_pnp_sys.xml”. Make a backup copy of this file, and then gut it.
Remove everything between and , leaving it empty.

Now it doesn’t make outbound network requests at all.
YMMV, and Merry Christmas.

23

[quote=“GroundLoop, post:22, topic:173509”]I made a change that fixes this problem on my VeraLite.

In /etc/cmh is the file “network_pnp_sys.xml”. Make a backup copy of this file, and then gut it.
Remove everything between and , leaving it empty.

Now it doesn’t make outbound network requests at all.
YMMV, and Merry Christmas.[/quote]

Anyone have any luck with this method?

24

Simply using the UI-provided checkbox to not ‘auto detect devices on my home network’ has stopped that incessant chatter, as mentioned earlier in this thread. I haven’t needed to modify the xml.

25

Below is the way I got mine to work on my vera3lite. There was no vlaning or any other network crap to do.
Go into your vera3lite advanced network page (the link to the page was removed for vera3lite gui, it was present on the vera2).
Go into your web browser and type http://your vera ip address, ie 192.168.1.1/cgi-bin/webif/info.sh (just your ip address by itself after http://192.168.1.1/ should be written only)
The user name is root, your password may be on the vera3lite box itself (I can’t remember where I got my password from, but I believe I had to remote in or something. An easier way may be just to log a support call).
Next, go and click on the networking tab at the top.
From there, go and click the “dhcp and dns” tab.
There will then be a setting called “dns forwardings”. Type your routers ip address, ie 192.168.2.254 (whatever is your dhcp and dns device that you get your address’ from)
Press the save button at the bottom and no more problems.

The Onkyo issue is with the wrong dns settings. There was a firmware fix for the vera3, however this only fixed windows7 pc’s and not other devices. I don’t know why vera doesn’t automatically put the ip address of your router when you have set up the vera to be a dhcp client.

26

[quote=“bucket23, post:25, topic:173509”]Below is the way I got mine to work on my vera3lite. There was no vlaning or any other network crap to do.
Go into your vera3lite advanced network page (the link to the page was removed for vera3lite gui, it was present on the vera2).
Go into your web browser and type http://your vera ip address, ie 192.168.1.1/cgi-bin/webif/info.sh (just your ip address by itself after http://192.168.1.1/ should be written only)
The user name is root, your password may be on the vera3lite box itself (I can’t remember where I got my password from, but I believe I had to remote in or something. An easier way may be just to log a support call).
Next, go and click on the networking tab at the top.
From there, go and click the “dhcp and dns” tab.
There will then be a setting called “dns forwardings”. Type your routers ip address, ie 192.168.2.254 (whatever is your dhcp and dns device that you get your address’ from)
Press the save button at the bottom and no more problems.

The Onkyo issue is with the wrong dns settings. There was a firmware fix for the vera3, however this only fixed windows7 pc’s and not other devices. I don’t know why vera doesn’t automatically put the ip address of your router when you have set up the vera to be a dhcp client.[/quote]

This sounds like a promising fix. I have a request in to support to see if I can get the password to go with ‘root’, so that I can try it. Has this proven to be a reliable solution that continue to work for you through power cycles, etc., without any negative effects?

27

Whilst you are waiting from support. @futzle developed an app to retrieve the root password
http://forum.micasaverde.com/index.php/topic,7110.msg45228.html#msg45228

28

Whilst you are waiting from support. @futzle developed an app to retrieve the root password
http://forum.micasaverde.com/index.php/topic,7110.msg45228.html#msg45228[/quote]

Thanks for the help. I dug out the password via the Wiki procedure, using putty. Now to see if the suggested fix works for me.

UPDATE: Unfortunately, although I followed the instructions literally, using the router address for the DNS Forwarding address, the change didn’t help on my system.

I will go back to using a secondary router to put the Onkyo on a separate subnet. That approach has been working for me, but I’m really hoping for a solution that will allow both devices to coexist on the same LAN/subnet.

29

[quote=“GroundLoop, post:22, topic:173509”]I made a change that fixes this problem on my VeraLite.

In /etc/cmh is the file “network_pnp_sys.xml”. Make a backup copy of this file, and then gut it.
Remove everything between and , leaving it empty.

Now it doesn’t make outbound network requests at all.
YMMV, and Merry Christmas.[/quote]

I’d like to get at that file to examine it and try your approach, but I haven’t been able to extract it yet. Using http://:3480/data-request?id=file&parameters=network_pnp_sys.xml, I get no response.

I’v been able to pull out other known files in /etc/cmh with that HTTP command, but not this one. Is it possible the file name is slightly different, or is there another, better method available? I’ve been digging through the Wiki trying to find another way, or a way to get a listing of all of the files in /etc/cmh, but I haven’t found any.

30

I bet you’ve been able to pull files from /etc/cmh-ludl but not from /etc/cmh.

Happily you can provide … to go up to the parent directory. I shake my head as I write this.

http://vera:3480/data_request?id=lu_file&parameters=../cmh/network_pnp_sys.xml

Note underscores where you had hyphens. Also parameters plural not parameter.

31

I bet you’ve been able to pull files from /etc/cmh-ludl but not from /etc/cmh.

Happily you can provide … to go up to the parent directory. I shake my head as I write this.

http://vera:3480/data_request?id=lu_file&parameters=../cmh/network_pnp_sys.xml

Note underscores where you had hyphens. Also parameters plural not parameter.[/quote]

Thanks - that worked much better. I had actually got the parameter(s) & underscores right on the command, I just dropped it on my post. Obviously, I’m in over my head on my effort to work around this problem. I’ll try the suggestion to empty the file, but I’m not optimistic it will be the cure. So far, only the use of a secondary router has been successful for me.

The use of “…” to get to the parent directory was something I’ve not used before, but I’ll try to remember that. Now that I see the file contents, I have to wonder how it applies to my system, as it references nothing I actually have. Interesting.

32

I hope this gets resolved soon. I bought the Onkyo TX-NR515 about 3 wweks ago and I have to keep it off the network to avoid the conflict with Vera Lite. I cannot take Vera off the network. I have to make a decision soon as to whether to keep the Onkyo. If I can’t put in on the network because of the conflict with Vera, it has to go back. It’s a very nice receiver, but this is a show stopper.

33

Don’t hold you breath for a fix soon. There are a few solutions, to make them both play nicely, but you might be sending the unit back.

  • Garrett
34

Have you tried adding a second router, and connecting the Onkyo to it, to isolate it from the Vera? That is the only proposed fix that has worked for me so far, and it’s probably the easiest on to do, assuming you have an old, serviceable router laying around. I keep trying the others, but so far, I’ve had to go back to that approach as a temporary (I hope) workaround.

35

This sounds like a promising fix. I have a request in to support to see if I can get the password to go with ‘root’, so that I can try it. Has this proven to be a reliable solution that continue to work for you through power cycles, etc., without any negative effects?
[/quote]

Always works. Sometimes the onkyo (actually an Integra 50.1) will still have the network part greyed out, but a restart will fix it.

Did you go back into your vera settings to make sure the dns forwarding took. Sometimes (happened to me a couple of times) the setting would revert back to what they were.

Also, you can set your onkyo to a manual address, including dhcp and dns settings. This will of course fix the issue to.

36

[quote=“bucket23, post:35, topic:173509”]Always works. Sometimes the onkyo (actually an Integra 50.1) will still have the network part greyed out, but a restart will fix it.

Did you go back into your vera settings to make sure the dns forwarding took. Sometimes (happened to me a couple of times) the setting would revert back to what they were.

Also, you can set your onkyo to a manual address, including dhcp and dns settings. This will of course fix the issue to.[/quote]

Thanks for getting back to me. I’m pretty sure I had it set up as you instructed. The only change I made was to the DNS Forwarding address, which I changed from a blank entry to my actual router LAN address. I did go back several times after the change to confirm that it didn’t revert back to the previous setting. (I just checked it again - still set to the router address as I had inputted yesterday, or before).

I believe I had also previously tested the Onkyo with a Fixed IP address, rather than DHCP without improvement. I wonder if there might be enough of a difference in the FW between the Onkyo and Integra units that could cause a difference in their behavior. In any case, I’ll go back in and run through the whole process again in the morning to make sure I didn’t make any mistakes. It sure would be nice if someone else were to confirm good results with this approach on the Onkyo, but we will continue trying. I can always go back to the secondary router, which works reliably for me.

UPDATE: I just went through the whole cycle again. The combo of a fixed IP address on the Onkyo and the DNS Forwarding setting on the Vera to the router IP, seemed to buy me just a bit of improvement. I sometimes could get up to about 5 minutes of NET connection and streaming before it would freeze up again, and it did seem that I could sometimes, but not always recover with a Standby/On cycle.

I also tried the Onkyo fixed IP with the DNS Forwarding on Vera set to the DNS address that my ISP provides, with no apparent difference from how it had behaved using the router address. I finally set the DNS Forwarding value back to blank, which it had been initially, along with the fixed Onkyo IP address. That combination didn’t let me get through the initialization at all, so it seems that it did make some difference, but the result was not nearly stable enough to use, except for a brief test.

I’m thinking that there are some system config variables, along with possible FW differences in the receivers that are giving me different results from yours. Unfortunately, this solution won’t really work for me. I’m now back to my secondary router workaround, which has been 100% stable for days. I appreciate your help on this, and I’m glad the DNS Forwarding fix is working for your system.

37

Got mine to work by blocking upnp traffic. If your router (firewall) has the option, block ports UDP 1900 and TCP 5000 for all IPs. This should stop the problem. Check out this thread http://forum.micasaverde.com/index.php?topic=12420

38

I’ve tried all morning to get this approach to work, using the Linksys E3000 Access Restriction settings. No luck here.

It’s amazing to me that there are such a variety of solutions that work for some, but not others. I’ll keep going through the list to see if one will help, but at least I can revert back to the secondary router solution, which does work for me.

39

I forgot to mention that I don’t use the streaming function on my Onkyo. I just use the network section to do firmware updates.

40

The failure kills access to any network function, and the use of USB. I got my TX=NR717 just a couple of weeks ago, and I haven’t had any updates via the network, in fact the only one I needed to apply could only be done via USB, but I’m pretty sure the network updates would be impossible with no functional network connection.