says...
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
extra
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
Perhaps ask papyrus for a patch so that the server responds to the first
client query over the same port that it listens on (32766). The server
should specify the port to be used by the client in the datagram of this
response. The client can then initiate the communication for the game
instead of the server, which would work correctly with ip masquerading.
Bart Westra
Quoted text (75 lines)
>From my investigations, it appears that the problem is related to the >extra >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...) >...AndrewI've already suggested this to papy. One of their programmers has
indicated that they think they've found out what the problem is and
they're working on workarounds for it. Claimed delivery date is
"sometime this week".
--
=========================================================
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.
=========================================================
excuse my question %-) .... are you guys running GPL on Linux ??
or just using the Linux-system as a server for your windows-client?
--
Surf Usenet at home, on the road, and by email -- always at Talkway.
http://www.talkway.com
Quoted text (10 lines)
> >Perhaps ask papyrus for a patch so that the server responds to the first > >client query over the same port that it listens on (32766). The server > >should specify the port to be used by the client in the datagram of this > >response. The client can then initiate the communication for the game > >instead of the server, which would work correctly with ip masquerading. > I've already suggested this to papy. One of their programmers has > indicated that they think they've found out what the problem is and > they're working on workarounds for it. Claimed delivery date is > "sometime this week".> excuse my question %-) .... are you guys running GPL on Linux ??
> or just using the Linux-system as a server for your windows-client?
> --
No... I am running linux as a gateway to allow multiple PCs on a private
network to be able to access the internet via a single [external] IP
address.
I'm running GPL on one of the PCs, not on the linux system itself. Its
just
that the traffic for GPL has to be properly handled by the linux system.
...Andrew
