BIG UPDATE FW Version 3.0.0.4.220

[psg190]

Port forward issues here. Any time I try to hit an open port pointing to my WHS from outside the network my router crashes and reboots. Not pleased.

 

[psg190]

Port forward issues here. Any time I try to hit an open port pointing to my WHS from outside the network my router crashes and reboots. Not pleased.

Scratch that. It's when I try to use my *.homeserver.com or *.asuscomm.com domains within the network to hit various ports running on my WHS 2011 box. That's strange. I never had this problem on the last revision of the firmware. I guess I'll just be using internal IPs while at home and the domains while away from home? Pretty crappy.

 

[psg190]

Scratch that. It's when I try to use my *.homeserver.com or *.asuscomm.com domains within the network to hit various ports running on my WHS 2011 box. That's strange. I never had this problem on the last revision of the firmware. I guess I'll just be using internal IPs while at home and the domains while away from home? Pretty crappy.

Now I realize that it is likely a NAT loopback issue/bug. Any idea where I could play with the settings to get it resolved?

 

[jackbrennan]

Hi all,

I've upgraded to the latest release mentioned in this thread. I upgraded the firmware and then turned off the router and held in the reset button for 30 seconds and it seemed to reset everything back to factory defaults.

However my question is that i read on page one that i should telnet into the router to properly reset the NVRAM. Is this recommended?

 

[WeekendWarrior]

Radio is switching off after reboot

Hi,

I've just upgraded the router from the Asus .178 to the
Asus .220 FW as follows:
- Cleared the NVRAM first with "mtd-erase -d nvram"
- Uploaded the .220 firmware
- Reboot
- Re-entered all settings
- Reboot

After the reboot it's noticed that the 2.4Ghz radio (not using the 5GHz) comes on for about 20 seconds and then turns off. When switching the radio off on the admin webpage and turn it on again, same behaviour.

I've then performed the 30/30/30 action, re-entered again all settings, same behaviour after the reboot. Does anybody experienced this with this new FW?

 

[geko53]

What happened when you telnet'd into your router and issued the "mtd-erase -d nvram" command, then? You've got me curious now *smile*.

Telnet told me that NVRAM had been erased, but in reality nothing happend - the old settings remained after rebooting... Only after pressing the reset button for 10 seconds nvram was "clean"...

 

[WeekendWarrior]

Hi,

I've just upgraded the router from the Asus .178 to the
Asus .220 FW as follows:
- Cleared the NVRAM first with "mtd-erase -d nvram"
- Uploaded the .220 firmware
- Reboot
- Re-entered all settings
- Reboot

After the reboot it's noticed that the 2.4Ghz radio (not using the 5GHz) comes on for about 20 seconds and then turns off. When switching the radio off on the admin webpage and turn it on again, same behaviour.

I've then performed the 30/30/30 action, re-entered again all settings, same behaviour after the reboot. Does anybody experienced this with this new FW?

Found the issue:
I've performed an other "mtd-erase -d nvram" and entered the settings.
After eacht setting change, I've rebooted the router monitored by a constant ping.... A normal reboot looks like (dutch):

Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
etc, etc

But as soon I disabled the 5Ghz radio and then performed the reboot, the pings are (dutch):

Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Time-out bij opdracht.
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=100
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Time-out bij opdracht.
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=100
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=100
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
Antwoord van 192.168.1.1: bytes=32 tijd<1 ms TTL=64
etc etc

And although the 5Ghz is off (correct), the 2.4GHz LED is on (correct), and the admin webpage is showing the radio is switched on (correct), there is no connection from my devices to the router after a minute or so after the reboot (incorrect).
Looks like everytime a new FW is released, a new bug in the WiFi-settings is introduced.....

 

[RMerlin]

Telnet told me that NVRAM had been erased, but in reality nothing happend - the old settings remained after rebooting... Only after pressing the reset button for 10 seconds nvram was "clean"...

I can't see any way your settings could survive running mtd-erase, since that effectively erase the content of the actual partition storing the settings.

 

[geko53]

I can't see any way your settings could survive running mtd-erase, since that effectively erase the content of the actual partition storing the settings.

So much about theories... I only can repeat: neither restore to factory default in WebGUI nor mtd-erase cleared NVRAM - the wireless settings (including SSID which differed from factory default) and the OpenVPN keys and settings "survived" and could only be erased by the use of the reset button on the router...

Good old Murphy - look down

 

[pcp]

hi..
being pretty new to the N66u and even newer to this forum: hello to all of you and thanks for doing what you do here =)

but this was not the reason for me chiming in

i just updated my N66u and restored my previously saved settings back in and everything is running fine so far.

The nvram check tells me:

size: 31911 bytes (33625 left)

So... can i assume, that "mtd-erase -d nvram" is not necessary for me, because nvram total is 64k?

best regards =)

greeting..
pcp

 

[psg190]

No one else is having loopback issues?

 

[RogerSC]

Hi all,

I've upgraded to the latest release mentioned in this thread. I upgraded the firmware and then turned off the router and held in the reset button for 30 seconds and it seemed to reset everything back to factory defaults.

However my question is that i read on page one that i should telnet into the router to properly reset the NVRAM. Is this recommended?

I do have one key piece of hardware that is connected to my router that requires fully erasing the nvram to operate correctly after a firmware upgrade. Just pressing the reset button for 30 seconds (or whatever) does not clear the nvram fully enough, apparently. I expect that there is other hardware out there that also benefits from fully erasing the nvram, which is normally done by telnet'ing into your router.

So yes, fully erasing the nvram after a firmware flash before entering your settings is good practice.

 

[psg190]

No one else is having loopback issues?

Looks like it was a GRO issue as referenced by Merlin. Took my flash drive out and it works fine now. Grrrrr.

 

[RMerlin]

Looks like it was a GRO issue as referenced by Merlin. Took my flash drive out and it works fine now. Grrrrr.

I mentionned that issue to Asus a few weeks ago, but I had only limited details at the time. I'll poke again at Asus's devs once I get ahold of the build 220 code and see if they can work on resolving this issue (either by fixing GRO, or by disabling it in their own releases). Having the router flat out crash under various usage scenario (NAT loopback, VPN access, etc...) is fairly major and needs to be addressed.

 

[RMerlin]

hi..
The nvram check tells me:

So... can i assume, that "mtd-erase -d nvram" is not necessary for me, because nvram total is 64k?

If you were running Asus's firmware, it's still recommended to erase the nvram when upgrading to 64 KB, to ensure a clean upgrade.

Also, it's not recommended to restore settings from a previous firmware version. It might work, but you might also run into issues down the road.

 

[pcp]

thank you! ill keep that in mind and restore settings 'manually', if i see issues. DHCP reservations are sort of pita this way
regards..
pcp

 

[RMerlin]

thank you! ill keep that in mind and restore settings 'manually', if i see issues. DHCP reservations are sort of pita this way
regards..
pcp

Before resetting/flashing, run this over Telnet:

nvram get dhcp_staticlist

Note down the string it returns. After resetting, telnet again, and run this:

nvram set dhcp_staticlist="what_you_noted_down"
nvram commit

There you go. Instant restored DHCP leases.

 

[pcp]

holy.. this easy? sweeet!

thank you so much!

 

[psg190]

I mentionned that issue to Asus a few weeks ago, but I had only limited details at the time. I'll poke again at Asus's devs once I get ahold of the build 220 code and see if they can work on resolving this issue (either by fixing GRO, or by disabling it in their own releases). Having the router flat out crash under various usage scenario (NAT loopback, VPN access, etc...) is fairly major and needs to be addressed.

Thanks Merlin! Needless to say it has been a bit of a headache. Appreciate all of your help!

 

[furiannn]

Before resetting/flashing, run this over Telnet:
Note down the string it returns. After resetting, telnet again, and run this:
There you go. Instant restored DHCP leases.

Nice, is there a command similar to this for the port forward table?