From owner-freebsd-pf@FreeBSD.ORG Mon Aug 15 14:34:54 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F1AE16A41F for ; Mon, 15 Aug 2005 14:34:54 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACA9E43D48 for ; Mon, 15 Aug 2005 14:34:53 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id j7FEYoqB023868 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 15 Aug 2005 16:34:51 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id j7FEYod6011136; Mon, 15 Aug 2005 16:34:50 +0200 (MEST) Date: Mon, 15 Aug 2005 16:34:50 +0200 From: Daniel Hartmeier To: Sergey Lapin Message-ID: <20050815143449.GA32151@insomnia.benzedrine.cx> References: <42FF47A2.1090208@yuckfou.org> <5111186986.20050814210129@hexren.net> <48239d39050815041712bd714c@mail.gmail.com> <48239d39050815042096f9890@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48239d39050815042096f9890@mail.gmail.com> User-Agent: Mutt/1.5.6i Cc: freebsd-pf@freebsd.org Subject: Re: Fwd: Dual-feed: PF setup troubles X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2005 14:34:54 -0000 I suspect the loop occurs through sys/net/if_ethersubr.c ether_output() /* * If a simplex interface, and the packet is being sent to our * Ethernet address or a broadcast address, loopback a copy. * XXX To make a simplex device behave exactly like a duplex * device, we should copy in the case of sending to our own * ethernet address (thus letting the original actually appear * on the wire). However, we don't do that here for security * reasons and compatibility with the original behavior. */ if ((ifp->if_flags & IFF_SIMPLEX) && (loop_copy != -1)) { int csum_flags = 0; if (m->m_pkthdr.csum_flags & CSUM_IP) csum_flags |= (CSUM_IP_CHECKED|CSUM_IP_VALID); if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) csum_flags |= (CSUM_DATA_VALID|CSUM_PSEUDO_HDR); if ((m->m_flags & M_BCAST) || (loop_copy > 0)) { struct mbuf *n; if ((n = m_copy(m, 0, (int)M_COPYALL)) != NULL) { n->m_pkthdr.csum_flags |= csum_flags; if (csum_flags & CSUM_DATA_VALID) n->m_pkthdr.csum_data = 0xffff; (void)if_simloop(ifp, n, dst->sa_family, hlen); } else ifp->if_iqdrops++; } else if (bcmp(eh->ether_dhost, eh->ether_shost, ETHER_ADDR_LEN) == 0) { m->m_pkthdr.csum_flags |= csum_flags; if (csum_flags & CSUM_DATA_VALID) m->m_pkthdr.csum_data = 0xffff; (void) if_simloop(ifp, m, dst->sa_family, hlen); return (0); /* XXX */ } } You route-to the broadcast packet, pf will call ether_output() to send it out through the new interface, and this piece of code in there will send it right back in through that interface again. If your ruleset then routes that resent packet again, you get a tight endless loop, locking up the kernel, like you describe. OpenBSD doesn't have this piece in ether_output(), I'm not sure in what cases people want outgoing broadcasts on an interface reflected back at them by the stack. You can try turning of the IFF_SIMPLEX flag on the interface (unsure about the entire effects of that), or simply exclude those broadcast packets from getting routed by pf (which isn't really intentional, is it?), like - ... from ... to any ... + ... from ... to !255.255.255.255 ... Or find the person familiar/responsible for this loop_copy code, and ask whether we can bypass it, for instance when the PF_ROUTED mbuf tag is present, or such. I'm not entirely sure this is the loop, but you can confirm by adding simple printf()s along that code path, you'll see them printed endlessly when the lockup occurs. Daniel