This project is read-only.

Password invalid

Feb 11, 2014 at 6:06 PM
Edited Feb 11, 2014 at 6:39 PM

I hope you are still working on this project :) Here's the question:

When I'm trying to log in to my server using the code you provided in documentation it throws an incorrect password exception. I'm sure the password is right. It's a bug?
An unhandled exception of type 'TimScripts.BF4Rcon.Frostbite.IncorrectPasswordException' occurred in TimScripts.BF4Rcon.Frostbite.Portable.dll
Feb 19, 2014 at 2:24 AM
Edited Feb 19, 2014 at 2:24 AM
Hey sparcopt! Sorry about the delay D:

With regards to this problem, it's probably a bug! Since I don't have a server to test with, I wasn't able to directly test the logon code :<. Just to be sure, you can try a plaintext logon.
// IRconClient client...
client.SendRequest("login.plaintext", "pass");
If it gives you an OK, then it's definitely a bug.

Now, since I'm unable to debug it myself, I can only speculate on what the bug is. However, I think the bug might be because the password hash that is sent out is in lowercase. The code I wrote for the BF4 library should be identical to the BF3 library, except that the BF3 library sent it in uppercase.

On line 158 (or nearby) of RconClient.cs is the code containing the call to GeneratePasswordHash. Below that, try adding passwordHash = passwordHash.ToUpperInvariant();

If logging in works after that, then I guess we've found the problem :D. Buuut, if it still doesn't work, you could still try debugging it yourself or changing up the code to do a plaintext login.

I had to create my own MD5 implementation since portable .NET doesn't come with it, so that could be the problem. It seemed to be working fine, though, at least after some manual testing on random strings. If you're feeling adventurous, you could also try swapping out my MD5 code for regular .NET's code. However, it would take quite a bit of doing to plug it into the portable code. I doubt that's the problem, though, so I guess it's a project to do if you're bored :D

With the important stuff out of the way...
Since there didn't seem to be much (if any) interest in it, I stopped working on this to work on another. I didn't outright abandon it though. I'm always happy to do bug fixes, and I'll totally consider getting back to work on it for reals right after my current project is done!

Thanks for the feedback, and I hope we can get this problem solved :D
Feb 19, 2014 at 3:18 AM
Edited Feb 19, 2014 at 3:50 AM
It's great hearing from you :D

Yes, it's definitely a bug because SendRequest gives me an OK response.

About the lack of interest don't let that stop you from working :) I'm sure that from time to time someone will find your library very usefull and unique! It's very usefull for me, otherwise I wouldn't have started developing my own RCon client for BF4.

Since the time of my question I have made a lot of progress into my application. Although, I have a question about handling server events. In order to handle different events, the following code is correct?
client.RconEvent += (sender, args) =>
    // when a player/admin sends a message
    if(args.EventName == "player.onChat")
         //do something
    if(args.EventName == "player.onJoin")
         //do something
    if(args.EventName == "player.onLeave)
         //do something
     // and so on...
This works but it's a good working scenario? If two events occur at the same precise time, the application will miss one and do another? Or it acts like a queue and it will run the missing event later, after the first is done?

Thank you!
Feb 19, 2014 at 3:05 PM
The RconEvent event will be raised as soon as the appropriate data is received from the server. The event handler will be called in the same order as the data is received. In addition, I believe the code currently will not raise RconEvent until the last event is done. This would actually be a bug, now that I look at it, since this allows an event handler to block the receiving of data for as long as it's running, which is less than optimal D:.

To more directly answer your question, the event handler will be raised for all events received (once per event). The event handlers will probably be invoked in the order they are received, but two event handlers may (after bug fix) be running at the same time. A good example is for the round over events. The server sends three events over to the client when a round is over. If, in your code, you need to have the data from all three events at the same time, you'll need to carefully write code that can handle all three to essentially be handled at the same time.

All that being said, the latest code contains a better event handling solution. I don't know if you're using the prerelease binaries, but using the newer features would require using the newer code (if you're not already). The handling events page shows the basics of the functionality. Essentially, the RconEventManager class parses the event data into a format easier to work with, such as player names becoming Players (as in the class!). The three round over events are also combined into a single event!
Feb 19, 2014 at 7:55 PM
Edited Feb 19, 2014 at 7:58 PM
So when an event is raised, it blocks the receiving of data from others?

Let's that the event player.onChat is raised at the same precise time that I'm sending a resquest (client.SendRequest("admin.listPlayers", "all")). The response of the request will be null. How to get around of this and make sure the event and the request will run without problems?

One option would be to create a second connection and client with the same IP, Port and password. Run the event on it and the request on the first client. I'm sure there is a better solution but I can't seem to find it :)
Feb 20, 2014 at 2:36 AM
Now, I haven't worked on the code in a little while, but I couldn't remember or find a case where SendRequest returns null. Probably a boo-boo on my part for not writing a test for it :D

Anyways, I did just check in some code that was deadlocking when a request was sent in an event handler, as well as some other situations maybe. Event handlers are now invoked on a separate thread; when an event packet is received, the invocation(s) are queued on the thread pool so that the read loop may continue its reading. Hopefully this will fix any issues with events you've been having!

Also included is the possible fix to logins I discussed earlier. I don't know if it'll work, but it can't get much worse than already broken anyway :D
Feb 20, 2014 at 2:55 AM
Perhaps it was not null and it was probably a deadlock. I also noticed that you couldnt send requests inside the events, I had to create threads :)

Great! When you are going to release it with the new fixs? I cant wait to see my events and requests fully working :)

Its not much of a deal if the login doesnt work, the important thing were the events fixs.

Thank you so much for taking the time from the other project to work on this.
Best regards.
Feb 20, 2014 at 3:34 AM
I'm always happy to fix bugs! I wasn't planning on putting up a release until the library was more complete and tested, which I guess might take a bit. I would definitely recommend grabbing the source yourself and building it, since that's pretty much what I'm gonna do when I put up the next release :D

Also, getting the login stuff working will hopefully happen eventually. A lot of the other code, like in PlayerCollection, relies on the IsLoggedOn property. Eventually, if/when I get a good block of time to work on this, I'll probably rent a small server for a month to knock out a lot of this stuff!
Feb 21, 2014 at 3:12 PM
Edited Feb 21, 2014 at 3:13 PM
I'm sorry for the ignorance D: I never did this. How can I open a class inside the dll file, in this case RconClient.cs? Do I have to install a decompiler?

Can you provide an unofficial release of the library with just the event fixs for me? It woud help me a lot. Right now I'm stuck because of the dealocks and I can't make any progress D:
Feb 22, 2014 at 2:23 AM
You can get the code here:

Just build it like any normal Solution (like with Visual Studio or MSBuild). No need to decompile :D

If you, by chance, are using an Express version of VS, I don't think you'll be able to open the solution because it contains multiple projects (or maybe you can idk). If you can't, you'll probably need to use MSBuild. See for using it. Also, it can be found at %systemroot%\Microsoft.NET\Framework64\<version>
Feb 22, 2014 at 3:20 AM
Somestimes I don't event think lol I complety forgot that I could browse the source code!!

Thanks :)
Feb 26, 2014 at 1:31 AM
Edited Feb 26, 2014 at 2:10 AM
Sorry for spaming this topic.

Are you aware of any memory leaks or anything else that could be using more and more memory as the time passes? I'm just asking but it's probably from my application. To be honest I don't have any clue.
Feb 26, 2014 at 2:48 AM
I don't know of any memory leaks, but I haven't used the library thoroughly enough to know if there are any. I didn't notice anything during a somewhat brief test a while ago, and FxCop didn't indicate objects left undisposed.

If you have a profiler handy, I would definitely try it.

Or, if you don't have one, I used to use (WinDbg) back when I didn't use one, either. I think getting WinDbg still requires getting the Windows SDK, btw.

I reviewed some of the code a bit, and nothing really stood out to me. The RequestManager, which off the top of my head is a possible source, looks clean after reading through it.

I'll take a more thorough look after I finished enough with my other project. Or, if you find something that would indicate it's the library's fault, I'll take a look sooner!