WakeONLAN did not work for direct cable connection ? (Nics..

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.
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

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
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

In article <HMKdneW7UezOui3anZ2dnUVZ_oesnZ2d.DeleteThis@comcast.com>,
glen herrmannsfeldt <gah.DeleteThis@ugcs.caltech.edu> 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 vjs.DeleteThis@rhyolite.com
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

Vernon Schryver wrote:

> In article <HMKdneW7UezOui3anZ2dnUVZ_oesnZ2d DeleteThis @comcast.com>,
> glen herrmannsfeldt <gah DeleteThis @ugcs.caltech.edu> 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
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

In article <GuudnRE21oid4izanZ2dnUVZ_sOrnZ2d RemoveThis @comcast.com>,
glen herrmannsfeldt <gah RemoveThis @ugcs.caltech.edu> 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+port+6277+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 vjs RemoveThis @rhyolite.com
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

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+port+6277+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
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

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.
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

In comp.dcom.lans.ethernet Skybuck Flying <spam.DeleteThis@hotmail.com> wrote in part:
> If I enable the lan interface then I can't play civilization
> and if I forget it there than that sux too.

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
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics.. 

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.
 >> Stay informed about: WakeONLAN did not work for direct cable connection ? (Nics..