says...
> >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.
>From my investigations, it appears that the problem is related to the
pickiness of IP masquerading. When you try to connect to a GPL server
from
a GPL client that a linux box is masquerading for, the following
occurs:
(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