Linux and gpl.

Hi 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. =========================================================

Quoted text (23 lines)

> >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 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