rec.autos.simulators

I have a problem connecting to the internet for multiplayer game...
At my home we use a linux server to connect us to the internet e.g.
I'm on a LAN.

Now the problem is that when I connect I see my local iP nummer and
not the numer provided by the ISP and which the linux server has..

Other computers can not find me and I can not find others...

Ne1 got a solution...?

I'm in exactly the same boat you are, and if you promise never to use the
term "Ne1" again, I'll let you know when I find a solution. :-)

If you're not already using the 2.0.35 kernel, I suggest you upgrade to
it.  At least at that point, we'll have a common code base with which to
refer.

Further, you shouldbe (and probably are) using IP masquerading.  The
problem is the way GPL communicates.  I have a whole mess of stuff I've
collected over the last couple of weeks, and I've discussed the problem
with Randy Cassidy and another Papy programmer.  I've tried a few things,
but to no avail.

--
=========================================================
John Simmons - Redneck Techno-Biker (Zerex12)
http://www.members.home.net/jms1/index.html

John Simmons - Barbarian Diecast Collector
http://members.home.net/jsimm/diecast_index.html

If you want to send me email, go to either of the URL's
shown above & click "Send Me Mail" in the contents frame.
=========================================================

(this is all UDP, of course)

1) GPL client sends a packet to a GPL Server's IP (& port = 32766).

2) The IP masquerading on the linux box takes the packet
    and replaces the source IP address with its own IP address, and replaces
    the source port with one of its own choosing (usually 60000+).  The
original
    source IP address and port are stored in the linux box's IP masquerading
    table.

3) The linux box sends the modified packet to the GPL server

4) The GPL server receives the packet on its 32766 port.  The source IP for
    the packet is the address of the linux box and the source port is the new
port
    picked by the linux box in (2).

5) The GPL server creates a new socket endpoint and binds this new endpoint
    to a new port.

6) The GPL server sends a return packet from this new endpoint back to the
    GPL client.  In this case, it thinks that the client is at
    <linux_box_ip>:<linux_box_masqueraded_port>.

7) The linux box receives this packet from the GPL server.  Normally, the
    IP masquerading code would see that the destination IP and port match
    an entry in its masquerading table, and subsequently re-header the packet

    with the internal GPL client's IP and port.  But NO, it DOES NOT DO THIS
    in this case because it expects the source port of this return packet to
be the
    SAME as the port it sent to in the first place.

I wrote some simple client/server programs to test this theory and in fact
this is
the observed behaviour.  As long as I send packets back to the linux box from
the
same port, the reverse masquerading works ok.  Whenever the packet is sent
back
from a different port, the packet does not get forwarded.

If there was a way to relax this rule and allow
the reverse part of the masquerading to proceed even if the source port of
the
return packet changes, then we would be in business.  We would be able to
connect no problem.

Anyone out there know if this is possible?  I don't see any way to do this
with
any of the linux IP masq tools currently out there, and ipfwadm does not
provide
any way to do this either.  ipautofw does not seem to work in this instance.
I think
it may be to do with the fact that I am trying to auto-fw ports in the
masquerading
60000+ range.  In any case, that is not a good solution since you don't know
in
advance which ports to forward.

For the record, I am using the 2.0.33 kernel. (I know, it isn't 2.0.35
yet...)

...Andrew