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":
WakeONLAN in motherboard bios (done that)
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.
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.
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.
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.
"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.
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.
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.
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.