Asus AC87U ARP requests waking Synology NAS

[Iwakan]

Before talking with Asus we need to know if this problem is present in stock firmware too. I use Merlin and can't check but maybe another member or RMerlin can confirm if networkmap module has been modified in Merlin.

 

[GSpock]

... or RMerlin can confirm if networkmap module has been modified in Merlin.

Look at this one: http://www.snbforums.com/threads/37...p-network-attached-printer.26529/#post-199470

 

[sfx2000]

I do not want to continue a polemic with you on the matter ..... it seems you keep on forgetting that the issue we are having was not present in older Merlin firmware ... and you seem to believe there is a bug in Synology FW and freescale chipset which BTW is not the chipset in my Synology ; if this is your point, fair enough, I have another one.

You seem to forget that ARP has nothing to do with triggering WOL - it's the Magic Packet that wakes the device up... the NAS is kept in the ARP table, so when it's in deep sleep, the Router can still match the MAC address of the NIC to the IP address of the NAS, that's the only purpose for ARP in the case of WOL...

Whether or not it worked before or after Asus Firmware updates - it's immaterial... there have been reports of Synology NAS boxes waking up unexpectedly with other router vendors as well.

If the Synology is doing WOL correctly, it ignores any packets except for the Magic Packet, but Synology is not doing that, or they're leaving the NIC in a bad state when they go into deep sleep... I looked at the Freescale/NXP case specifically, as that's what OP has in his NAS, but the bug could actually be in the mainline code, and as such, affect other Architectures as well (ARM/x86)

The real fix needs to come from Synology.

Have a very nice day... And next time someone offers to provide some in-depth insight, perhaps you should appreciate their time and contributions, whether you agree with it or not.

 

[sfx2000]

Fear and Loathing of the blocked post...

"This message is awaiting moderator approval, and is invisible to normal visitors."

 

[GSpock]

You seem to forget that ARP has nothing to do with triggering WOL - it's the Magic Packet that wakes the device up... the NAS is kept in the ARP table, so when it's in deep sleep, the Router can still match the MAC address of the NIC to the IP address of the NAS, that's the only purpose for ARP in the case of WOL...

Whether or not it worked before or after Asus Firmware updates - it's immaterial... there have been reports of Synology NAS boxes waking up unexpectedly with other router vendors as well.

If the Synology is doing WOL correctly, it ignores any packets except for the Magic Packet, but Synology is not doing that, or they're leaving the NIC in a bad state when they go into deep sleep... I looked at the Freescale/NXP case specifically, as that's what OP has in his NAS, but the bug could actually be in the mainline code, and as such, affect other Architectures as well (ARM/x86)

The real fix needs to come from Synology.

Have a very nice day... And next time someone offers to provide some in-depth insight, perhaps you should appreciate their time and contributions, whether you agree with it or not.

Let's agree to disagree ; I disagree that you have offered in-depth insight, you simply loop back on saying Synology has to provide a fix while we (a few others and I ) have demonstrated the issue we talk about (i.e. systematic hourly wake-up of -NAS) is in Merlin FW(admitted by Merlin himself in another post related to printer wake-up) EVEN if you might be right than in other circumstances, the NAS wakes-up when it should not .... but that was not the point here.
Anyway, indeed, thanks for your time exchanging points of view.
End of story & last message to you on this topic from my side.

 

[Iwakan]

Asus is aware of this issue. There are some Asus developers collaborating in this forum and they have been informed about the problem by Rmerlin and other members (also by me) but to be honest I don't think they will hear us, at least, to release a fix quickly...

...and from my point of view the fix could be easy, let the admin choose between using enhanced network map, basic network map or completely disable this feature.

 

[john9527]

This is not anything new in the world of product development....

Product A (Asus) makes an enhancement, following all specs and practices. The result of this change is to expose a problem in Product B (Synology). Now what to do? The technically correct solution is for Product B to fix their product. However, everyone will point the finger at Product A since 'it used to work before'. I've see this many times in my career.

Now, Product A, being concerned about the incorrect perception of their product, may try to develop a workaround if possible depending on complexity and the ability to work around the technical implementation. It may not be, or the changes may be too cost ineffective/difficult to implement.

I suspect the change was to address issues with a slowly populating client list (why when I open the client list doesn't it immediately show all my clients?). So Asus likely had a reason for the change.

 

[sfx2000]

Asus is aware of this issue. There are some Asus developers collaborating in this forum and they have been informed about the problem by Rmerlin and other members (also by me) but to be honest I don't think they will hear us, at least, to release a fix quickly...

...and from my point of view the fix could be easy, let the admin choose between using enhanced network map, basic network map or completely disable this feature.

Yeah, but it does seems that Asus's changes seem to be problematic - so perhaps backing out changes is the fix...

Been there, done that - and having felt the pain of making a change to fix/workaround someone else's error...

 

[Iwakan]

I finally found a temporary workaround using ebtables that works fine for me. By adding this lines to services-start script you can configure an arp proxy to filter all arp requests from internal network to NAS letting router do this job (first command) and block all arp requests from router itself to NAS (second command). Third command is for add an static entry on router's arp table for NAS.

ebtables -t nat -A PREROUTING -p arp --arp-opcode request --arp-ip-dst [NAS IP] -j arpreply --arpreply-mac [NAS MAC]

ebtables -A OUTPUT -p arp --arp-ip-src [ROUTER IP] --arp-ip-dst [NAS IP] -j DROP

arp -s [NAS IP] [NAS MAC]

Finally you need to add an script to add an static entry in NAS arp table for router every reboot.

For me this is working fine and now my NAS is not waking up every hour. Please take care if you want to implement this workaround as it can break something in your environment.

P.S. Asus, please, fix this!

 

[GSpock]

Finally you need to add an script to add an static entry in NAS arp table for router every reboot.

Hi,
thanks for this. Can you please clarify what this sentence means ? Is this not already covered in your post by the arp -s [NAS IP] [NAS MAC] command ?
Rgds,
GS

 

[Iwakan]

Hi GSpock

You need to add a static arp entry in router and nas arp tables. First arp -s is for add a nas entry in router's arp table. Last sentence means that you need to add a static arp entry in NAS arp table about router info (arp -s [ROUTER IP] [ROUTER MAC])

 

[GSpock]

Hi GSpock

You need to add a static arp entry in router and nas arp tables. First arp -s is for add a nas entry in router's arp table. Last sentence means that you need to add a static arp entry in NAS arp table about router info (arp -s [ROUTER IP] [ROUTER MAC])

Thanks Iwakan,
just for info, when I tried the command on the Synology system, I got back the following error:
SIOCSARP: Operation not permitted

that was because I was connected as "admin". Once conntected as "root", the command sucessfully completed.
GS

 

[Iwakan]

Thank you for the info. Have you tried this? Is working?

 

[GSpock]

Thank you for the info. Have you tried this? Is working?

not yet ... no much access to IT equipements those days .... since it worked for you, no doubt it will work for others ...

 

[Yiannis]

Someone mentioned to activate the firewall on Synology and add a "deny" rule for Asus IP address. I did that and the Synology sleeps like a baby.

Here is also Synology's help page on this case. Make sure you meet the requirements.

https://www.synology.com/en-global/...Synology_NAS_from_entering_System_Hibernation