Reply

Re: Firmware 1.0.1.18 & WOL

schmieg
Aspirant

Firmware 1.0.1.18 & WOL

I recently installed Firmware 1.0.1.18 on my WNDR4500 and am having an unusual problem that occurred immediately. I use WOL through a Magic Packet to turn my network on every weekday morning. The computers are on all day long and then shut down at night after performing a backup. Since installing the new firmware, they are all receiving WOL signals all day long, even if the network computer that issues the Magic Packet to the local network is turned off. The only way to prevent the computers from firing up every few minutes is to disconnect the LAN cable or the power cable from the various computers. I have no need to use WOL across the WAN and only wish to use it on the LAN. Does anyone have any idea what is happening here and what settings I need to make to keep WOL locally, but prevent it from coming in from somewhere outside the network or from the router, whichever might be causing this?

Thanks.
Message 1 of 32
jmizoguchi
Virtuoso

Re: Firmware 1.0.1.18 & WOL

make sure you hard reset the router after flashing the firmware.

if still the same issues then revert the firmware and contact support for issues at my.netgear.com
VPN Case Study

VPNCASESTUDY.COM

"Our Second To None VPN Related Setup Case Study[/COLOR][/URL]

"One Stop Solution To Your Netgear VPN Connectivity"

*Visit the site for Non-VPN related Doc & Links* [Windows & Mac user/support]





June Mizoguchi-
Message 2 of 32
fordem
Mentor

Re: Firmware 1.0.1.18 & WOL

Have you actually confirmed that what you are getting ARE in fact WOL magic packets?

First - some systems can be "woken" by packets other than WOL magic packets, so that having the computers wake is no confirmation that WOL magic packets are being sent.

Second - magic packets are defined as having the MAC address of the target host repeated sixteen consecutive times, so they have to be created specifically for the hosts that you have on your network, making it highly unlikely that the router would be creating such packets on it's own.

So that you get an idea of how improbable such a thing is - a MAC address is 48 bits, so there are 281,474,976,710,656 possible MAC addresses.

Give a man a fish, feed him for a day
Teach a man to fish, feed him for life.
Message 3 of 32
mluna20
Tutor

Re: Firmware 1.0.1.18 & WOL

This is the R4500 Forum, not the WNDR4500 forum.
Message 4 of 32
tamanaco
Apprentice

Re: Firmware 1.0.1.18 & WOL

There is definitely something in firmware 1.0.1.18 affecting WOL enabled PCs. I didn't believe it at first, but after I upgraded to the latest firmware my media server only sleeps for a couple minutes and then wakes up without any device sending it the Magic Packet. As fordem mentions above, this is very improbable, but it's happening. My understanding of WOL is that With Wake Up on Magic the NIC looks at pockets of traffic with its MAC address in the pocket header and for a specific series of numbers that make up the Magic Packet in the data field. Once it finds the token pattern it wakes up the computer. To Wake Up on Link the computer only looks at the header of the packet for its MAC address and then wakes up the server. I reverted to 1.0.1.6 and the problems goes away. Waited a couple hours and the media server remained off. Installed 1.0.1.18 again and the problem returned. The WOL setting in the media server have been the same for years. Wish I could attach an image of the server adapter settings... they read as follow: Allow the computer to turn off this device to save power (CHECKED) Allow this device to wake the computer (CHECKED) Only allow a magic packet to wake the computer (CHECKED!!!) This is the reverse behavior I used to experience a few years back when I first setup the media server to WOL on Magic Packet. Once it was awaken with WOL the system returned to standby mode after a certain time. But this a MS WAD estrange behavior you need to interact with the server or have a app to prevent standby after WOL. see http://support.microsoft.com/kb/810719
Message 5 of 32
Valenni
Novice

Re: Firmware 1.0.1.18 & WOL

I also has this problem and had to disable smart LAN or WOL from BIOS. Otherwise rol back the firmware until Netgear get it sorted. (Which I hope is soon)
Message 6 of 32
Retired_Member
Not applicable

Re: Firmware 1.0.1.18 & WOL

My WNDR4500 did the same thing. I disabled WOL in the bios, and computer stopped turning itself on. I ended up reverting back to firmware 1.0.6.
Message 7 of 32
fordem
Mentor

Re: Firmware 1.0.1.18 & WOL

tamanaco wrote:
My understanding of WOL is that With Wake Up on Magic the NIC looks at pockets of traffic with its MAC address in the pocket header and for a specific series of numbers that make up the Magic Packet in the data field. Once it finds the token pattern it wakes up the computer.


This is incorrect - you can send any packet as long as it contains the "token pattern" which is a 256 character string containing the MAC address of the NIC sixteen (16) consecutive times. Since the packet must conform to the other Layer2 protocols, this 256 character string is usually in the data area of the packet.

If you're going to place the MAC address of the NIC in the packet header, there are only two places it can fit - in the source MAC address field, or the destination MAC address field (both of which can only contain it once) - the source MAC address will obviously contain the MAC addresses of the sending NIC, and if the magic packet is correctly formed the destination MAC should contain the LAN broadcast address FF-FF-FF-FF-FF-FF-FF-FF-FF.

To Wake Up on Link the computer only looks at the header of the packet for its MAC address and then wakes up the server.


I'm not certain if this is correct - what "link" are we talking about? Link in the sense of an ethernet LAN would be the link pulses that are used to establish that a connection exists - if you have a WoL capable host powered off it maintains a link to the switch (check the link status LEDs).

Some systems can be configured to wake on receipt of a magic packet, and others to wake on receipt of ANY packet and this is where I suspect the issue may be coming from - the router under the new firmware is sending some sort of a network broadcast - specifically NOT a magic packet containg the MAC address of the target host, but because of the host has been configured, it wakes.

This is the reason that my previous post asks if anyone with the problem has confirmed that a magic packet is being sent.

At this point we know that something in the firmware causes the host to wake, but to state that it's a magic packet is to jump to a conclusion.

Give a man a fish, feed him for a day
Teach a man to fish, feed him for life.
Message 8 of 32
tamanaco
Apprentice

Re: Firmware 1.0.1.18 & WOL

fordem wrote:
This is incorrect - you can send any packet as long as it contains the "token pattern" which is a 256 character string containing the MAC address of the NIC sixteen (16) consecutive times. Since the packet must conform to the other Layer2 protocols, this 256 character string is usually in the data area of the packet.

If you're going to place the MAC address of the NIC in the packet header, there are only two places it can fit - in the source MAC address field, or the destination MAC address field (both of which can only contain it once) - the source MAC address will obviously contain the MAC addresses of the sending NIC, and if the magic packet is correctly formed the destination MAC should contain the LAN broadcast address FF-FF-FF-FF-FF-FF-FF-FF-FF.


It is not "incorrect"... you're just describing the process in more detail. The token is made up of a "specific series of numbers" which you described in your reply and added information related to the layer of the OSI model that's is responsible for reading the field.


fordem wrote:
I'm not certain if this is correct - what "link" are we talking about? Link in the sense of an ethernet LAN would be the link pulses that are used to establish that a connection exists - if you have a WoL capable host powered off it maintains a link to the switch (check the link status LEDs).

Some systems can be configured to wake on receipt of a magic packet, and others to wake on receipt of ANY packet and this is where I suspect the issue may be coming from - the router under the new firmware is sending some sort of a network broadcast - specifically NOT a magic packet containg the MAC address of the target host, but because of the host has been configured, it wakes.


I was just describing the problem not detailing the WOL process. But to clarify the Data "Link" layer (Layer 2) of the OSI contains the Magic Packet. But a PC can also be awaken without the magic packet.

fordem wrote:
This is the reason that my previous post asks if anyone with the problem has confirmed that a magic packet is being sent.

At this point we know that something in the firmware causes the host to wake, but to state that it's a magic packet is to jump to a conclusion.


Nowhere in my description of the problem do I state that the magic packet is causing it. I just described the settings of the server of the server that's waking up. It's set to wake on magic packet. In other words, if should "not" wake up from other broadcasted frames.

Below is the description summary of the broadcast frame that I "suspect" is causing the server to wake up. XX:73:40 is the MAC address of the NIC in the media server with IP address 192.168.1.100.

1696 73.113069 UniwillC_XX:73:40 Broadcast ARP Who has 192.168.1.100? Tell 0.0.0.0
Ethernet II, Src: UniwillC_39:73:40 (XX:XX:XX:XX:73:40), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

To which the media server responds immediately with:

1697 73.114047 192.168.1.100 239.255.255.250 IGMP V2 Membership Report / Join group 239.255.255.250
Ethernet II, Src: UniwillC_XX:73:40 (XX:XX:XX:XX:73:40), Dst: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)
Internet Protocol, Src: 192.168.1.100 (192.168.1.100), Dst: 239.255.255.250 (239.255.255.250)

As I sniff for magic packets the NIC keeps receiving packet similar to the one below every 20 or so seconds.

Time received:
08/04/12 10:54:19
UDP Header:
|-Source IP : 157.56.149.60
|-Destination IP : 192.168.1.100
|-Source Port : 3544
|-Destination Port : 61791
|-UDP Length : 117
|-UDP Checksum : 30109
MAC Address:
FF FF 00 00 00 00
Raw Data (109 bytes):
00 01 00 00 93 63 05 37 5E 7C 97 94 00 00 00 0E
A0 93 C9 C3 D7 60 00 00 00 00 30 3A FF FE 80 00
00 00 00 00 00 80 00 F2 27 62 C7 6A C3 FE 80 00
00 00 00 00 00 00 00 FF FF FF FF FF FE 86 00 64
9D 00 00 00 00 00 00 3A 98 00 00 07 D0 03 04 40
40 FF FF FF FF FF FF FF FF 00 00 00 00 20 01 00
00 9D 38 95 3C FF 00 00 00 00 20 01 00

Again, I'm posting what I see not detailing the WOL process or identifying the cause of the problem.
Message 9 of 32
fordem
Mentor

Re: Firmware 1.0.1.18 & WOL

tamanaco wrote:
It is not "incorrect"... you're just describing the process in more detail. The token is made up of a "specific series of numbers" which you described in your reply and added information related to the layer of the OSI model that's is responsible for reading the field.


I hate repeating myself, but, you seem to not to grasp the point. It's incorrect because a correctly formed magic packet will NEVER have the target MAC address in the packet header.

tamanaco wrote:
My understanding of WOL is that With Wake Up on Magic the NIC looks at pockets of traffic with its MAC address in the pocket header and for a specific series of numbers that make up the Magic Packet in the data field. Once it finds the token pattern it wakes up the computer.


The packet headers should contain two MAC addresses, the source MAC address which will be the MAC address of whatever host sent the packet, and the destination MAC address should be the hardware broadcast address, which will be FF-FF-FF-FF-FF-FF-FF-FF

After examining the contents of the packets provided - they don't appear to be related to WoL - the first is an ARP request, and as far I can tell, the source address field appears to show what you claim is the MAC address of the media server, which I believe is what you're trying to wake - so I think we can safely conclude that that packet is not the one that's waking the media server, as it's being sent by the media server.

The second packet, which you describe as a response from the media server shows the same source address, as the first, and it seems to be attempting to join a multicast group, or at least establish the fact that the multicast packets should be sent to it.

The third packet appears to come from Microsoft (the source ip belongs to them) and does not contain the required string to wake the media server.

Perhaps what you need to do is disconnect the media server (if it's off there should be no data traffic with it's MAC address in the address fields to cause any confusion.

Disconnect it and leave the network idle for 30 minutes or so, by which time any network hosts that have it's MAC address in the arp cache should have flushed it, and then start sniffing..

Below are the contents of the data field of a Magic packet sent to 00-0D-60-83-8E-38 - see how easy it is to pickout the 16 repetitions?

00000000 : FF FF FF FF FF FF 00 0D 60 83 8E 38 00 0D 60 83
00000010 : 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00 0D
00000020 : 60 83 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38
00000030 : 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00 0D 60 83
00000040 : 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00 0D
00000050 : 60 83 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38
00000060 : 00 0D 60 83 8E 38

Notice also that I have no qualms about posting a MAC address on a public forum - there's nothing that anyone can do with the data to either hack my server (it's an IBM xSeries server), or to incriminate me in any way.

You might also want to use something like the Depicus Wake-on-LAN monitor as this will only show "true" magic packets ie, any packet containing the required 16 consecutive MAC addresses, ignoring all other traffic.

In fact - if Depicus Wake-on-LAN monitor doesn't show any traffic - it's a fairly safe conclusion that whatever is happening to wake the media server, it's not happening through a magic packet.

Give a man a fish, feed him for a day
Teach a man to fish, feed him for life.
Message 10 of 32
tamanaco
Apprentice

Re: Firmware 1.0.1.18 & WOL

fordem wrote:
I hate repeating myself, but, you seem to not to grasp the point. It's incorrect because a correctly formed magic packet will NEVER have the target MAC address in the packet header. The packet headers should contain two MAC addresses, the source MAC address which will be the MAC address of whatever host sent the packet, and the destination MAC address which will be FF-FF-FF-FF-FF-FF-FF-FF
Maybe I'm loosing it in my old age, but how does the NIC know that the WOL Magic Packet is meant for itself? As far as I know, a WOL UDP magi packet contains the MAC address of the target computer. The WOL UDP magic packet has to be 16 times larger than the byte representation of the MAC address + six bytes for the header. For a total 102 bytes. First six bytes are filled with 0xFF. The next six bytes is the MAC of the destination. The subsequent set set of six bytes are filled with the MAC address of the target device until the packet is full. The FF destination that you mentioned is for broadcast message. The WOL UDP Magic Packets that I'm talking about are meant for a "specific" machine MAC address. Not a broadcasted WOL message.
fordem wrote:
After examining the contents of the packets provided - they don't appear to be related to WoL - the first is an ARP request, and as far I can tell, the source address field appears to show what you claim is the MAC address of the media server, which I believe is what you're trying to wake - so I think we can safely conclude that that packet is not the one that's waking the media server, as it's being sent by the media server. The second packet, which you describe as a response from the media server shows the same source address, as the first, and it seems to be attempting to join a multicast group, or at least establish the fact that the multicast packets should be sent to it. The third packet appears to come from Microsoft (the source ip belongs to them) and does not contain the required string to wake the media server. Perhaps what you need to do is disconnect the media server (if it's off there should be no data traffic with it's MAC address in the address fields to cause any confusion. Disconnect it and leave the network idle for 30 minutes or so, by which time any network hosts that have it's MAC address in the arp cache should have flushed it, and then start sniffing.. Below are the contents of the data field of a Magic packet sent to 00-0D-60-83-8E-38 - see how easy it is to pickout the 16 repetitions? 00000000 : FF FF FF FF FF FF 00 0D 60 83 8E 38 00 0D 60 83 00000010 : 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00 0D 00000020 : 60 83 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00000030 : 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00 0D 60 83 00000040 : 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00 0D 00000050 : 60 83 8E 38 00 0D 60 83 8E 38 00 0D 60 83 8E 38 00000060 : 00 0D 60 83 8E 38 Notice also that I have no qualms about posting a MAC address on a public forum - there's nothing that anyone can do with the data to either hack my server (it's an IBM xSeries server), or to incriminate me in any way. You might also want to use something like the Depicus Wake-on-LAN monitor as this will only show "true" magic packets ie, any packet containing the required 16 consecutive MAC addresses, ignoring all other traffic. In fact - if Depicus Wake-on-LAN monitor doesn't show any traffic - it's a fairly safe conclusion that whatever is happening to wake the media server, it's not happening through a magic packet.
The "summary" of the messages packets I posted arrived at the instant that the server woke up. As I mentioned they were "suspect" as I did not look deep enough into their content to see if they were malformed. I'm not saying that they're the cause of the problem, but they are the messages that WireShark shows when the server first responds. Before those messages the MAC and IP addresses of the server do not appear in the LAN traffic. It could be that a prior message caused it to wake. I did the a short sniff without any other machines in the network except for the Router, server and the laptop I was using to sniff. The Router and Server had been rebooted prior to that. With the same setup, when I re-install the prior version of firmware on the router, the server does not wake up unless another device in the network sends it the WOL magic packet. Regarding MAC addresses in the forum... I rather play it safe. Not that my server might be hacked, but the MAC address of the NIC of the server might or might not have access to a secured network. Spoofing a MAC is not a hard thing to do and associating it to my user id here isn't hard either.
Message 11 of 32
fordem
Mentor

Re: Firmware 1.0.1.18 & WOL

First -there is NO way those can be the packets that arrived at the instant the server woke - theose packets contain the server MAC address as the source address - the server sent those packets.

Let me ask you this - how long does it take between when you hit the power button & cold boot that server and it completes POST? How long does it take between the completion of POST and the loading of the OS?

The only reason that a system will do an ARP request on it's own ip address is to determine if the address is already in use by another system - that means that by the time you see those packets, the system has completed POST and loaded the OS - whatever woke it is long gone.

Second - I'm really not in the mood to go into the details of why the NIC doesn't check the headers for its MAC address - suffice to say, that under normal circumstances (when the OS is running), the NIC just grabs whatever comes down the wire and passes it to the OS, it's the OS and the network stack that filters the packets - the NIC is not that smart.

I don't know if you've missed the fact that I keep saying with a correctly formed magic packet the destination MAC address has to be a hardware BROADCAST address - so - if the NIC was looking for its MAC address in the destination field, it would never find it. The OS does look for that MAC address, but, if the host is off, the OS isn't running.

If you want all the nitty gritty details as to how WoL is supposed to work, and why it has to be a broadcast packet - there's a massive WoL thread - use advanced search, put fordem as the user name and either WOL or magic as the keyword.

Give a man a fish, feed him for a day
Teach a man to fish, feed him for life.
Message 12 of 32
tamanaco
Apprentice

Re: Firmware 1.0.1.18 & WOL

fordem wrote:
If you want all the nitty gritty details as to how WoL is supposed to work, and why it has to be a broadcast packet - there's a massive WoL thread - use advanced search, put fordem as the user name and either WOL or magic as the keyword.


No need for me to look up any details, I know how it works. When a device in the network sends a WOL magic packet to another device in the same LAN segment the destination MAC needs to be part of the packet otherwise all the other systems set to WOL on magic packet in that segment would wake. That's what I was saying. Networking is no longer my day-to-day job, but I started with mainframes using bus and tag with 8.5" diskette controllers that needed be IMLed manually. On the early days of LANs I worked with Ungermann-Bass, IBM Broadband PC network and Token Ring connected to IBM 360 Controllers as LAN mostly existed within corporate entities. If you want to discuss IBM Geographically Dispersed Parallel Sysplex on OS/390 which was the last thing I worked on before I retired... I would be happy to oblige. WOL is not rocket science neither is Parallel Sysplex. No need to be condescending. In the technical field a skill set is tied to the current specifications of the technology in question. Anyone with a little technical savvy and the brain to find and assimilate the right information can figure out how WOL works.

All I want is to take advantage of the new features of the N900 provided by the new firmware without loosing the capability of turning on/off my media server remotely. I was posting the symptoms and what I saw happening without asserting that I knew exactly what was causing the problem. I was going to dig a little deeper and maybe help just a bit. Given the tone of the responses I now lost the interests to dig much deeper into this issue and report the little that I find. I have better things to do. I'm back to the previous firmware and have no WOL issues. I quoted you in my first post because, as you said, the probability of what was being reported was very remote. I was agreeing with your assessment.
Message 13 of 32
fordem
Mentor

Re: Firmware 1.0.1.18 & WOL

tamanaco wrote:
No need for me to look up any details, I know how it works. When a device in the network sends a WOL magic packet to another device in the same LAN segment the destination MAC needs to be part of the packet otherwise all the other systems set to WOL on magic packet in that segment would wake.


I suggest you go lookup those details - because you're still not correct. One of the things I've said in every response in this thread is that a correctly formed magic packet needs to be a broadcast packet - in other words - the destination MAC address will be FF-FF-FF-FF-FF-FF and NOT the target MAC address.

Because it's a broadcast packet, ALL the hosts on the network will receive it - if they are already on, the network stack will discard the packet, if they are off but configured for Wake-on-LAN only ONE will wake - the one that recognizes it's own MAC address as being the one contained in the sixteen repetitions.

Give a man a fish, feed him for a day
Teach a man to fish, feed him for life.
Message 14 of 32
Mars Mug
Virtuoso

Re: Firmware 1.0.1.18 & WOL

I’ve seen a few Motherboard BIOS with a variety of options for WoL, e.g. Magic Packet, Pattern Match, LAN Activity. Some BIOS will only have the option to enable / disable WoL with the details of how to respond being set in Windows at the driver advanced settings e.g. http://www.energystar.gov/index.cfm?c=power_mgt.pr_power_mgt_wol It’s clear to me that since the setting can be selected in the OS, that data must be stored in the BIOS, or more likely in the LAN device (card or on board) since Windows cannot operate until the PC is woken.

So in this case I am wondering if Fordem’s point in post #3 might be the root cause here, i.e. the systems may not be set specifically to detect the Magic Packet.

fordem wrote:
First - some systems can be "woken" by packets other than WOL magic packets, so that having the computers wake is no confirmation that WOL magic packets are being sent.


So, are we absolutely sure that the selection in the BIOS/Driver are for Magic Packet and not another WoL option?

Also, it’s not clear if all computers wake at the same time, or if they wake at random intervals.

Take a look at this; http://support.microsoft.com/kb/941145

This may also be relevant since it specifies several other wake up options that Win7 / Vista can respond to, most of which I believe could easily be triggered by general router activity (which could change from one router firmware version to another).
Message 15 of 32
dwil2001
Aspirant

Re: Firmware 1.0.1.18 & WOL

OK, I too upgraded to 1.0.1.18 a week or so ago and noticed also that every computer I had configured for Sleep, especially the laptops on my network, were waking up all the time. Prior to this they behaved as they should, only wake up when I open the lid, touch the keyboard, etc.
I ran a WireShark trace and the router with this firmware is now sending out MagicPackets every 5 minutes, and yes with the MAC address in them.
Here are the packets:
1056 142.285764000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for 00:ff:35:cc:12:34 (00:ff:35:cc:12:34)
1057 142.286057000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for Cisco-Li_58:56:78 (00:0f:66:58:56:78)
1058 142.286328000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for BrotherI_03:78:90 (00:80:77:03:78:90)
1059 142.286610000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for AsustekC_24:00:11 (c8:60:00:24:00:11)
1060 142.286859000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for Panasoni_b6:22:33 (00:80:f0:b6:22:33)
1061 142.287175000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for Azurewav_a0:44:55 (74:2f:68:a0:44:55)
1062 142.287444000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for SlingMed_0b:77:88 (00:13:b6:0b:77:88)
1063 142.287763000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for Panasoni_b3:99:aa (00:80:f0:b3:99:aa)
1064 142.287975000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for Giga-Byt_ee:bb:cc (50:e5:49:ee:bb:cc)
1065 142.288240000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for Wistron_04:dd:ff (00:26:2d:04:dd:ff)
1066 142.288408000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for D-Link_87:ab:cc (00:26:5a:87:ab:cc)
1067 142.288626000 192.168.1.1 192.168.1.255 WOL 144 MagicPacket for AsustekC_75:de:ee (c8:60:00:75:de:ee)

I reverted to V1.0.1.6_1.0.24 and there no longer MagicPackets being sent. I hope Netgear is aware of this and provides a fix. I'm not sure what there thinking is that they would want to wake up every computer on my network that is in Sleep mode. And yes I use Sleep mode and I do want the ability to wake them up as my Backup server will wake them up for a backup at 5 am everyday and then they go back to Sleep. Dale...
Message 16 of 32
fordem
Mentor

Re: Firmware 1.0.1.18 & WOL

Did you capture any other WOL packets or just the ones you posted? I'm curious as to how the router "knew" which MAC addresses to put in the magic packets.

Give a man a fish, feed him for a day
Teach a man to fish, feed him for life.
Message 17 of 32
Mars Mug
Virtuoso

Re: Firmware 1.0.1.18 & WOL

Well if the router is keeping a record of the MAC addresses I would expect it to be in volatile RAM, in which case power cycling the router with the PCs shut down should cause it to lose the MAC addresses, may be worth checking out?
Message 18 of 32
gab42
Aspirant

Re: Firmware 1.0.1.18 & WOL

I have had the same issue that appeared at my home all of sudden; I couldn’t pin-point when exactly it did start. One thing is sure; WOL was working like a champ when I did my initial setup with the WNDR4500.

After a week of troubleshooting the NIC drivers on both on my Windows 7 desktop and on my WHS 2011 server (they were both systematically waking up 5 minutes after hibernation) without success, I went back to basics.

I’ve started to isolate the problem component by component and I did pin-point the WNDR4500.
How? I simply replaced the router with an old generation one (also a NetGear) and everything did work fine again.

Then I came on this forum and I saw that some of you suspected the firmware 1.0.1.18 and also noticed that couple did downgrade his WNDR4500 to fix the issue.

Guess what? I have also downgraded my WNDR4500 and everything is working fine again since.
There is without any doubt a WOL bug in firmware 1.0.1.18. I can’t explain how to fix it nor what it is but it is fact since it is waking up within 5 minutes computer that have WOL enabled.

Thanks all for sharing your experience because it did help me fix mine.

FYI: Both my desktop and my server are set up to use DHCP but I have assigned them fixed IP address on the WNDR4500.

Gab.
Message 19 of 32
Puffnstuff
Guide

Re: Firmware 1.0.1.18 & WOL

I have wol disabled on my pc's however with the 1.0.1.18 fw the router was waking up my network pc's even though wol is disabled in bios. After rolling back the fw this behavior stopped. I've never had a pc with wol disabled wake up before until this latest fw so it's a new one on me.
Message 20 of 32
nkraus
Aspirant

Re: Firmware 1.0.1.18 & WOL

The new firmware wakes up my two NAS after 5 minutes. There is no way to change the kind of how wake up works. I had to roll back to the old firmware. Please fix the problem, because on my NAS I need the WOL.
Message 21 of 32
nkraus
Aspirant

Re: Firmware 1.0.1.18 & WOL

Is there any info if anybody is working on the problem an when there will be a solution?
Message 22 of 32
cpe111
Novice

Re: Firmware 1.0.1.18 & WOL

The adapter should wake to a frame sent specifically to that adapters mac address OR a broadcast address .....

Once the LAN controller has been put into the Magic Packet mode, it scans all incoming frames addressed to the node for a specific data sequence, which indicates to the controller that this is a Magic Packet frame. A Magic Packet frame must also meet the basic requirements for the LAN technology chosen, such as SOURCE ADDRESS, DESTINATION ADDRESS (which may be the receiving station's IEEE address or a MULTICAST address which includes the BROADCAST address) ..

from http://www.activexperts.com/activsocket/tutorials/wol/
Message 23 of 32
fdnyfish
Aspirant

Re: Firmware 1.0.1.18 & WOL

You need to downgrade your firmware to 1.0.1.6 if you want the WOL to stop waking your devices after 5 minutes.

see below

http://forum1.netgear.com/showthread.php?t=77883
Message 24 of 32
tamanaco
Apprentice

Re: Firmware 1.0.1.18 & WOL

I opened a ticket with Netgear support on this issue about a week ago, but I'm still waiting for a resolution. They said that they're working on it. Hopefully, they'll let me get my hands on "beta" firmware releases targeted to address this issue as they did when they were working to resolve a previous USB performance issue. Maybe if more users open tickets about this problem Netgear will give it higher priority.
Message 25 of 32
Top Contributors
Discussion stats
Announcements

Orbi WiFi 6E