Unless Spring has command-line parameters that will allows me to set players and mods...LAN+Online solution...?
Moderator: Moderators
-
Stealth870
- Posts: 166
- Joined: 13 Sep 2004, 00:25
LAN+Online solution...?
2 comps on my LAN want to play with a friend online. I should be able to host a game from my LAN, the online guy will join fine, the LAN comp will connect via IP. Thats how it should be but it can't. Can someone please implement a simple method of joining a game manually? You should be able to join a hosted room via IP instead of just double clicking the room from the list. Or if thats not the actual problem, a way so that while IN the room, the guy on the LAN can type in the IP that the game will try to join when the host starts. Either that or a little check box named "LAN" so that when he checks it, the host sends the IP to the guy on the LAN and then the LAN guy will connect to the LAN host properly...something like that. Unless Spring has command-line parameters that will allows me to set players and mods...
Unless Spring has command-line parameters that will allows me to set players and mods...
oh and keep me posted on your progress.@Stealth870: That can be done with TASServer. You should run it with -lan argument (just use LanServer.bat) and let the guy from the internet host the battle, not one of you guys who are on LAN. It's all in the readme.txt though.
Try to post question regarding lobby server/client in TASClient bugs/help thread ...
Try to post question regarding lobby server/client in TASClient bugs/help thread ...
-
colorblind
- Spring Developer
- Posts: 374
- Joined: 14 Mar 2005, 12:32
But if you want one of the locals to host, there's a workaround too.
* Start the battle normally (with the client).
* The other locals won't be able connect: they have to quit spring ...
* and edit SCRIPT.TXT; change "hostip" to the local ip-address of the server.
* Finally start spring with "spring.exe script.txt".
It should connect properly.
* Start the battle normally (with the client).
* The other locals won't be able connect: they have to quit spring ...
* and edit SCRIPT.TXT; change "hostip" to the local ip-address of the server.
* Finally start spring with "spring.exe script.txt".
It should connect properly.
My solution
For those interested I have made a exe program combined with a batch file to change the IP address and launch TASpring with the adjusted script file.
Its my first attempt at programing and I used a basic compiler I had, but it works.
All you need to do is to go to start the game as normal, except you will not be able to join properly. Once you are at the "Waiting for other players to Join" prompt you Shift Esc to quit then run the batch file which you should have a shortcut to.
The batch file needs to be updated with your specific data before you can use it but this only needs to be done once. The data required is the drive & directory your spring program is installed on entered after the cd.
ie cd e:\programs\TASpring
then after the updateIP.exe enter the IP address of the Lan host
ie updateIP.exe 192.168.0.2
the next line starts spring using tmpscript.txt created by updateIP.exe
ie spring.exe tmpscript.txt Do not adjust this line
Spring will restart connecting you into the game.
I found this methode to be relatively quick and easy so others in the game will not be waiting as long to start.
Its my first attempt at programing and I used a basic compiler I had, but it works.
All you need to do is to go to start the game as normal, except you will not be able to join properly. Once you are at the "Waiting for other players to Join" prompt you Shift Esc to quit then run the batch file which you should have a shortcut to.
The batch file needs to be updated with your specific data before you can use it but this only needs to be done once. The data required is the drive & directory your spring program is installed on entered after the cd.
ie cd e:\programs\TASpring
then after the updateIP.exe enter the IP address of the Lan host
ie updateIP.exe 192.168.0.2
the next line starts spring using tmpscript.txt created by updateIP.exe
ie spring.exe tmpscript.txt Do not adjust this line
Spring will restart connecting you into the game.
I found this methode to be relatively quick and easy so others in the game will not be waiting as long to start.
It has been my experience that the reason you cant host a game on a LAN in this manner
LAN:
HOST, player1, 2, etc
------------------------------
Internet:
Player1,2,3 etc.
Even if you want to host a game with the lobby client for a game with players on the LAN only, this also applies....
You firewall/router is dropping the packets sent from your LAN clients to the host computer. This is usually because of IP spoofing protection built into firewalls. I was able to disable my spoofing protection and host a game with LAN players and Internet players successfully. I turn the spoofing protection off to play games this way, and turn it back on when I am done.
When your LAN PC tries to connect to the LAN host it uses the internet ip (ex 215.23.165.233) and not your host's LAN IP or private IP (ex 192.168.0.3). The LAN client gets the host IP from the lobby server. The lobby server only knows the LAN server's Internet IP address. It gives that to your LAN client and the client uses that Internet IP address to try to connect to the LAN host instead of the LAN IP, which would work. When your LAN client tries to connect to the Internet IP it MUST go through its gateway, which is your firewall/router. The router gets the data and sees that it is data sent from a LAN IP address to the Internet IP address and throws it away, because it could be an IP spoof attack coming from the Internet.
I was able to turn off IP spoofing on my router, because it is a linux-based router called Smoothwall.
This is just an FYI, I just thought I'd let you know, since I went through the same thing.
Here's a simple suggestion for the devs...Have a box in battleroom window where clients can specify alternate host address when they join a game. For example, I could put in 192.168.0.200 as the alternate host address in my client PC. Most people will not touch it, but it would be a wonderful help to people such as Stealth870 and myself. It would solve the lanplay issue. You could even make the box greyed out for the host and have it contain the LAN ip address of the host machine making it easier for newbies. All the changes that would have to be made would be in the lobby program I believe.
LAN:
HOST, player1, 2, etc
------------------------------
Internet:
Player1,2,3 etc.
Even if you want to host a game with the lobby client for a game with players on the LAN only, this also applies....
You firewall/router is dropping the packets sent from your LAN clients to the host computer. This is usually because of IP spoofing protection built into firewalls. I was able to disable my spoofing protection and host a game with LAN players and Internet players successfully. I turn the spoofing protection off to play games this way, and turn it back on when I am done.
When your LAN PC tries to connect to the LAN host it uses the internet ip (ex 215.23.165.233) and not your host's LAN IP or private IP (ex 192.168.0.3). The LAN client gets the host IP from the lobby server. The lobby server only knows the LAN server's Internet IP address. It gives that to your LAN client and the client uses that Internet IP address to try to connect to the LAN host instead of the LAN IP, which would work. When your LAN client tries to connect to the Internet IP it MUST go through its gateway, which is your firewall/router. The router gets the data and sees that it is data sent from a LAN IP address to the Internet IP address and throws it away, because it could be an IP spoof attack coming from the Internet.
I was able to turn off IP spoofing on my router, because it is a linux-based router called Smoothwall.
This is just an FYI, I just thought I'd let you know, since I went through the same thing.
Here's a simple suggestion for the devs...Have a box in battleroom window where clients can specify alternate host address when they join a game. For example, I could put in 192.168.0.200 as the alternate host address in my client PC. Most people will not touch it, but it would be a wonderful help to people such as Stealth870 and myself. It would solve the lanplay issue. You could even make the box greyed out for the host and have it contain the LAN ip address of the host machine making it easier for newbies. All the changes that would have to be made would be in the lobby program I believe.
I have no idea what problems you guys are having, since it works withouth problems on my LAN. So it would help if you would be more specific about your problems.
You did read readme.txt? It says LAN clients should not host if players from the internet are participating in a battle as they would receive only local IP addresses. Also, try changing UDP source port on LAN clients (each should have unique UDP source port), it might help.
I guess I can add "alternate address" to the lobby though, but I'd rather fix these problems ...
You did read readme.txt? It says LAN clients should not host if players from the internet are participating in a battle as they would receive only local IP addresses. Also, try changing UDP source port on LAN clients (each should have unique UDP source port), it might help.
I guess I can add "alternate address" to the lobby though, but I'd rather fix these problems ...
Betalord, if you don't have a problem hosting games where players from your LAN and players on the internet join, then your firewall is NOT blocking IP spoofs.
One type of IP spoof that attackers use is sending massaged (modified packets) packets of data to your Internet IP and thus your firewall. The attacker changes the sender's IP address in the packets so your firewall thinks that the packets came from your LAN and will treat them as such. This kind of spoofing is only one way communication, because changing the sender's IP address makes it impossible to get communication back from the victims machines. I don't know how someone would make an effective attack with this technique, but it is possible that if they know a weakness in some software you are running, they could circumvent your firewall and send just the right data to change what they need. Its a strech, but may be possible. That's my guess, there may be more severe issues I am not aware of.
That is why many firewalls have this spoofing protection.
The problem with this spoofing protection comes up when a LAN PC tries to host a game using the lobby client and have another PC on the LAN join and connect to the host when the game starts.
The other LAN PC will get the Internet address of your firewall when it joins the game hosted by your LAN PC in the TASclient program. When the game starts, the LAN pc sends the packets to the Internet address of the firewall, they go to the firewall. The firewall sees that the packets are from a LAN IP address sent to the Internet address, so the firewall drops the packets because they could be spoofs.
The best way around this enhanced security is to allow people to type in an alternate IP address for the LAN host. That way the packets are sent directly to the LAN host and are not dropped.
I hope this clarifies things. Sorry, but my writing skills have gone down the tube after a lot of mindless factory toil.
The ONLY convenient way I get around this is to turn off spoofing protection, but it was not easy for me. I use a linux router, Smoothwall, and I had to add some commands to a script file using vi and reboot the router each time I toggle the protection.
I have not tried editing a script real quick and typing in this or that to join the game, that sounds tedious. It would be better to just tell your LAN clients the LAN IP of the LAN host so they can just connect to that IP instead of the firewall's IP address. I am betting this is easier for newbies as well, so long as you display the LAN IP address on the host machine so they can easily see it. Some people may not know the easy way of finding their lan IP address, lol.
One type of IP spoof that attackers use is sending massaged (modified packets) packets of data to your Internet IP and thus your firewall. The attacker changes the sender's IP address in the packets so your firewall thinks that the packets came from your LAN and will treat them as such. This kind of spoofing is only one way communication, because changing the sender's IP address makes it impossible to get communication back from the victims machines. I don't know how someone would make an effective attack with this technique, but it is possible that if they know a weakness in some software you are running, they could circumvent your firewall and send just the right data to change what they need. Its a strech, but may be possible. That's my guess, there may be more severe issues I am not aware of.
That is why many firewalls have this spoofing protection.
The problem with this spoofing protection comes up when a LAN PC tries to host a game using the lobby client and have another PC on the LAN join and connect to the host when the game starts.
The other LAN PC will get the Internet address of your firewall when it joins the game hosted by your LAN PC in the TASclient program. When the game starts, the LAN pc sends the packets to the Internet address of the firewall, they go to the firewall. The firewall sees that the packets are from a LAN IP address sent to the Internet address, so the firewall drops the packets because they could be spoofs.
The best way around this enhanced security is to allow people to type in an alternate IP address for the LAN host. That way the packets are sent directly to the LAN host and are not dropped.
I hope this clarifies things. Sorry, but my writing skills have gone down the tube after a lot of mindless factory toil.
The ONLY convenient way I get around this is to turn off spoofing protection, but it was not easy for me. I use a linux router, Smoothwall, and I had to add some commands to a script file using vi and reboot the router each time I toggle the protection.
I have not tried editing a script real quick and typing in this or that to join the game, that sounds tedious. It would be better to just tell your LAN clients the LAN IP of the LAN host so they can just connect to that IP instead of the firewall's IP address. I am betting this is easier for newbies as well, so long as you display the LAN IP address on the host machine so they can easily see it. Some people may not know the easy way of finding their lan IP address, lol.
I know what IP spoofing is, but the problem seems to be that your server assigns you an internet IP instead of your local IP (e.g. 192.168.x.y). It always assigns local IP for me. Try this: let the host be from a LAN computer that is NOT running the server. This might help, as server tries to resolve 127.0.0.1 (localhost) to outside IP, which seems to be internet IP in your case (and 192.168... in my case). Tell me if it helps.
I don't understand what you mean by having one PC run the server and another one be the host. Do you mean have a different pc start the lobby room and the other serve the game when it starts?I know what IP spoofing is, but the problem seems to be that your server assigns you an internet IP instead of your local IP (e.g. 192.168.x.y). It always assigns local IP for me. Try this: let the host be from a LAN computer that is NOT running the server. This might help, as server tries to resolve 127.0.0.1 (localhost) to outside IP, which seems to be internet IP in your case (and 192.168... in my case). Tell me if it helps.
When I said server or host I meant the same thing. My writing skills suck, lol.
Since I cant explain things well, I will just play out two scenarios. My setup with spoofing on and spoofing off.
Scenario 1 - Spoofing protection OFF
My firewall has the IP address 12.241.193.87 which is gets from my ISP.
My firewall has port 8452 forwarded to IP address 192.168.0.101
LAN PC 1 gets IP address 192.168.0.101 from the firewall.
LAN PC 2 gets IP address 192.168.0.102 from the firewall.
LAN PC 1 loads TASClient and opens a battleroom.
The TAS server that LAN PC 1 connects to sees that LAN PC 1 has the IP address 12.241.193.87 because of the firewall's Network Address Translation.
LAN PC 2 joins the battleroom.
The game is launched.
LAN PC 2 is told by TASClient that the game server, LAN PC 1, has the IP address 12.241.193.87.
LAN PC 2 attempts to connect the 12.241.193.87. Since the address is not on LAN PC 2's network determined by its netmask (255.255.255.0) it sends the packets to its gateway, the firewall.
The firewall reads the packets as from 192.168.0.102 determines they go to the firewall's Internet IP address. The router also reads the recievers port number as 8452 and knows to forward the packets to 192.168.0.101.
LAN PC 1 recieves the packets and is able to make the connection.
The game starts and everything is great.
Scenario 2 - Spoofing protection ON
My firewall has the IP address 12.241.193.87 which is gets from my ISP.
My firewall has port 8452 forwarded to IP address 192.168.0.101
LAN PC 1 gets IP address 192.168.0.101 from the firewall.
LAN PC 2 gets IP address 192.168.0.102 from the firewall.
LAN PC 1 loads TASClient and opens a battleroom.
The TAS server that LAN PC 1 connects to sees that LAN PC 1 has the IP address 12.241.193.87 because of the firewall's Network Address Translation.
LAN PC 2 joins the battleroom.
The game is launched.
LAN PC 2 is told by TASClient that the game server, LAN PC 1, has the IP address 12.241.193.87.
LAN PC 2 attempts to connect the 12.241.193.87. Since the address is not on LAN PC 2's network determined by its netmask (255.255.255.0) it sends the packets to its gateway, the firewall.
The firewall reads the packets as from 192.168.0.102 determines they go to the firewall's Internet IP address. The router also reads the recievers port number as 8452 and knows to forward the packets to 192.168.0.101. The firewall decides that since the packets are originating from the LAN network, 192.168.0.0, and are sent to the firewall's Internet IP address, that the packets may be part of an IP spoof attack and does not forward them.
LAN PC 1 does NOT recieve the packets and is UNable to make the connection.
The game times out and the players are returned to the battleroom.
Now, Betalord, you are the admin of the TAS servers, right? If the server you connect to is running on your network, you WILL NOT have a problem with spoofing protection enabled. The scenario will play out differently, because the server will get your computer's (192.168.0.0) IP address and that is the IP address it will give to the other LAN players. They WILL NOT send the packets to the firewall to be rejected. The packets go right to your LAN game server.
If you add the box to the TASClient to enter an alernate server IP address in. LAN PC 2 would never send the packets to the firewall to be rejected, it would instead send them directly to LAN PC 2, fixing my problem.
I hope this clarifies what I am saying.
I thought you run TASServer yourself on one of the local computers? If true, then try running it on a computer that is NOT hosting a battle. That is, if you have 2 computers on LAN, let A run the server, and both A and B run client and connect to TASServer on A. Then let B host a battle. This way server will not try to resolve loobback address (localhost / 127.0.0.1) to external address, which is what it is trying to do so that both internet and LAN players could participate in battles.I don't understand what you mean by having one PC run the server and another one be the host. Do you mean have a different pc start the lobby room and the other serve the game when it starts?
No, what I am doing is connecting to the TAS server on the internet so that my friend and I can play on a team with other people on the Internet. If I hosted my own TAS server it would allow us to easlily play games, but we would be the only ones on our TAS server. So, we NEED to connect to the TAS server on the Internet.
That is another story ... There is no elegant solution for it (at least I don't see one), I guess I can add an option to the client to detect if host's address is actually client's outbound address and so replacing it with host's local address (which should be set by the client).No, what I am doing is connecting to the TAS server on the internet so that my friend and I can play on a team with other people on the Internet
Does spring itself support it?Betalord wrote:That is another story ... There is no elegant solution for it (at least I don't see one), I guess I can add an option to the client to detect if host's address is actually client's outbound address and so replacing it with host's local address (which should be set by the client).No, what I am doing is connecting to the TAS server on the internet so that my friend and I can play on a team with other people on the Internet
Yes, I have played with my friend on LAN and people on the Internet in the same game, but I had to turn my spoofing protection off to do it. Some people may not be able to.
That would be great! It would help people like me out a lot.I guess I can add an option to the client to detect if host's address is actually client's outbound address and so replacing it with host's local address (which should be set by the client).
Hi
for those looking for the bat and exe file I mentioned you can find them here
http://www.fileuniverse.com/?p=showitem&ID=1553
Have fun
for those looking for the bat and exe file I mentioned you can find them here
http://www.fileuniverse.com/?p=showitem&ID=1553
Have fun