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.

> The "ndp -i em0 accept_rtadv", if it worked (already taking a look at
> it) is on a similar principle, but having O(supported AFs) separate
> utilities or O(interfaces) sysctls like in linux would be ugly;
> similarly disabling echo replies everywhere looks like an overkill to
> me, since you typically need tunnel fo just few places and not on all
> interfaces at the same time.
> 
> -- 
> Martin Pelikan

-- 
Christiano Farina HAESBAERT
Do NOT send me html mail.

Reply via email to