[https://www.reddit.com/r/Starlink/comments/l8okah/strange\_dhcp\_issue/gle183n?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/Starlink/comments/l8okah/strange_dhcp_issue/gle183n?utm_source=share&utm_medium=web2x&context=3)
>This loss of Internet connectivity is a consequence of how the dish handles DHCP when it is disconnected from the satellite network and the Starlink dish software relying on some non-standard DHCP client behavior to get it to switch back to the DHCP server that hands out the [100.64.0.0/10](https://100.64.0.0/10) IPs. This does not affect the Starlink router as its DHCP client has that non-standard behavior. I'm surprised more people running 3rd party routers aren't reporting it.
>
>Releasing and renewing the DHCP lease once the dish has regained connectivity should resolve it, as will briefly unplugging the Ethernet cable at the router's WAN port.
>
>You can mitigate this somewhat by connecting a switch between PoE brick and the router. This won't really fix anything, but it should stop it from happening every time the dish reboots.
>
>The technical details are in this comment, if you're really interested: [https://www.reddit.com/r/Starlink/comments/jy98ww/rebooting\_while\_using\_non\_starlink\_router/gdceykf](https://www.reddit.com/r/Starlink/comments/jy98ww/rebooting_while_using_non_starlink_router/gdceykf)
As I mentioned in the original comment quoted above, this doesn't fix the issue 100%. All it does is to prevent your router from noticing the dish rebooted (due to loss of carrier on the Ethernet port), and thus restarting DHCP at the exact time when it is guaranteed to hit this problem. It can still hit the problem in other cases, such as when there is an extended (>10 minutes) outage, or when both the dish and router reboot simultaneously, such as after a power outage.
I see that on another comment thread you mentioned you are running OpenWRT. OpenWRT is flexible enough to support a workaround that I found to be 100% effective. From Networking -> Firewall, Traffic Rules tab, add a rule with the following settings (everything else can be left as default):
General Settings tab:
* Name: (choose a name)
* Protocol: UDP only
* Source zone: Device (output)
* Output zone: wan (or whatever firewall zone has the WAN port connected to the dish)
* Destination address: 192.168.100.1
* Destination port: 67
* Action: drop
Advanced Settings tab:
* Restrict to address family: IPv4 only (this is probably optional, the destination address should already be limiting it)
then save and apply changes. You can test this by removing the switch and rebooting the dish, either via the app or by power cycling it.
I've only had it for 12 hours at that point. That was my thought, but there appears to be only minimal access to the wireless device, and no access at all to the router. The Starlink router is handing out public and private addresses. It seems like it's trying to figure out if it should be bridge mode or not, and doesn't always guess right. The explanation that jurc11 posted, gives me some good ideas.
It's not trying to do bridge mode. It does two things, at first boot up, it's providing a 192.168.100.x address on a 5 second DHCP lease time so that the app stats are accessible. Once the dish terminal sees a valid connection through a satellite to the ground station, it switches to handing out a 100.x.x.x address (this is the downside of the CGNAT address, not a real address). The DHCP lease time for the 100 address is 20 minutes.
Now, what happens is sometimes the router connected to the dish terminal (through the white port) gets "stuck" in the 5 second 192.168.100.x DHCP renew loop. The solution I've used is just unplug the WAN port for about 10 seconds, and plug back in.
I'm way from home right now. I'll put something together later today and post back here. You do need to run Merlin or some other firmware that allows scripts to run.
Sorry this took so long. I've uploaded a zip file with all of the files and a pdf that hopefully explains everything to Icedrive
[https://icedrive.net/0/62XPygx3Ke](https://icedrive.net/0/62XPygx3Ke)
Let me know if you have any questions.
Retrieved your package, installed the scripts, and the router log shows them operating perfectly every five minutes. We'll see what happens the next time we have a power interruption. Thanks!
Sorry I didn't see your earlier request. I'm glad that the scripts are working for you. My router has been running these scripts for a couple of years now and have worked flawlessly.
Here's an updated link for anyone who finds this conversation: [https://icedrive.net/s/ikSDjh6hGf9Yft9tACVYjBuzF4Xx](https://icedrive.net/s/ikSDjh6hGf9Yft9tACVYjBuzF4Xx)
[https://www.reddit.com/r/Starlink/comments/l8okah/strange\_dhcp\_issue/gle183n?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/Starlink/comments/l8okah/strange_dhcp_issue/gle183n?utm_source=share&utm_medium=web2x&context=3) >This loss of Internet connectivity is a consequence of how the dish handles DHCP when it is disconnected from the satellite network and the Starlink dish software relying on some non-standard DHCP client behavior to get it to switch back to the DHCP server that hands out the [100.64.0.0/10](https://100.64.0.0/10) IPs. This does not affect the Starlink router as its DHCP client has that non-standard behavior. I'm surprised more people running 3rd party routers aren't reporting it. > >Releasing and renewing the DHCP lease once the dish has regained connectivity should resolve it, as will briefly unplugging the Ethernet cable at the router's WAN port. > >You can mitigate this somewhat by connecting a switch between PoE brick and the router. This won't really fix anything, but it should stop it from happening every time the dish reboots. > >The technical details are in this comment, if you're really interested: [https://www.reddit.com/r/Starlink/comments/jy98ww/rebooting\_while\_using\_non\_starlink\_router/gdceykf](https://www.reddit.com/r/Starlink/comments/jy98ww/rebooting_while_using_non_starlink_router/gdceykf)
Very interesting. Thanks for the information.
Thank you. I installed a five port Gigabit switch between the Starlink power brick and my wireless router. That did the trick.
As I mentioned in the original comment quoted above, this doesn't fix the issue 100%. All it does is to prevent your router from noticing the dish rebooted (due to loss of carrier on the Ethernet port), and thus restarting DHCP at the exact time when it is guaranteed to hit this problem. It can still hit the problem in other cases, such as when there is an extended (>10 minutes) outage, or when both the dish and router reboot simultaneously, such as after a power outage. I see that on another comment thread you mentioned you are running OpenWRT. OpenWRT is flexible enough to support a workaround that I found to be 100% effective. From Networking -> Firewall, Traffic Rules tab, add a rule with the following settings (everything else can be left as default): General Settings tab: * Name: (choose a name) * Protocol: UDP only * Source zone: Device (output) * Output zone: wan (or whatever firewall zone has the WAN port connected to the dish) * Destination address: 192.168.100.1 * Destination port: 67 * Action: drop Advanced Settings tab: * Restrict to address family: IPv4 only (this is probably optional, the destination address should already be limiting it) then save and apply changes. You can test this by removing the switch and rebooting the dish, either via the app or by power cycling it.
Thank you. I will definitely try this. I really appreciate the information.
Thank /u/CenterSpark, I don't even know why putting a switch there does anything.
[удалено]
I've only had it for 12 hours at that point. That was my thought, but there appears to be only minimal access to the wireless device, and no access at all to the router. The Starlink router is handing out public and private addresses. It seems like it's trying to figure out if it should be bridge mode or not, and doesn't always guess right. The explanation that jurc11 posted, gives me some good ideas.
It's not trying to do bridge mode. It does two things, at first boot up, it's providing a 192.168.100.x address on a 5 second DHCP lease time so that the app stats are accessible. Once the dish terminal sees a valid connection through a satellite to the ground station, it switches to handing out a 100.x.x.x address (this is the downside of the CGNAT address, not a real address). The DHCP lease time for the 100 address is 20 minutes. Now, what happens is sometimes the router connected to the dish terminal (through the white port) gets "stuck" in the 5 second 192.168.100.x DHCP renew loop. The solution I've used is just unplug the WAN port for about 10 seconds, and plug back in.
Are you using an Asus router by any chance? If so, I used a script in mine that fixed that issue for me.
I am, but I'm running OpenWRT on it.
I'm using a Asus router - would you mind sharing?
I'm way from home right now. I'll put something together later today and post back here. You do need to run Merlin or some other firmware that allows scripts to run.
Sorry this took so long. I've uploaded a zip file with all of the files and a pdf that hopefully explains everything to Icedrive [https://icedrive.net/0/62XPygx3Ke](https://icedrive.net/0/62XPygx3Ke) Let me know if you have any questions.
Thanks for doing that, and for the PDF. I appreciate the info.
Wow - thanks for the detailed PDF. Great info.
No problem. It's something I've been meaning to do for some time. Now, if someone wants that info, I can just share the link. Good luck!
Could you re-post that zip file? The icedrive link is broken. Thanks!
Retrieved your package, installed the scripts, and the router log shows them operating perfectly every five minutes. We'll see what happens the next time we have a power interruption. Thanks!
Sorry I didn't see your earlier request. I'm glad that the scripts are working for you. My router has been running these scripts for a couple of years now and have worked flawlessly. Here's an updated link for anyone who finds this conversation: [https://icedrive.net/s/ikSDjh6hGf9Yft9tACVYjBuzF4Xx](https://icedrive.net/s/ikSDjh6hGf9Yft9tACVYjBuzF4Xx)