> it doesn't really matter, it's far easier prevent people from connecting by
> tying up all the free slots (google q3fill).
>
>
>
I already have that patched in my ioquake3-server branch. I actually have 2
things:
1. If a certain server cvar is set, limit the number of "connect" packets
from a si
On 11/10/2010 04:46 AM, Patrick Baggett wrote:
OK so 1024 getchallenge packets every 40 milliseconds. Each getchallenge
packet's payload is about 20 bytes or so. Add the UDP header and that
probably goes up to about 40 bytes (I actually don't know how bit the UDP
headers are off hand, would h
>
> > I have not checked the TCP/IP stack code before, but how does someone
> like
> > BSD handle storing of SYN packets in their network code? I imagine SYN
> > packet is similar to challenge, but I don't know too much about TCP/IP.
>
> The trick is to not store the cookie on the server but rathe
>
>
> OK so 1024 getchallenge packets every 40 milliseconds. Each getchallenge
> packet's payload is about 20 bytes or so. Add the UDP header and that
> probably goes up to about 40 bytes (I actually don't know how bit the UDP
> headers are off hand, would have to read the specs). OK, so I need
Nerius Landys wrote:
> I have not checked the TCP/IP stack code before, but how does someone like
> BSD handle storing of SYN packets in their network code? I imagine SYN
> packet is similar to challenge, but I don't know too much about TCP/IP.
The trick is to not store the cookie on the server b
So after getting more familiar with the getchallenge code in sv_client.c of
ioquake3, I started thinking about how to do a denial of service attack.
Here is the idea.
I send getchallenge UDP packets to an ioquake3 server, where the source
address and port of each packet is spoofed, chosen at rando