Home » MODDING HQ 1.13 » v1.13 Multiplayer Development & Bug Reports » multiplayer bug reports
multiplayer bug reports[message #214124] Sat, 25 April 2009 13:23 Go to next message
Native_Elder

 
Messages:58
Registered:April 2009
hi everybody. While playing multiplayer games of 1.13, i thought that this is a truly new approach to ja2 and very exciting. I'm looking for a place to post MP-related bugs so it can be further improved.

- team size and stability: when playing 5 vs 5 (random mercs) the game seems almost completely stable (see exceptions below) while 6 vs. 6 is almost unplayable. Interrupts, ending turns and the like all cause issues in 6 vs. 6, the game regularly hangs, turns must be ended using alt-e all the time. In 5 vs. 5 this is almost never the case.

- 1st aid pack freeze
the game freezes when you try to put a 1st aid pack in your mercs first hand (while a weapon is still there). Normally, the gun would swap to the lower "second" hand. Here, MP freezes hard and must be terminated.

- broadcast number IP bug: any IP that includes the number 255 somewhere will be considered as a broadcast number that is invalid to connect to. Broadcast number IP is 255.255.255.255, while stuff like 123.166.23.255 that are perfeclty valied otherwise willbe considered broadcast IP's by the programme.

- interrupt through walls without LOS. This is a bug i observed a couple of times that a merc, especially with the gun raised, will interrupt another merc even if there's no Line of sight.

- scroll to opponents position. sometimes the game will autoscroll to where the (invisible) opponent is during his turn. But this is rather rare.

that's about what i recall right now. Sorry if these bugs are known and taken care of, just wanting to help Smile
Re: multiplayer bug reports[message #214174] Sat, 25 April 2009 21:44 Go to previous messageGo to next message
RoWa21

 
Messages:2039
Registered:October 2005
Location: Austria
Thanks for collecting these bugs. We are trying to fix them.

PS: A new test version including file transfer, some bug and a new feature "maximum AI enemies in CO-OP" should be ready soon.


Re: multiplayer bug reports[message #214176] Sat, 25 April 2009 22:03 Go to previous messageGo to next message
SpaceViking

 
Messages:760
Registered:January 2004
Location: Rochester, Minnesota, USA
Please do NOT include file transfer. The JA2 code is very poorly written re: security and thus easily exploited.


Re: multiplayer bug reports[message #214180] Sat, 25 April 2009 22:23 Go to previous messageGo to next message
RoWa21

 
Messages:2039
Registered:October 2005
Location: Austria
SpaceViking
Please do NOT include file transfer. The JA2 code is very poorly written re: security and thus easily exploited.


I don't understand what the problem should be if files are transfered from A to B? What problems should we expect with the JA2 source code??


Re: multiplayer bug reports[message #214200] Sun, 26 April 2009 06:53 Go to previous messageGo to next message
SpaceViking

 
Messages:760
Registered:January 2004
Location: Rochester, Minnesota, USA
It is quite easy to exploit file transfer to cause files to be overwritten on the target system. It is made easier when the code doesn't do bounds checking and such. JA2 is mostly old C code and that is prime turf for that sort of thing.


Re: multiplayer bug reports[message #214211] Sun, 26 April 2009 13:21 Go to previous messageGo to next message
redgun

 
Messages:190
Registered:March 2007
Location: Austria
so if I understand that correctly JA2 could be used then in order to infect a system with malware?
Re: multiplayer bug reports[message #214226] Sun, 26 April 2009 16:15 Go to previous messageGo to next message
BirdFlu

 
Messages:445
Registered:September 2007
Location: Lampukistan
You are describing two problems, overwriting files and buffer overflows.

1. Files are supposed to be written only in a user provided directory. The transferred filenames are supposed to be relative (not absolute) and are used to build the final file path
(/). If the transferred path is global then newly constructed path will be invalid, as such a path don't exist (eg. \C:\WINDOWS\whatever). You can additionally check for ':' occurences. If you try to break out of by transferring "..\..\WINDOWS\whatever", then it can easily be checked whether the string contains the substring "..". So, overwriting random files can be prevented.

2. Buffer overflows are of course a general problem of C/C++, especially when you accept data from a unverified source. But with this argument the whole multiplayer project can be questioned. Adding file transfer to it opens a new can of worms, as not only the data transfer has to be secure, but also the processing (mostly reading, i suppose) of the transferred files. So, someone will have to take a look at these loaders. Random files should not be a problem, as they will be transferred but not processed. So it comes to game relevant data like ini files, map files, prof.dat files and maybe a couple of others. I think this should be manageable from a security point of view.

Any other specific concerns that i left out and should be addressed?

[Updated on: Sun, 26 April 2009 19:50] by Moderator


Re: multiplayer bug reports[message #214292] Mon, 27 April 2009 11:03 Go to previous messageGo to next message
Native_Elder

 
Messages:58
Registered:April 2009
RoWa21
Thanks for collecting these bugs. We are trying to fix them.

PS: A new test version including file transfer, some bug and a new feature "maximum AI enemies in CO-OP" should be ready soon.


sounds cool rowa21. If the file transfer feature would indeed be a controversial issue, then maybe you postpone it until the differences and issues are resolved? or is this feature critical in the eyes of the MP community?


what would the file transfer system allow in terms of file or data size? assuming i wanted to play wildfire-1.13 in multiplayer (for example) but only i have the mod installed (or even larger, renegade republic) my friend only has a basic install of 1.13.
in such a case, tons of data would have to be sent over. I guess the system would be more appropriate for smaller data sizes? or could it handle larger sizes too?


another question, although not really on the topic, about the idea of a "passive" server.

Right now, the server has, in the minimum, to start the server and start the game and click ready. The server has to play as a client and needs to press "continue" after the fight is over.

A passive server in my view would only have to start the game, the rules are then set, and clients could connect and play without the server having to do anymore than just starting a server (like once in a day, or, given some stability issues, once a couple of hours)
also the server wouldn't necessarily be a client and joining the game. The idea is to make coordination of multiplayer games easier, having an IP people could connect to most of the times to base their game on. Maybe some sort of warning message would have to be sent whenever the server fails (game crashes, etc.)

but clearly, this is just an idea i wanted to share and has less priority than the bug fixes, especially the 6th men stability issue and the medipack freeze. :wave:
Re: multiplayer bug reports[message #214298] Mon, 27 April 2009 14:06 Go to previous messageGo to next message
Zathras

 
Messages:44
Registered:December 2008
Location: Sydney, Australia
The file transfer is primarily designed so that we can have a seperate tabledata balance for multiplayer and to allow custom map download if a client is missing such a map. It wouldnt be the best option to send whole mods, but it could be done.

The other drawcard in future will be that we can use it to download any files that a client might have out of state with a server and thus it will provide a little bit of cheat mitigation.

I agree with JA2 being a older codebase it is probably vulnerable to all sort of buffer overruns.

Perhaps a simple option for security is to force the client to choose whether to proceed with connecting if it has to download files.

As for a dedicated server, not really needed IMHO, the way i plan to get around that is to have a master server list and browser in-game, this will also facilitate NAT punchthrough.

Would only go the dedicated server route if we changed the game to be some kind of persistant campaign later on. That said, the code can support a seperate server fine.


Re: multiplayer bug reports[message #214305] Mon, 27 April 2009 16:11 Go to previous messageGo to next message
Native_Elder

 
Messages:58
Registered:April 2009
Zathras


Would only go the dedicated server route if we changed the game to be some kind of persistant campaign later on. That said, the code can support a seperate server fine.


you caught me, of course i was aiming the dedicatd server idea at a more advanced stage of the project. i've been thinking of what problems the status quo would have for this to work from a users/ gui perspective, and i thought maybe a simple first solution could be that the server establishes the initial settings, and then for the start of the game, e.g. select maps and unlocks the laptop, the server's role could be forwarded to the first active client.

i'd like to add that this idea is aimed at a strongly developed idea of the multiplayer and i agree that under the status quo, especially also the status quo of the community, it is not a very imminent suggestion. But thanks for elaborating zathras. :wave:


as to the tabledata balance as primary use of the file transfer system i just wanted to say that the xml editor seems to save all xml files at once and unless you're somwhat knowledgeable just what exact files were actually changed during your xml editor session, you might end up sending the entire tabledata folder most of the time. maybe we're lucky and the xml editor gets an overhaul in this respect so it can easily be seen by date which xml's are actually changed and which aren't after a xml editor session. This is unless i didn't understand the xml editor's working well enough or unless the file transfer code takes this into account already, then this paragraph can be considered void.
Re: multiplayer bug reports[message #214754] Fri, 01 May 2009 00:35 Go to previous message
Native_Elder

 
Messages:58
Registered:April 2009
Native_Elder


- 1st aid pack freeze
the game freezes when you try to put a 1st aid pack in your mercs first hand (while a weapon is still there). Normally, the gun would swap to the lower "second" hand. Here, MP freezes hard and must be terminated.



this one may very well have been a false positive, i'm very sorry. I guess nobody else ecnountered it?
Previous Topic: Improved UI Patch
Next Topic: MP stuff breaks release build (sort of)
Goto Forum:
  


Current Time: Sat Sep 22 23:57:52 EEST 2018

Total time taken to generate the page: 0.01381 seconds