Neo2003

I get this too. Mee too Found what could cause this but not why yet. Mangosd did receive a packet from Wardend which is not understood, so skipping 2 uint8 per second is low and makes like a freeze. Moreover, I added a BanLength option in config in days. 0 = infinite else the number of days. I will post a new version soon when I know better what could cause an invalid packet from Wardend. Maybe try to change the port used. 4321 may be used for something else so try something higher. I will move to port 6555 in next patch by default.

Hello, Just tested on Gentoo X64 with GCC 4.4.5, no problem found. Maybe related to other changes? I doubt GCC can be the cause.

I will write again the same things: 1) Warden modules are from blizz and for wow client and client is for windows. 2) Warden modules are some DLL win32 3) To have the keys, we need to run the module 4) The daemon is for this, so it is for windows 32, it can run on linux wine x32 5) Core can be on Windows/Linux x32 or x64 6) If the code in the wardend was in core, core had to run on windows only That's it. Note: I will take a look and the compilation problems

Yes, register reset the counter then the client has no chance to reply in the 2 seconds delay. Nice catch.

You can't really without adding some log output Btw, go around line 157 of src/game/WardenMgr.cpp 1st replace "session->m_WardenTimer.Reset();" line 158 by "session->m_WardenTimer.SetCurrent(0);" If this does not help, keep this modification and also increase the time to 3 minutes line 157. Let's see if this strange .Reset() which does not really reset anything has something to do with this problem, or if the time is too short.

TrustUs DevilSide SignSwap BreakTrue :cool: ...

Wardend.ico is in the .diff (saved with --binary option). I don't know why some of you miss this file after you apply this git diff. Anyway just copy /src/mangosd/mangosd.ico to /src/wardend/ and rename it wardend.ico.

Can you please check if the client did stop to reply to cheat-check? I let the client 2 minutes, which is long enough I think. Btw, there is a new version, see 1st post. - Time source changed to be from World always - Wardend can timeout and much more I recommend you try the new data, less duplicate page checks and new pages/lua checks.

You probably have another check failed just before this one. This message is a false positive one when another check fails. I fixed this case and will upload a new patch this evening with others changes.

Better version of the patch in 1st post.

Maybe throw the same message @ bliz. telling them warden serves nothing...

After a discussion directly with Ambal, we agree. I will do another better patch to remove the need of this sMapMgr.Update(0); which is clearly not the way to go.

I will drop it from warden_check_memory table, just do the same. It's possible that I made a typo on the samples.

I mean that the "sMapMgr.Update(diff);" is in the code section under if (m_timers[WUPDATE_OBJECTS].Passed()), so called only when the timer is finished. This works because the timer is set to interval 0 so always passed. If you try to give a value to this timer interval like 1000, it will be passed every 20 cycles of 50ms so you will call Update(diff) with diff=50 (the real time passed in the main loop) every 1000ms (when timer is passed) which is wrong. Moreover you pass a 50ms diff here every 50ms and same in worldsession so the diff in map is double speed, which again is not yet a problem because it has no use currently, but made my warden patch twice speed when called from map::update(diff), with this diff. So better to send 0 in one of these both calls.

Hello, What features does the patch add? Fix timers code in World.cpp, remove unneeded timers and fix diff in map update. For which repository revision was the patch created? 11315 Is there a thread in the bug report section or at lighthouse? None, since they work fine currently just because the diff is not used in MapMgr.Update Who has been writing this patch? Please include either forum user names or email addresses. Me Patch: diff --git a/src/game/Map.cpp b/src/game/Map.cpp index 747088e..6686316 100644 --- a/src/game/Map.cpp +++ b/src/game/Map.cpp @@ -444,7 +444,7 @@ void Map::Update(const uint32 &t_diff) WorldSession * pSession = plr->GetSession(); MapSessionFilter updater(pSession); - pSession->Update(t_diff, updater); + pSession->Update(updater); } } diff --git a/src/game/World.cpp b/src/game/World.cpp index 04e0820..79699fb 100644 --- a/src/game/World.cpp +++ b/src/game/World.cpp @@ -1299,8 +1299,6 @@ void World::SetInitialWorldSettings() LoginDatabase.PExecute("INSERT INTO uptime (realmid, starttime, startstring, uptime) VALUES('%u', " UI64FMTD ", '%s', 0)", realmID, uint64(m_startTime), isoDate); - m_timers[WUPDATE_OBJECTS].SetInterval(0); - m_timers[WUPDATE_SESSIONS].SetInterval(0); m_timers[WUPDATE_WEATHERS].SetInterval(1*IN_MILLISECONDS); m_timers[WUPDATE_AUCTIONS].SetInterval(MINUTE*IN_MILLISECONDS); m_timers[WUPDATE_UPTIME].SetInterval(getConfig(CONFIG_UINT32_UPTIME_UPDATE)*MINUTE*IN_MILLISECONDS); @@ -1450,13 +1448,8 @@ void World::Update(uint32 diff) sAuctionMgr.Update(); } - /// [*] Handle session updates when the timer has passed - if (m_timers[WUPDATE_SESSIONS].Passed()) - { - m_timers[WUPDATE_SESSIONS].Reset(); - - UpdateSessions(diff); - } + /// [*] Handle session updates + UpdateSessions(diff); /// [*] Handle weather updates when the timer has passed if (m_timers[WUPDATE_WEATHERS].Passed()) @@ -1488,14 +1481,10 @@ void World::Update(uint32 diff) } /// [*] Handle all other objects - if (m_timers[WUPDATE_OBJECTS].Passed()) - { - m_timers[WUPDATE_OBJECTS].Reset(); - ///- Update objects when the timer has passed (maps, transport, creatures,...) - sMapMgr.Update(diff); // As interval = 0 + ///- Update objects (maps, transport, creatures,...) + sMapMgr.Update(diff); - sBattleGroundMgr.Update(diff); - } + sBattleGroundMgr.Update(diff); ///- Delete all characters which have been deleted X days before if (m_timers[WUPDATE_DELETECHARS].Passed()) @@ -1911,7 +1900,7 @@ void World::UpdateSessions( uint32 diff ) WorldSession * pSession = itr->second; WorldSessionFilter updater(pSession); - if(!pSession->Update(diff, updater)) // As interval = 0 + if(!pSession->Update(updater)) { RemoveQueuedSession(pSession); m_sessions.erase(itr); diff --git a/src/game/World.h b/src/game/World.h index 32ef77b..44acb21 100644 --- a/src/game/World.h +++ b/src/game/World.h @@ -71,15 +71,13 @@ enum ShutdownExitCode /// Timers for different object refresh rates enum WorldTimers { - WUPDATE_OBJECTS = 0, - WUPDATE_SESSIONS = 1, - WUPDATE_AUCTIONS = 2, - WUPDATE_WEATHERS = 3, - WUPDATE_UPTIME = 4, - WUPDATE_CORPSES = 5, - WUPDATE_EVENTS = 6, - WUPDATE_DELETECHARS = 7, - WUPDATE_COUNT = 8 + WUPDATE_AUCTIONS = 0, + WUPDATE_WEATHERS = 1, + WUPDATE_UPTIME = 2, + WUPDATE_CORPSES = 3, + WUPDATE_EVENTS = 4, + WUPDATE_DELETECHARS = 5, + WUPDATE_COUNT = 6 }; /// Configuration elements diff --git a/src/game/WorldSession.cpp b/src/game/WorldSession.cpp index 2db93f4..9bbf11d 100644 --- a/src/game/WorldSession.cpp +++ b/src/game/WorldSession.cpp @@ -198,7 +198,7 @@ void WorldSession::LogUnprocessedTail(WorldPacket *packet) } /// Update the WorldSession (triggered by World update) -bool WorldSession::Update(uint32 diff, PacketFilter& updater) +bool WorldSession::Update(PacketFilter& updater) { ///- Retrieve packets from the receive queue and call the appropriate handlers /// not process packets if socket already closed diff --git a/src/game/WorldSession.h b/src/game/WorldSession.h index 8ac7d17..f11793f 100644 --- a/src/game/WorldSession.h +++ b/src/game/WorldSession.h @@ -242,7 +242,7 @@ class MANGOS_DLL_SPEC WorldSession void QueuePacket(WorldPacket* new_packet); - bool Update(uint32 diff, PacketFilter& updater); + bool Update(PacketFilter& updater); /// Handle the authentication waiting queue (to be completed) void SendAuthWaitQue(uint32 position); Reason: WUPDATE_SESSIONS and WUPDATE_OBJECTS are used to make a 0 interval timers! useless and: if (m_timers[WUPDATE_OBJECTS].Passed()) { m_timers[WUPDATE_OBJECTS].Reset(); ///- Update objects when the timer has passed (maps, transport, creatures,...) sMapMgr.Update(diff); // As interval = 0 sBattleGroundMgr.Update(diff); } - We update a 0 timer, so always passed - We call some other object update when the timer is Passed, so the update are done with a ~50ms diff instead of the real diff, this works only because the timer serves nothing with an interval 0. Set the interval to 1000 and the update will be called with diff=50 every 1000ms. - "// As interval = 0": No, the diff is ~50ms here. - Here sMapMgr.Update::Update() must be called with 0, not the ~50ms diff since it's called also from elsewhere. I did not understand why my warden timer where strange, now I know Edit: New version of the patch. I did not remind properly since I saw this long ago, it's WorldSession::Update() which was called twice with a diff making it having an internal unused diff at double speed. So I simply remove the diff from this method.

Hello iforgotmypassword Feel free to PM me a link explaining this. Since client 2.something, I was never able to make client load a modified dbc anymore, it always tell something like "the file blabla.dbc is failing signature check". If I make it load a custom dbc, then I can consider making this implementation. For the moment by the way, I did make wardend cut the connection after a timeout, it was not easy.

Some data for pages that should detect a hack if I made it properly INSERT IGNORE INTO `warden_check_page` VALUES (2538611263, '1529EB2FBA39B306B018DAD4A6046DF4F877F49A', 0x63D801B0, 24), (4289895411, 'AE4C7A22758087A10D0DE5BD2A79669DE553F6B2', 0x63D801B0, 24), (1683631648, '6D4B77EA21B47111544505A8D7DB34031BD42C5D', 0x63D801B0, 24), (0812875479, '0DF67B88FE74BD837B39E293246AC834AF247E96', 0x63D801B0, 24), (0767954206, 'F5E39AF674FD53890C199C522BF36413281972D0', 0x63D801B0, 24);

For "most" of the existing hacks, it's a matter of putting the proper data in the DB to detect them with MEM_CHECK, LUA_CHECK or PAGE[AB]_CHECK. Currently there is in the DB only sample data and a single version of WPE detection, I plan to add more checks but I am not familiar with them and the way they work, so I mostly rely on you to help me on this If you know the way to detect one hack, PM me with the data to scan, then I will encrypt them to fill the DB in a format warden directly understand and also to protect a bit these sensitive information. Unfortunately I don't have the CheckId for MODULE_CHECK for any module, so even if I implement this check, we can not run it, it would be useful for some hacks too, I even have data for it.

New version for 11313 posted with memory leak fixed and another reactor on Linux.

I found and fixed the wardend memory problem. I did send 25000 packets to ask for a module load/key generation/module unload. The test took 21 seconds on my test PC and the process has not increased in memory. Also not a single module load error while this stress was more on ACE and BufferedSocket than on Module load/unload code which is fast anyway. I will check if I find what can cause connection problem on Linux and upload a new version this evening. Edit: I fixed the Linux problem. The ACR::reactor was not a proper type for linux in WardenMgr

I think the too problems are related. "Got 15264 bytes of data, 18976 bytes needed, waiting for next tick", not much a problem. The ACE::reactor did call the packet parser while the full packet was not completely received. I need to remove this old message "Command handler failed for cmd 3 recv length 15264". "WardenSocket::_HandleLoadModule, received 19620": this is a problem. We need 18976 bytes and we got 19620 bytes, there a a memory problem somewhere probably related to "wardend allocate 150Mb".

Hello, I saw the quite same problem personally when having mangosd on Linux and Wardend on a different Windows Box. This was because a firewall was preventing anything to go back to mangosd. Since I use a ping between the too and mangosd don't see the pong message from wardend, it thinks wardend is no more here and closes the connection, then retry to open a new one. I have to put some code in wardend to also close the connection after a timeout and will take a look at wardend memory allocation.

Oh, I did forget to update VC80 and VC100 projects. wardend must use the BufferedSocket.cpp/.h which is in /src/wardend, not the realmd one Since you probably use VC100, remove BufferedSocket.cpp and BufferedSocket.h from wardend project and re-add the ones in /src/wardend This error is because realm version of these file is limited to 4k packets only.

Hello, This time I found a way to fix this incomplete packet problem + fixed another problem at wardend reconnection due to lost flag set. Please use the last version I just posted (see 1st post) and report if anything else is broken. Neo2003

Vlad852, try to get latest version I just posted. I made lot of mistakes with my booleans in previous one.