I have just been advised to ditch pfSense for an Eminem 'thing'
-
I would capture on the synology sonce you're trying to find what traffic is being received by it that's preventing it from sleeping.
Second choice would be a wireshark/tcpdump on a switch mirror port of the port the synology is plugged into.
-
Do the NASes use FHCP? If yes, it might be leases running out and renewals triggering the wake-up.
You could also emulate the behaviour Cisco-home-stuff, by writing a hell script which randomly locks up the router. No more ARP messages after that.
-
Do the NASes use FHCP? If yes, it might be leases running out and renewals triggering the wake-up.
I just spent while googling this to determine if 'FHCP' is commonly used to referer to a fixed lease but I think it's more likely a typo? :P Anyway that seems like a good call. The default DHCP lease time is 2 hours but can vary if the client asks for longer (or shorter). If you are using DHCP then try increasing the leasing time or moving to fixed IPs for the NAS devices. A packet capture would tell you if that is the cause though.
You could also emulate the behaviour Cisco-home-stuff, by writing a hell script which randomly locks up the router.
Ha! Sounds like you speak from painful experience.
Steve
-
I would suggest the sniffing on pfsense vs the Synology, just because the gui interface to the packet capture is going to be much easier to download and send on. With tcpdump you would have to write to a file, then pull that file off. And just the fact your running tcpdump on it should keep it from sleeping I would think.
While your sniffing - if you notice the thing try and go to sleep and then wake up and let us know this time - we can look in the sniff and see what was going on at that time.
While a switch would work - that is clearly going to be more complicated than the gui on pfsense ;) Sniffing on your machine with wireshark would show you broadcast traffic and arp - but you wouldn't see any unicast to the synology IP, unless you were on a span port on the switch that set it up to let you see the traffic, etc.
Sniff on pfsense should be the easy route to getting the info we want - which is what is on the network that could keep it from sleeping… Might be NOTHING, but we don't know until we see it.
-
Also..
If Dr Dre can put his name to laptops I can't see why Eminem shouldn't be doing routers. He's clearly found a gap in the market. :PSteve
-
Do the NASes use FHCP? If yes, it might be leases running out and renewals triggering the wake-up.
Thank you for your reply :P
No, they do not: they are passively set to static IP, meaning:
- On the Synology they are set to DHCP (I recall at first I had them set to static there too, but after that I couldn't access them anymore):
- On pfSense they are assigned a static IP.
They get the static IP from pfSense for a year now, so that is working. There is no explicit lease time set on pfSense, btw, it is simply using the defaults.
You could also emulate the behaviour Cisco-home-stuff, by writing a hell script which randomly locks up the router. No more ARP messages after that.
;D ;D ;D
(Been there, done that. The same script works for zyxel and draytek, btw).
-
I would suggest the sniffing on pfsense vs the Synology,
I am currently running the snif, I will upload it next; thank you John for your help :-*
-
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. -
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.
