On 14.11.2016 15:24, Franco Fichtner wrote: > I've opened a review to start removal of if_output from the > pf code with a conservative first batch, which would eventually > enable ipfw and pf redirect packets using the same PACKET_TAG_IPFORWARD > mechanism. It was met with multiple opinions, but no agenda out > of the current situation: > > https://reviews.freebsd.org/D8109 > > Since the discussion went stale, I would like to pose three > questions to a wider audience: > > Is there interest in keeping the netpfil framework consistent > for use with either ipfw or pf? > > Is there interest in keeping the netpfil framework consistent > for use with ipfw and pf running at the same time? > > Is there anyone willing to review and guide work towards > correcting these oddities? Hi, I have some thought related to your proposal. What you think if we will introduce new KPI to work with fwd_tags? With such KPI we can make fwd_tags opaque for PFIL consumers and handle tags identically in all *proto*_output() routines. For first glance I can propose the following: /* ip_var.h */ #define IP_HAS_NEXTHOP(m) ((m)->m_flags & M_IP_NEXTHOP) int ip_set_fwdtag(struct mbuf *m, struct sockaddr_in *dst, u_short ifidx); int ip_get_fwdtag(struct mbuf *m, struct sockaddr_in *dst, u_short *ifidx); void ip_flush_fwdtag(struct mbuf *m); /* ip6_var.h */ #define IP6_HAS_NEXTHOP(m) ((m)->m_flags & M_IP6_NEXTHOP) int ip6_set_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, u_short ifidx); int ip6_get_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, u_short *ifidx); void ip6_flush_fwdtag(struct mbuf *m); Since I'm not quite aware how PF handles PACKET_TAG_IPFORWARD tags, you can modify this to fully cover its needs. -- WBR, Andrey V. Elsukov
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:08 UTC