Date: Sun, 23 Aug 2015 17:09:57 +0200 From: Kristof Provost <kp@FreeBSD.org> To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Near-term pf plans Message-ID: <20150823150957.GK48727@vega.codepro.be>
next in thread | raw e-mail | index | archive | help
Hi, Some of you may have noticed that I fixed a couple of pf issues (or in some cases broke things. Sorry Allan.) recently. Here's a quick list of my current priorities: - PR 127042, 202178: This is a panic when an interface an ifgroup have the same name. There's a fix for the immediate problem in https://reviews.freebsd.org/D3435 I'm inclined to say that ifgroups and interfaces should share a namespace. That would certainly help pf, because it uses both interchangeably, which just doesn't work unless they're in the same namespace. That affects more in the network stack though, so I'd like opinions for people with more experience with ifgroups. - PR 202351 This is a panic after ip6 reassembly in pf. We set the rcvif to NULL when refragmenting. That seems to go OK execpt when we're refragmenting broadcast/multicast packets in the forwarding path. It's not at all clear to me how that could happen. - Removal of frag drop / frag crop support in pf. pf has two (or really three, but crop and drop mode are very similar) ways to handle fragmented packets. I've recently extended the 'reassemble' mode to also work for ip6. The crop/drop modes really only verify that fragments make sense (i.e. don't claim to deliver data beyond the last fragment, or duplicate data). I'd like to remove support for the crop/drop modes for two reasons: * the code is relatively large and complex. I've already run into a couple of problems related to it. * It doesn't do what users expect. Enabling scrub fragment crop doesn't actually mean pf will filter on the entire fragment. You still end up having to let all fragments pass through the firewall. There's a patch to do just that here: https://reviews.freebsd.org/D3466 - PR 198868, 193579 (TSO issues) pf has issues on certain network interfaces with TSO enabled. The most important of these are amazon VMs. I believe the problem is that pf tries to work with packets with full checksums. Usually output packets have pseudo-header checksums in the IP and TCP headers. pf doesn't know about those. It always tries to do updates on checksums assuming there's a full checksum. (Which is the case, pf always calculates a full checksum in pf_check_out()) I believe the fix for this issue is to have pf be aware of the pseudo-header checksums. The type of checksum can be determined from the CSUM_TCP and CSUM_TCP_IPV6 flags. Whenever pf changes a packet header it will have to check for those flags to figure out if the checksum should be updated or not. - PR 188511 divert-reply implementation for pf I need to review the use case and implementation of the work done by PiBa.NL.dev@gmail.com - PR 172648 This bug started out with an issue with TCP reassembly, but I've not been able to reproduce that. There is a problem with rdr targets for ipv6 though. With rdr to ::1 we fail the scope check in ip6_input() (right after the pfil hook) because we have a packet to localhost with a m->m_pkthdr.rcvif which is not a loopback interface. That can be fixed by having pf rewrite the rcvif, but that'd special-case rdr to ::1. We've got a similar problem for the reply. There we've got a packet from ::1 to something else. This fails the scope lookup too. In essence the problem is that we've already made the routing decision before pf gets the chance to rewrite the destination address. I'm not quite sure how to fix this though. If anyone has any comments or questions, or disagrees with any of the above, please let me know. If anyone knows of critical problems not on this list please let me know, and I'll see what I can do. Also, pf is currently an (unpaid) side project for me. I'm reasonably limited in the amount of time I can invest in it. Regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150823150957.GK48727>