I've recently been setting up a network video recorder and half a dozen IP cameras around the house and garden. Everything is connecting wirelessly through the Home Hub6 using the 2.4GHz band, which certainly simplified the installation - no video cables to feed through walls and under ground. The NVR sits under the TV in the lounge so that when we can easily review the recordings or even monitor the cameras, especially the one at the front door, if we need to. The HH6 router is in my study, about 2m from the main phone point. So far, so good.
However I have noticed a strange effect and wondered if anyone can explain it.
For various reasons I wanted the NVR to be on a specific IP address in the network. The cameras are on IP addresses assigned by the router. I switched off the DHCP option in the NVR setup and set the IP to 192.168.1.12 and rebooted it. As expected, it restarted with the new, fixed IP address and I checked this on the HH6 interface on my PC - the HH6 sees the NVR on the static fixed address of 192.168.1.12 - well outside of the DHCP range. Now the weird part...
When the NVR is on this fixed IP it can only intermittently see the cameras and drops the connections every few seconds!
I checked by changing the NVR setup back to get a DHCP allocated address from the router (192.168.1.97 as it turned out) and the NVR can connect to the cameras very reliably. Back to the fixed address of 192.168.1.12 and the NVR drops the camera connections every few seconds. It does see the cameras, but not reliably, almost as if the wifi signal to the NVR is reduced when using the fixed IP.
I'm not changing the settings for the IP cameras - they are still DHCP allocated - and they are a lot further from the router than the NVR with some half way down the garden. Also, I can still connect to the networked cameras through the router with my mobile phone, irrespective of the NVR setting, so I am certain it isn't them changing connectivity.
Since the IP address range is just packet switching within the router I did not expect the wifi performance to change just by moving the NVR to a different IP address. The only other fixed IP peripherals I use are a network laser printer server and a colour printer-scanner, on IP addresses 192.168.1.10 & 11 respectively and these connect very reliably. However they are in the same room as the router, so I expect them to be seeing a strong wifi signal anyway. Meanwhile the smart TV sitting directly above the NVR has a DHCP allocated IP and that also sees a reliable wifi signal.
So, does anyone know if the HH6 has different wifi signal strength for fixed and allocated IP addresses?
If not, does anyone have any suggestions to explain why the NVR sees the networked cameras reliably with a DHCP address and inconsistently, although still connecting, with a fixed IP address.
Using manual or dynamic addressing has absolutely no bearing on the radio signal strength. This is something else.
When you set the address manually what do you set the subnet, gateway and DNS entries to?
Do you see the same problem if you reserve an IP for the NVR on the home hub instead?
As I said, that's what I initially thought as well, but it isn't quite as "black and white" as that: lots of things can affect the radio signal, including interference from other sources. Unfortunately these sources can also include components within the hub itself, if the design is less than perfect.
When I set the address on the NVR manually I use exactly the same settings for the subnet, gateway and DNS as when it is set by DHCP - I only change the assigned IP address. That is why the NVR can actually connect to the network and see tha cameras at all, even intermittently.
Reserving a static IP on the HH6 doesn't work. If DHCP is enabled on the NVR then it makes an address request on connecting to the network and gets the address that the Hub DHCP server assigns to it. That should be the static address fixed on the hub, but the hub can only allocate such addresses (whether fixed or not) from the DHCP pool range. You can't configure the hub to allocate a fixed address outside of the DHCP range, you just set the connecting device not to make a DHCP request. If the DHCP setting is off then the NVR doesn't make an address request and uses the IP address that it is set to, which can (and should) be outside of the DHCP pool. That is the way that IP address allocation works, and this is behaving exactly as expected.
Further investigation suggests that this is likely to be an EMC issue with the HH6 itself. With DHCP disabled on the NVR I have now checked the performance on several IP addresses. Some addresses show reduced reliability of the connection and others have significantly improved reliability, which can only be the RF signal to noise ratio. Clearly the internal data switching and routing within the HH6 on certain addresses is interfering with the RF signal.
With hindsight this isn't surprising for a product that is as cheap as chips and has had so many other unreliability issues. In fact, I now wonder how many of the reports of poor HH6 performance, loss of connectivity to some devices etc., are actually down to these RF interference issues.
I never asked you to reserve an IP outside of the DHCP range, so the same question still stands... is performance affected in the same way by a reserved IP? What about if you switch from DHCP to static and temporarily use the same IP that DHCP provided that you know has good performance?
Regardless, it is highly unlikely that the source IP address can have any affect at all on a radio signal. In TCP/IP The source address is simply stored as a binary value within the header of an IP datagram, encapsulated along with a TCP segment and then transmitted as a frame via the physical layer (in this case the radio). This physical layer is far removed from the IP address (in fact it doesn't even care about IP, its job is just to transmit and receive frames regardless of their content). You could even choose a protocol that doesn't involve IP addressing (e.g. IPX) to demonstrate that point.
That's not to say that something couldn't be wrong at the application or transport layer that is causing performance issues for certain IP addresses, but it's far fetched to suggest that the slight difference in content of a transmitted frame is altering the SNR of a radio receiver (in fact the home hub won't even know the sending IP until the frame has already been received over the radio). It's far more likely the NVR has a bug in its network stack that is being exposed when using static addressing which is affecting the TCP/UDP performance... e.g. a difference in MTU or TCP Window Size values.
If you really want to prove if the issue is between DHCP/Static why don't you adjust your DHCP range so that it covers the 192.168.1.12 address and see what performance is like when DHCP provides that same IP?
Switching from DHCP to static with the same address on the Hub doesn't change the performance.
Similarly, grabbing the same address from the DHCP pool without the NVR making a DHCP request doesn't change the performance.
Changing to specific addresses does change performance - some work better than others.
As I said in my earlier post, this is address specific, not whether it is DHCP allocated or not.
I don't understand your latter point. If I change the pool range to cover 192.168.1.12 then the router might assign that address on a DHCP request from the NVR, but it might not. Given the range of addresses, it probably wouldn't. AFAIK, the only way of forcing it to do so would be to restrict the DHCP pool to that single address, which would completely mess up the other 16 devices currently connected. I think I'll pass on that can of worms.
Anyway, having found a fixed IP address which works well (192.168.1.63), my current problem is resolved.