I have a router that I've set to randomise the MAC address every 3 days. When that happens the interface gets dropped for a moment to apply the changes. When it comes back online, Newt fails to reconnect, and does its consecutive pings. WARN: 2026/04/09 00:31:22 Periodic ping failed (15 consecutive failures): all 4 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
I checked with to make sure it had nothing to do with the MAC randomisation, and sure enough, a simple router reboot causes Newt to go into stasis.
I have two servers running on the same network, with different Newt versions, they both go into stasis.
Environment
OS Type & Version: DietPi 0.6.2
Pangolin Version: 1.17.0 (happened on 1.15.x as well)
Newt Version: 1.9.0 and 1.11.0
To Reproduce
Have a working instance of pangolin, with Newt running, then restart the interface that Newt is connected to.
Expected Behavior
Newt should be able to identify the interface has probably restarted, and attempt to initiate some kind of reconnection.
Originally created by @Frost-4X on GitHub (Apr 9, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2815
### Describe the Bug
I have a router that I've set to randomise the MAC address every 3 days. When that happens the interface gets dropped for a moment to apply the changes. When it comes back online, Newt fails to reconnect, and does its consecutive pings.
`WARN: 2026/04/09 00:31:22 Periodic ping failed (15 consecutive failures): all 4 ping attempts failed, last error: failed to read ICMP packet: i/o timeout`
I checked with to make sure it had nothing to do with the MAC randomisation, and sure enough, a simple router reboot causes Newt to go into stasis.
I have two servers running on the same network, with different Newt versions, they both go into stasis.
### Environment
- OS Type & Version: DietPi 0.6.2
- Pangolin Version: 1.17.0 (happened on 1.15.x as well)
- Newt Version: 1.9.0 and 1.11.0
### To Reproduce
Have a working instance of pangolin, with Newt running, then restart the interface that Newt is connected to.
### Expected Behavior
Newt should be able to identify the interface has probably restarted, and attempt to initiate some kind of reconnection.
I've turned of my randomisation schedule, so this will affect me less. However, its still an inconvenience if my router ever gets power cycled, I lose my Pangolin connections. Then I have to connect to my server via other tunnelling services, and restart both instances of Newt.
<!-- gh-comment-id:4210677511 -->
@Frost-4X commented on GitHub (Apr 9, 2026):
I've turned of my randomisation schedule, so this will affect me less. However, its still an inconvenience if my router ever gets power cycled, I lose my Pangolin connections. Then I have to connect to my server via other tunnelling services, and restart both instances of Newt.
@oschwartz10612 commented on GitHub (Apr 9, 2026):
Would you be able to do a power cycle and provide the whole newt log?
<!-- gh-comment-id:4210909108 -->
@oschwartz10612 commented on GitHub (Apr 9, 2026):
Would you be able to do a power cycle and provide the whole newt log?
I assume you mean the router. I'll attach a log later.
<!-- gh-comment-id:4210959707 -->
@Frost-4X commented on GitHub (Apr 9, 2026):
Power cycle what?
I assume you mean the router. I'll attach a log later.
@github-actions[bot] commented on GitHub (Apr 24, 2026):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
<!-- gh-comment-id:4309620962 -->
@github-actions[bot] commented on GitHub (Apr 24, 2026):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@AstralDestiny commented on GitHub (Apr 24, 2026):
Curious why the mac randomization? Don't want isp to track you or something even though no matter how much time the public ip changes they have something that will always point to you as a customer and your past given ip's handed out..
As for newt put it into --log-level debug and restart and let us know what the logs say. Just know logs might contain your domain and other stuff.
<!-- gh-comment-id:4309643116 -->
@AstralDestiny commented on GitHub (Apr 24, 2026):
Curious why the mac randomization? Don't want isp to track you or something even though no matter how much time the public ip changes they have something that will always point to you as a customer and your past given ip's handed out..
As for newt put it into --log-level debug and restart and let us know what the logs say. Just know logs might contain your domain and other stuff.
My router is a subnet router under another router that's connecting to the WAN. By Randomising, it makes the traffic seem like different devices, though its pretty evident where its coming from. It just something I setup once and forgot to disable. The problem has nothing to do with randomisation, that's just the trigger.
I'll try remember to get around to posting some debug logs, pretty busy at present.
<!-- gh-comment-id:4309665587 -->
@Frost-4X commented on GitHub (Apr 24, 2026):
My router is a subnet router under another router that's connecting to the WAN. By Randomising, it makes the traffic seem like different devices, though its pretty evident where its coming from. It just something I setup once and forgot to disable. The problem has nothing to do with randomisation, that's just the trigger.
I'll try remember to get around to posting some debug logs, pretty busy at present.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Frost-4X on GitHub (Apr 9, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2815
Describe the Bug
I have a router that I've set to randomise the MAC address every 3 days. When that happens the interface gets dropped for a moment to apply the changes. When it comes back online, Newt fails to reconnect, and does its consecutive pings.
WARN: 2026/04/09 00:31:22 Periodic ping failed (15 consecutive failures): all 4 ping attempts failed, last error: failed to read ICMP packet: i/o timeoutI checked with to make sure it had nothing to do with the MAC randomisation, and sure enough, a simple router reboot causes Newt to go into stasis.
I have two servers running on the same network, with different Newt versions, they both go into stasis.
Environment
To Reproduce
Have a working instance of pangolin, with Newt running, then restart the interface that Newt is connected to.
Expected Behavior
Newt should be able to identify the interface has probably restarted, and attempt to initiate some kind of reconnection.
@Frost-4X commented on GitHub (Apr 9, 2026):
I've turned of my randomisation schedule, so this will affect me less. However, its still an inconvenience if my router ever gets power cycled, I lose my Pangolin connections. Then I have to connect to my server via other tunnelling services, and restart both instances of Newt.
@oschwartz10612 commented on GitHub (Apr 9, 2026):
Would you be able to do a power cycle and provide the whole newt log?
@Frost-4X commented on GitHub (Apr 9, 2026):
Power cycle what?
I assume you mean the router. I'll attach a log later.
@github-actions[bot] commented on GitHub (Apr 24, 2026):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@AstralDestiny commented on GitHub (Apr 24, 2026):
Curious why the mac randomization? Don't want isp to track you or something even though no matter how much time the public ip changes they have something that will always point to you as a customer and your past given ip's handed out..
As for newt put it into --log-level debug and restart and let us know what the logs say. Just know logs might contain your domain and other stuff.
@Frost-4X commented on GitHub (Apr 24, 2026):
My router is a subnet router under another router that's connecting to the WAN. By Randomising, it makes the traffic seem like different devices, though its pretty evident where its coming from. It just something I setup once and forgot to disable. The problem has nothing to do with randomisation, that's just the trigger.
I'll try remember to get around to posting some debug logs, pretty busy at present.