UDP catchall

[Bruce M. Simpson]

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