I have unplugged my vera2 after having started over 3 times on ui5 in as many months. When i add ping, Google weather and wake on lan, after some hours, days or weeks it seems to revert to a prior state with ‘apps’ (plugins) uninstalled and Dhcp server enabled. Grrrr… A rogue Dhcp server (vera) is bad! Also, I noticed that on ui5 it does not seem to be possible to enter the wrt ui, like was possible on ui4. Tips and suggestions would be appreciated.
EDIT: I forgot to mention that after dealing with issues with the network player features on my Onkyo, I seems that Vera is the casue. Grrrr!
A-ha! Well, your comment would lead me to believe that the cause was Google Weather… before we rule, it would be good to see any other responses. All I can say was that I was not happy that the DHCP server fired up all by itself… almost like the Vera auto-restored…
Not sure if this helps your situation and perhaps everyone already knows this, but I did not realize that (on my Vera2 with UI5) the UI5 network settings overwrite the openWRT page. I kept changing settings in OpenWRT only to have them go back to default.
I still use OpenWRT to set my static leases, but the primary settings are done in UI5.
I’ve also had trouble with my DSL modem login taking forever (not Vera’s fault) and during the time that Vera doesn’t have an internet connection it is very slow and flaky.
Any chance you can post the wrt url and any information on default credentials. I noticed that ui5 does not provide a link to the openwrt ui, like was the case in the prior uiX versions.
Ok, so I have an update on this. I left my Vera 2 unplugged for about 4 weeks and never had a problem on my network.
As soon as I reintroduced it the problem returned. I used the openwrt URL to ensure that dhcp server was disabled and no change. I suspected dnsmasq disabled it and still not change. An output of ps -fe below to show what is running.
[CODE]# ps -fe
PID USER VSZ STAT COMMAND
1 root 1444 S init
2 root 0 SW [keventd]
3 root 0 RWN [ksoftirqd_CPU0]
4 root 0 SW [kswapd]
5 root 0 SW [bdflush]
6 root 0 SW [kupdated]
8 root 0 SW [mtdblockd]
95 root 0 SWN [jffs2_gcd_mtd4]
120 root 1444 S init
160 root 1692 S syslogd -C256
162 root 1436 S klogd
175 root 708 S /sbin/hotplug2 --override --persistent --set-worker /
316 root 0 SW [khubd]
580 root 0 SW [loop0]
873 root 1440 S crond -c /etc/crontabs -l 5
935 root 1120 S /usr/sbin/dropbear -p 22 -P /var/run/dropbear.1.pid
1072 root 1452 S /bin/ash /usr/bin/Start_LuaUPnP.sh
1144 root 1440 S /bin/ash /usr/bin/Start_serproxy.sh
1162 root 1440 S /bin/ash /usr/bin/Start_NetworkMonitor.sh
1246 root 11032 S /usr/bin/LuaUPnP
1249 root 4316 S /usr/bin/NetworkMonitor
1262 root 1560 S /bin/ash /usr/bin/cmh-ra-daemon.sh
1327 root 1228 S ssh -p 232 -T -y -i /etc/cmh-ra/keys/cmh-ra-key.priv
1356 root 4316 S /usr/bin/NetworkMonitor
1359 root 4316 S /usr/bin/NetworkMonitor
1365 root 4316 S /usr/bin/NetworkMonitor
1367 root 4316 S /usr/bin/NetworkMonitor
1383 root 3472 S lighttpd -f /etc/lighttpd.conf
1391 nobody 864 S /usr/sbin/dnsmasq -D -y -Z -b -E -s lan -S /lan/ -l /
1399 root 1448 S udhcpc -S -t 0 -i br-lan:0 -b -p /var/run/dhcp-br-lan
1439 root 11032 S /usr/bin/LuaUPnP
1447 root 11032 S /usr/bin/LuaUPnP
1450 root 11032 S /usr/bin/LuaUPnP
1469 root 1428 S sleep 60
1534 root 1180 S /usr/sbin/dropbear -p 22 -P /var/run/dropbear.1.pid
1621 root 11032 S /usr/bin/LuaUPnP
1660 root 11032 S /usr/bin/LuaUPnP
1661 root 11032 S /usr/bin/LuaUPnP
1709 root 1432 S sh -c /usr/bin/sync_time.sh
1710 root 1500 S /bin/ash /usr/bin/sync_time.sh
1729 root 1444 S rdate -s ac-ntp1.net.cmu.edu
1734 root 1432 S sleep 5
1735 root 1444 S -ash
1736 root 11032 S /usr/bin/LuaUPnP
1741 root 11032 S /usr/bin/LuaUPnP
1742 root 11032 S /usr/bin/LuaUPnP
1743 root 11032 S /usr/bin/LuaUPnP
1744 root 11032 S /usr/bin/LuaUPnP
1745 root 11032 S /usr/bin/LuaUPnP
1746 root 11032 S /usr/bin/LuaUPnP
1747 root 11032 S /usr/bin/LuaUPnP
1748 root 11032 S /usr/bin/LuaUPnP
1749 root 11032 S /usr/bin/LuaUPnP
1750 root 11032 S /usr/bin/LuaUPnP
1751 root 11032 S /usr/bin/LuaUPnP
1752 root 11032 S /usr/bin/LuaUPnP
1764 root 1436 R ps -fe
[/CODE]
netstat output below:
# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:49451 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3480 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:1088 127.0.0.1:80 TIME_WAIT
tcp 0 0 127.0.0.1:1090 127.0.0.1:80 TIME_WAIT
tcp 0 0 127.0.0.1:49451 127.0.0.1:1089 TIME_WAIT
tcp 0 0 192.168.1.105:49451 192.168.1.105:1069 TIME_WAIT
tcp 0 0 192.168.1.105:49451 192.168.1.105:1077 TIME_WAIT
tcp 0 0 192.168.1.105:49451 192.168.1.105:1084 TIME_WAIT
tcp 0 268 192.168.1.105:22 192.168.1.102:50449 ESTABLISHED
tcp 0 0 127.0.0.1:3480 127.0.0.1:1091 TIME_WAIT
tcp 0 0 192.168.1.105:1026 173.254.216.41:232 ESTABLISHED
tcp 0 0 192.168.1.105:49451 192.168.1.105:1062 TIME_WAIT
netstat: /proc/net/tcp6: No such file or directory
udp 0 0 127.0.0.1:1024 0.0.0.0:*
udp 0 0 0.0.0.0:53 0.0.0.0:*
udp 0 0 0.0.0.0:67 0.0.0.0:*
udp 0 0 0.0.0.0:1900 0.0.0.0:*
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 7 [ ] DGRAM 370 /dev/log
unix 2 [ ] DGRAM 3463
unix 2 [ ] DGRAM 1233
unix 2 [ ] DGRAM 1186
unix 2 [ ] DGRAM 1143
unix 2 [ ] DGRAM 666
Here is a post that describes a conflict between Onkyo and Vera with regards to upnp.
You need to be connected using the reverse proxy via cp.mios.com. This means that you should see https://fwd1.mios.com in the address bar.
SETUP, Net & Wifi
Select the following options:
“Directly to the Internet. Vera is a Gateway”
What type of connection do you have: “DHCP” (this is the WAN port Eth1 that is connected to your LAN)
“Firewall Active” (this is the key right here)
LAN DHCP Server = “On” (we should be able to connect to the Eth2 and get a DHCP from the Vera if we ever want to do that)
Wireless = “No”
Click Save and apply and WAIT (notice the browser will be waiting) until you see the restart messages in the Net & wifi dialog window. AFTER you see that you may also see the RED save button, which you can click. You’ll be prompted that the save completed and to click Continue.
IMPORTANT: Go back to Net & Wifi and confirm that your selections are still there. If not, repeat the above steps and remember to follow the WAIT step above.
The residual issue that I am working on is to add port forwards on the Vera WAN Eth1 (the house LAN) port to the Vera LAN Eth2 port IP address (192.168.81.1) so that we can maintain http and ssh access to the Vera without having to use the reverse proxy connection to the Vera. So far the GUI is not cooperating, so I will be connecting to the Eth2 port to test maing these changes next.
UPDATE: SO I can confirm that connecting to the Eth2 port on Vera 2 using the above config gets you a DHCP from Vera. This then enables you to navigate to the Open WRT page (http://192.168.81.1/cgi-bin/webif/info.sh) and configure port forwarding (from the Vera WAN IP to the Vera LAN IP). However, the port forwards don’t work, or that the Vera doesn’t allow ports to be forwarded to itself and a special firewall rule is still required. So, some work remains.
The alternate approach that would require changes on the home network, is putting Vera into a separate subnet on the home LAN. This would require work on the home network routing or putting the home network behind a router (firewall). This isn’t my favorite choice as has dependencies external to Vera. I want a solution internal to Vera! Thus far, tech support are unresponsive to my tickets… so I’ll keep working on this and see if I am able to cross the finish line by doing additional reading and research.
2
Based on JJWATMYSELF description of the issue I placed Vera 3 and Vera to linked by ethernet on a subnet behind another router (firewall) with holes for port 80 and 8080.
The results are:
My Onkyo TR-NR808 works properly for the first time since installed. It now works with the internet radio, intranet mediaserver and IP remote control.
If you have not, go do it now… we need them to fix this problem ASAP and only getting tons of complaints will get them to pay attention. At minimum, I want them to give us a way to turn off uPnP
I just sent in a ticket…
I need to know how to turn of uPnP completely. The Vera's uPnP is killing my Onkyo receiver's networking capabilities. Please see this thread and the problem affects everyone owning an Onkyo receiver made in the last 2 years.
Wow… this is brilliant troubleshooting folks! I have spent the last few months frustrated with my TX-NR818 not able to connect out. I called Onkyo support to troubleshoot and eventually reset the system and it was never fixed. Their thought is it was a hardware issue. I have literally spent 24 hours over a couple of months trying to figure this out. Switching out network gear, cables, factory resetting the Onkyo twice and various others.
I could get a DHCP address, but nothing more… As soon as I turn off “Auto Detect Devices” on my Vera Light, everything worked perfectly fine!.
I find this thread after a few months of hell. I sent my Onkyo TX-NR3009 in for repair not once but TWICE. It was not at all immediately obvious that the Onkyo broke when the MiCasa (VeraLite) went in. Switches, cables all manner of things replaced.
The FW in this thing must be fixed! I’ve never seen something so offensive on the network. Not just the Onkyo either. WOL packets that shouldn’t happen and other strange things. iRule doesn’t control it correctly which I begin to blame on the MiCasa more than iRule (but I’m admittedly jaded right now).
I found this thread searching for Onkyo and MiCasa problems. Only after I verified without doubt that the MiCasa had to be unplugged for the Onkyo to work.
I had the same problem with my vera 3 that I just installed a week ago. This should not be default behavior. The device should come up assuming it is a client on my network. I realize the device is built on a wireless router platform, but the software should not assume that users need these features upon initial power-up.
Onkyo/Integra have released an official fix! It seems to be only as a USB update, I have been struggling for a while with this issue doing the update as I type, hopefully all goes well.
Good luck with everyone else and hopefully your model has a firmware update!
so glad i got a Yamaha 600Watt amp a year ago instead of the onkyo … i’d be pullin my hairs out if it did this sorta crap… fo real. besides that the audioquality is unmatched.
