fios set top boxes

This has nothing to do with vera SENDING packets.

When the FIOS boxes renew their lease (or the network reboots) they see the vera lite as a router. It is this reason that the boxes go into a loop requesting a network address from the Vera. Like any other network device they should move on in the routing table after a few failed attempts however that does not happen, thus the continuous loop.

Either 1) FIOS boxes recognize what the vera is, and thats just never going to happen.

or 2) The vera stops acting as a router to any ip/mac address that we program it to ignore. (then it will just forward the packets along to the router).

Vera can fix this easily, Verizon surely will never even flinch at the small amount of us.

If it’s boot-time interference, then folks may want to read this older thread:
http://forum.micasaverde.com/index.php/topic,9895.0.html (Vera Lite)

and later in the thread for Vera3 units also:
http://forum.micasaverde.com/index.php/topic,9895.msg175478.html#msg175478 (Vera3)

I only saw it because I changed primary router, and it responded a tiny-bit slower than the original one… just enough for Vera to get in and answer DHCP requests on it’s WAN interface.

It may be worth a try, even if only to discount it. It wasn’t until I was neck-deep in tcpdump that I realized what was causing my Network devices to periodically fall off the 'net.

[quote=“dmercer3, post:21, topic:176059”]This has nothing to do with vera SENDING packets.

When the FIOS boxes renew their lease (or the network reboots) they see the vera lite as a router. It is this reason that the boxes go into a loop requesting a network address from the Vera. Like any other network device they should move on in the routing table after a few failed attempts however that does not happen, thus the continuous loop.

Either 1) FIOS boxes recognize what the vera is, and thats just never going to happen.

or 2) The vera stops acting as a router to any ip/mac address that we program it to ignore. (then it will just forward the packets along to the router).

Vera can fix this easily, Verizon surely will never even flinch at the small amount of us.[/quote]
And this declaration is based on what exactly? How is Vera “acting as a router”? This thread started with discussion of a Vera Lite, which does not provide routing. How or why would the FiOS box(and old bad Onkyo firmware) perceive Vera Lite as a router?

[quote=“Z-Waver, post:23, topic:176059”][quote=“dmercer3, post:21, topic:176059”]This has nothing to do with vera SENDING packets.

When the FIOS boxes renew their lease (or the network reboots) they see the vera lite as a router. It is this reason that the boxes go into a loop requesting a network address from the Vera. Like any other network device they should move on in the routing table after a few failed attempts however that does not happen, thus the continuous loop.

Either 1) FIOS boxes recognize what the vera is, and thats just never going to happen.

or 2) The vera stops acting as a router to any ip/mac address that we program it to ignore. (then it will just forward the packets along to the router).

Vera can fix this easily, Verizon surely will never even flinch at the small amount of us.[/quote]
And this declaration is based on what exactly? How is Vera “acting as a router”? This thread started with discussion of a Vera Lite, which does not provide routing. How or why would the FiOS box(and old bad Onkyo firmware) perceive Vera Lite as a router?[/quote]

DHCP is a routing function, provided by the Vera Lite. If the Vera Lite provides IP addresses to requesting nodes, it is acting as a router. Any DHCP server on a network is essentially a router unless the node is redirected. (or directed specifically, mac filtering/static address/etc.).

DHCP is not a routing function, but more importantly, Vera Lites do not offer DHCP functionality. DHCP and routing are optional components of Vera 3, not Vera Lite.

Correct. And Vera 3 is only supposed to offer DHCP (if enabled) on it’s WiFi net and local LAN ports. Not on it’s WAN port.

Given that the DHCP engine (a mod’d version of dnsmasq) is enabled by default, and somewhat misconfigured, most people will have it enabled in their environments (both Vera3 and VeraLite).

The VeraLite thread I linked below outlines the issue in gory details, along with a VeraLite-specific fix people can try for that type of issue (thanks to @hugheaves).

Probably worth a try for people having issues with their STB’s, no?

censored I just SSH’d into my Vera3 and you are right, the darned thing is set to also service the WAN port. I’m extremely surprised this has not caused me any issues but then my Unix server handles DHCP and must be responding quicker.

I’m wondering if this has bitten me in the arse 2 weekend ago when I upgraded my backbone to a 24port Gb switch and everything got connected directly to that backbone. I did have some issues with DHCP and Vera might have contributed and muddles the symptoms.

Too late now as I have to work tomorrow, but I’ll see if I can disabled Vera 3’s DHCP, at least on the WAN port, and hook my bright House Cisco cable box back up. If that stays up then this may indeed be the cause and the trick in the thread you linked may fix it. I don’t care if Vera’s 3 DHCP gets disabled as I have nothing connected to her wired or wireless any more.

Given that the DHCP engine (a mod’d version of dnsmasq) is enabled by default, and somewhat misconfigured, most people will have it enabled in their environments (both Vera3 and VeraLite).

The VeraLite thread I linked below outlines the issue in gory details, along with a VeraLite-specific fix people can try for that type of issue (thanks to @hugheaves).

Probably worth a try for people having issues with their STB’s, no?[/quote]
That issue was fixed(on Vera Lites at a minimum) several firmware versions ago, in 2012.

Interesting…

[tt]tcpdump[/tt], running on a VeraLite (ver:1.5.622, ip:192.168.6.150) appears to at least indicate some involvement in DHCP Responses:

07:58:28.396321 IP 192.168.6.151.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:4a:92:cb:72:c1 (oui Unknown), length 300 07:58:28.398088 IP 192.168.6.150.67 > 192.168.6.151.68: BOOTP/DHCP, Reply, length 300

07:59:49.770205 IP 192.168.6.151.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:4a:92:cb:72:c1 (oui Unknown), length 300 07:59:49.771898 IP 192.168.6.150.67 > 192.168.6.151.68: BOOTP/DHCP, Reply, length 300

I don’t have a old hub handy to be able to trace both sides, at the same time, but I can see from the rtr’s [tt]tcpdump[/tt] (on 192.168.6.1) that it’s similarly responding to the DHCP request.

I haven’t yet cracked open the Response packet, but to me a “fix” for this issue would have VeraLite not respond AT ALL to these requests, a silent/passive observer - avoiding any type of engagement.

For the test environment/measurement, I cracked a bunch of stuff out of storage. I wanted to see exactly what a VeraLite was doing, and not rely upon potentially out of date posts.

[ul][li]Reset the VeraLite to defaults[/li]
[li]Validated that it was running 1.5.622[/li]
[li]Cabled an empty switch (Netgear ProSafe GS108) to an unused subnet (with it’s own DHCP Server, ip:192.168.6.1)[/li]
[li]Cabled VeraLite to that segment (ip:192.168.6.150 was given to it by the subnet’s DHCP srv)[/li]
[li]Installed [tt]tcpdump[/tt] onto the VeraLite ([tt]opkg update; opkg install tcpdump[/tt])[/li]
[li]Run tcpdump on eth0 [tt](tcpdump -i eth0 “(port 67 or port 68)”[/tt])[/li]
[li]Cabled A Netbook of mine to that segment (ip:192.168.6.151 was given to it by the subnet’s DHCP srv)[/li][/ul]

At this point, disabling/enabling the Interface on the Netbook was enough to trigger the DHCP process to restart. The packet traces above show that the VeraLite, in default “out of box” configuration & running the latest binaries, is still participating in the DHCP process at some level.

Emprirical data. Nice.

I’ll shut up now.

Updated Vera 3 with below info from the thread referenced

/etc/config# uci set dhcp.wan.force=0
/etc/config# uci commit
:/etc/config# uci show dhcp

Output of that last command:
dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded=1
dhcp.@dnsmasq[0].boguspriv=1
dhcp.@dnsmasq[0].filterwin2k=0
dhcp.@dnsmasq[0].localise_queries=1
dhcp.@dnsmasq[0].rebind_protection=1
dhcp.@dnsmasq[0].rebind_localhost=1
dhcp.@dnsmasq[0].local=/lan/
dhcp.@dnsmasq[0].domain=lan
dhcp.@dnsmasq[0].expandhosts=1
dhcp.@dnsmasq[0].nonegcache=0
dhcp.@dnsmasq[0].readethers=1
dhcp.@dnsmasq[0].leasefile=/tmp/dhcp.leases
dhcp.@dnsmasq[0].resolvfile=/tmp/resolv.conf.auto
dhcp.@dnsmasq[0].authoritative=1
dhcp.lan=dhcp
dhcp.lan.interface=lan
dhcp.lan.start=100
dhcp.lan.limit=150
dhcp.lan.dynamicdhcp=1
dhcp.lan.ignore=0
dhcp.lan.force=1
dhcp.lan.leasetime=60m
dhcp.wan=dhcp
dhcp.wan.interface=wan
dhcp.wan.dynamicdhcp=0
dhcp.wan.ignore=0
dhcp.wan.dhcp_option=option:dns-server
dhcp.wan.force=0

Connected my Bright House Cisco cable box to the network. Resulting in the box reboot within 2 minutes.

Did some more research and made the below change as well
uci set dhcp.wan.ignore=1
uci commit

and restarted the network on my Vera3 with the command
/etc/init.d/network reload

Reconnected my Bright House cable box to the network. It has been running solid for the last 12 of hours. keeping my fingers crossed

How-To (Use at your own risk)
Remote into your vera using an SSH client (On unix it’ s a standard tool, for Windows, I suggest to use Putty [http://www.putty.org])
The user ID will be root and the password is on the bottom of your unit (unless you changed it)

Once logged in and you are at the command prompt, type in the below commands line by line, pressing the Enter key after each line. Note: these commands are case sensitive.

[b]cd /etc/config

uci set dhcp.wan.force=0

uci set dhcp.wan.ignore=1

uci commit

/etc/init.d/network reload[/b]

After which, press the CTRL and D keys at the same time to log off.

Now connect your FIOS/Cable box and see if that fixes the issue.

My veraedge used to keep sending UpnP request to my Ring Doorbell (DHCPDiscovery & logIPRequest in the log). The edge was hanged and I had to unplugged the power and plugged it again to restart it. I contacted Vera Support and they told me I should turn off my Ring Door Bell as Ring may be the cause for my Edge to be frozen. I asked them how to filter out those requests but they did not know how to do it.

I read many topics about Onkyo, vera, and UpNP discovery. I almost wanted to buy a Netgear Nighthawk to create a VLAN for my veras only. Somehow I read this topic and followed BOFH instruction and it works. No more UpNP requests for both of my veras :slight_smile:

I have just encountered the same problem with Cisco boxes and a veralight after loosing power. Troubleshooting with Fios was painful, as they basically replaced every piece of equipment from the boxes to the ONT before discovering that plugging in the Vera was what caused the boxes to reboot.

Although it seems to only affect the boxes if they boot after the vera, I’m a bit uncomfortable with a setup that could potentially go haywire anytime the power goes out and boxes/ router resets.

Does anyone think that Vera will address this ., as I doubt Cisco will with such a small affected user base., as I don’t feel tech savvy enough to troubleshoot much, I have to decide if I should return the Vera and go with a different device.

Thanks for any input