--- At Tue, 25 Apr 2006 15:34:52 -1000, Les Vogel wrote:
>>> And the answer is....
>>> DON'T tell the other client. Let the other client get the info for
>>> themselves from their own network stack.
>>> Sending your own IP address over the network as part of your payload
>>> is ALWAYS WRONG.
>On Apr 23, 2006, at 11:43 PM, Quinn wrote:
>>  Well, there are always circumstances where things like this
>> fail. If there's a NAT between you and the remote host, for
>> example. Or if the firewall is blocking incoming connections to
>> your server port. Still, it's a good place to start.
>I agree with Peter, it's best not to include an IP address or ports
>in your payload. Some protocol's require it, and some NAT
>implementations fix them up. FTP and RTSP come to mind.
>While this isn't necessarily reliable, you can look at your IP
>address to see if it's in a "local" range to help you determine if
>you are on a NAT system. (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
>and a few others http://www.rfc-editor.org/rfc/rfc1918.txt ) Some
>well meaning sysAdmin's just make this stuff up, so this technique
>won't always work. If it's in one of these ranges, you are probably
>NAT'd, if the other's IP address is in the same range, you can just
>report your "private" address, if it's not, you can do a trace route
>(RFC1393) and look for a router that's got a public IP address. That
>might be you (alas no guarantee). There are some services that will
>report to you your "real" IP address, you might try to google for it,
>I can't recall what it's called. (It's been a while since I thought
>about these kinds of issues). An important point, is that when you
>are behind a NAT'ed environment, your port may change as well, it's
>hard to tell. Also, a SysAdmin (person who setup the Router) may
>have setup a port map. I would suggest that you allow your users
>someway to specify (if you can't figure it out) what "real" IP
>address they have. (allow a port # as well)
Thanks for all the good information.
In this case, the protocol that I am implementing uses STUN <http://
www.faqs.org/rfcs/rfc3489.html> (with some small variations) when one
end is behind a NAT. This generally takes care of any problems like this.
However, in some cases, the machine will not be NATed and will be
required to report it's address appropriately.
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden