What's new

RT66U Firing ARP-Requests all day (Waking my Synology NAS from Sleep)

  • 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!

radza

New Around Here
Hi there SNB-Community!

I have an issue regarding a RT66U-Router and it's "feature"/habit to relentlessly fire arp-request-broadcasts into my "small net".

That wouldn't be a problem if it were'nt for my NAS Server (Synology DS213+), which is configured to fall into hibernation mode after 10 Minutes of being idle. My router keeps waking it up...

It's been a long way to determine the exact cause of my NAS waking up all the time. I was able to exclude all other possible causes, so I will not go into detail here. (since this is not the NAS-forum)

I already tried static ARP (arp -s <ip> <mac> and also added this command to the startup script). But the damn router continues to query the net for my NAS arp-data.

Since ARP is indispensable, I am not asking how to disable it ;-)
But why the hell has my router nothing better to do than fire arp-requests all day? I really need to know a way to either stop or at least reduce the arp-requests to my NAS. I already made sure the arp-table gets filled with the nas-data after reboot, so it will always have the information it needs.
But how can i command my router to stop asking about network devices it already knows?

A little help would be much appreciated. :)

Thanks in advance,
with best regards,
radza
 
This is most likely caused by networkmap which keeps track of the devices currently on your network.

Just as a test, telnet into your router, and kill the networkmap process:

Code:
killall networkmap

See if your NAS goes to sleep normally after that. If it does, it will confirm that it's the source of the requests.

Unfortunately networkmap cannot be disabled at this time.
 
thanks a lot for that quick response
Unfortunately that didnt do the trick :(

Killing networkmap made me take a closer look to the table of processes.
I discovered a service called lighttpd-arpping which i killed for testing.

That seemed to help. The nas stayed asleep a while longer. But the router restarted that service again by itself.. and voila : nas wakes up..

Can you help me a little further?

Thanks again
Regards
 
Last edited:
thanks a lot for that quick response
Unfortunately that didnt do the trick :(

Killing networkmap made me take a closer look to the table of processes.
I discovered a service called lighttpd-arpping which i killed for testing.

That seemed to help. The nas stayed asleep a while longer. But the router restarted that service again by itself.. and voila : nas wakes up..

Can you help me a little further?

Thanks again
Regards

That service is part of AiCloud. AiCloud can be disabled if you don't need it.
 
That service is part of AiCloud. AiCloud can be disabled if you don't need it.

Unfortunately i need the WOL feature of AiCloud, so disabling it is no way to go for me =/
While it's disabled, by the way, the NAS does NOT wake up from harddrive-hibernation mode. It has no effect on the deep sleep mode where the blue LED pulses and the whole system hibernates at 2W~. In the deep sleep mode it still get's woken up even with the services "networkmap" and the AiCloud ARPPing-tool killed.

Do you have an idea why it behaves this way?

Thank you :)

@jlake the thread you posted contained some comments about a mysterious patch which should fix various hibernation issues.. but noone posts a link to download.. ?! i can't seem to find this patch. :(
 
Maybe I am wrong about my arp-related suspicion..

This is a logfile my NAS created.
Maybe this helps?

Code:
[URL="https://dl.dropboxusercontent.com/u/7854408/log.txt"]https://dl.dropboxusercontent.com/u/7854408/log.txt[/URL]

Can you see anything?
 
No other idea then, I'm not familiar with Synology products, so I don't know how its power saving modes work.
 
This post may help explain why my Mac Pro has been waking up exactly once an hour, then going right back to sleep 30 seconds later.
 
This post may help explain why my Mac Pro has been waking up exactly once an hour, then going right back to sleep 30 seconds later.

Normally, a networked device shouldn't wake up unless explicitly receiving a WOL packet. If your Mac wakes up on any kind of network activity that seems to refer to it then Apple hasn't thought this too well.

I can understand a NAS working differently because it might be randomly accessed by other devices, but a computer? WOL should be the only network-based method of waking these up.
 
mac probably parts of apple's own cloud. just a thought. not using apple anyway

It's a 2009 model that doesn't have any of the new Internet-enabled features. iCloud is not installed.

It's also connected via Wi-Fi using the three-antenna Apple Airport Extreme card (AR5BXB112 model, Atheros 9380 chipset). http://www.amazon.com/dp/B00881PHO2/?tag=snbforums-20. The computer has internal antenna with connectors labeled 1, 2, 3, and they're all plugged in.

There isn't anything else in the Mac's logs to indicate why it's waking up. It just does. The screen doesn't turn on, though -- just the tower.
 
Normally, a networked device shouldn't wake up unless explicitly receiving a WOL packet. If your Mac wakes up on any kind of network activity that seems to refer to it then Apple hasn't thought this too well.

I can understand a NAS working differently because it might be randomly accessed by other devices, but a computer? WOL should be the only network-based method of waking these up.

The funny thing is. I explicitly configured the WOL on my nas via Ethtool on the CLI to exclusively react to a magic packet. I could also set the attribute that would make my nas wake via arp request.. but it seems to ignore this.. or maybe i am just on the wrong path here.. really frustrating Problem
 
I am having the same issue. It started with firmware 380.57 and is present in the stock ASUS firmware (judging by a post I found on their support forum). They seem to have changed something in their code and the ARP requests are being sent hourly, seemingly to every IP address in the LAN IP range. I tried putting in a static ARP entry but that doesn't seem to change the behavior of whatever process is doing (what I can only assume) is an hourly update of the ARP table. I tried killing the networkmap process and it restarted when I accessed the web UI and refreshed the device list without waking my NAS, so it appears to be some other process. AI Cloud is disabled and the arpping process is not running. I have no clue what they changed but it is a bit annoying. The previous 378-series firmware did not cause the NAS to wake up.

As bad as I hate to do it, I may have to revert to the previous firmware until such time as Merlin has recovered from his health issues and puts out an updated build. I rely too much on some of the added features to go back to the stock firmware.

Does anyone know if there are any configuration changes in 380.57 that would hose up the router if I downgraded to the previous 378-series firmware?
 
I have an update. I used the Synology firewall functionality to block my router from accessing the system via all ICMP, TCP and UDP ports and the DiskStation stopped waking up every hour (port forwarding and access via VPN to the NAS both still work of course). It appears to be some other function than the ARP packets that are actually waking up the NAS.

I tried this configuration change after I tried being logged into the router and watching the netstat output around the time the NAS was waking up and I noticed outbound port 139 connections from the router to the NAS. I have no clue why the router would be making that connection but the NAS was seeing it as a Windows File Sharing connection and waking up the disks to handle the subsequent login and file access (that never happened of course).

This must be some new "feature" in the ASUS firmware. On a side note, I have all of the file sharing and media sharing features on the router turned off as I don't need them with a dedicated NAS and it was STILL making hourly connection attempts on port 139 to the NAS.
 
Having the same issue with ds214 and RT-AC66U.
Reverted to the previous Merlin's firmware, 378.56_2.
But still the same. nas wakes up every hour.
 
Having the same issue with ds214 and RT-AC66U.
Reverted to the previous Merlin's firmware, 378.56_2.
But still the same. nas wakes up every hour.

378.54_2 was the last "working" version.

I am having the same issue. It started with firmware 380.57 and is present in the stock ASUS firmware (judging by a post I found on their support forum). They seem to have changed something in their code and the ARP requests are being sent hourly, seemingly to every IP address in the LAN IP range. I tried putting in a static ARP entry but that doesn't seem to change the behavior of whatever process is doing (what I can only assume) is an hourly update of the ARP table. I tried killing the networkmap process and it restarted when I accessed the web UI and refreshed the device list without waking my NAS, so it appears to be some other process. AI Cloud is disabled and the arpping process is not running. I have no clue what they changed but it is a bit annoying. The previous 378-series firmware did not cause the NAS to wake up.

As bad as I hate to do it, I may have to revert to the previous firmware until such time as Merlin has recovered from his health issues and puts out an updated build. I rely too much on some of the added features to go back to the stock firmware.

Does anyone know if there are any configuration changes in 380.57 that would hose up the router if I downgraded to the previous 378-series firmware?

You are a genius dude, I added 192.168.1.1 to the Synology Firewall on Deny all and my NAS sleeps like a baby on the latest Merlin firmware (380.57)
 

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