Lat Trick Bot

[Lambchops]

That will be a plan for future, as a 1-st step it's easier to send packets all the time.

And it causes disconnect, no idea why, but that's unacceptable behavior even if i sent them in wrong time and to wrong ips

This is actually a good sign. Causing the disconnect means that the packets are ending up where they should be... --> they are going to the WC2 client.

Of course at this point what you are making is a disc-bot, because you are sending the client rubbish packets - in this case "For the Alliance" which is clearly causing a problem for the client.

I discussed this in September 2016 when I first posted this solution:

The packets can be anything. Null packets would probably work fine, whatever, as long as it doesn't crash the client with garbage, its all good. We have then done our “lat trick” between the host and the joining client which is the only one not already being done. End of hosting issues forever. GG

I can quite easily help you with code that will let you detect when the client is hosting a game, and not in the channel or in game, that is very simple.

It will be up to you to make sure that your address list has ONLY the players in the channel, not those in games, otherwise you could possibly disconnect other people playing or contribute to game lag.

Sending out packets all the time to everyone is a bad idea, for a lot of reasons, not the least of which is that you are opening up your own firewall to everyone on the server for no reason. People could drop-hack you from games while they are in the channel or worse.

-- edit --

Do you see that we dont need to know the remote port? Only use the local game port as both the source and destination

Which is the reason you can't get it to work through symmetric NAT. Why not just do it properly?

I think just standard 'socket' 'connect' and 'sendto' etc. should do it for anything I've been talking about..

I'm a bit busy working on another project right now, but when I get some spare time I'll fix it for you if the 'expert' hasn't worked it out by then

[Lambchops]

@iL

Your definition of how remote port and local port is correct actually, you are right that is how it works.

So we are able to port forward now, but possibly the problem is that Python is intercepting packets destined for War2 causing the game to disconnect. I will have to think about this...

My first idea is to try changing the "binding" IP address. 0.0.0.0 means to listen on all interfaces, but we don't actually want to listen on any interfaces.. not sure what to do. I will keep testing


I can add error checking so that if a socket fails it keeps trying instead of crashing

@AHB

Dear noob. You are not listening on any interfaces. That would require using the 'listen()' API

The reason the person that you copied this code from used bind(0.0.0.0,port) is to associate the local port number with the socket, while sendto() sets the remote port...

Have you worked out what you copy/pasted yet?  #GodlyExpert  #ROTF

[Lambchops]

@iL

Shouldn't really be spending time on this, but here's a quick dll to help.

it exports 2 functions

Code: [Select]

BOOL hosting(void)
returns TRUE if local player is host and in pre-game lobby.

BOOL send_packet(CHAR* addr, int local_port, int remote_port)
sends your "For The Alliance" packet.

this way you can do something like:

Code: [Select]

if(hosting()){
    send_packet("111.222.3.44",6112,6114);
}


Havn't thoroughly tested it yet but it should work ok I think.

I can PM you the C++ source code if you want. (don't want to post it here or scrubs might use it to make hacks).

[AHB]

@Lambchops once again you talk way too much and neither of us have time to keep reading your meaningless replies while we are solving hosting

You "knew" the solution 2 years ago yet never programmed it. Why? Because either you dont actually understand the solution or you don;t know how to program. Probably both.

Why dont you quick talking and go set up a pvpgn server, write the proof of concept, and actually do something useful? Oh wait because you cant. You cant even write psuedo code lol that is a joke

If we want to only send packets to people in channels, that is easy to do. I would just add a few lines to make a request to the server status page and parse it out. The only problem with that is that we would have to tie IP addresses to usernames which isnt exactly desirable, so if we can find a way to not do it that way, it would be better. One solution would be to have iL rewrite player_ips.php to only output IP Addresses of players who in a channel, but that would be some work on the backend that I'm not sure he has time for at the moment

But dont worry about it iL and I have it covered

[Lambchops]

You "knew" the solution 2 years ago yet never programmed it. Why?

Because I didn't have time to do it properly and wouldn't bother using a crappy mass-spamming approach like the one you are attempting to use. I did discuss this approach and why it was not a good idea. All of this is published on this forum, as I'm sure you know.

You could just say "thanks" when I yet again explain things or fix stuff for you (no charge).

Seriously grow up.

Try this:




You know I would actually help you a lot more.

[Lambchops]

One solution would be to have iL rewrite player_ips.php to only output IP Addresses of players who in a channel

Yes this is what I just said on this page, it has to happen. The client side of the problem I have already coded for you in the dll above. Excatly who do you think you're convincing?.... I doubt your mom reads this forum

[AHB]

Actually wrong, I came up with it on my own while hacking an IP camera and that is how I learned about UDP hole punching and was the inspiration for the program:

http://forum.war2.ru/index.php/topic,4009.0.html

but nice try

By the way here was your response saying it is impossible:

"""There are many ways this could be accomplished, but they all involve some reasonably tricky mods and/or additions to the wc2 exe... one day maybe...""""

"one day maybe" well guess that day is today thanks to my dedicated research and terrible programming skills, neat huh?

[Lambchops]

Actually wrong, I came up with it on my own while hacking an IP camera and that is how I learned about UDP hole punching and... blah blah

LOL. Bullshit

That exact link you just quoted is you making one post about STUN because you found an article about it online, so I replied to your post and explained why it wouldn't work, what had to be done to make it work, and even posted a link to my original thread supplying pages of detailed explainations about the entire thing.

 .... then you went away for a month and came back saying you had just spent a month becoming an "expert" by researching it online. But you never noticed anything I posted and just "came up with it"?

Next you make this post with some shitty snippets of code that you have copy/pasted that you don't even understand, the only thing you do understand is that you want SQL access so you can keep running your noobish little SQL scripting hacks on the server.

Hysterics... wipe that brown drool of your chin noob.

"one day maybe" well guess that day is today thanks to my dedicated research and terrible programming skills, neat huh?

pffff you are using the sort of mass spamming that is just going to cause problems, you can't even get it to stop crashing, it still doesnt work, and I provided a well written alternative that doesn't crash or fail plus detects hosting in a couple of hours.

I was refering to doing it properly. The approach you are attempting to use might barely work with the fixes I have told you that you need ONLY because there are very few people using the server. In any real environment with a busy server it would definately fail and cause issues for most users and even their families once you spammed their home routers up with rubbish.

[Lambchops]

So, for future, our logic should be more complicated. Looks like we have to read game data port for each client or check the port from hosted game.
Sad, but looks like there's no way to know UDP port for original client with no lat bots even if his ports are fine.

This is why at the least you should have the clients registering their details with the server when they enter the channel.....

actually you should have the clients telling the server when they are trying to join a game, then the server frowarding the address/port to the host so the host can punch a hole.

^ this is how it should be done. Not just spamming everyone all the time and hoping it works.

[iL]

Tried in different options:
repeated UDP packets to all players every 10 sec, 1 single ip to every player, nobody can join my game hosted from unforwarded 6113.

If i keep repeating packets to every player, i can't join any game (i get lat).
If i stop lat trick bot, i still can't join until i restart war2.

What does it mean?
How windows handle that packets? Maybe windows send "answer" to the application sent the request? That is my next idea.
Otherwise i have no explanation what happens.
@Lambchops, i'll try your dll, but i almost sure that will not help as you open sockets the same way as a python script.

I'd say we have to inject sending packets into war2 process somehow.

[shesycompany]

should people that cant port foreward ..should they even be allowed to game? lance had his bots guess he is gone again.. well carry on

maybe everyone needs thier own device to get to the internet..i know yall on a mission but dsl sucks with 2 users..be better if 1 used the 56k part..

[Lambchops]

@Lambchops, i'll try your dll, but i almost sure that will not help as you open sockets the same way as a python script.

I'd say we have to inject sending packets into war2 process somehow.

Slightly different. You will notice that you can start my dll after wc2 is already started, but you must open the python script before wc2 so it takes precedence. This is not desirable.

I am using the windows API networking primatives. All networking ends up using these functions regardless of the source.
Just because python methods have the same name like "sendto" does not mean that they are the same - the paramaters are different so python is simplifying things behing the scenes before passing them to the API functions. I don't know how close to a 1:1 translation the python methods are, and I don't really need to know as I wouldn't bother using them.

And yes this is a bad way to be doing this, as I have said. It's unlikely to work without causing problems/glitches, but you are trying it out, so I am trying to help.

I have documented the correct way to do this many times, it is only the script-kiddie making noise that is confusing the issue.

Have sent a PM with more specific information.

[iL]

lance had his bots guess he is gone again.. well carry on

Lance released his bot as opensource, anyone can host it. The only thing required is windows hosting.

Slightly different.

Anyway, need to check your functions, maybe they will work better.
I'll try that when i have time.
All current tries made me impossible to join anyone's game, also nobody can join my one.

[iL]

Well, checked your things another way:
Changed all the socket code to Lampchops code:

Code: [Select]

    for player_ip in player_ip_list:
      try:
        # Target host is IP of player you want to be able to join your game
        target_host = player_ip
        # send some data
        os.system("hostholecmd.exe " + str(player_ip) + " " + str(war2_client_port) + " " + str(war2_remote_port))
      except Exception as e:
        print e
    time.sleep(10)

Nothing changed:
my port (war2_client_port) is 6113, not forwarded, remote port is 6112.
Then i hosted the game, then started that script with loop for chat players only, and... they wasn't able to join.
Then i stopped my loop and wasn't able to join any  game until rejoin bnet with war2.

Any other ideas what to do?

[iL]

oh shit it works!!!!!

UDP hole punching for the win, check this out for proof (notice "your port is closed", but abcde joined my game):

I still didn't reach such progress with that UDP Hole thing.
How you reach that? When you sent UDP to abcde? After you host the game? Or before you host the game? Or before you joined BNET? Or when?

Maybe the problem is related to non-standart port somehow. Next step from my side is to stop portforward on router and change port to 6112.

But it doesn't work for me when i send UDP from 6113 to 6112 (even when i send packets once and right atfer hosting the game). I send UDP to 3-5 active players in chat (including one who tried to join).

Also after sending such UDP from my side i haven't been able to join until rejoin bnet on war2.

What's rejoin BNET from networking side? Looks like BNET part is a separate process inside war2 application. It's being restarted when i rejoin bnet? So it closes and recreates all the sockets again or what?

I still think proper way is to use BNET part of war2 to send UDP packets to peers.
Then war2 send packet, so war2 will receive it back. Works fine when you manually try to join someone's game and then he can join your game.