Date: Thu, 03 May 2001 23:56:06 +0900 From: itojun@iijlab.net To: snap-users@kame.net Cc: Lars Eggert <larse@ISI.EDU>, freebsd-net@freebsd.org, altq@csl.sony.co.jp Subject: Re: (KAME-snap 4636) ALTQ and tunnel devices ... Message-ID: <936.988901766@itojun.org> In-Reply-To: gunther's message of Thu, 03 May 2001 06:46:36 GMT. <3AF0FECC.5A191574@aurora.regenstrief.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>O.K., I have taken the gre-tun.c code and learned how to use the >tun device. Then, I thought, I would simply build an RFC 1933 >IP over IP(v4) tunnel daemon (iptund). This was all very simple >and worked using any kind of protocol, except -- BUMMER -- I >can't open a raw IP socket with the IPPROTO_IPIP (#4). Of course, >as we read in /sys/netinet/ip_encap.c, there are many things that >want to use protocols 4 and 41 and so we need -- again (!) -- >a filter based on src and dst fields, etc. This ip_encap code >acts, once again, like ipfilter, ipfw, the ALTQ classifyer, or >bpf. The only problem with this mechanism is that I can't >seem to find a way to participate in the game from userspace. >So, an IPIP tun daemon doesn't seem possible without hacking >kernel. I really think that IPIP (IP protocol #4 and #41) does not fit well to the manipulation by raw ip sockets. my reasonings: - when a protocol type is handled by the kernel, normally they won't presented to raw ip sockets. (on outbound, you can fabricate ip protocol type by using IP_HDRINCL, but that is an exception) - since IPIP (#4 and #41) are not the final header, the behavior will be ambiguous when there are multiple encapsulations. with the 4.4BSD code, when there's no matching vif tunnels (and gif/ipip), the packet will be presented to raw ip socket. the behavior has been there, and it should still work. i'd suggest you to use bpf for both inbound and outbound instead.... itojun PS: i've committed a change to ecn code. hope the fix corrects the behavior. thanks for reporting. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?936.988901766>