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

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.

Ok,

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

http://209.167.114.38/support/techsu...-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.

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 wrote:

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.

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

In article ,
glen herrmannsfeldt wrote:

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.

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 wrote:

In article ,
glen herrmannsfeldt wrote:

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.

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.

"Be Liberal in What You Accept, Conservative in What You Send"
would seem to apply here. The server should return using the
original destination address and port. The client should, if
possible, accept it even with the wrong source address and port.

I did once run UDP through a NAT router with the translated
address on the outside. Like most NAT routers, it did not
translate the source address. When the UDP packet arrived at
the destination with the original source address, the reply
was sent directly to the client, but with a different source
address. I believe this was SunRPC based, and it did work.
I tried TCP through the same system and it failed for the
obvious reasons.

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.

As I learned accidentally once, binding to a specific address does
not bind to an interface. If the datagram comes in on a different
interface, it will still be accepted. Otherwise it would have to
go out, find another router, and then come back in the other 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.

I haven't looked at UDP NAT logic lately. It wouldn't seem hard
for it to do it based only on the source address of the outgoing
data, and so the destination address of the incoming data. The main
problem I remember with UDP is that there is no way to know when to
remove a NAT entry. If they don't time out fast enough, there may
not be enough port numbers for the needed translations. If they
time out too fast, and the reply comes back slowly, the connection
might fail.

-- glen

In article ,
glen herrmannsfeldt wrote:

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.

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.

"Be Liberal in What You Accept, Conservative in What You Send"
would seem to apply here.

That does not and should not apply to firewalls.

The server should return using the
original destination address and port.

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.


The client should, if
possible, accept it even with the wrong source address and port.

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...7+like+port+53


As I learned accidentally once, binding to a specific address does
not bind to an interface. If the datagram comes in on a different
interface, it will still be accepted. Otherwise it would have to
go out, find another router, and then come back in the other interface.

"Bind to an interface" is almost universally understood as shorthand
for "bind to an IP address configured on a 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.

I haven't looked at UDP NAT logic lately.

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."

It wouldn't seem hard
for it to do it based only on the source address of the outgoing
data, and so the destination address of the incoming data.

Stateful firewalls are not exactly new products. See
http://www.google.com/search?q=udp+stateful+firewall


The main
problem I remember with UDP is that there is no way to know when to
remove a NAT entry. If they don't time out fast enough, there may
not be enough port numbers for the needed translations. If they
time out too fast, and the reply comes back slowly, the connection
might fail.

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 wrote:

(snip)

"Be Liberal in What You Accept, Conservative in What You Send"
would seem to apply here.

That does not and should not apply to firewalls.

Maybe, but not completely. If you can't use a protocol through
the firewall, someone will disable the firewall.
(snip)

The client should, if
possible, accept it even with the wrong source address and port.

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.

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.

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...7+like+port+53
(snip)

I haven't looked at UDP NAT logic lately.

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.

Yes, but it should work for the majority of uses or people
won't use it.

There obviously should be no global specification of
firewalls...well, except for something like "protect and serve."
(snip)

The main
problem I remember with UDP is that there is no way to know when to
remove a NAT entry. If they don't time out fast enough, there may
not be enough port numbers for the needed translations. If they
time out too fast, and the reply comes back slowly, the connection
might fail.

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

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.

"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.

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

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.

Damn, testing this technology the next morning turns out to be pretty hard.

This ****ing 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 bull****/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.