Bugzilla Bug 98726

the tcpserver program allows a max number of connections (default 40). It does
not allow for a maximum per ip address. This patch allows for that. Without
this patch, tcpserver is highly suseptable to very basic DOS attacks.

This is for the ucspi-tcp ebuild, tcpserver program.

Created an attachment (id=63193) [details]
The limits patch

This is the limits patch, should work on 64bit machines as well as linux-like
enviroments (mac psx, ect)

ucspi-tcp belongs to base-system

yes, but qmail herd has been taking care of it due to the heavy qmail/ucspi-tcp
integration

I've bumped the package to -r11 and added that patch. For the next time, please
provide one that applies directly and doesn't need rediffing. Can you test it,
please?

No response, closing.

(In reply to comment #5)
> No response, closing.

Gah... got lost in e-mail shuffle, plz re-open and I will test.

I think you should have been able to do that yourself, anyway, reopened.

This patch doesn't work when compiled with ipv6 support. It will only allow
total connections up to MAXCONNIP (or MAXCONNC) since it doesn't copy the
remoteip correctly for ipv6.

Making the patch ipv6-ready should be quite simple.

Created an attachment (id=76896) [details]
ssl patch for limits

Adds ipv6 compatibility to limits patch. Should be applied after limits patch
and of course only if compiled with ipv6.

(From update of attachment 76896 [details])
bugged patch

Created an attachment (id=76956) [details]
ipv6 patch for limits

Adds ipv6 compatibility to limits patch. Should be applied after limits patch
and of course only if compiled with ipv6.

accidentally mixed ipv4 and ipv6 subnet code

Due to an updated ssl patch, the limit patch(es) don't apply anymore. Can you
please submit new patches for ucspi-tcp-0.88-r14?

(In reply to comment #12)
> Due to an updated ssl patch, the limit patch(es) don't apply anymore. Can you
> please submit new patches for ucspi-tcp-0.88-r14?
> 

Supplying new patches shouldn't be a problem but actually your rediffed patch
"ucspi-tcp-0.88-ipv6-ssl-20050405.patch" won't work (and possibly crash).

Snipped:
...
+struct conn {
+  int pid;
+  char remoteip[4];
+} *conns;
...

char[4] for ipv6?

revision 1.2
date: 2006-03-14 20:06:46 +0100;  author: hansmi;  state: Exp;  lines: +8 -2; 
commitid: 15df441714454567;
Disabled the rediffed patch, it's broken. Put an ewarn there instead.

I think that's better, then. Thanks. I currently don't have enough time and
motivation to work this IPv6 stuff out.

Created an attachment (id=96809) [details]
ucspi-tcp-0.88-r16.ebuild

Ok guys.

I've created a new ebuild for ucspi-tcp which includes my new ssl-, ipv6- and
limits-patches. All possible combinations are covered and working (tested on
x86).

Please note that I've removed the limit features (parameter -C and -e) of the
origin ssl patch, since its a feature which is already covered by the limits
patch.

*** Bug 148584 has been marked as a duplicate of this bug. ***

Reopen.

Created an attachment (id=101953) [details]
ucspi-tcp-0.88-r17.ebuild

Found a bug in my rediffed and slightly reorganized limits patch and fixed it.
The bug causes the limits defined in the cdb file not to work. The new ebuild
(r17) already includes the fixed patch.

I work at an ISP were we have implemented this patch and can say that for the
last week it has been running flawlessly.  This type of functionality SHOULD
have been in the package since it's begining.  PLEASE PLEASE make this part of
the standard gentoo ebuild in portgage as others would benefit from this
greatly.  Thank you!

there is also ipsvd, which AFAICT has all of tcpservers functionality, but
without any patching... ymmv

it's not in portage (yet) unfortunately ... see bug #76522

(In reply to comment #20)
afaik ipsvd doesn't support limits based on cpu load

still running flawless now on all filter machines.  Any chance of this making
it into portage? please with sugar on top?

I won't add custom patches to ucspi-tcp anymore. Sorry about that. Please use
UCSPI_TCP_PATCH_DIR.

(In reply to comment #23)
> I won't add custom patches to ucspi-tcp anymore. Sorry about that. Please use
> UCSPI_TCP_PATCH_DIR.
> 

It doesn work, there is some issue with the other patch.
I tried r17, but it cant even download these patchs.

Is there any chance to get working Limit patch in ucspi ?

(In reply to comment #24)
> It doesn work, there is some issue with the other patch.

Please be more specific.

> I tried r17, but it cant even download these patchs.

There's no r17 for ucspi-tcp.

(In reply to comment #25)

> Please be more specific.
http://manuel.mausz.at/programming/patches/ucspi-tcp/ucspi-tcp-ssl-20050405-mm.patch
doesnt exist.

> 
> There's no r17 for ucspi-tcp.
There is r17 patch upthere in this bug report.
I found r18, at Manuel's webpage. i manage to fix download paths in -r18 from
his web page and it compile w/o problem and then it also work. Im testing it on
server which accept approx 4 smtp connections per second.

I will try to create attachment and add it.

Created an attachment (id=108790) [details]
SSL support, Limit support with correct download links

This ebuild has been created by Manuel Mausz, i just found it at his web (lol)
and corrected some download links. It compiled w/o problem on x32 and amd64.
Con. limit and Load limit are both working. However more testers are welcome.
It runs well for several hours on 2 servers (x32 and amd64) with out any
problem.
This also include some ssp support, but it hasnt been tested by me.

(In reply to comment #26)
> There is r17 patch upthere in this bug report.

That doesn't matter, sorry. The only relevant source I'm talking about is the
official portage tree.

> http://manuel.mausz.at/programming/patches/ucspi-tcp/ucspi-tcp-ssl-20050405-mm.patch
> doesnt exist.

In that case, I'd have to bump the old ebuild again. Instead, I'm going to mark
ucspi-tcp-0.88-r16 stable soon™. Can you please try with it?