Problem rt-n66 with cable modem dcm-475

[DSwit]

Has the dcm-475 modem been bridged by your isp?

In non bridged mode the dcm-475 router may be attempting to assign a 192.168.1.x address to the asus which would be problematic, while the dlink routers generally use a 192.168.0.x address range although there are exceptions.

Are you powering up the two devices at the same time or waiting for the dcm-475 modem to train up before powering on the asus router?

Are you reloading settings previously saved from an older firmware install?

I would recommend only upgrading to the last stable version of RMerlin's firmware during the troubleshooting process. I say this as a best practices statement as using beta code during any troubleshooting process can introduce other factors that a person may not be aware of immediately and impede the process of determining the actual cause of the issue. This not to say that RMerlin's firmware is of itself problematic, it is normally rock solid. However, using beta code during troubleshooting should be reserved for a last resort imho.

 

[Mistermoonlight]

In non bridged mode the dcm-475 router may be attempting to assign a 192.168.1.x address to the asus which would be problematic, while the dlink routers generally use a 192.168.0.x address range although there are exceptions.

Probably working in bridge mode. I am getting 1st a private address 192.168.100.x while the cable network is not linked. My router lan address is a different subnet, so i guess it should not cause any problem.

Are you powering up the two devices at the same time or waiting for the dcm-475 modem to train up before powering on the asus router?

Because i want to simulate the exact behavior when a power failure returns, both are powered at the same time (i know that if the cable modem llinked 1st and the router starts after, this is ideal and would probably not cause any problem). Unfortunatly, the behavior and want to solve is not like this and is useless to simulate a different behavior than the one that causes problem. I got this same router a couple of years running with a dsl modem without ever getting any sort of brownout problem

Are you reloading settings previously saved from an older firmware install?

I reset everything in the router and reconfigured from scratch after uppdating to 50beta1.

I would recommend only upgrading to the last stable version of RMerlin's firmware during the troubleshooting process.

Yes i understand this, but i was running a previous 2 years old real stable firmware with the exact same issue, and i updated only to see if this would change something. Nothing change at all after 50beta1 update, so this tells me that it is not more broken in the new firmware, if it was a bug, it was already there in the previous 2 yrs old firm...

Thanks for all the idea.

 

[john9527]

Not sure if this will work, but you might try using a postconf script to insert a delay since these are run as a blocking script. I'd suggest maybe using dnsmasq.postconf with a long sleep command in it.

 

[Mistermoonlight]

Not sure if this will work, but you might try using a postconf script to insert a delay since these are run as a blocking script. I'd suggest maybe using dnsmasq.postconf with a long sleep command in it.

I am gonna try this...

Thanks

 

[Mistermoonlight]

I have tried a script like "dnsmasq.postconf" with this content

#!/bin/sh
sleep 45


I have also tried "dhcp6s.postconf" with the same content. I thought these would postpone in time the dhcp service. Is this wan dhcp client or lan dhcp server that is related to dhcp6s.postconf? This does not delay at all the wan dhcp client who is getting an ip as fast as before the postpone script.

I have also noticed that the 1st 2 wan transactions after power up of both modem/router are ipv6 "multicasr listener report", 1st one from the modem, and second one from the router. But router ipv6 gui page has 3 settings to disable Is this ipv6 configuration is supposed to keep the router from sending any ipv6 packet to the wan???

 

[Mistermoonlight]

Googling told me dhcp6s is for server, so it is related to lan side i guess. This was not a good script to use i guess...

 

[john9527]

I took a look at the code...try using fstab.postconf

 

[tk421]

I had this exact same issue, with a ac68u and dcm-476. Basically if the router started up before the modem was ready, it would fail to get an IP, try again, fail, then give up forever.

I solved it (at least I think I did - haven't had any more issues) by creating a script in wan-start that basically waits a little bit, sees if it can ping something, and if not, restarts the wan interface.

Here's the contents of my wan-start:

#!/bin/sh

exec 200>/tmp/wancheck.lck
flock -n 200 || exit 0
sleep 90
ping -W 5 -c 1 8.8.8.8  >/dev/null 2>&1
if [ $? -eq 0 ]; then
   logger -t WANCHECK WAN OK
else
   logger -t WANCHECK WAN Failed. Restarting
   flock -u 200
   service restart_wan
fi

The flock is necessary to prevent multiples running at the same time.

 

[Mistermoonlight]

john9597 said:

I took a look at the code...try using fstab.postconf

For an unknown reason, it is not working. I guess there is something buggy at that time in the wan dhcp client that this solution could not solve.

tk421 said:

I had this exact same issue, with a ac68u and dcm-476. Basically if the router started up before the modem was ready, it would fail to get an IP, try again, fail, then give up forever.

I solved it (at least I think I did - haven't had any more issues) by creating a script in wan-start that basically waits a little bit, sees if it can ping something, and if not, restarts the wan interface.

Here's the contents of my wan-start:

Code:

#!/bin/sh

exec 200>/tmp/wancheck.lck
flock -n 200 || exit 0
sleep 90
ping -W 5 -c 1 8.8.8.8 >/dev/null 2>&1
if [ $? -eq 0 ]; then
logger -t WANCHECK WAN OK
else
logger -t WANCHECK WAN Failed. Restarting
flock -u 200
service restart_wan
fi

The flock is necessary to prevent multiples running at the same time.

Yes your script solved the problem . Everytime, i could get a public ip in around 95 to 120 secs after powerup. As we can see that the sleep in your scrippt was 90 secs, this tells me that most of the time my router is not able to get an ip by itself without restarting the wan driver through your script...

I have also discovered something like a kind of another bug: the gui internet status could tell the internet is connected on the main page even if the wan ip is 0:0:0:0 (the modem provided a private address at the beginning), no matter if i refresh the web page or click on the 'globe' icon to see the wan connection details.

I am also happy to see that i am not alone in the universe with this strange bug and it is probably a problem in the wan driver of the router. Something that probably does not help the dhcp protocol to get a public address is that once the wan is getting a private address, the lan to wan path is opened and i have 2 voip ata that are flooding the path with repetitive request to register to their servers. So maybe some dhcp packets get lost because of packets buffer filled???

So a very great thank to both of you for all the time you put to help me on this

 

[Mistermoonlight]

Added another contribution to RMerlin donation page cause this flexible firmware saved the situation again.

 

[Rankdropper84]

Just to throw something different out there, what is the downstream/upstream power levels your modem is receiving along with the signal to noise ratio? I just skimmed through all the posts in this thread so I apologize if you already answered this but when you say "power failure" do you mean the modem is resetting itself or are you tripping a breaker in essence? To me it sounds like you might have power levels that are causing the modem to reset itself.

 

[Mistermoonlight]

Power failure, i mean no more electricity coming to the router