WakeONLAN did not work for direct cable connection ? (Nics were shutdown after a night of sleep ?)

Discussion in 'Asus' started by Skybuck Flying, Feb 9, 2008.

  1. Hello,

    I have two computers directly connected via a UTP cable (for ethernet).

    Both computers have wake on lan enabled.

    Both computers use windows xp.

    Both windows xp are told to not turn off the power for the nic/network
    device.

    Last night I shutdown the computers, I checked the nic leds on the back and
    they were still burning.

    Yesterday I also did some tests and then it was working.

    This morning I check the computers and the leds of the nics are not burning
    anymore ?!?!

    It seems after a while they were shutdown ?

    Can this be prevented ?

    Maybe with some network/nic options ?

    I have asus a8n32-sli with nvidia and marvel ethernet controllers and
    3COMC2000 nic for older pc.

    There is one setting which looks interesting which I haven't tried yet:

    It says:

    "Wake From Shutdown" Value: Off

    Maybe I should put this to On ?

    Sounds logical... but I need confirmation.

    What exactly is "Wake from shutdown" ?

    Bye,
    Skybuck.
     
    Skybuck Flying, Feb 9, 2008
    #1
    1. Advertisements

  2. Ok,

    I love answering my own questions, I SHARE THE FOLLOWING LINK WITH
    YOOOOOUUUUUU:

    http://209.167.114.38/support/techsupport/tsbs/all/-TSB001290.htm

    It says for the marvel adapter (which happens to be my lan adapter) "it's
    necessary to enable both settings":

    1. WakeONLAN in motherboard bios (done that)

    2. Wake from shutdown in adapter/driver/nic settings (did not do that) ;)

    So I shall put it to on.

    Don't know yet about 3COMC2000 nic in other pc... maybe it has similiar
    options.

    Today before I go to sleep I will check it out , put everything on ON, then
    go to sleep.

    And then I will try again the next morning ! ;)

    Also I still need to find out a trick to wake up my internet computer from
    the internet.

    It's nic was on... but ofcourse the subnet directed broadcast didn't go past
    the router.

    But that's stuff/matter/subject for another discussion/thread :) actually
    one already going on on tcp/ip newsgroup.

    Bye,
    Skybuck.
     
    Skybuck Flying, Feb 9, 2008
    #2
    1. Advertisements

  3. Hmm, I forgot to do the wake up test this morning.

    Anyway, the local area connection is now active even while the other
    computer is off.

    Civilization 3 Conquest can now no longer host games properly because the pc
    is now multi-homed and civ3 does not select the correct interface/local
    address. So icmp port unreachable is sent back to clients trying to join the
    game.

    Bye,
    Skybuck.
     
    Skybuck Flying, Feb 10, 2008
    #3
  4. That would seem either a defect in civ3 or the IP implementation.
    (Possibly a NAT implementation error.)

    A TCP connection is defined by the quad (source address, source port,
    destination address, destination port). Routing should get it out
    the right path even with the other address.

    It is usual for UDP to accept packets sent to any interface.
    If a program binds to a specific interface when it isn't required,
    I would consider it a defect.

    -- glen
     
    glen herrmannsfeldt, Feb 11, 2008
    #4
  5. On the contrary, in servers for UDP based applications, failing
    to bind to specific network interfaces is generally a serious bug,
    or least evidence that the application is a toy.

    When the server answers a request, it must send with the same source
    IP address and port number as the client used for its destination IP
    address and port number. Otherwise the response is quite likely to be
    discarded by firewalls near near either end of the path. In many
    UNIX-like TCP/IP implementations, the only way for an application to
    know the destination IP address of a received UDP datagram is to receive
    it on an socket bound to a specific IP address and so network interface.

    Even in socket implementations with extensions that tell the application
    the destination addresses of received UDP datagrams, the application
    generally wants to have bound the socket from which it sends the response
    to control the source address of the response. Binding a socket for
    every response wastes CPU cycles, which argues for having outgoing
    sockets bound to specific interfaces. Those bound sockets for sending
    responses may as well be used for receiving requests.


    Vernon Schryver
     
    Vernon Schryver, Feb 11, 2008
    #5
  6.  
    glen herrmannsfeldt, Feb 12, 2008
    #6
  7. "Be Liberal in What You Accept, Conservative in What You Send"
    would seem to apply here.[/QUOTE]

    That does not and should not apply to firewalls.
    That's what I said, and generally the best and often only way to
    do that is to bind individual sockets to interfaces. That is why
    it Glen Herrmannsfeldt original claim quoted above about it being
    a bug for a program to bind to a specific interface is wrong.

    Safe firewalls should not be (only) on the system running the
    application; so called "personal firewalls" run on Windows boxes
    are junk, as demonstrated by the malware that turns them off.
    A firwall running on a separate system in the path cannot recognize
    a UDP packet from a strange source because it doesn't know what
    applications are being run. It is thus generally not possible for
    a system consisting of an application computer protected by a
    separate firewall to accept packets from an unexpected source.

    For that matter, even firewalls on the system running the application
    generally cannot recognize packets from strange sources.

    Of course, authorization checks based on source IP address are
    extremely weak, but every little bit helps, particularly when trying
    to protect Windows boxes.

    You can tell people running your UDP based application to treat
    your UDP port like port 53, but that often does not work. People
    resist opening ports in their firewalls. See for examples
    http://www.google.com/search?q=treat+port+6277+like+port+53

    "Bind to an interface" is almost universally understood as shorthand
    for "bind to an IP address configured on a network interface."

    What's that about "UDP NAT logic" and where would one look at it?
    There is no global specification of firewalls or NAT. There are
    descriptions of current and previous notions of NAT, but its a moving
    target. There obviously should be no global specification of
    firewalls...well, except for something like "protect and serve."
    Stateful firewalls are not exactly new products. See
    http://www.google.com/search?q=udp+stateful+firewall

    NAT is not a part of a firewall, although it is often also provided on
    boxes that are firewalls. It makes as little sense to talk about NAT
    as a firewall as to talk about converting between DLS signalling and
    802.3 as a firewall on the grounds that so called "DSL modems" also
    include firewall functions

    "Port numbers" are not the resource for which there might be too few
    in either NAT or a stateful firewall, but table entries. Only some
    forms of NAT involve translating port numbers, and for those that don't
    there can be no shortage.


    Vernon Schryver
     
    Vernon Schryver, Feb 12, 2008
    #7
  8. Vernon Schryver wrote:

    (snip)
    Maybe, but not completely. If you can't use a protocol through
    the firewall, someone will disable the firewall.
    (snip)
    Consider the very common case of a combination NAT router/firewall.
    For a TCP connection from inside, the NAT router will add an entry
    to the NAT table when the connection is opened, and route to the
    appropriate host based on the quad for the returning data.

    For UDP, one could add a NAT entry for the source address and port
    for the outgoing datagram, and the corresponding destination address
    and port for the incoming datagram. I suppose there is some risk
    that malicious datagrams could get through while those entries are
    active. Unless one is monitoring outgoing traffic, one would not
    know the specific port, and would not know the service that
    translated port was assigned to.
    Yes, but it should work for the majority of uses or people
    won't use it.
    For 99% of the people, which is home users, they are related.
    A NAT router won't route incoming data that doesn't have an entry
    in the NAT table because it doesn't know where to send it.
    That is enough of a firewall for most users.
    For those that do, there can be a shortage. If you don't time out UDP
    entries, you will eventually run out of translation ports. As far as
    UDP itself, though, there is no reason a reply can't come hours or
    days after the request. I have worked on systems where a request
    started a complex search system which sent a reply back when the search
    was finished.

    -- glen
     
    glen herrmannsfeldt, Feb 13, 2008
    #8
  9. Ok, this morning I did the tests:

    1. Try wake up over the internet. This didn't work, probably because arp
    entry timed out (?)

    2. Try wake up over the lan. Surprisingly this didn't work as well ?

    I have a little theory about that:

    First both computers need to be online so that the ethernet adapters can
    establish the link exchange format etc.

    Then it's ok to turn off both computers but their configuration must not be
    changed. (Maybe because I changed enable/disable caused it to fail)

    Anyway for the marval adapter I have changed wakeup to magic packet only.

    Maybe I should not have done because last time magic packet and pattern
    worked ok.

    But gonna try it anyway.

    So tomorrow I do another wake on lan test ;)

    This time I leave all settings as they were.

    Bye,
    Skybuck.
     
    Skybuck Flying, Feb 13, 2008
    #9
  10. Damn, testing this technology the next morning turns out to be pretty hard.

    This fucking morning it didn't work, because I forgot to enable the LAN
    interface.

    If I enable the lan interface then I can't play civilization and if I forget
    it there than that sux too.

    I was about to dismiss this technology as bullshit/crap.

    But I shall try again, some day.

    Not today, not tomorrow.

    Because I don't wanna do a reboot, just to enable the wake on lan again.

    Because I disabled it again.

    Stinky.

    Oh well.

    I am gonna let it be.

    I wasted enough time on this technology.

    It's not for me.

    Bye,
    Skybuck.
     
    Skybuck Flying, Feb 15, 2008
    #10
  11. This sounds very odd. MS-Civilization is a very popular
    game and I doubt they want to deal with many tech support
    calls or disgruntled customers.

    But most games use funny ports and you have to make sure
    any firewall is properly configured.

    -- Robert
     
    Robert Redelmeier, Feb 15, 2008
    #11
  12. Very few people can host civilization 3 conquest games.

    People probably don't bother to call in for multiplayer problems, and maybe
    most use cracks anyway or something ;)

    Bye,
    Skybuck.
     
    Skybuck Flying, Feb 16, 2008
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.