1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Shibby & WOL, not remembering MACs ?

Discussion in 'Tomato Firmware' started by Kobalt, Dec 14, 2013.

  1. Kobalt

    Kobalt Reformed Router Member

    Using tomato-K26USB-1.28.RT-N5x-MIPSR2-115-AIO-64K on RT-N66U, and going to the WOL section, the top shoudl show a list of MACs available, but, it only shows machines that are on.
    Clicking refresh does bring up the other machines, but, once those go offline, then their MACs also vanish from the list.

    I know I can use the edit box to enter the MAC and do WOL that way, but that is a pain to do all the time..

    Why don't it remember the MACs last on the system when those machines get turned off ?
     
  2. darkknight93

    darkknight93 Networkin' Nut Member

    Not sure but the devices vanish as soon as the dhcp leasetime eexpires.
    Try setting these dhcp leases to static via basic -> static dhcp
     
  3. Kobalt

    Kobalt Reformed Router Member

    That don't seem to help.

    http://192.168.1.1/tools-wol.asp only shows machines that are on, which makes it worthless...
    In DD-WRT, they had a 'remember' checkbox, and it seems that is what tomato needs as well.
     
  4. koitsu

    koitsu Network Guru Member

    I would argue strongly against this feature. When ARP expires, the entries should go away. This is how all networking devices work and how Ethernet is supposed to work. There's really no point to a "Remember" checkbox; devices showing up when they aren't even powered on? Silly if you ask me. But that's my two cents, and my opinion is just as valid (or invalid) as anyone elses.
     
  5. PetervdM

    PetervdM Network Guru Member

    "remember" would be a valuable addition, as long as the value is stored in nvram only, NOT in the arp table
     
  6. Kobalt

    Kobalt Reformed Router Member

    You misunderstand, the device(s) in question are powered down, HOWEVER, they can still acknowledge the WOL command, once it is sent to them.
    That means, while they may be powered off, BIOS still monitors the NIC for the WOL message.

    Right now, the process is, check device list to find it. Copy down the MAC, go to the WOL screen, and paste it there.

    There is no reason *not* to offer a 'remember' setting for convenience, or barring that, just have an additional WOL option in the device list screen that would do basically the same thing.
     
  7. koitsu

    koitsu Network Guru Member

    Let me explain how Wake-on-LAN works. Please keep in mind I am talking about the Device List. If there is a separate section for WOL-specific things that doesn't rely on ARP, then please see the very last paragraph.

    This sort of subject has come up before, where folks have advocated that devices "which were previously alive/online but are no longer still show up in the Device List", and WOL is usually cited as justification. I'll explain how WOL actually works:

    1. The devices in question you think are powered down aren't really -- there is still a very low amount of voltage going to the devices from the PSU via AC cord (I believe roughly 3.3V or 5V). The Ethernet NICs and PHYs are still operational, but are operating in an extremely "low-power" mode. The only way to truly power off a device at this point in the world of technology is to literally unplug it from the wall or remove its battery; else there is always some degree of low voltage flowing.

    The chips do not have a fully functional Ethernet layer (layer 2) in this mode. They instead are operating, as stated, in an extremely minimal state where they do monitor Ethernet (ARP) frames for very specific things, which leads me to...

    2. Wake-on-LAN works by sending a "magic packet" -- in most cases, an Ethernet ARP packet -- destined to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff) with very specific payload contents. The contents vary per vendor and NIC; for example Intel chips might expect a specific series of bytes in their payload, while others (Realtek, Marvell, etc.) expect a completely different series of bytes. What conditions need to be met for WOL to work varies per NIC vendor; some require that you actually send the ARP packet to the specific MAC address of the NIC, while others (as stated) use the broadcast address.

    The device still does not have a fully working Ethernet layer (layer 2) at this point. That means it will not respond to normal ARP requests. The device/NIC is not "on the network" at this point; there is no functional OS to actually handle Ethernet frames.

    3. Once the proper WOL frame is received, the chip will internally switch on some features, and initiate/simulate the power button being pressed (usually via a physical wire/trace between the NIC and the mainboard; for example physical NIC cards (as in ones that go in PCI slots, rather than on-board ones) often require a physical cable from a WOL header on the card to connect to the motherboard for this to work). The system powers on, the OS begins loading, which ideally includes the NIC drivers as well as fully functional Ethernet and TCP/IP layers.

    At this point the device should have a working layer 2 (Ethernet), layer 3 (IP et al), and layer 4 (TCP/UDP/ICMP) layer, since the operating system is (presumably) up. This means the OS will respond to ARP packets.

    This is why WOL devices which are "powered off" should not show up in the Device List. They aren't really online at all -- they are in an extremely minimal power-on state, and there is no OS to handle proper ARP. (Without ARP/Ethernet, the higher layers (3 through 7) will not function). Such a feature would confuse users; they would go to their Device List, see a device showing up there, and think "oh! It must be online because there's the MAC address and the IP!" and try to talk to it with 100% failure; even arp -a would not show a MAC address for it. Any existing (online) device which had previously known of said (now-powered-down) device would periodically be sending out ARP broadcast requests saying "Who has IP a.b.c.d?" and getting no response (from the device that's powered down/waiting for WOL).

    Now, if there is in fact a separate list of devices/etc. in a WOL section (I do not use Shibby firmware so this isn't a feature I'm familiar with): I suppose that could be kept, yes. However, I strongly advocate that list be kept in RAM (i.e. temporary), and not NVRAM. People who use VLANs and multiple bridges and put their routers on extremely busy networks (you should read the forum posts that show up here -- there was a guy who was using an Asus RT-N16 as a primary router for a small company of a hundred people or so!) would easily chew up tons of NVRAM. These routers have more RAM than they do NVRAM, and even the smallest key/value mapping (MAC address-to-IPv4 address mapping) would take up roughly 10 bytes per entry (more like 16 bytes to keep things aligned). A hundred devices = 1KByte of NVRAM wasted.

    Anyway that's all I have to say on the matter. If someone does implement this, they had better really think about the implications and engineering before doing so.
     

Share This Page