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

Reply to
Skybuck Flying
Loading thread data ...

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)

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

Reply to
Skybuck Flying

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.

Reply to
Skybuck Flying

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

Reply to
glen herrmannsfeldt

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 snipped-for-privacy@rhyolite.com

Reply to
Vernon Schryver

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

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.

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

Reply to
glen herrmannsfeldt

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

formatting link

"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

formatting link

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 snipped-for-privacy@rhyolite.com

Reply to
Vernon Schryver

(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

Reply to
glen herrmannsfeldt

Ok, this morning I did the tests:

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

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

Reply to
Skybuck Flying

In comp.dcom.lans.ethernet Skybuck Flying wrote in part:

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

Reply to
Robert Redelmeier

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.

Reply to
Skybuck Flying

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.