Getting DHCP response from Comcast

I gave an RPi4 based router to my sister as a housewarming present. She owns a straight cable modem from Netgear, and a Netgear Nighthawk router running stock firmware which was working fine. She got it hooked up fine between the new RPi and the modem, and was able to connect to the modem interface to see stats, but can not get Comcast to give her a DHCP response. If she hooks up her previous router it gets one and works fine. The previous router is a Netgear Nighthawk that isn't OpenWrt compatible.

We tried turning off the modem and nighthawk router overnight and in the morning she still couldn't get a response. I'm not sure if the nighthawk has a "dhcp release" button she can press, I'll ask about that. Any other suggestions?

How long does Comcast usually set their leases?

I have Comcast, and in my experience, rebooting the modem usually clears the previously learned MAC address. I have, at times, had to do several reboots (3-4), although I don't know if that was a placebo. You can always call them (lots of fun, of course) to ask them to clear the backend binding.

Is the RPi ethernet plugged directly into the cable modem? Is your sister's network entirely wireless behind the RPi? Or does it use ethernet, too (if so: is there another ethernet adapter (USB-ethernet), is this handled by VLANs on the built-in ethernet interface and a managed switch between the cable modem and the Pi)?

managed switch. the 8th port is untagged for vlan 2 and the WAN interface is eth0.2, there's also a static "modem" interface bound to eth0.2 with the network needed to talk to the modem's config page. So I know the managed switch is properly putting packets out / in that port.

I did definitely suggest that, but she's super busy and hasn't had the time to waste on hold. I was hoping an overnight with the modem off would clear the backend... :frowning:

What specific model of managed switch?

Some managed switches do not allow you to setup the management VLAN, and the switch itself could be claiming the DHCP lease from Comcast. This is true on the TP-Link "unmanaged pro" switches (which are, contrary to their title, managed insofar as they have VLAN features) such as the TL-SG105E, 108E, and the 116E.

If the switch is set to get a DHCP address, it should be set to a manually set static IP to avoid the risk of the WAN DHCP lease being claimed by the switch.

I will look into that, it is an SG108e but it's a recent one, and all the recent ones seem to have that bug fixed. Port 8 is untagged for vlan2 and not a member of vlan1. It used to be in earlier firmwares that vlan1 was not "removable" from a port, but that's no longer true. I also believe I set a static IP on it already, but I'll look into this! thanks for that thought.

also I did tell her to turn on the switch and RPi first and wait a full minute before booting the modem. so it should get DHCP from the RPi. of course she might not have actually followed those directions carefully.

Mine is maybe a year old and suffers from this bug. I don't know if there is a newer revision, but mine is up-to-date on the firmware.

I would recommend that she try connecting the modem directly to the Pi and then using a wifi connection to the Pi to see if it has obtained a DHCP lease.

Over on the Ubiquiti forums (where I am also active), there is a user who has provided a fairly extensive explanation of the various bugs/issues with that switch, especially when on the WAN side of a network. If you need/want, I can try to find it.

1 Like

Definitely configure the switch for a static IP on your LAN. That will prevent it from taking your one public IP from Comcast. I know the V3 SG108E management interface listens on all VLANs.

If it is a business class account you may need to call in for a MAC change. You can set the OpenWrt wan MAC to the clone of the old router. If you're going to continue to use the old router in the network you should change its MAC to something other than the one you're using on the wan. Stock firmware almost always has a way to do that.


hmm... excellent I will be sure we set a static IP, and this gives me hope we can debug it easily. I was fairly sure I'd set up the switch for static, but I could easily have accidentally done something else.

What I don't understand about this bug is, is the management sending out DHCP requests on all VLANs? that makes no sense! Everything I've read suggests that vlan 1 is the management vlan, and port 8 is definitely only a member of vlan2 and has pvid 2. I was pretty careful about that.

here's the bug I was assuming you were referring to:

VLAN 1, the default VLAN, cannot be edited, and it has to be a member in every port. The switch’s management interface is in VLAN 1. In essence, the switch management interface is reachable via every port, certainly not a very good security setup.

It's no longer the case that you can't remove a port from VLAN 1, starting with switch version 3 firmware released in 2018 (version 20171214). The switch I sent her was version 5

From TP-link:

Modifications and Bug Fixes:

New Features/Enhancement:
1.The port can be removed from VLAN1
2.The port of VLAN1 can choose tagged/untagged

I'm not saying you guys are wrong, but I am wondering what is the point of that bug fix if they are sending out DHCP on all vlans?

No, unfortunately this switch is really badly designed from a firmware standpoint -- it really does send out DHCP requests on all configured VLANs... I'm not sure if it does all simultaneously and takes the first one it gets (race condition), or if it sequentially goes through the VLANs (would be an interesting Wireshark experiment).

Most managed switches allow you to specify the management VLAN. That management VLAN, in turn, sets both the listening interface (i.e. it will not listen on other VLANs for local connections, such connections would have to go through a L3 routing system to get to the management network) and it sets which network it will use for DHCP requests (if not set as static).

This series of switches simply does not have the management VLAN as a user setting, and just listens on all. I would imagine that it wouldn't be able to respond to a connection attempt from another VLAN simply due to it being on an a different L3 network, but the fundamental issue is that the user/admin doesn't have a means of ensuring that the DHCP address is acquired from the correct VLAN.

Here is the writeup from BuckyeNet on the UI community forums which is excellent and detailed, but also includes external links that explain even more of the issues with this switch. It is fine for use inside a home network, or the MTU (multi tenant unit -- i.e. apartment VLANs), but exposing it to a potentially hostile environment (corporate network or actual internet connection) can be problematic.

I personally own the TL-SG105E, and I have a TL-SG116E deployed at my dad's house. I wish I had chosen something different, but I'm not too woried about it in these environments.

I checked and her switch is set to static IP mode. I'm shocked that they "fixed" this problem of not being able to remove vlan1 but then you can talk to it on other vlans? In fact I'm so shocked that I'm tempted to test this theory on one of the ones on my desk. I'm going to set one port to be vlan 37 (totally not in use) and then put my laptop on that vlan and config its network to be the same as my vlan 1 address space, and try to talk to the admin configurator. I'm hoping it's not possible to login.

I could imagine it sending out DHCP on all vlans... ok, could be... but the switch in question is not using DHCP so we eliminated that possibility... but it's hard for me to imagine it will accept connections on any port in any vlan to the configurator.

I'll report back on findings.

Yeah, I'm not sure that it will work if it doesn't have a proper L3 route, but it is clear that there is a design issue with the switch.

Did you get a chance to have your sister run the Pi directly into the modem (instead of through the switch) -- it will give a lot of insight into the situation if we can validate that the Pi does indeed get an address on the WAN. That said, since the WAN is currently tagged on the Pi, you'd have to alter the config a bit.

Do you have a copy of the /etc/config/network file handy -- I'd like to see how it is currently setup.

OMG you're absolutely right, I set up port 2 as vlan 33... I gave a static IP to my laptop in the same subnet as the ip address of the switch... and set the port id for port 2 as vlan 33... saved config... and was able to login from that port!

definitely would not have chosen this switch if I knew this. what a huge flaw.

Yes in the context it will be used in, this is not exploitable from the internet, because it uses a static private IP address and so port 8 which is the WAN uplink will generally not route private IPs to the switch... But what a POS. Glad I used a randomly generated password from a strong crypto password maker!

They published that firmware saying you could remove VLAN 1 etc and I thought this problem had been sorted over 2 years ago. Little did I know it listens on any port? wtf?

In any case, we know

  1. The Switch is not configured to ask for DHCP and therefore not stealing the Comcast IP
  2. She can log into the RPi and see that it does not get an IPv4 from Comcast
  3. She can log into the modem and see that in fact packets going out eth0.2 do head out port 8 towards the modem and she can browse the modem's configurator.

It seems likely that comcast has bound her IP address to the MAC of her existing router... and probably she needs to clone it or get comcast to unbind?

1 Like

This also strikes me as potentially unnecessary, so I would like to see that config file. I have had Comcast for many years with several different modems (although all Arris Surfboard modem only units). In all cases, I have not needed to have any special routes or other configs to reach the modem's status page. I just make sure my network is not overlapping, and I can simply go to that page without any separate networks/vlans, static routes, bindings, etc.

Well, I bet you did get an IP address on the WAN? Because without any working WAN it's impossible for OpenWrt to know which interface to send packets to :wink:

we added it after the fact so we could browse the modem.

Thanks for running that experiment. I honestly wasn't sure if it would work or not, and I didn't have the energy to pull out my unit to test... lol.

Yeah, with that extra datapoint, it does really suggest that this was a stupid design. However, some people have suggested that this is done intentionally because they want to make sure basic users (who are just learning VLANs) cannot lock themselves out of the switch. Bad design decision, but a reasonable explanation about why they haven't fixed this.

yeah, I could see that, but then there should be a checkbox or something "admin available only on VLAN ... (may lock you out of switch configurator)" or something

Stop using logic! That's not how consumer devices work. :rofl:

1 Like

Multiple examples online of this happening to comcast subscribers. Most people seem to eventually solve it but fail to actually post what the solution was, or they just keep trying stuff and they don't know what really solved it.

A few people seem to think that it's possible for the modem to retain its memory of the MAC address through power-offs if its connected to the cable itself. Also in this case there's some kind of signal amplifier involved, which is connected to power, so maybe there's a voltage that can keep something energized inside the modem when it's not plugged in... I'm not sure.

In any case here's my next thing I'm going to recommend to her, but I'm going to do it on the weekend when her family doesn't need to be online for work.

  1. Turn off modem, router, switch. Unplug modem from cable/coax and switch (modem sitting on table with nothing connected)
  2. Wait 5 minutes
  3. turn on the RPi, wait 1 minute
  4. turn on the switch wait 1 minute
  5. connect coax to modem, connect modem to switch
  6. turn on modem

If that doesn't work, then I'm going to force her to call comcast... I don't want to go the MAC address cloning method because it's fragile, will break if she does an upgrade without keeping settings, and she'll have to remember that particular mac address forever. It's a mess. It should be possible to replace your router!

1 Like

That seems like cruel and unusual punishment... you must really not like your sister :rofl:

Your approach seems fine. You might also try reversing the tagging situation on the WAN/LAN -- so make the WAN untagged on the ethernet port and the LAN tagged (and of course bridged with wifi). This way, it is possible to do a direct connection between the modem and the Pi so that the switch can be taken out of the equation for testing, if necessary. Of course, don't forget the adjust the switch configuration accordingly.

Also, make sure the switch is indeed configured properly on both the 802.1Q VLAN config page AND the 802.1Q PVID Setting page. The port going to the modem must have that VLAN untagged in the first page, and set as the PVID in the second. Both must be set or you will not get your expected results. Similarly, on the port for the Pi, you need to make sure that the appropriate VLAN is set to untagged and PVID (and of course the tagged VLAN set as well).

Finally, even when you get this working, there is an issue of robustness of this solution. If the power-on sequencing turns out to be a critical factor, your sister will have to deal with that every time there is a power event or anything else the interrupts the connectivity. There are some applications, like making a 'WAN passthrough' for ISP provided IPTV boxes and such, where this switch is usually fine. However, using this particular switch for both WAN and LAN may not be a good idea. There are many other vendors that have better firmware.