XBox One X: "Can't get an IP address"

Help
1

Thanks ahead of time for the attention and patience!

Basic setup description... XB1X is hard-wired (through a couple of switch hops) to the router, RPi0 running Raspbian and Pi-hole with latest versions/packages is wired directly to the router. Pi-hole is providing DHCP service, router DHCP is disabled.

XB1X reports "Can't get an IP address", and won't connect to any online services. Pi-hole reports an assigned IP to the XB1X under DHCP settings, and the XB1X reports the same IP when I go into its network settings. Interestingly, Pi-hole "sees" the XB1X (with the same IP) under the network tool, but reports 0 queries (no queries are reported in the logs for the XB1X IP, either).

As far as "have you tried"s... IP lease release and DHCP reservation on Pi-hole didn't seem to change anything, nor did attempting static IP and DNS settings on the XB1X. I've tried various permutations of Pi-hole and XB1X power cycles (including yanking the power cable from the XB1X to clear the cache), in combination with fiddling with Pi-hole DHCP settings and XB1X network settings, but so far, no dice.

I have read several threads regarding whitelisting Microsoft domains, but the Pi-hole isn't reporting any queries from the XB1X, so I don't think that's my issue.

If I re-enable DHCP on my router, XB1X connects just fine.

Plz halp. <3

2

Have you tried clearing the alternative MAC address in the Xbox network settings or trying each of the available ports, also in settings? Or, send me the XB1X, I'm totally sure I can get it fixed in a few months or years.

3

This may contribute to your observation.

A DHCP client will broadcast for a DHCP server to request a lease from.
Technically, broadcasts are limited to the same link (aka network segment aka collision domain).
Now, certain network equipment like additional routers, APs or switches, as well as VLANs may split your network into multiple separate segments.
If your Pi-hole machine and your Xbox would reside on different links, then your Pi-hole would never receive your Xbox broadcasts.
To verify this, try to connect your Xbox to same segment as your Pi-hole: It should be able to get a lease then.

You would need to configure a DHCP relay forwarding those broadcasts to your Pi-hole on the respective equipment.

Another explanation would be that your Xbox would claim the same IP address for its wired and wireless interface (does it have one?), and would be refused to assign the same IP to the respective other interface.

4

Gave this (clearing alternate MAC address) a shot as part of my "fiddling with network settings" on the XB1X. Pi-hole reported a few (unblocked, Microsoft domains) queries when I first did this, but XB1X still reports "Can't get an IP address", and queries have stopped showing up on Pi-hole again, even after repeated "clear alternate MAC address" operations.

5

Not sure this (network segmenting issues) is it either...

Our whole network is "segmented" in similar fashion (using switches to break out more wired connections, including switches running to other switches), and so far this is the only device to have an issue. In particular, an LG smart TV on the same segment as the XB1X is having no problems.

6

Try this. Turn off wifi. Instead of clearing the MAC, assign it a random address. Random MAC Address Generator - Create Random MACs - Online - Browserling Web Developer Tools

If the conflict is the wired and wireless have same MAC, that should identify the issue.

7

Do your Xbox's DHCP requests register in Pi-hole's log?

grep "dnsmasq-dhcp" /var/log/pihole.log
8

Additionally, you could check DHCP packets received/sent if install tcpdump (sudo apt install tcpdump):

pi@ph5a:~ $ sudo tcpdump -ntqi any udp port 67 or udp port 68
[..]
IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
IP 10.0.0.2.67 > 10.0.0.143.68: UDP, length 312

EDIT: Ow you can drop the -q argument for little more details:

pi@ph5a:~ $ sudo tcpdump -nti any udp port 67 or udp port 68
[..]
IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 0c:2f:b0:XX:XX:XX, length 308
IP 10.0.0.2.67 > 10.0.0.143.68: BOOTP/DHCP, Reply, length 312
1 Like
9

If OP has connected his network using only switches then there should be no issues with DHCP. As long as he isn't using old hub devices, using another home router as a switch, or hasn't configured VLANs (which I don't think OP has).

10

At this point, OP will confess to fibbing a bit when originally describing OP's network topology. I profess it was in hopes of eliminating unnecessary detail, but after further tinkering, my unique setup appears to be partly responsible... In an effort to atone for OP's sins, OP will now divulge the onerous truth of OP's network map, as well as the limited success OP has had in OP's continuing ministrations.

The XB1X is, in fact, wired into a child node of a Linksys Velop mesh network. Exonerating myself somewhat, the aforementioned LG smart TV (which presents no obvious network difficulties) is plugged into the same child node. The rest of the network is composed of further child nodes, and, indeed, switches branching off from some of the child nodes to other clients, and even to further branching switches.

Now, I have found that if I unplug (from power) the child node to which the XB1X is wired to, unplug (from power) the XB1X, DHCP release the XB1X's IP in Pi-hole, wait an obligatory 30 seconds, then plug both the child node and XB1X back in, the XB1X will connect to the internet with no apparent problems. However, this state only lasts for several minutes, after which the XB1X once again starts complaining that it can't get an IP. Checking query activity in the Pi-hole for the IP assigned to the XB1X shows no obvious issues, with absolutely no blocked queries (the queries simply abruptly stop at the point where the XB1X starts reporting problems). If I repeat this procedure, the results are the same.

Another interesting point here... As a tinkering step, at the suggestion of a Reddit thread, I'd attempted to set a DHCP reservation for the XB1X for an IP outside of the DHCP assignment range (e.g. same as my gateway, except ending in "x.x.x.2"). The quirky bit is that, even after releasing the "old" assigned IP in Pi-hole with the child node and XB1X unplugged (from power), after I plug the child node and XB1X back in, the Pi-hole evidently assigns the XB1X back to the same "old" IP, rather than the one specified in the DHCP reservation. In fact, through all of my troubleshooting (including dozens of IP releases at this point), the Pi-hole keeps assigning the XB1X the same exact IP.

One thing I have not yet tried, is a power cycle of the mesh parent node (the rest of the fam hasn't been in a position to tolerate internet interruptions), to which the Pi-hole's RPi0 is directly connected.

Continued thanks for the replies and suggestions, and I again beg your mercy for the initial glossing over of specifics...

1 Like
11

It assigns the same IP because it uses a deterministic hash on the MAC address to generate it. Change the MAC, change the IP.

12

That would depend on the additional equipment and its configuration.

L3 switches can split your network into separate segments, and some switches labeled as "L2 plus", "smart L2" or similar may be hybrid L2/L3 switches with limited configuration options (so they may lack e.g. DHCP relay options).

When that happens, what are the corresponding DHCP activities in Pi-hole's log?

Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

1 Like
13

Appreciate the continued attention here. I will create and upload a debug log, and check the DHCP activity, when I am next able (hopefully tomorrow evening). For the moment, other life obligations beckon...

14

Friends, I am tentatively reporting a successful workaround. I hesitate to label it a full-blown "solution", as manual intervention is yet required, however the fix is a simple one, and so far seems to be effective and holding.

It was ultimately this statement that led me to victory. As part of my continued fiddling, I manually set an alternate MAC on the XB1X, and all now seems to be well, as well as consistently so. This has also had the follow-on effect of getting a different IP address assigned to the XB1X by the Pi-hole. For referencing purposes later, the "default" obstinate (non-working) MAC and IP for the XB1X end in --:E6 and --.93, respectively, and the alternate agreeable (working) values end in --:E4 and --.91.

In my continued atonement, I have gone ahead and "broken" said fix, then re-applied it, for the purposes of testing its validity. I have endeavored to take adequately detailed notes of the process in hopes of providing useful info to this treasured and hallowed community, and notionally other wanting passers-by.

I have also generated a debug log covering the time period of this latest "controlled testing", which should have been uploaded here:

https://tricorder.pi-hole.net/IRzj3fcR/

As for providing further, potentially valuable background information, I have created a graphic detailing the relevant portion of my network map, hopefully displayed below.

Network Map v2
Network Map v2640×480 80.3 KB

As for a textual description, the parent node of our mesh wifi network is wired directly to our modem. From there, it is wirelessly connected to a child node, to which the offending XB1X and a perfectly-behaving smart TV are directly connected. As an interesting aside, two switch hops down from the same child node is an XB1, which, in similar fashion as the smart TV, exhibits no issues with regard to network connectivity.

Now to the tinkering... Below is a somewhat detailed sequence of events, corresponding to the period "captured" in the above debug log, with local timestamps (US EST, GMT-5) interjected. Note that XB1X "indications of GOOD network connection" are evidenced by the presence of updated community and game "notifications" (a recent corporately-motivated translation for "ads") on the home screen, as well as a lack of a "Connect to XBox Network" notification. Also note that, during the periods of BAD XB1X network connection, the XB1X would still report the IP assigned by the Pi-hole (--.93) in its advanced network settings, even though network tests would fail and report "Can't get an IP address". ...and if you would be so kind as to note just one further thing, an XB1X restart (to the best of my, admittedly squishy, knowledge) is nearly equivalent to a pulling of the power cord, at least with respect to relevant cache clearing.

(failed to capture an initial timestamp - ever shall I repent my heedlessness)

  • Cleared alternate MAC on XB1X, setting to default (--:E6).
  • Unplugged XB1X from power.
  • Unplugged child node from power.
  • Flushed Pi-hole logs and network table.
  • Released XB1X IP leases (--.93 and --.91) in Pi-hole.
  • Restarted Pi-hole.
    [1256]
  • Plugged XB1X into power.
  • Plugged child node into power.
  • Waited for child node to report successful connection to parent.
    [1302]
  • Turned on XB1X, initially indicated GOOD network connection (using --:E6 MAC).
  • Pi-hole indicates XB1X assigned to "default" IP (--.93).
  • Ran XB1X network test, result GOOD.
    [1304]
  • BAD network connection indicated on XB1X.
  • Ran XB1X network test, result BAD.
  • Cleared alternate MAC on XB1X and restarted.
    [1307]
  • BAD network connection indicated on XB1X.
  • Ran XB1X network test, result BAD.
  • Manually set alternate MAC on XB1X (--:E4) and restarted.
    [1312]
  • Pi-hole indicates XB1X assigned to new IP (--:91).
  • GOOD network connection indicated on XB1X.
  • Ran XB1X network test, result GOOD.
  • Restarted XB1X.
    [1314]
  • GOOD network connection indicated on XB1X.
  • Ran XB1X network test, result GOOD.

I also took a look at the DHCP activity, as suggested, and below is what was returned. Non-related IPs and MACs have been redacted, and I've only left the ending values for the XB1X (seemed like an adult thing to do). Referencing the earlier network map, "XB1X-49" is the ID of the offending XB1X, and "LGwebOSTV" is the Smart TV.

Feb 23 12:49:34 dnsmasq-dhcp[22643]: DHCP, IP range 192.168.1.10 -- 192.168.1.254, lease time 1d
Feb 23 12:55:25 dnsmasq-dhcp[506]: DHCP, IP range 192.168.1.10 -- 192.168.1.254, lease time 1d
Feb 23 12:58:11 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --
Feb 23 12:58:11 dnsmasq-dhcp[506]: DHCPOFFER(eth0) -- --
Feb 23 12:58:11 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) -- --
Feb 23 12:58:11 dnsmasq-dhcp[506]: DHCPACK(eth0) -- -- Linksys11736
Feb 23 12:58:24 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --
Feb 23 12:58:24 dnsmasq-dhcp[506]: DHCPOFFER(eth0) -- --
Feb 23 12:58:24 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) -- --
Feb 23 12:58:24 dnsmasq-dhcp[506]: DHCPACK(eth0) -- -- LGwebOSTV
Feb 23 12:58:31 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e6
Feb 23 12:58:31 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 12:58:31 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) --.93 --:e6
Feb 23 12:58:31 dnsmasq-dhcp[506]: DHCPACK(eth0) --.93 --:e6 XB1X-49
Feb 23 13:03:50 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) -- --
Feb 23 13:03:50 dnsmasq-dhcp[506]: DHCPOFFER(eth0) -- --
Feb 23 13:03:50 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) -- --
Feb 23 13:03:50 dnsmasq-dhcp[506]: DHCPACK(eth0) -- -- Linksys11736
Feb 23 13:04:00 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) -- --
Feb 23 13:04:00 dnsmasq-dhcp[506]: DHCPACK(eth0) -- -- LGwebOSTV
Feb 23 13:04:13 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --.93 --:e6
Feb 23 13:04:13 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:04:16 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --.93 --:e6
Feb 23 13:04:16 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:04:20 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --.93 --:e6
Feb 23 13:04:20 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:04:28 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --.93 --:e6
Feb 23 13:04:28 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:04:44 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --.93 --:e6
Feb 23 13:04:44 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:05:17 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --.93 --:e6
Feb 23 13:05:17 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:05:17 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) --.93 --:e6
Feb 23 13:05:17 dnsmasq-dhcp[506]: DHCPACK(eth0) --.93 --:e6 XB1X-49
Feb 23 13:07:11 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e6
Feb 23 13:07:11 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:07:16 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e6
Feb 23 13:07:16 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:07:21 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e6
Feb 23 13:07:21 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:07:29 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e6
Feb 23 13:07:29 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:07:46 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e6
Feb 23 13:07:46 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:08:19 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e6
Feb 23 13:08:19 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.93 --:e6
Feb 23 13:08:19 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) --.93 --:e6
Feb 23 13:08:19 dnsmasq-dhcp[506]: DHCPACK(eth0) --.93 --:e6 XB1X-49
Feb 23 13:10:39 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) -- --
Feb 23 13:10:39 dnsmasq-dhcp[506]: DHCPACK(eth0) -- -- HS220
Feb 23 13:11:31 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e4
Feb 23 13:11:31 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.91 --:e4
Feb 23 13:11:31 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) --.91 --:e4
Feb 23 13:11:31 dnsmasq-dhcp[506]: DHCPACK(eth0) --.91 --:e4 XB1X-49
Feb 23 13:13:58 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --:e4
Feb 23 13:13:58 dnsmasq-dhcp[506]: DHCPOFFER(eth0) --.91 --:e4
Feb 23 13:13:58 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) --.91 --:e4
Feb 23 13:13:58 dnsmasq-dhcp[506]: DHCPACK(eth0) --.91 --:e4 XB1X-49
Feb 23 13:18:13 dnsmasq-dhcp[506]: not using configured address -- because it is in use by the server or relay
Feb 23 13:18:16 dnsmasq-dhcp[506]: DHCPDISCOVER(eth0) --
Feb 23 13:18:16 dnsmasq-dhcp[506]: DHCPOFFER(eth0) -- --
Feb 23 13:18:16 dnsmasq-dhcp[506]: no address range available for DHCP request via lo
Feb 23 13:27:52 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) -- --
Feb 23 13:27:52 dnsmasq-dhcp[506]: DHCPACK(eth0) -- -- amazon-ce7f8734c
Feb 23 13:31:39 dnsmasq-dhcp[506]: DHCPREQUEST(eth0) -- --
Feb 23 13:31:39 dnsmasq-dhcp[506]: DHCPACK(eth0) -- --

I am venturing into unknown territory at this point (I am both excited and terrified), but what stands out to me are the repeated DISCOVER and OFFER exchanges taking place with the default MAC and IP addresses (--:E6 and --.93) vs. the single exchange using the adjusted ones (--:E4 and --.91). I will take my cookie for astute observation, and leave the causal determination to those who speak fluent ethernet.

I again am undyingly appreciative of the capability and support offered here (donation incoming), and will gladly participate in further testing and troubleshooting if it may be desired and/or warranted.

2 Likes
15

Great comment with lots of information and detail, good job troubleshooting and finding a solution. The network topology image made me burst out laughing :joy:

I do agree with you regarding the DISCOVER and OFFER exchanges, it is very strange. In this exchange, we can clearly see that the server is receiving and trying to respond to the DHCP Client (XB1X). But XB1X keeps sending DISCOVER. So it appears that the OFFER either doesn't reach the XB1X, or it just doesn't "hear" the messages. But then how come it heard the OFFER the first time and responded with a REQUEST? Also, I think it is strange that XB1X asks for IP after the DHCP Server already has sent an ACK. Did it not receive the ACK and therefore retries? Many questions here...

What I find even stranger is that changing the MAC actually resolved the issue. Sure, this will allow the Pi-Hole DHCP to assign a new IP address and see the XB1X as an entirely new host in the network. But if the problem was occuring because of a network issue, then changing MAC address wouldn't really resolve anything.

If we were to assume that this is a network problem, then I would've guessed that there is a physical layer issue (Layer 1 issue). That the problem is either related to the host (XB1X), something with the cable used between XB1X and network, or issue with Ethernet port, etc. But your further troubleshooting with MAC address somewhat disproves that it is a physical layer issue, and more of a data-link layer issue (Layer 2).

1 Like
16

The illustration from below wiki might explain a bit:

Below is correct:

Below is wrong with a 3 second delay when the XB1X retries with a DHCPDISCOVER instead of following up with a DHCPREQUEST:

Not sure why.
Could be the XBox not accepting the DHCPOFFER (maybe the DHCP packet was mangled), maybe a timing issue, or maybe the DHCPOFFER was not received by XB1X.

For nostalgia sake, my Raspi Kodi media center (a far distant descendant of XBMC) does below:

pi@ph5a:~ $ tail -F /var/log/pihole.log | grep dnsmasq-dhcp
[..]
Feb 23 23:07:49 dnsmasq-dhcp[434]: DHCPDISCOVER(eth0) 10.0.0.9 b8:27:eb:XX:XX:XX
Feb 23 23:07:49 dnsmasq-dhcp[434]: DHCPOFFER(eth0) 10.0.0.9 b8:27:eb:XX:XX:XX
Feb 23 23:07:49 dnsmasq-dhcp[434]: DHCPREQUEST(eth0) 10.0.0.9 b8:27:eb:XX:XX:XX
Feb 23 23:07:49 dnsmasq-dhcp[434]: DHCPACK(eth0) 10.0.0.9 b8:27:eb:XX:XX:XX avr

pi@ph5a:~ $ sudo tcpdump -ni any udp port 67 or udp port 68
[..]
23:07:49.218063 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from b8:27:eb:XX:XX:XX, length 300
23:07:49.224714 IP 10.0.0.2.67 > 10.0.0.9.68: BOOTP/DHCP, Reply, length 317
23:07:49.227635 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from b8:27:eb:XX:XX:XX, length 300
23:07:49.249965 IP 10.0.0.2.67 > 10.0.0.9.68: BOOTP/DHCP, Reply, length 317

EDIT: Ow ps. I believe your beautifull topology diagram is lacking Pi-hole am I right?

1 Like
17

How patently brazen of me. I have amended the graphic, and beg your forgiveness.

1 Like
18

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.