Date: Sat, 27 Oct 2007 04:21:23 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Matus Harvan <mharvan@inf.ethz.ch> Cc: freebsd-net@freebsd.org, Brooks Davis <brooks@freebsd.org>, Max Laier <max@love2party.net> Subject: Re: UDP catchall Message-ID: <4722AEB3.1010208@FreeBSD.org> In-Reply-To: <20071026154057.GG1049@styx.ethz.ch> References: <20070909201837.GA18107@inf.ethz.ch> <20071026154057.GG1049@styx.ethz.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Matus Harvan wrote: > Hi, > > I was wondering if I could get some feedback about the patch and > whether others think it could be committed. > The UDP catchall patch as submitted here clashes with the blackhole functionality, and also bypasses the update of the protocol statistics and unreachable port rate limiting. It is not yet suitable for a production kernel. It probably shouldn't trigger the log_in_vain message, however that log message is misleading anyway (the reception of UDP datagrams destined for unbound ports is not a 'connection attempt'). I would argue that the UDP and TCP catchall feature should perhaps have a configurable port range as well, under net.inet.ip.portrange.relayhigh/relaylow. This would allow the inpcb code to avoid allocating sockets from that range at all -- as well as allowing inbound packets for that range to be immediately relayed to mtund without the cost of a hash lookup. Whether or not multicasts are O.K. for catchall should also be configurable (bypassing the noportbcast check), however the only way for this to work reliably without running multicast forwarding on the same node is for the mtund to explicitly join multicast groups -- because the code which maps inbound multicasts to sockets has to run further up in another block inside udp_input(). If you needed to intercept multicasts on a multicast router, note that there is an upcall mechanism. This works along similar lines to the RTF_XRESOLVE flag -- the multicast forwarding table is implemented in FreeBSD as a hash-table based cache which does not hold all of the state, and it communicates with userland using custom IGMP messages on a raw socket which never actually appear on the wire in the IGMP protocol. Some implementations of PIM depend on this too. Unfortunately these only go to one socket, ip_mrouter -- however with some code changes you could tell mtund about these IGMP upcalls as well. regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4722AEB3.1010208>