[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[altq 845] Re: ALTQ and tunnel devices ...
>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
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....
PS: i've committed a change to ecn code. hope the fix corrects the behavior.
thanks for reporting.