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.