Obtaining IP address from DHCP

I recently upgraded my broadband service from Vodafone to a Pro II Full Fibre plan with a Ultra Hub router. The system is generally working but with one issue that I've been unable to resolve. Neither the internet radio nor the battery doorbell chime will connect to wifi. There were no such problems using the old router.

It's clear that the issue is not with the devices, since I have tried 3 radios and 2 versions of the doorbell chime, and all have failed to connect.

What the radios end up with is one of two messages. Either a simple "Failed to connect" or a more informative "Failed to obtain IP address from DHCP - limited or no connectivity".

I have tried every trick I've been able to find to fix this, including
- splitting out a separate 2.4 GHz frequency SSID because the door chime is designed only to operate on 2.4
- restarting the router devices
- tried connecting by different methods: pressing the WSP button on the router; entering the router password on the device.
- checking connections and related information: the radios show the following even though there is no connection to DHCP.
"View settings
"Active connection: WLAN is active
"MAC address: 30:58:90:4C:B3:F3
"DHCP: DHCP enable
"SSID: Vodafone28779B
"IP address: 169.254.116.151
"Subnet mask: 255.255.0.0
"Gateway address: 0.0.0.0
"Primary DNS: 0.0.0.0 "

The IP address shown does not appear to be the router's, but since the DHCP is apparently unable to give an IP address to the device, it's not clear to me where it comes from.

If anyone has any suggestions on how to fix this I'd be very grateful indeed.

The IP address is in the range 169.254.0.0/16, which is the IPv4 link-local range which configures itself, although I have only ever known trouble when addresses in that range show up. If your devices have these addresses, but previously got their IP addresses via DHCP it is a sure indication that there is no DHCP response from your router.

Go to your router and do whatever is necessary to enable DHCP over Wireless and make sure that your devices know any SSID and password required by your router.

Thanks, I'll try this

Hi I have similar system it works, but, have had problems with UtraHub and ARP Mac resolution, the router does seem to have problems in this low level area.

It other devices are get an IP Address from the router, the DHCP server appears to be running in the router.

If you can, do a quick IP Scan of your LAN, this may or may not reveal something.

FYI I have a previous router setup as an access point with theWIFI and DHCP Server enabled, there is NO Overlap of my LAN’s address space within the DHCP Address allocation table.

There is a CAT5 connection between the access point and the UltraHub.

I have a combination of WIRE and WIFI Connections with DHCP and FIXED so it does work to the appropriate standards.

Your devices for some reason are not reaching the UltraHub DHCP Server, load the Vodafone App on your phone, go to manage WIFI and turn Compatibility mode WIFI if you haven’t already done this.


Let us know current status.

Thanks for this. Last night I managed to overcome the problem by disconnecting the booster router and removing a Vodafone implanted antivirus tool. I need to experiment further with the booster to see if I can overcome the problem there, meanwhile everything seens to be functioning well enough from just the main ultra hub.

Your "booster router" needs not to be configured as a router or doing most of the things associated with a router. It needs to be quietly present at no higher than Layer 2 except for having its own IP address so you can access its config and nothing connected to the WAN port.

When you reintroduce the "booster router"

Set it to either a static ip or dhcp server off....

having two dhcp servers on the same subnet will cause problems as devices won't know which device to connect to.

So long as the DHCP Server address spaces don’t overlap it doesn’t matter, the client broadcast for a IP address goes to both and the first one back to client is used, if it’s within the previous lease time the first one back, it carries on otherwise it gets a new IP, remember servers and hosts over Ethernet communicate via MAC addresses otherwise NAT would never work, I.e. all non lan IPs have the routers MAC within the hosts ARP Table.

having 2 dhcp severs wont cause problems if they are configyred correctly its when one server in the same scope doesnt know what the otherone is doing that problems happen

In reply to a post by ultraproblems:

So long as the DHCP Server address spaces don’t overlap it doesn’t matter, the client broadcast for a IP address goes to both and the first one back to client is used

Actually, that's why it's *dangerous* to have two DHCP servers on the same subnet with overlapping pools. DHCP server 1 could give out an address to one client, but DHCP server 2 doesn't know about this, so could end up giving out the *same* address to a different client, leading to an IP address conflict

Unless you have the two DHCP servers coordinating with each other (which is difficult to set up), you need to have non-overlapping pools, e.g. DHCP server 1 has pool 192.168.1.50-149 and DHCP server 2 has 192.168.1.150-249

In reply to a post by ultraproblems:

remember servers and hosts over Ethernet communicate via MAC addresses otherwise NAT would never work, I.e. all non lan IPs have the routers MAC within the hosts ARP Table.

Non-LAN IPs don't exist in the host's ARP table at all. When you try to communicate with any non-local address (say 8.8.8.8) then the destination IP address is looked up in the host's forwarding table, which returns the default gateway. Then the default gateway is looked up in the ARP table, and the ethernet frame is encapsulated to the gateway's MAC address, i.e. the router.

Whether the router does NAT or not is unrelated to this. The host can *only* ever create ethernet frames addressed to other devices on the same LAN, and it encapsulates datagrams to the "next hop" device on the same LAN.

In reply to a post by pyarwood:

having 2 dhcp severs wont cause problems if they are configyred correctly

Most home routers don't let you change the default router (gateway) that the DHCP issues. You can control the size of the scope, but that doesn't help you. For these two reasons, the standard recommendation is "turn off DHCP on your old router being used as a WiFi access point".

If you run DHCP on a full computer, or Raspberry Pi or NAS box, or something else, usually full configuration is possible.

In reply to a post by candlerb:

Whether the router does NAT or not is unrelated to this. The host can *only* ever create ethernet frames addressed to other devices on the same LAN, and it encapsulates datagrams to the "next hop" device on the same LAN.

Where the "netstat -rn" command is quite useful, from the *nix world, it usefully works on Windows since NT (whereas Win95/98 era required the odd "route print").

That's old school. "ip route [-6]" is what modern Linux distros use.

Under Ubuntu, you need to install "net-tools" to get the legacy tools (netstat, route, ifconfig, arp ...etc)

In reply to a post by candlerb:

That's old school. "ip route [-6]" is what modern Linux distros use.

Agreed, "ip addr" is a lot easier to remember, however the "ip" command isn't (yet) cross platform.

Under Ubuntu, you need to install "net-tools" to get the legacy tools (netstat, route, ifconfig, arp ...etc)

I'm mostly on RHEL derivatives, Rocky etc, and It appears it is also "net-tools" that I use with dnf.

In reply to a post by jchamier:

"ip addr" is a lot easier to remember

and "ip a" easier still

In reply to a post by DFScale:

and "ip a" easier still

great for obscure scripting too.

In reply to a post by jchamier:

great for obscure scripting too.

Fair point. I think this marks a point where I would script differently from how I use the CLI

I have, ( and this will blow some minds) three DHCP Servers, one is UltraHub, one is a TPLlink on the same subnet they have the same DGW (default gateway) and no overlapping address space, both have 24 hour lease. It’s curious that the TPLink seems (due to IP Addresses) to supply, most but not all of the IP addresses.
The third one is connected to one of the boosters, this is setup has an IP Router, the LAN side has a DHCP Server obviously setup to a different Subnet. On this LAN there is a lot of local media traffic which kept away from the first subnet (yes I know switches segment traffic) ounce and for all. One of the reasons for the second LAN is the SKY Q-Boxes you can get issues with 4K videos on busy networks. The devices on second LAN can reach the Internet.
All SKY Equipment is setup on copper with Fixed IPs
Yes I know about possible double NAT issues with some gaming apps no one plays games on the second LAN.
If you want to know about DHCP and have a week to kill download RFC2939 it was updated only a couple of days ago, seriously do what I do use it as a reference for the bits you need.

The problem with all of this is those routers are unlikely to properly to conform to standards or expected ways of working so you are adding a lot of unknowns into all of that. Whereas vendors like Cisco or Microsoft (Microsoft DHCP) will do a fair bit of testing those routers will literally only be tested for home user and probably never tested against interacting with any other device types on the same network. You can look at it all theoretically and say it should work but the real world often throws unexpected issues up.

With all network issues you strip equipment out down to the bare minimum one Ultra Hub Router , re-run tests and record results. Introduce items of equipment re-run tests and record results, keep doing this till you reach the desired topology.
During the above, speed tests were carried out and apart from the normal deviation with multiple tests, they were all similar with no major deviation.

Carried on inspection just to be sure.

Run Wireshark for any unpredictable frames, record the traces, move Wireshark around the network and do same.

Check error logs that are available for any lan and WiFi issues, only annoying entries in the WAN logs loads of entries from various IPs trying to open well known and obscure TCP Ports within the Ultra Hub, been thinking about a firewall with a blacklist.

Run JPERF between lan hosts for lan throughput record results, got what was expected.

Run various IP Scanners physically verify all listed MAC Addresses.

Run ping test between various points on the network while running Wireshark filtered to ICMP, this will give you lan traffic timings, again what was expected. Tried different sizes, large ones to force fragmentation no issues.

Large portion of the traffic is over copper.