Also, if you know the source address, you can filter them using wireshark
to see what they send to you
Den 03/10/2012 01.50 skrev lee bailey lee.bailey@gmail.com:
Just use iptables to block the packet itself.
You can use a sniffer like tcpdump to find the string of the udp packet.
I used a
Each UDP packet has a header and a payload (the data). The header contains
the source port, the destination port, packet's length and a checksum. Linux
automatically drops the packets with invalid length (short packet) or if
checksum validation fails (bad checksum), so you can't block them.
I
See jnettop (add a rule for each server). Also you can use iptables (add a
rule without any target for each server, only to count the number of
received/sent packets and their size).
-Original Message-
From: hlds_linux-boun...@list.valvesoftware.com
On 01/10/2012 20:35, Marco Padovan wrote:
Those changes happens only when running the server as root, if you do
not run it as root those changes fails and the scheduler/priority is not
changed...
Well no, that's not strictly the case. You can allow the changes without
being root
as others
On a clean centos or debian install the server will make use of a better
scheduling algorithm if run as root.
At this point if nothing changes I'm sure we will see many people
running it as root in order to achieve better performance without having
to modify a clean centos /debian install
Il
On 03/10/2012 20:21, Marco Padovan wrote:
On a clean centos or debian install the server will make use of a better
scheduling algorithm if run as root.
At this point if nothing changes I'm sure we will see many people
running it as root in order to achieve better performance without having
to
Sorry, I'm not much interested to discuss with you further about this
whole thing.
I'm just asking to the dev to please take out these lines of codes
making the processes self changing the scheduler and the priorities.
Il 03/10/2012 21:38, dan ha scritto:
On 03/10/2012 20:21, Marco Padovan
If Valve put thread priority changing code, they did it with a specific
purpose in mind.
I'm pretty sure they won't change it because one bad server operator who
runs a poorly configured server is complaining very ineloquently about how
it can mess up an improperly configured system.
On Wed,
Ok, thanks
Il 03/10/2012 22:45, Eli Witt ha scritto:
If Valve put thread priority changing code, they did it with a specific
purpose in mind.
I'm pretty sure they won't change it because one bad server operator who
runs a poorly configured server is complaining very ineloquently about how
I set the cvar to change the replay bot's name, but it still shows up as
replay while in game. I have a plugin that will report name
changes/chat/etc to an IRC channel, and I can see that Replay changes it's
name - but when I join the game and look, I still see replay instead of
the name change.
Where did you set the cvar? It should be in relay.cfg I believe (and that
where I have mine set and working).
On Wed, Oct 3, 2012 at 5:24 PM, doc drga...@gmail.com wrote:
I set the cvar to change the replay bot's name, but it still shows up as
replay while in game. I have a plugin that will
I had it set in server.cfg, just moved it now - will be able to confirm
later today.
I only ask because I -see- the name changing in my IRC relay, Replay
changed it's name to Farts.govorwhatever, but in game no changes occurred.
I will respond later to confirm if this was fixed.
On Wed, Oct 3,
You don't happen to have the sm plugin loaded that changed the replay not name
prior to the cvar? That was resetting mine.
Steven J. Sumichrast
On Oct 3, 2012, at 5:33 PM, doc drga...@gmail.com wrote:
I had it set in server.cfg, just moved it now - will be able to confirm
later today.
I
13 matches
Mail list logo
