I have just been advised to ditch pfSense for an Eminem 'thing'
-
Do you have WOL enabled on the Synology machines? If so you might want to check which modes are set for waking up and change them or disable WOL if it is not needed. I had the same issue where a machine would sleep/suspend but wake up within a few minutes even though it was not needed. In Linux with ethtool WOL can be configured with the following:
p Wake on phy activity
u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages
a Wake on ARP
g Wake on MagicPacket
s Enable SecureOn(tm) password for MagicPacket(tm)
d Disable (wake on nothing). This option clears all previous options.Thank you, Gibby; as a matter of fact: yes, WOL is enabled. I recall it doesn't work ;D ;D ;D
Unfortunately, there is nothing to be customized (in the GUI): I attached a screenshot.
The configuration options you posted are promising; it might very well be this is a cause of the problem. I've sent the capture to JohnPoz, I'd not be surprised if John would share your thoughts :P
Thank you again,
Bye,
-
@Hollander:
Thank you NoyB ;D
I just checked: it appears tcpdump is installed by default on the Synology.
So now there are two (three) ways of doing this I guess:
A. pfSense: System/Diagnostics (John)
B. Synology (tcpdump)
C. (Wireshark directly - my guess, at least).Will they show the same results, should I run one of them, or both?
A will certainly be different that B and C.
B and C would likely be very close. Mostly dependent on where/how Wireshark sniffer is connected.Personally I'd do B because that is the network interface traffic that is in question. A capture of the pfSense interface as John points out is certainly the easier, but may or may not be exposed to the traffic that is keeping the Synology machine from hibernating. But the Synology interface definitely would be.
Since John is working with you, follow his lead though.
-
I second Gibby on the WOL. And a newbie shall lead them.
If there is not much WOL configuration options, you might try turning it completely off to see if that is the area of the problem.
Even if it turns out not to be the problem. Very good call Gibby.
-
Interesting info. I wasn't aware of anything but wake-on-magic packet. Good to know. :)
Steve
-
So he sent me a sniff.. And the only traffic I see on there that would keep the synology awake would be the synology. Which I see at 192.168.2.22, and gateway would be 2.1 I would assume
He is arping for the gateway every minute or so, he is doing ntp queries to the gateway 2.1 all the the time. I don't see him shut up for any longer than a minute ever in the sniff that runs for 36 minutes.
The only traffic that is not generated by 2.22 which I assume is the synology it from 2.11 and 2.12 arping for 2.22.. I see 2.11 arping for 2.22 every 5 minutes.. 2.12 only the once very early in the sniff.
So I would say that maybe the 2.11 arps are keeping him up – other then all the chatter he is sending out for ntp and his browser announcements and UPNP he sends out.. I would post some shots but still looks like getting 500 internal errors when trying to attach.
-
@Hollander:
yes, WOL is enabled. I recall it doesn't work
Most systems have many different power states. Typically WOL cannot wake the system from some of them. For instance some systems may wake from suspend/standby/sleep but may not be able to wake from hibernate.
-
So he sent me a sniff.. And the only traffic I see on there that would keep the synology awake would be the synology. Which I see at 192.168.2.22, and gateway would be 2.1 I would assume
He is arping for the gateway every minute or so, he is doing ntp queries to the gateway 2.1 all the the time. I don't see him shut up for any longer than a minute ever in the sniff that runs for 36 minutes.
The only traffic that is not generated by 2.22 which I assume is the synology it from 2.11 and 2.12 arping for 2.22.. I see 2.11 arping for 2.22 every 5 minutes.. 2.12 only the once very early in the sniff.
So I would say that maybe the 2.11 arps are keeping him up – other then all the chatter he is sending out for ntp and his browser announcements and UPNP he sends out.. I would post some shots but still looks like getting 500 internal errors when trying to attach.
Thank you very, very, much John :-*
I finally found an explanation of ARP I understand ( :P): when machines in the LAN communicate with eachother they have to send packets based on MAC address, not based on IP-address (never knew that at all). So ARP is the translation from IP to MAC. There is something called an 'ARP-cache', which every machine (desktops, servers) has. Only if an IP is not in the ARP-cache will a broadcast be sent out 'tell to … who has'.
From your analysis comes:
1. Two LAN desktop clients (W7-Pro), 2.11 & 2.12, ARP for 2.22. This is strange to me, as they have no business with that machine at all. They shouldn't even know it exists, let alone ask for it's MAC, as it is a 'backend machine', meant for backups between Synologies only; no LAN desktop client has access to it at all (there are no UID's, no SMB-mappings, or whatever). Perhaps it comes from some weird W7-'scan the network' kind of stuff?
2. Aside from .1., the 2.22, the Synology, is doing:- ARP for 2.1 (pfSense)
- NTP
- "browser announcements and UPNP" (as you write it, but I have no idea what it is :-). From the 'simple' log after running the packet capture also came this: 18:59:03.368856 IP 192.168.2.22.137 > 192.168.2.255.137: UDP, length 50. Is this the UPNP you mean?
What I don't understand is: if there is such a thing such as an 'ARP cache', why are both the 2.22 (Synology) and the 2.11/2.12 (desktop clients) constantly ARP-ing? Aren't they supposed to have that 'cache' that lasts longer than a couple of minutes?
What we at least know is pfSense is not ARP-ing the 2.22 as the Synology support representative said/guessed (he didn't even ask for logs). I did set up a static ARP for it, I don't know if it had anything to do with that.
From my memory I recall I've read here traffic on the same subnet does not go via the router, but simply via the switch ( I'm still not on top of this -> the router does IP-adressing and ARP, so some of the traffic has the involvement of the router would be my reasoning. I'm probably once again proving my noob-ness ;D). I have HP Procurve switches, and I've read somewhere I should set static ARP on the switch as well (so not only on pfSense, where it currently already has been set for 2.22). But will that solve any problem, if the Synology is initiating the ARP-ing? Shouldn't it be some static ARP set on the Synology? (And, again, does it make sense the Synology is ARP-ing so frequently? It should have an ARP-cache, no?).
Finally, it problably won't make sense to disable ARP on the W7-desktop clients, right? Since they need to ARP 'occassionally' (when they've cleared their cache - for whatever reason I fail to understand; if I tell a static ARP-entry on W7 (don't know how to do that yet, but just reasoning), and the 2.22 is always (static IP) on 2.22, there shouldn't be any reason to 'periodically clear the cache'.
I apologize for writing this slightly less structured than I normally do; haven't slept all night, and it is 7.14 PM at this moment already. I hope it is at least in some way understandable :-[
Thank you for all your help; muchos appreciados ;D
-
@Hollander:
What I don't understand is: if there is such a thing such as an 'ARP cache', why are both the 2.22 (Synology) and the 2.11/2.12 (desktop clients) constantly ARP-ing? Aren't they supposed to have that 'cache' that lasts longer than a couple of minutes?
Nope. That's about how long arp cache table entries typically last.
I think you have a few possible avenues of pursuit available.
- Configure Synology WoL to only wake on magic packet.
- Figure out why those W7 machines are arp-ing the Synology and stop it. First thing that comes to mind is Home Group config.
- Add static arp entries on those W7 machines in hopes it will stop them from arp-ing the Synology.
- Turn off Synology WoL and wake by a local time schedule instead.
-
OP, have you gone through their KB titled "What stops my Synology NAS entering System Hibernation?" -> (https://www.synology.com/en-us/knowledgebase/faq/568)?
It looks like there are 15+ other things that need to be researched before we even start going down that rabbit hole of looking at arp messages from PFsense. I think Synology is feeding you a line of BS.
-
From that article
"Local Master Browser: Synology NAS cannot hibernate if Local Master Browser is enabled (Go to Control Panel > Win/Mac/NFS > Windows File Service > Enable Local Master Browser)"
From the sniff it has not marked it is NOT browse master, or NOT backup, etc. So clearly from an election it could be the master browser.
From this
"If there are no unicast packets to the Synology NAS in 2 minutes, then the Synology NAS will enter the System Hibernation."I can tell you from the sniff that was 36 minutes – there WAS no unicast traffic TOO 2.22 -- there were a lot of answers to its queries for ntp. there was some arp, and there was some broadcast traffic and multicast - but there was NO Unsolicited unicast traffic to it in the whole 36 minutes.
-
Thank you John for your help, as I wrote you in the PM also :-*
Just a small update: Synology has done some remote debugging for two hours with two guys, leading to the diagnose they need guy-3, who wasn't in the house ;D
So they will try again next Monday, and I will update what comes from it.
