Neo2003

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.

Iif anyone has a funny name for the tool, have a go and tell us

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.

nope, client can load modified Spell.dbc and there is many guides how to modify some stuff like global cooldowns, etc

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

OK, seems is working. But some problems exist: memory leak in warden demon, after connecting about 300 testers, wardend allocate 150Mb. Also still sometime:

2011-04-03 21:36:31 WardenSocket::_HandleLoadModule, received 15264

2011-04-03 21:36:31 Got 15264 bytes of data, 18976 bytes needed, waiting for next tick

2011-04-03 21:36:31 Command handler failed for cmd 3 recv length 15264

2011-04-03 21:36:31 WardenSocket::_HandleLoadModule, received 19620

2011-04-03 21:36:31 Wardend::LoadModule()

2011-04-03 21:36:31 ERROR:Warden module seams damaged, cannot find signature data.

2011-04-03 21:36:31 There was a problem in running the sent module

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".

I have a problem runing this with wine, the warden daemon is working, the connection is established with the mangosd server, but the connection is lost each 10-20 seconds (and reconects instantly). Someone has the same issue runing it with wine?

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.

Oh, I saw the problem too, but I don't have it always.

I send the module from mangosd to wardend and sometimes the BufferedSocket code does not get the packet which is around 20KB in one shot, I get a 34xx size packet then the rest. I don't know how to fix, I will probably have to drop this BufferedSocket code from wardend and use a simpler one.

Edit: Seams that the Socket is still getting data while we already parse the packet. The only difference with previous code is the removal of the DB ping code which added some delay, so I tested a small hack which seams to fix this:

Open src/wardend/main.cpp and go line 238

Replace:

   while (!stopEvent)
   {
       // dont move this outside the loop, the reactor will modify it
       ACE_Time_Value interval(0, 100000);

       if (ACE_Reactor::instance()->run_reactor_event_loop(interval) == -1)
           break;

       if (m_ServiceStatus == 0) stopEvent = true;
       while (m_ServiceStatus == 2) Sleep(1000);
   }

By:

   while (!stopEvent)
   {
       // dont move this outside the loop, the reactor will modify it
       ACE_Time_Value interval(0, 100000);

       if (ACE_Reactor::instance()->run_reactor_event_loop(interval) == -1)
           break;
       // Let time for the socket to get all data
       Sleep(500);
       if (m_ServiceStatus == 0) stopEvent = true;
       while (m_ServiceStatus == 2) Sleep(1000);
   }

Tell me is you face the problem again after adding this small delay.

Neo2003

you need to compile wine with win64 support

No.

Wardend CAN BE ONLY Win32. If you compile it for Winx64 or any other OS (Linux, Mac...). It won't work.

I recall you that Warden modules ARE 32bit PE DLL, so as for all 32bits DLL, you can only load it from a Windows Process which is 32 bits.

I did remove the Linux support on purpose in code because it can only be Win32.

Compile it with VC2005, VC2008 or VC2010, then copy wardend.exe, ACE.dll, tbbmalloc.dll and wardend.conf to a Win32 capable environment (Any Windows or a 32 bits wine or anything that knows how to run a 32bits Windows PE executable.