Jump to content
Sign in to follow this  
gonk

Fennec.ws network traffic

Recommended Posts

Yeah, i saw the response.

Okay, than we are good in terms of BE version. However i'm concerned that none of our servers are listed on GameTracker as populated. :(

10:35:45 BattlEye Server: Initialized (v1.120)

Share this post


Link to post
Share on other sites

Perhaps notify the gametracker staff about ArmA 2 / OA change to v3.

Share this post


Link to post
Share on other sites

Well, what seems odd is that some servers are ok while others are not. Which doesn't make much sense.

Share this post


Link to post
Share on other sites
Well, what seems odd is that some servers are ok while others are not. Which doesn't make much sense.

It does in relation to:

The v3 should become active after restarting the server since today.

Share this post


Link to post
Share on other sites

so just once again for sure! :)

to enable the flooding protection on Your server

1. restart server

2. use BattlEye

both steps combined give best results

Share this post


Link to post
Share on other sites

[snip]

base_packet ="\xFE\xFD\x00\x10\x20\x30\x40"
info_packet = "\xFF\xFF\xFF\x01"
full_packet = base_packet + challenge_packet + info_packet

The base_packet is actually just: "\xfe\xfd\x00"

The 4 bytes after that is a request ID which should be 4 random bytes. These bytes will then be sent after the header in all further packets. Verifying these bytes protects the client against spoofed replies.

Share this post


Link to post
Share on other sites

The challenge response im getting on servers that are still on old, contains 0@0 at the end, which im using to determine that the server doesn't need one.

Share this post


Link to post
Share on other sites
The challenge response im getting on servers that are still on old, contains 0@0 at the end, which im using to determine that the server doesn't need one.

Thanks. That was fairly obvious when pointed out. :)

Share this post


Link to post
Share on other sites

We are currently on "raporting ip" setting as "localhost". It was the only method to "enable the flooding protection". Even commenting the line in cfg wouldn't help. Will see with the new BE, yesterday version 119 was no go.

What a shame with GT.

Share this post


Link to post
Share on other sites
We are currently on "raporting ip" setting as "localhost". It was the only method to "enable the flooding protection". Even commenting the line in cfg wouldn't help. Will see with the new BE, yesterday version 119 was no go.

What a shame with GT.

Keep in mind that the GameSpy and BE fix cannot prevent these excessive requests from reaching your host. Only a firewall in front of your server can achieve that.

Share this post


Link to post
Share on other sites

To disable the GameSpy reporting you need to add a faulty string like:

reportingIP="<>";

Share this post


Link to post
Share on other sites
Keep in mind that the GameSpy and BE fix cannot prevent these excessive requests from reaching your host. Only a firewall in front of your server can achieve that.
The requests will hopefully subside once the tools or people wielding them figure out it is now useless :)

In any case the excessive requests are but a fraction of the data that was generated before :)

I can confirm the fixes for BE are working too - I can successfully query server-info first and then player-info, thanks!

Edited by Sickboy

Share this post


Link to post
Share on other sites

In essence, it comes down to:

base_packet = "\xFE\xFD\x00"
challenge_packet = "\x[size=2][color=#000080][size=2][color=#000080]FE\[/color][/size][/color][/size][size=2][color=#000080][size=2][color=#000080]xFD\[/color][/size][/color][/size][size=2][color=#000080][size=2][color=#000080]x09"[/color][/size][/color][/size]
random_id = "\x10\x20\x30\x40"
info_packet = "\xFF\xFF\xFF\x01"

If you want to have death stats in the info packet change the info request

from info_packet = "\xFF\xFF\xFF\x01" to info_packet = "\xFF\xFF\xFF\xFF"

PS: thanks for the help, everyone.

PPS: the random_id is actually a timestamp, but for server queering does not matter.

Share this post


Link to post
Share on other sites

glad to see this is being addressed... good work..

Share this post


Link to post
Share on other sites
If you want to have death stats in the info packet change the info request

from info_packet = "\xFF\xFF\xFF\x01" to info_packet = "\xFF\xFF\xFF\xFF"

Not sure what the difference is, it seems to give the same information that you receive already from player info, but in a different format:

Instead of: PlayerName - Team - Score - Deaths per player

You get: First all PlayerNames, then all Teams, then all Scores, then all Deaths.

Also it seems it doesn't matter if you send "\xFF\xFF\xFF\x01" or "\xFF\xFF\xFF\xFF". Both will send the player info in the "First all playernames, then all teams", etc format. While leaving out the last byte, or replacing it with e.g \x00, it will list players in the normal format.

Personally, I actually send \xFF\x00\x00 first to get only the server-info, and then I send \x00\xFF\x00 to get the player-info seperately.

Because the packets only support up to 1400 bytes, servers with lots of players / mods etc don't fit everything in 1 packet.

(I have been unable to figure out how to receive multiple packets for the same info query; if anyone knows im all ears :)).

---------- Post added at 11:27 ---------- Previous post was at 10:52 ----------

Actually, if you include the 4th character in the info packet (\x01, or \xFF), you will also receive a "Splitnum" value, if it is \x00, there are more packets. If it's something else it seems to mark the end of available packets.

Edited by Sickboy

Share this post


Link to post
Share on other sites

Actually, if you include the 4th character in the info packet (\x01, or \xFF), you will also receive a "Splitnum" value, if it is \x00, there are more packets. If it's something else it seems to mark the end of available packets.

The byte following the 'splitnum\0' can be parsed like this:

flag = s.get_byte.unpack("C")[0]

index = flag & 127

final = flag & 0x80 > 0

index is the packets index in the series, it's possible to recieve packets out of order so reassembly in the correct order is required to query some servers.

Share this post


Link to post
Share on other sites

In any case the excessive requests are but a fraction of the data that was generated before :)

I can confirm the fixes for BE are working too

That is what I can also confirm, the 120 version keeps the server stable and the requests if any they have no impact

Share this post


Link to post
Share on other sites

Gametracker shame on you

Share this post


Link to post
Share on other sites

The BE "fix" is as good as it can get. There's nothing you can really do to stop the inbound UDP packet. At most, you can block it at your firewall but the ISP / provider is still going to see that as inbound traffic. If you are on a quota, it will hit your quota.

However, the inbound UDP packets are quite small - only 60 bytes in length. It was the outbound response that was causing most of the traffic. This is now shut off with BE.

Thanks to gonk for first seeing and reporting the problem, and thanks to $able for providing a quick fix.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×