On Sat, Jul 16, 2011 at 11:04:44PM +0200, Claudio Jeker wrote: > On Sat, Jul 16, 2011 at 05:38:45PM -0300, Christiano F. Haesbaert wrote: > > On Sat, Jul 16, 2011 at 04:42:41PM +0200, Martin Pelikan wrote: > > > 2011/7/16 Christiano F. Haesbaert <haesba...@haesbaert.org>: > > > > H,m, I think it would, since bpf can catch the packet, another possible > > > > option > > > > would be IP_DIVERT to catch the packets and then send it with the raw > > > > socket, > > > > but would still be a little awkward (IMHO). > > > > > > What's awkward about bpf/divert(4)? And how hard is to filter the > > > proper replies from the tunnel traffic? It's I think the cleanest > > > solution above all (and portable at least to freebsd, too). > > > > Nothing awkward about divert(4), I was just thinking, since there's an icmp > > socket, I'd like to use it. divert(4) is a reasonable alternative. > > > > > > These things would be great to be controlled per-rdomain or > > > per-interface, fwiw. Even ip_forwarding could, if it doesn't clash > > > with the RFCs. But I guess it would be hard to implement, since it's > > > highly AF-specific, struct domain has no place for it and there's no > > > tool doing similar things (would be like "route -T1 set -inet > > > reply_to_icmp 1" ?). And forwarding is used all over the code, which > > > makes changes like this bug-prone. > > > > Indeed implying no echo for all interfaces may be a bad thing. > > > > Honestly, if you like playing evil things with packets use the bpf socket. > You can use it to recv and send packets and there is a option to not pass > packets intercepted by the bpf handler to the network stack. We don't need > more buttons for a very uncommon use case. >
Ok, np. -- Christiano Farina HAESBAERT Do NOT send me html mail.
