WAN_detect issues

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Only on Vodafone Portugal - FIber line
2. WAN Connection - DHCP and VLAN 100 for Internet tagged

What is the expected output? What do you see instead?
No issues should be expected, at least when using a stock firmware from ASUS, 
and using the Thomson Router from Vodafone.
It happens everyday between 23:00 and around 23:05, the wan goes down:
Jul 28 23:02:04 detect_wan: No response from gateway (93.108.192.1)! Perform 
DHCP renew...
Jul 28 23:02:22 RT-N56U: wan down (eth3)
Jul 28 23:02:22 dhcp client: deconfig: lease is lost
Jul 28 23:05:59 RT-N56U: wan up (eth3)
Jul 28 23:05:59 RT-N56U: Hardware NAT: Enabled, IPv4/PPPoE offload 
[WAN]<->[LAN/Wi-Fi]
Jul 28 23:05:59 RT-N56U: Software FastNAT: Disabled
Jul 28 23:05:59 RT-N56U: DDNS: Start update DDNS...
Jul 28 23:05:59 RT-N56U: DDNS: WAN IP address [xx.xx.xx.xx] not changed since 
the last update. Skip update.
Jul 28 23:05:59 dhcp client: bound (eth3), IP: xx.xx.xx.xx, GW: 93.108.192.1, 
lease time: 3600

What version of the product are you using? On what operating system?
Any version from your custom firmware have the same problem. It is OS 
independent.

We discovered that between that time (23:00 to 23:05) the ISP gateway stops 
responding to arp requests. I've tested adding the MAC-Address of GW on the ARP 
table as static, but no good. Using another FW from DD-WRT on the RT-N16U and 
the adding the ARP Static of the GW it resolves the problem. This is not a 
hardware problem from my RT-N56U as there are lots of persons using the same 
ISP that report the same issue when using your FW.

We intend to use your FW, because of it's features, performance and stability 
but would like to have this problem solved. Maybe changing some settings on the 
"wan_detect" method, give us some tests commands so we can give it a try. We 
only have 1 possibility per day, that's why we are only raising this issue now, 
as it took so much time to have some conclusions.

Please help us out thank you

Original issue reported on code.google.com by gjbarra...@gmail.com on 28 Jul 2012 at 10:50

[GoogleCodeExporter]

Hi all,

I had reported something like this previously, but my technical know how was 
not enough to progress much on testing such as my friend above.
Thanks to him we both have been testing different approaches to the problem 
such as adding the MAC-Address of the GW to the ARP table as static.
Others using Draytek devices and dd-wrt on RT-N16 devices solved this issue by 
using the method described above.

I have the exact same problem with the router as described above, every day 
between 23:00/23:05 the wan goes down.

Please let us know if we can help with anything in solving this issue.

Rgds.

Original comment by sousamig...@gmail.com on 28 Jul 2012 at 10:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Try to disable GreenEthernet on switch control page.

Original comment by andy.pad...@gmail.com on 30 Jul 2012 at 2:27

[GoogleCodeExporter]

Hi Andy,

Thanks for getting back to us.
I at least, have the green ethernet functionality always disabled.

Original comment by sousamig...@gmail.com on 30 Jul 2012 at 2:47

[GoogleCodeExporter]

You can disable "detect_wan" logic (gateway ARP poller). Type manual command
nvram set detectWan=0
and update WAN connection from main page

detect_wan logic used only for Automatic IP.

Original comment by andy.pad...@gmail.com on 30 Jul 2012 at 3:17

[GoogleCodeExporter]

That's exactly what we are using: Automatic IP.

Will this have any repercussion in the automatic ip service at all? Or does it 
only mean that we have always to manually start the connection from the WAN 
connection main page?
Imagining another scenario in which the router looses wan connectivity, we 
would have to go there manually and start the connection?

Will test it for now and maybe we can carry on from here.

Thanks a lot!

Original comment by sousamig...@gmail.com on 30 Jul 2012 at 3:31

[GoogleCodeExporter]

Hi Andy,

Thank you for your feedback, we will give try in our only testing window per 
day between 23:00 to 23:05. :)

keep up the excellent work!!!

Original comment by gjbarra...@gmail.com on 30 Jul 2012 at 3:41

[GoogleCodeExporter]

With detectWan=0 logic always not started "detect_wan" daemon on WAN up.

nvram set detectWan=0
nvram commit

commit - writed settings in NOR flash and detectWan=0 will be stored after 
reboot or after poweroff.

Original comment by andy.pad...@gmail.com on 30 Jul 2012 at 3:51

[GoogleCodeExporter]

Basically we will have the WAN interface always up and in case of failure (ARP 
GW) it will not go down, even if it looses the IP (DHCP lease finished) it will 
keep up and trying to get from the DHCP an IP Address.
We are in Automatic IP mode so...

appreciate your help.

Original comment by gjbarra...@gmail.com on 30 Jul 2012 at 4:11

[GoogleCodeExporter]

Hi Andy,

It worked!!! With the detectWan=0 the interface didn't went down. thank you.

You could make an option on the web interface so that anybody could disable 
this "detect_wan" method when "Automatic IP" mode is chosen. It would be 
dedicated to all the users that at least here in Portugal that use Vodafone as 
the Internet service provider through fiber optic, and use this router and your 
excellent FW. In any other ISP that this happen it would be also be an 
advantage on your side.

Once again thank you for your help & work on this FW. keep up!!

Original comment by gjbarra...@gmail.com on 30 Jul 2012 at 10:31

[GoogleCodeExporter]

Hi all,

To reinforce my friend's feedback on this.
IT WORKED! :)

It actually is not a "problem" on your firmware itself, I ran the test tonight 
using a beta firmware from Asus 3.0.0.4.154 with your recommendations of 
disabling the detectWan. It worked perfectly! :)

If an checkbox could be added on the web interface to disable this config, it 
would make it perfect for everyone at least in Portugal using this firmware! :)

Thanks a lot for the help, attention and also for this great firmware (which 
after this final test I will indeed be reverting back! :D)
Kind Regards.

Original comment by sousamig...@gmail.com on 30 Jul 2012 at 10:35

[GoogleCodeExporter]

You can imagine as you can see in the attached speedtest with an Internet 
connection of 400Mb down and 40Mb up that we definitely need an excellent 
router and a perfect FW, so we really, really thank you for your help after all 
the long nights that we had trying to figure out and trying to collect all the 
necessary information to give to you so you could give us a quick resolution, 
as you did.

Regards,
Gonçalo

Original comment by gjbarra...@gmail.com on 30 Jul 2012 at 11:11

Attachments:

• 2092157921.png

[GoogleCodeExporter]

Added ARP ping alive to control OFF/ON in WebGUI

https://code.google.com/p/rt-n56u/source/detail?r=70d948bc4afa1ed1c8b68358e5ebab
5af38473d5

Original comment by andy.pad...@gmail.com on 31 Jul 2012 at 9:43

[GoogleCodeExporter]

To Gonçalo

N56U performance on IPoE and PPPoE connection:
WAN -> LAN 930Mbps
WAN <- LAN 890Mbps

Tested by iperf

Original comment by andy.pad...@gmail.com on 31 Jul 2012 at 9:46

[GoogleCodeExporter]

Andy,

Thanks a lot for this. Not only have you provided us with the solution for the 
issue really fast, but minutes after we reported and requested for this feature 
to be available on the webgui you have delivered.

I'm really amazed at the quality of your support on this project.
I can only say thanks a lot for everything and ask if there's a donate link or 
something around? :)

Kind Regards.

Original comment by sousamig...@gmail.com on 31 Jul 2012 at 9:47

[GoogleCodeExporter]

Hi  sousamig, just wanted to let you know there is a Donate button on Project 
Home page, I personally used it to support this wonderful project, the 
developers deserve this for sure :)

Original comment by bluesurv...@gmail.com on 31 Jul 2012 at 7:50

[GoogleCodeExporter]

Andy, so, in the latest firmware, is it possible to set detectWAN=0 from the 
Web GUI? I'm not sure what your comment on 31 Jul 2012 - "Added ARP ping alive 
to control OFF/ON in WebGUI" means.

Can you clarify?

Thanks.

Original comment by chu...@gmail.com on 14 Jul 2014 at 10:27