Date: Mon, 29 Oct 2007 10:04:24 -0500 From: Brooks Davis <brooks@FreeBSD.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: freebsd-net@FreeBSD.org, Matus Harvan <mharvan@inf.ethz.ch>, Max Laier <max@love2party.net> Subject: Re: UDP catchall Message-ID: <20071029150424.GA68594@lor.one-eyed-alien.net> In-Reply-To: <4722AEB3.1010208@FreeBSD.org> References: <20070909201837.GA18107@inf.ethz.ch> <20071026154057.GG1049@styx.ethz.ch> <4722AEB3.1010208@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 27, 2007 at 04:21:23AM +0100, Bruce M. Simpson wrote: > Matus Harvan wrote: > > Hi, > > > > I was wondering if I could get some feedback about the patch and > > whether others think it could be committed. > > =20 >=20 > The UDP catchall patch as submitted here clashes with the blackhole=20 > functionality, and also bypasses the update of the protocol statistics a= nd=20 > unreachable port rate limiting. It is not yet suitable for a production= =20 > kernel. >=20 > It probably shouldn't trigger the log_in_vain message, however that log= =20 > message is misleading anyway (the reception of UDP datagrams destined fo= r=20 > unbound ports is not a 'connection attempt'). >=20 > I would argue that the UDP and TCP catchall feature should perhaps have = a=20 > configurable port range as well, under=20 > net.inet.ip.portrange.relayhigh/relaylow. This would allow the inpcb cod= e to=20 > avoid allocating sockets from that range at all -- as well as allowing= =20 > inbound packets for that range to be immediately relayed to mtund withou= t=20 > the cost of a hash lookup. While I think this idea has some merit, I think we specifically want the current wildcard ability to allow for a system that requires minimal configuration. The problem with a range is that it doesn't allow disjoint sets and it requires that if you really do want all the ports you need to produce a list of currently allocated ports to avoid allocating. A more (over)engineered solution holds some attraction, but I'm not yet convinced the fact that it could exist precludes the current implementation. -- Brooks --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHJfZ3XY6L6fI4GtQRAjRcAJ9PkFzl9krtoFlgTw9wJUm5L0+UEQCgpt1g 9mxaAZuuCItNmZWLG7QeiCY= =lkBT -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071029150424.GA68594>