What's new

Device all of a sudden is assigning itself a 169.254 IP address when coming out of standby

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

After having uninstalled and reinstalled Diversion from amtm the problem did not occur anymore.
It's about 10 days. I also reconfigured the DHCP to start IP allocation from 192.168.1.2 (before it was assigned to Diversion but now no more needed from 5.0).

Instead of powercycle you can reboot from amtm or run "service reboot" (simple reboot does not solve the issue).

It seems the packet loss is not the issue here even if I am still monitoring if the problem occurs.

Please advise if the Diversion uninstall/install solve the problem (in the Diversion page it is stated that the upgrade should be done from amtm and not from WebGUI); this might be the reason why I had problems; I see you did the same :)
Thanks for the reboot tips. A full power cycle often drops my WAN for several minutes and the fiber ONT doesn't seem to like it so it would be nice to reboot and not have to wait for WAN.

I did the Diversion upgrade from AMTM, not the WebGUI. What I meant by "inline" is that I didn't do an uninstall first and then install.

Will post an update after several days of testing, and fingers crossed it's sorted.
 
Try unplugging and replunging the port. Is there a switch between the host and the router? If you have spanning tree enabled, try keeping it disabled. If Asus dose not implement port fast then traffic will be blocked for 30 seconds when a port comes up and this can cause DHCP issues of the type you described.
Oh I unplugged and plugged many times. No switch, direct connection and I tried more than one port. As I said, I disabled spanning tree and it made no difference. Also the same problem occurs with devices with static IP address, it's not a DHCP issue
 
What is not changing your problem? With no additional switches involved, there is no reason to have spanning tree enabled. Turn it off if it is on and see if that helps.
I was sayin that I do not have a switch in between the router and the NAS and the problem is on the NAS.
I have a switch on another port where I have the TV and a Raspberry.
By th way with the same set-up I never had problems for years.
 
Oh I unplugged and plugged many times. No switch, direct connection and I tried more than one port. As I said, I disabled spanning tree and it made no difference. Also the same problem occurs with devices with static IP address, it's not a DHCP issue

Manually configure the IP on the host. Then you have no reliance on DHCP.
 
Manually configure the IP on the host. Then you have no reliance on DHCP.
It will not solve the issue. Even fixing the IP in the host will not unlck the situation (at least in my case).
Anyhow after Diversion uninstall/install the problem is not manifested so far.
 
It will not solve the issue. Even fixing the IP in the host will not unlck the situation (at least in my case).
Anyhow after Diversion uninstall/install the problem is not manifested so far.
How long have you been running since the diversion uninstall/reinstall?

Did you load your settings for diversion from a backup or start from scratch?
 
It will not solve the issue. Even fixing the IP in the host will not unlck the situation (at least in my case).
Anyhow after Diversion uninstall/install the problem is not manifested so far.

Great! I've been much happier since I stopped using most addons. While they provide nice features, they lead to frustrations like this. I now run addons like this on my NAS as a VM or plug in.
 
How long have you been running since the diversion uninstall/reinstall?

Did you load your settings for diversion from a backup or start from scratch?
It's now about two weeks and I started from scratch. Also I removed in the DNS the IP reserved for pixelserv.
 
Manually configure the IP on the host. Then you have no reliance on DHCP.
I already configured a static IP address on the host to test and it was no different. The port still remained in disabled state. I'm still waiting to test if reinstalling Diversion has made any difference and will update in a week
 
I guess I don't "get" the assigning of static IPs. There's more work involved just doing that, before the more work involved in assigning hostnames to those addresses in the router. If the clients behave properly while obtaining their DHCP address (which almost invariably doesn't vary anyway) then their hostnames work properly via DNS automatically. What's not to like about that?
 
I guess I don't "get" the assigning of static IPs. There's more work involved just doing that, before the more work involved in assigning hostnames to those addresses in the router. If the clients behave properly while obtaining their DHCP address (which almost invariably doesn't vary anyway) then their hostnames work properly via DNS automatically. What's not to like about that?
Agreed. I only tried a static IP address to test if it was a DHCP issue or not. So much to like about DHCP so everything bar my router uses DHCP under normal operations
 
I was sayin that I do not have a switch in between the router and the NAS and the problem is on the NAS.
I have a switch on another port where I have the TV and a Raspberry.
By th way with the same set-up I never had problems for years.

Just remove all the add-on scripts and reset/configure the router - Eric's code is fine...

You'll be better off for it...
 
Agreed. I only tried a static IP address to test if it was a DHCP issue or not. So much to like about DHCP so everything bar my router uses DHCP under normal operations

The reason for the static manual configured IP is to avoid communications problems on your network, router, or host resulting in missed DHCP packets.
 
Just remove all the add-on scripts and reset/configure the router - Eric's code is fine...

You'll be better off for it...

I agree with this. There is beauty in simplicity. The add on apps get almost no regression testing. You run them at your own risk and in my experience pain.
 
Just remove all the add-on scripts and reset/configure the router - Eric's code is fine...
I agree: after about one month I can say that since I reinstalled Diversion and amtm from scretch the problem disappeared ; so something was most likely messed in the router configuration.
 
Things seem to be working now that uninstalled and reinstalled diversion. 👍👍

(No hard resets accompanying it.)
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top