From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 06:41:30 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A8CD1065672; Mon, 4 Jun 2012 06:41:30 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id A88B98FC12; Mon, 4 Jun 2012 06:41:29 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q546eNVA050547; Mon, 4 Jun 2012 08:40:23 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) (authenticated bits=0) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q546eJmj050542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jun 2012 08:40:20 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) Date: Mon, 4 Jun 2012 08:40:16 +0200 (CEST) From: Joerg Pulz To: Daniel Hartmeier , =?ISO-8859-15?Q?Ermal_Lu=E7i?= In-Reply-To: Message-ID: References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3469798045-1136351326-1338792020=:89783" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mailhost.frm2.tum.de [129.187.179.12]); Mon, 04 Jun 2012 08:40:20 +0200 (CEST) Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) 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, 04 Jun 2012 06:41:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3469798045-1136351326-1338792020=:89783 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 1 Jun 2012, Ermal Luçi wrote: > On Fri, Jun 1, 2012 at 10:25 AM, Joerg Pulz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On Tue, 29 May 2012, Daniel Hartmeier wrote: >> >>> On Sun, May 27, 2012 at 06:30:09PM +0000, Joerg Pulz wrote: >>> >>>>  i've seen 12 more "pf_route: m0->m_len < sizeof(struct ip)" messages >>>> since the system is running after adding your patch, but no panic. >>>>  Is there another place in the code where i can add an additional check? >>> >>> >>> Yes, the following patch adds more checks to pf. >> >> >> Daniel, >> >> after several days waiting for a panic since i applied your new patch, it >> finally happend last night. >> >> Below is the kgdb(1) output. I tried to print as much as possible to give >> you the most informations. >> >> Hope this helps to find the cuase of the trouble or at least to get a bit >> closer. >> >> #### kgdb.out_len >> pf_test() at pf_test+0x259 >> pf_check_out() at pf_check_out+0x71 >> pfil_run_hooks() at pfil_run_hooks+0x113 >> >> ip_output() at ip_output+0x6de >> ip_forward() at ip_forward+0x19e > > It is quite strange that you do not have a pfil_run_hooks() here as well! > Maybe you are running ipsec, if so i would expect that to show in the trace!? > > Can you describe the setup you have in more detail to understand what > interactions are happening with the stack? Ermal, for detailed information please take a look at PR: kern/168190 Everything is described there. Meanwhile, i got five more panics. Four of them look exactly like the first one: panic: pf_test: 1: m->m_pkthdr.len 176, m->m_len 0 and the last one shows: panic: pf_test: 1: m->m_pkthdr.len 310, m->m_len 0 All panics with "m->m_pkthdr.len 176, m->m_len 0" show "bge0" as ifname, which is the external interface. The last panic with "m->m_pkthdr.len 310, m->m_len 0" shows "bge1" as ifname, which is the internal interface. All dumps look like the first one, only interface counters, addresses (memory and involved src and dst) differ. For the sake of completeness, here is the output of the last dump. Any further ideas? Kind regards Joerg #### kgdb.out_len6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: pf_test: 1: m->m_pkthdr.len 310, m->m_len 0 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x182 pf_test() at pf_test+0x259 pf_check_out() at pf_check_out+0x71 pfil_run_hooks() at pfil_run_hooks+0x113 ip_output() at ip_output+0x6de ip_forward() at ip_forward+0x19e ip_input() at ip_input+0x680 swi_net() at swi_net+0x15a intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xaf fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe - --- trap 0, rip = 0, rsp = 0xffffff8000241d00, rbp = 0 --- KDB: enter: panic Dumping 714 out of 4077 MB:..3%..12%..21%..32%..41%..52%..61%..72%..81%..92% Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /boot/kernel/ipmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipmi.ko #0 doadump (textdump=0) at pcpu.h:224 224 __asm("movq %%gs:0,%0" : "=r" (td)); (kgdb) up 10 #10 0xffffffff80326737 in pf_test (dir=2, ifp=0xfffffe0003002000, m0=0xffffff80002418e8, eh=0x0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:6725 6725 panic("pf_test: 1: m->m_pkthdr.len %d, m->m_len %d", (kgdb) list 6720 goto done; 6721 } 6722 6723 if (m->m_pkthdr.len < sizeof(struct ip) || 6724 m->m_len < sizeof(struct ip)) 6725 panic("pf_test: 1: m->m_pkthdr.len %d, m->m_len %d", 6726 (int)m->m_pkthdr.len, (int)m->m_len); 6727 6728 #ifdef __FreeBSD__ 6729 if (m->m_flags & M_SKIP_FIREWALL) { (kgdb) p *m $1 = {m_hdr = {mh_next = 0xfffffe0005a80800, mh_nextpkt = 0x0, mh_data = 0xfffffe001a8bb174 "E", mh_len = 0, mh_flags = 66, mh_type = 1, pad = "­ÞÞÀ­Þ"}, M_dat = {MH = {MH_pkthdr = {rcvif = 0xfffffe0003001800, header = 0x0, len = 310, flowid = 0, csum_flags = 768, csum_data = 26821, tso_segsz = 0, PH_vt = {vt_vtag = 0, vt_nrecs = 0}, tags = {slh_first = 0xfffffe00058bc580}}, MH_dat = {MH_ext = { ext_buf = 0x3765016c0045
, ext_free = 0x376501360045, ext_arg1 = 0x4e79875d91110437, ext_arg2 = 0x3601004557b3bb81, ext_size = 3584, ref_cnt = 0x240119ac05079b0a, ext_type = -239336701}, MH_databuf = "E\000l\001e7\000\000E\0006\001e7\000\0007\004\021\221]\207yN\201»³WE\000\0016\000\016\000\000\177\001zÜ\n\233\a\005¬\031\001$\003\003¼ñ\000\000\000\000E\000\001\032\f\213\000\000>\021°k¬\031\001$\n\233\a\005\0005öf\001\006«û\200[\201\200\000\001\000\001\000\003\000\006ÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­Þ"}}, M_databuf = "\000\030\000\003\000þÿÿ\000\000\000\000\000\000\000\0006\001\000\000\000\000\000\000\000\003\000\000Åh\000\000\000\000\000\000ÞÀ­Þ\200Å\213\005\000þÿÿE\000l\001e7\000\000E\0006\001e7\000\0007\004\021\221]\207yN\201»³WE\000\0016\000\016\000\000\177\001zÜ\n\233\a\005¬\031\001$\003\003¼ñ\000\000\000\000E\000\001\032\f\213\000\000>\021°k¬\031\001$\n\233\a\005\0005öf\001\006«û\200[\201\200\000\001\000\001\000\003\000\006ÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­Þ"...}} (kgdb) p *ifp $2 = {if_softc = 0xffffff80007b1000, if_l2com = 0xfffffe000300ba40, if_vnet = 0x0, if_link = {tqe_next = 0xfffffe0003001000, tqe_prev = 0xfffffe0003001818}, if_xname = "bge1", '\0' , if_dname = 0xfffffe00028f0758 "bge", if_dunit = 1, if_refcount = 1, if_addrhead = {tqh_first = 0xfffffe0003009800, tqh_last = 0xfffffe00059236b8}, if_pcount = 0, if_carp = 0x0, if_bpf = 0xfffffe00050a4880, if_index = 6, if_index_reserved = 0, if_vlantrunk = 0x0, if_flags = 34819, if_capabilities = 524443, if_capenable = 524443, if_linkmib = 0x0, if_linkmiblen = 0, if_data = { ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006', ifi_hdrlen = 18 '\022', ifi_link_state = 2 '\002', ifi_spare_char1 = 0 '\0', ifi_spare_char2 = 0 '\0', ifi_datalen = 152 '\230', ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 1000000000, ifi_ipackets = 354876, ifi_ierrors = 0, ifi_opackets = 141821, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 106681967, ifi_obytes = 12317395, ifi_imcasts = 169195, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 3, ifi_epoch = 1, ifi_lastchange = {tv_sec = 1338708223, tv_usec = 13051}}, if_multiaddrs = {tqh_first = 0xfffffe0005926b40, tqh_last = 0xfffffe00058b8d00}, if_amcount = 0, if_output = 0xffffffff8073d2f5 , if_input = 0xffffffff8073c8cb , if_start = 0xffffffff803c2b67 , if_ioctl = 0xffffffff803c8d9a , if_init = 0xffffffff803c8d54 , if_resolvemulti = 0xffffffff8073c28d , if_qflush = 0xffffffff807350b2 , if_transmit = 0xffffffff80734f7e , if_reassign = 0, if_home_vnet = 0x0, if_addr = 0xfffffe0003009800, if_llsoftc = 0x0, if_drv_flags = 64, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 511, ifq_drops = 0, ifq_mtx = {lock_object = { lo_name = 0xfffffe0003002028 "bge1", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006cf480}, mtx_lock = 4}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 511, altq_type = 0, altq_flags = 1, altq_disc = 0x0, altq_ifp = 0xfffffe0003002000, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0xffffffff80ad06c0 "ÿÿÿÿÿÿ", if_bridge = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xfffffe0003002278}, if_afdata = {0x0, 0x0, 0xfffffe0005821a00, 0x0 , 0xfffffe0005815880, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_afdata_initialized = 2, if_afdata_lock = { lock_object = {lo_name = 0xffffffff80acf95a "if_afdata", lo_flags = 69402624, lo_data = 0, lo_witness = 0xffffff80006cf400}, rw_lock = 1}, if_linktask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff80737559 , ta_context = 0xfffffe0003002000}, if_addr_mtx = {lock_object = { lo_name = 0xffffffff80ac1a20 "if_addr_mtx", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006c8b80}, mtx_lock = 4}, if_clones = {le_next = 0x0, le_prev = 0x0}, if_groups = { tqh_first = 0xfffffe0005065ae0, tqh_last = 0xfffffe0005065ae8}, if_pf_kif = 0xfffffe0005888300, if_lagg = 0x0, if_description = 0x0, if_fib = 0, if_alloctype = 6 '\006', if_cspare = "\000\000", if_ispare = {0, 0, 0, 0}, if_pspare = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} (kgdb) p pd $3 = {lookup = {done = 0, uid = 0, gid = 0, pid = 0}, tot_len = 0, hdr = { tcp = 0x0, udp = 0x0, icmp = 0x0, icmp6 = 0x0, any = 0x0}, nat_rule = 0x0, eh = 0x0, src = 0x0, dst = 0x0, sport = 0x0, dport = 0x0, pf_mtag = 0xfffffe001a43dbd8, p_len = 0, ip_sum = 0x0, proto_sum = 0x0, flags = 0, af = 0 '\0', proto = 0 '\0', tos = 0 '\0', dir = 0 '\0', sidx = 0 '\0', didx = 0 '\0'} (kgdb) p pf_status $4 = {counters = {634320, 0, 0, 0, 0, 0, 0, 0, 320, 0, 6, 0, 0, 0, 0}, lcounters = {0, 0, 0, 0, 0, 0, 0}, fcounters = {719058, 4120, 4008}, scounters = {0, 0, 0}, pcounters = {{{0, 0, 0}, {0, 0, 0}}, {{0, 0, 0}, {0, 0, 0}}}, bcounters = {{0, 0}, {0, 0}}, stateid = 5749708040966246424, running = 1, states = 112, src_nodes = 0, since = 1338708224, debug = 1, hostid = 4123334744, ifname = '\0' , pf_chksum = "quÎ\205<0­ hº\021»¾vi\203"} (kgdb) p pf_status.running $5 = 1 (kgdb) up #11 0xffffffff8032cc7b in pf_check_out (arg=) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:4184 4184 chk = pf_test(PF_OUT, ifp, m, NULL, inp); (kgdb) list 4179 h = mtod(*m, struct ip *); 4180 HTONS(h->ip_len); 4181 HTONS(h->ip_off); 4182 } 4183 CURVNET_SET(ifp->if_vnet); 4184 chk = pf_test(PF_OUT, ifp, m, NULL, inp); 4185 CURVNET_RESTORE(); 4186 if (chk && *m) { 4187 m_freem(*m); 4188 *m = NULL; (kgdb) up #12 0xffffffff8074adcf in pfil_run_hooks (ph=) at /usr/src/sys/net/pfil.c:89 89 rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, ifp, dir, (kgdb) list 84 KASSERT(ph->ph_nhooks >= 0, ("Pfil hook count dropped < 0")); 85 for (pfh = pfil_hook_get(dir, ph); pfh != NULL; 86 pfh = TAILQ_NEXT(pfh, pfil_link)) { 87 if (pfh->pfil_func != NULL) { 88 ASSERT_HOST_BYTE_ORDER(m); 89 rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, ifp, dir, 90 inp); 91 if (rv != 0 || m == NULL) 92 break; 93 ASSERT_HOST_BYTE_ORDER(m); (kgdb) p *pfh $6 = {pfil_link = {tqe_next = 0x0, tqe_prev = 0xfffffe0005821b00}, pfil_func = 0xffffffff8032cc0a , pfil_arg = 0x0} (kgdb) up #13 0xffffffff80776b3a in ip_output (m=0xfffffe001a8bb100, opt=) at /usr/src/sys/netinet/ip_output.c:512 512 error = pfil_run_hooks(&V_inet_pfil_hook, &m, ifp, PFIL_OUT, inp); (kgdb) list 507 goto passout; 508 509 /* Run through list of hooks for output packets. */ 510 odst.s_addr = ip->ip_dst.s_addr; 511 ASSERT_HOST_BYTE_ORDER(m); 512 error = pfil_run_hooks(&V_inet_pfil_hook, &m, ifp, PFIL_OUT, inp); 513 if (error != 0 || m == NULL) 514 goto done; 515 516 ip = mtod(m, struct ip *); (kgdb) p *ip $7 = {ip_hl = 5 '\005', ip_v = 4 '\004', ip_tos = 0 '\0', ip_len = 13825, ip_id = 3584, ip_off = 0, ip_ttl = 127 '\177', ip_p = 1 '\001', ip_sum = 56442, ip_src = {s_addr = 84384522}, ip_dst = {s_addr = 604051884}} (kgdb) p flags $8 = 1 (kgdb) p mtu $9 = 1500 (kgdb) p *ia $10 = {ia_ifa = {ifa_addr = 0xfffffe000592f338, ifa_dstaddr = 0xfffffe000592f348, ifa_netmask = 0xfffffe000592f358, if_data = {ifi_type = 0 '\0', ifi_physical = 0 '\0', ifi_addrlen = 0 '\0', ifi_hdrlen = 0 '\0', ifi_link_state = 0 '\0', ifi_spare_char1 = 0 '\0', ifi_spare_char2 = 0 '\0', ifi_datalen = 0 '\0', ifi_mtu = 0, ifi_metric = 0, ifi_baudrate = 0, ifi_ipackets = 6077, ifi_ierrors = 0, ifi_opackets = 2883, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 823732, ifi_obytes = 309266, ifi_imcasts = 0, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 0, ifi_lastchange = {tv_sec = 0, tv_usec = 0}}, ifa_ifp = 0xfffffe0003002000, ifa_link = {tqe_next = 0xfffffe0005923600, tqe_prev = 0xfffffe00030098b8}, ifa_rtrequest = 0, ifa_flags = 5, ifa_refcnt = 7, ifa_metric = 0, ifa_claim_addr = 0, ifa_mtx = { lock_object = {lo_name = 0xffffffff80ad4634 "ifaddr", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006c8980}, mtx_lock = 4}}, ia_subnet = 2887319808, ia_subnetmask = 4294967040, ia_hash = {le_next = 0x0, le_prev = 0xfffffe000587ff70}, ia_link = { tqe_next = 0x0, tqe_prev = 0xfffffe00058e1d28}, ia_addr = { sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, sin_addr = { s_addr = 2533431724}, sin_zero = "\000\000\000\000\000\000\000"}, ia_dstaddr = {sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, sin_addr = {s_addr = 4278262188}, sin_zero = "\000\000\000\000\000\000\000"}, ia_sockmask = { sin_len = 7 '\a', sin_family = 2 '\002', sin_port = 0, sin_addr = { s_addr = 16777215}, sin_zero = "\000\000\000\000\000\000\000"}} (kgdb) p *dst $11 = {sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, sin_addr = { s_addr = 604051884}, sin_zero = "\000\000\000\000\000\000\000"} (kgdb) #### kgdb.out_len6 - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzFhTSPOsGF+KA+MRAtVJAJ4oHrqC8Y4O0q0vHjgnhJ7wrVlE7ACfSkc0 6juyQmrvcT+m74JdfH30tlE= =ayEo -----END PGP SIGNATURE----- --3469798045-1136351326-1338792020=:89783-- From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 06:50:13 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BA82106566B for ; Mon, 4 Jun 2012 06:50:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 050978FC16 for ; Mon, 4 Jun 2012 06:50:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q546oCP2096949 for ; Mon, 4 Jun 2012 06:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q546oCNZ096948; Mon, 4 Jun 2012 06:50:12 GMT (envelope-from gnats) Date: Mon, 4 Jun 2012 06:50:12 GMT Message-Id: <201206040650.q546oCNZ096948@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Joerg Pulz Cc: Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Pulz 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, 04 Jun 2012 06:50:13 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Joerg Pulz To: Daniel Hartmeier , =?ISO-8859-15?Q?Ermal_Lu=E7i?= Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Mon, 4 Jun 2012 08:40:16 +0200 (CEST) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3469798045-1136351326-1338792020=:89783 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 1 Jun 2012, Ermal Luçi wrote: > On Fri, Jun 1, 2012 at 10:25 AM, Joerg Pulz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On Tue, 29 May 2012, Daniel Hartmeier wrote: >> >>> On Sun, May 27, 2012 at 06:30:09PM +0000, Joerg Pulz wrote: >>> >>>>  i've seen 12 more "pf_route: m0->m_len < sizeof(struct ip)" messages >>>> since the system is running after adding your patch, but no panic. >>>>  Is there another place in the code where i can add an additional check? >>> >>> >>> Yes, the following patch adds more checks to pf. >> >> >> Daniel, >> >> after several days waiting for a panic since i applied your new patch, it >> finally happend last night. >> >> Below is the kgdb(1) output. I tried to print as much as possible to give >> you the most informations. >> >> Hope this helps to find the cuase of the trouble or at least to get a bit >> closer. >> >> #### kgdb.out_len >> pf_test() at pf_test+0x259 >> pf_check_out() at pf_check_out+0x71 >> pfil_run_hooks() at pfil_run_hooks+0x113 >> >> ip_output() at ip_output+0x6de >> ip_forward() at ip_forward+0x19e > > It is quite strange that you do not have a pfil_run_hooks() here as well! > Maybe you are running ipsec, if so i would expect that to show in the trace!? > > Can you describe the setup you have in more detail to understand what > interactions are happening with the stack? Ermal, for detailed information please take a look at PR: kern/168190 Everything is described there. Meanwhile, i got five more panics. Four of them look exactly like the first one: panic: pf_test: 1: m->m_pkthdr.len 176, m->m_len 0 and the last one shows: panic: pf_test: 1: m->m_pkthdr.len 310, m->m_len 0 All panics with "m->m_pkthdr.len 176, m->m_len 0" show "bge0" as ifname, which is the external interface. The last panic with "m->m_pkthdr.len 310, m->m_len 0" shows "bge1" as ifname, which is the internal interface. All dumps look like the first one, only interface counters, addresses (memory and involved src and dst) differ. For the sake of completeness, here is the output of the last dump. Any further ideas? Kind regards Joerg #### kgdb.out_len6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: pf_test: 1: m->m_pkthdr.len 310, m->m_len 0 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x182 pf_test() at pf_test+0x259 pf_check_out() at pf_check_out+0x71 pfil_run_hooks() at pfil_run_hooks+0x113 ip_output() at ip_output+0x6de ip_forward() at ip_forward+0x19e ip_input() at ip_input+0x680 swi_net() at swi_net+0x15a intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xaf fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe - --- trap 0, rip = 0, rsp = 0xffffff8000241d00, rbp = 0 --- KDB: enter: panic Dumping 714 out of 4077 MB:..3%..12%..21%..32%..41%..52%..61%..72%..81%..92% Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /boot/kernel/ipmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipmi.ko #0 doadump (textdump=0) at pcpu.h:224 224 __asm("movq %%gs:0,%0" : "=r" (td)); (kgdb) up 10 #10 0xffffffff80326737 in pf_test (dir=2, ifp=0xfffffe0003002000, m0=0xffffff80002418e8, eh=0x0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:6725 6725 panic("pf_test: 1: m->m_pkthdr.len %d, m->m_len %d", (kgdb) list 6720 goto done; 6721 } 6722 6723 if (m->m_pkthdr.len < sizeof(struct ip) || 6724 m->m_len < sizeof(struct ip)) 6725 panic("pf_test: 1: m->m_pkthdr.len %d, m->m_len %d", 6726 (int)m->m_pkthdr.len, (int)m->m_len); 6727 6728 #ifdef __FreeBSD__ 6729 if (m->m_flags & M_SKIP_FIREWALL) { (kgdb) p *m $1 = {m_hdr = {mh_next = 0xfffffe0005a80800, mh_nextpkt = 0x0, mh_data = 0xfffffe001a8bb174 "E", mh_len = 0, mh_flags = 66, mh_type = 1, pad = "­ÞÞÀ­Þ"}, M_dat = {MH = {MH_pkthdr = {rcvif = 0xfffffe0003001800, header = 0x0, len = 310, flowid = 0, csum_flags = 768, csum_data = 26821, tso_segsz = 0, PH_vt = {vt_vtag = 0, vt_nrecs = 0}, tags = {slh_first = 0xfffffe00058bc580}}, MH_dat = {MH_ext = { ext_buf = 0x3765016c0045
, ext_free = 0x376501360045, ext_arg1 = 0x4e79875d91110437, ext_arg2 = 0x3601004557b3bb81, ext_size = 3584, ref_cnt = 0x240119ac05079b0a, ext_type = -239336701}, MH_databuf = "E\000l\001e7\000\000E\0006\001e7\000\0007\004\021\221]\207yN\201»³WE\000\0016\000\016\000\000\177\001zÃœ\n\233\a\005¬\031\001$\003\003¼ñ\000\000\000\000E\000\001\032\f\213\000\000>\021°k¬\031\001$\n\233\a\005\0005öf\001\006«û\200[\201\200\000\001\000\001\000\003\000\006ÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­Þ"}}, M_databuf = "\000\030\000\003\000þÿÿ\000\000\000\000\000\000\000\0006\001\000\000\000\000\000\000\000\003\000\000Ã…h\000\000\000\000\000\000ÞÀ­Þ\200Ã…\213\005\000þÿÿE\000l\001e7\000\000E\0006\001e7\000\0007\004\021\221]\207yN\201»³WE\000\0016\000\016\000\000\177\001zÃœ\n\233\a\005¬\031\001$\003\003¼ñ\000\000\000\000E\000\001\032\f\213\000\000>\021°k¬\031\001$\n\233\a\005\0005öf\001\006«û\200[\201\200\000\001\000\001\000\003\000\006ÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞà €Â­ÃžÃžÃ€Â­ÃžÃžÃ€Â­ÃžÃžÃ€Â­ÃžÃžÃ€Â­ÃžÃžÃ€Â­ÃžÃžÃ€Â­ÃžÃžÃ€Â­Ãž"...}} (kgdb) p *ifp $2 = {if_softc = 0xffffff80007b1000, if_l2com = 0xfffffe000300ba40, if_vnet = 0x0, if_link = {tqe_next = 0xfffffe0003001000, tqe_prev = 0xfffffe0003001818}, if_xname = "bge1", '\0' , if_dname = 0xfffffe00028f0758 "bge", if_dunit = 1, if_refcount = 1, if_addrhead = {tqh_first = 0xfffffe0003009800, tqh_last = 0xfffffe00059236b8}, if_pcount = 0, if_carp = 0x0, if_bpf = 0xfffffe00050a4880, if_index = 6, if_index_reserved = 0, if_vlantrunk = 0x0, if_flags = 34819, if_capabilities = 524443, if_capenable = 524443, if_linkmib = 0x0, if_linkmiblen = 0, if_data = { ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006', ifi_hdrlen = 18 '\022', ifi_link_state = 2 '\002', ifi_spare_char1 = 0 '\0', ifi_spare_char2 = 0 '\0', ifi_datalen = 152 '\230', ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 1000000000, ifi_ipackets = 354876, ifi_ierrors = 0, ifi_opackets = 141821, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 106681967, ifi_obytes = 12317395, ifi_imcasts = 169195, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 3, ifi_epoch = 1, ifi_lastchange = {tv_sec = 1338708223, tv_usec = 13051}}, if_multiaddrs = {tqh_first = 0xfffffe0005926b40, tqh_last = 0xfffffe00058b8d00}, if_amcount = 0, if_output = 0xffffffff8073d2f5 , if_input = 0xffffffff8073c8cb , if_start = 0xffffffff803c2b67 , if_ioctl = 0xffffffff803c8d9a , if_init = 0xffffffff803c8d54 , if_resolvemulti = 0xffffffff8073c28d , if_qflush = 0xffffffff807350b2 , if_transmit = 0xffffffff80734f7e , if_reassign = 0, if_home_vnet = 0x0, if_addr = 0xfffffe0003009800, if_llsoftc = 0x0, if_drv_flags = 64, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 511, ifq_drops = 0, ifq_mtx = {lock_object = { lo_name = 0xfffffe0003002028 "bge1", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006cf480}, mtx_lock = 4}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 511, altq_type = 0, altq_flags = 1, altq_disc = 0x0, altq_ifp = 0xfffffe0003002000, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0xffffffff80ad06c0 "ÿÿÿÿÿÿ", if_bridge = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xfffffe0003002278}, if_afdata = {0x0, 0x0, 0xfffffe0005821a00, 0x0 , 0xfffffe0005815880, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_afdata_initialized = 2, if_afdata_lock = { lock_object = {lo_name = 0xffffffff80acf95a "if_afdata", lo_flags = 69402624, lo_data = 0, lo_witness = 0xffffff80006cf400}, rw_lock = 1}, if_linktask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff80737559 , ta_context = 0xfffffe0003002000}, if_addr_mtx = {lock_object = { lo_name = 0xffffffff80ac1a20 "if_addr_mtx", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006c8b80}, mtx_lock = 4}, if_clones = {le_next = 0x0, le_prev = 0x0}, if_groups = { tqh_first = 0xfffffe0005065ae0, tqh_last = 0xfffffe0005065ae8}, if_pf_kif = 0xfffffe0005888300, if_lagg = 0x0, if_description = 0x0, if_fib = 0, if_alloctype = 6 '\006', if_cspare = "\000\000", if_ispare = {0, 0, 0, 0}, if_pspare = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} (kgdb) p pd $3 = {lookup = {done = 0, uid = 0, gid = 0, pid = 0}, tot_len = 0, hdr = { tcp = 0x0, udp = 0x0, icmp = 0x0, icmp6 = 0x0, any = 0x0}, nat_rule = 0x0, eh = 0x0, src = 0x0, dst = 0x0, sport = 0x0, dport = 0x0, pf_mtag = 0xfffffe001a43dbd8, p_len = 0, ip_sum = 0x0, proto_sum = 0x0, flags = 0, af = 0 '\0', proto = 0 '\0', tos = 0 '\0', dir = 0 '\0', sidx = 0 '\0', didx = 0 '\0'} (kgdb) p pf_status $4 = {counters = {634320, 0, 0, 0, 0, 0, 0, 0, 320, 0, 6, 0, 0, 0, 0}, lcounters = {0, 0, 0, 0, 0, 0, 0}, fcounters = {719058, 4120, 4008}, scounters = {0, 0, 0}, pcounters = {{{0, 0, 0}, {0, 0, 0}}, {{0, 0, 0}, {0, 0, 0}}}, bcounters = {{0, 0}, {0, 0}}, stateid = 5749708040966246424, running = 1, states = 112, src_nodes = 0, since = 1338708224, debug = 1, hostid = 4123334744, ifname = '\0' , pf_chksum = "quÃŽ\205<0­ hº\021»¾vi\203"} (kgdb) p pf_status.running $5 = 1 (kgdb) up #11 0xffffffff8032cc7b in pf_check_out (arg=) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:4184 4184 chk = pf_test(PF_OUT, ifp, m, NULL, inp); (kgdb) list 4179 h = mtod(*m, struct ip *); 4180 HTONS(h->ip_len); 4181 HTONS(h->ip_off); 4182 } 4183 CURVNET_SET(ifp->if_vnet); 4184 chk = pf_test(PF_OUT, ifp, m, NULL, inp); 4185 CURVNET_RESTORE(); 4186 if (chk && *m) { 4187 m_freem(*m); 4188 *m = NULL; (kgdb) up #12 0xffffffff8074adcf in pfil_run_hooks (ph=) at /usr/src/sys/net/pfil.c:89 89 rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, ifp, dir, (kgdb) list 84 KASSERT(ph->ph_nhooks >= 0, ("Pfil hook count dropped < 0")); 85 for (pfh = pfil_hook_get(dir, ph); pfh != NULL; 86 pfh = TAILQ_NEXT(pfh, pfil_link)) { 87 if (pfh->pfil_func != NULL) { 88 ASSERT_HOST_BYTE_ORDER(m); 89 rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, ifp, dir, 90 inp); 91 if (rv != 0 || m == NULL) 92 break; 93 ASSERT_HOST_BYTE_ORDER(m); (kgdb) p *pfh $6 = {pfil_link = {tqe_next = 0x0, tqe_prev = 0xfffffe0005821b00}, pfil_func = 0xffffffff8032cc0a , pfil_arg = 0x0} (kgdb) up #13 0xffffffff80776b3a in ip_output (m=0xfffffe001a8bb100, opt=) at /usr/src/sys/netinet/ip_output.c:512 512 error = pfil_run_hooks(&V_inet_pfil_hook, &m, ifp, PFIL_OUT, inp); (kgdb) list 507 goto passout; 508 509 /* Run through list of hooks for output packets. */ 510 odst.s_addr = ip->ip_dst.s_addr; 511 ASSERT_HOST_BYTE_ORDER(m); 512 error = pfil_run_hooks(&V_inet_pfil_hook, &m, ifp, PFIL_OUT, inp); 513 if (error != 0 || m == NULL) 514 goto done; 515 516 ip = mtod(m, struct ip *); (kgdb) p *ip $7 = {ip_hl = 5 '\005', ip_v = 4 '\004', ip_tos = 0 '\0', ip_len = 13825, ip_id = 3584, ip_off = 0, ip_ttl = 127 '\177', ip_p = 1 '\001', ip_sum = 56442, ip_src = {s_addr = 84384522}, ip_dst = {s_addr = 604051884}} (kgdb) p flags $8 = 1 (kgdb) p mtu $9 = 1500 (kgdb) p *ia $10 = {ia_ifa = {ifa_addr = 0xfffffe000592f338, ifa_dstaddr = 0xfffffe000592f348, ifa_netmask = 0xfffffe000592f358, if_data = {ifi_type = 0 '\0', ifi_physical = 0 '\0', ifi_addrlen = 0 '\0', ifi_hdrlen = 0 '\0', ifi_link_state = 0 '\0', ifi_spare_char1 = 0 '\0', ifi_spare_char2 = 0 '\0', ifi_datalen = 0 '\0', ifi_mtu = 0, ifi_metric = 0, ifi_baudrate = 0, ifi_ipackets = 6077, ifi_ierrors = 0, ifi_opackets = 2883, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 823732, ifi_obytes = 309266, ifi_imcasts = 0, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 0, ifi_lastchange = {tv_sec = 0, tv_usec = 0}}, ifa_ifp = 0xfffffe0003002000, ifa_link = {tqe_next = 0xfffffe0005923600, tqe_prev = 0xfffffe00030098b8}, ifa_rtrequest = 0, ifa_flags = 5, ifa_refcnt = 7, ifa_metric = 0, ifa_claim_addr = 0, ifa_mtx = { lock_object = {lo_name = 0xffffffff80ad4634 "ifaddr", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006c8980}, mtx_lock = 4}}, ia_subnet = 2887319808, ia_subnetmask = 4294967040, ia_hash = {le_next = 0x0, le_prev = 0xfffffe000587ff70}, ia_link = { tqe_next = 0x0, tqe_prev = 0xfffffe00058e1d28}, ia_addr = { sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, sin_addr = { s_addr = 2533431724}, sin_zero = "\000\000\000\000\000\000\000"}, ia_dstaddr = {sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, sin_addr = {s_addr = 4278262188}, sin_zero = "\000\000\000\000\000\000\000"}, ia_sockmask = { sin_len = 7 '\a', sin_family = 2 '\002', sin_port = 0, sin_addr = { s_addr = 16777215}, sin_zero = "\000\000\000\000\000\000\000"}} (kgdb) p *dst $11 = {sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, sin_addr = { s_addr = 604051884}, sin_zero = "\000\000\000\000\000\000\000"} (kgdb) #### kgdb.out_len6 - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzFhTSPOsGF+KA+MRAtVJAJ4oHrqC8Y4O0q0vHjgnhJ7wrVlE7ACfSkc0 6juyQmrvcT+m74JdfH30tlE= =ayEo -----END PGP SIGNATURE----- --3469798045-1136351326-1338792020=:89783-- From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 06:53:54 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 040001065670; Mon, 4 Jun 2012 06:53:54 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBD08FC15; Mon, 4 Jun 2012 06:53:52 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q546riQu014439 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 08:53:44 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q546riHY015404; Mon, 4 Jun 2012 08:53:44 +0200 (MEST) Date: Mon, 4 Jun 2012 08:53:44 +0200 From: Daniel Hartmeier To: Joerg Pulz Message-ID: <20120604065344.GA13069@insomnia.benzedrine.cx> References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) 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, 04 Jun 2012 06:53:54 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 01, 2012 at 10:25:39AM +0200, Joerg Pulz wrote: > panic: pf_test: 1: m->m_pkthdr.len 176, m->m_len 0 > pf_test() at pf_test+0x259 > pf_check_out() at pf_check_out+0x71 > pfil_run_hooks() at pfil_run_hooks+0x113 > ip_output() at ip_output+0x6de > ip_forward() at ip_forward+0x19e > ip_input() at ip_input+0x680 > swi_net() at swi_net+0x15a The interesting part is in pfil_rule_hooks: > #12 0xffffffff8074adcf in pfil_run_hooks (ph=) at /usr/src/sys/net/pfil.c:89 > 89 rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, > ifp, dir, > (kgdb) p *pfh > $6 = {pfil_link = {tqe_next = 0x0, tqe_prev = 0xfffffe0005821b00}, > pfil_func = 0xffffffff8032cc0a , pfil_arg = 0x0} There is a check on entry, which didn't trigger, so the mbuf was fine when the function was called. We're in the second pass of the loop, there seem to be (at least) two registered hooks, with pf being called second. What is the first one? You disabled ipfw, so my guess is ipfilter is first. Can you try to print *tqe_prev in the pfil_run_hooks frame? Now, the question is whether the first hook modifies the mbuf, or if it's pf on the way seen in your stack trace. I added further checks (before and after each hook), see the updated patch of pfil.c below. You could also disable ipfilter (so the module isn't loaded at all, and no pfil hook is registered). I'm reading more mbuf functions to find out what might leave the first chunk of an mbuf with m_len 0 (possibly some m_adj() call?), and from where it might be called. Kind regards, Daniel --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pfil.diff" Index: sys/net/pfil.c =================================================================== RCS file: /home/ncvs/src/sys/net/pfil.c,v retrieving revision 1.19.2.1 diff -u -r1.19.2.1 pfil.c --- sys/net/pfil.c 23 Sep 2011 00:51:37 -0000 1.19.2.1 +++ sys/net/pfil.c 4 Jun 2012 06:39:46 -0000 @@ -46,6 +46,8 @@ #include #include +#include +#include static struct mtx pfil_global_lock; @@ -74,15 +76,31 @@ struct mbuf *m = *mp; int rv = 0; + if (m->m_pkthdr.len < sizeof(struct ip) || + m->m_len < sizeof(struct ip)) + panic("pfil_run_hooks: 1: m->m_pkthdr.len %d, m->m_len %d", + (int)m->m_pkthdr.len, (int)m->m_len); PFIL_RLOCK(ph, &rmpt); KASSERT(ph->ph_nhooks >= 0, ("Pfil hook count dropped < 0")); for (pfh = pfil_hook_get(dir, ph); pfh != NULL; pfh = TAILQ_NEXT(pfh, pfil_link)) { if (pfh->pfil_func != NULL) { + ASSERT_HOST_BYTE_ORDER(m); + if (m->m_pkthdr.len < sizeof(struct ip) || + m->m_len < sizeof(struct ip)) + panic("pfil_run_hooks: 2: m->m_pkthdr.len %d, " + "m->m_len %d", (int)m->m_pkthdr.len, + (int)m->m_len); rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, ifp, dir, inp); if (rv != 0 || m == NULL) break; + ASSERT_HOST_BYTE_ORDER(m); + if (m->m_pkthdr.len < sizeof(struct ip) || + m->m_len < sizeof(struct ip)) + panic("pfil_run_hooks: 3: m->m_pkthdr.len %d, " + "m->m_len %d", (int)m->m_pkthdr.len, + (int)m->m_len); } } PFIL_RUNLOCK(ph, &rmpt); --8t9RHnE3ZwKMSgU+-- From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 07:00:25 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B375D1065673 for ; Mon, 4 Jun 2012 07:00:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 90DDC8FC08 for ; Mon, 4 Jun 2012 07:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5470Pd6015019 for ; Mon, 4 Jun 2012 07:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5470PEw015018; Mon, 4 Jun 2012 07:00:25 GMT (envelope-from gnats) Date: Mon, 4 Jun 2012 07:00:25 GMT Message-Id: <201206040700.q5470PEw015018@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Daniel Hartmeier Cc: Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Hartmeier 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, 04 Jun 2012 07:00:25 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Daniel Hartmeier To: Joerg Pulz Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Mon, 4 Jun 2012 08:53:44 +0200 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 01, 2012 at 10:25:39AM +0200, Joerg Pulz wrote: > panic: pf_test: 1: m->m_pkthdr.len 176, m->m_len 0 > pf_test() at pf_test+0x259 > pf_check_out() at pf_check_out+0x71 > pfil_run_hooks() at pfil_run_hooks+0x113 > ip_output() at ip_output+0x6de > ip_forward() at ip_forward+0x19e > ip_input() at ip_input+0x680 > swi_net() at swi_net+0x15a The interesting part is in pfil_rule_hooks: > #12 0xffffffff8074adcf in pfil_run_hooks (ph=) at /usr/src/sys/net/pfil.c:89 > 89 rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, > ifp, dir, > (kgdb) p *pfh > $6 = {pfil_link = {tqe_next = 0x0, tqe_prev = 0xfffffe0005821b00}, > pfil_func = 0xffffffff8032cc0a , pfil_arg = 0x0} There is a check on entry, which didn't trigger, so the mbuf was fine when the function was called. We're in the second pass of the loop, there seem to be (at least) two registered hooks, with pf being called second. What is the first one? You disabled ipfw, so my guess is ipfilter is first. Can you try to print *tqe_prev in the pfil_run_hooks frame? Now, the question is whether the first hook modifies the mbuf, or if it's pf on the way seen in your stack trace. I added further checks (before and after each hook), see the updated patch of pfil.c below. You could also disable ipfilter (so the module isn't loaded at all, and no pfil hook is registered). I'm reading more mbuf functions to find out what might leave the first chunk of an mbuf with m_len 0 (possibly some m_adj() call?), and from where it might be called. Kind regards, Daniel --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pfil.diff" Index: sys/net/pfil.c =================================================================== RCS file: /home/ncvs/src/sys/net/pfil.c,v retrieving revision 1.19.2.1 diff -u -r1.19.2.1 pfil.c --- sys/net/pfil.c 23 Sep 2011 00:51:37 -0000 1.19.2.1 +++ sys/net/pfil.c 4 Jun 2012 06:39:46 -0000 @@ -46,6 +46,8 @@ #include #include +#include +#include static struct mtx pfil_global_lock; @@ -74,15 +76,31 @@ struct mbuf *m = *mp; int rv = 0; + if (m->m_pkthdr.len < sizeof(struct ip) || + m->m_len < sizeof(struct ip)) + panic("pfil_run_hooks: 1: m->m_pkthdr.len %d, m->m_len %d", + (int)m->m_pkthdr.len, (int)m->m_len); PFIL_RLOCK(ph, &rmpt); KASSERT(ph->ph_nhooks >= 0, ("Pfil hook count dropped < 0")); for (pfh = pfil_hook_get(dir, ph); pfh != NULL; pfh = TAILQ_NEXT(pfh, pfil_link)) { if (pfh->pfil_func != NULL) { + ASSERT_HOST_BYTE_ORDER(m); + if (m->m_pkthdr.len < sizeof(struct ip) || + m->m_len < sizeof(struct ip)) + panic("pfil_run_hooks: 2: m->m_pkthdr.len %d, " + "m->m_len %d", (int)m->m_pkthdr.len, + (int)m->m_len); rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, ifp, dir, inp); if (rv != 0 || m == NULL) break; + ASSERT_HOST_BYTE_ORDER(m); + if (m->m_pkthdr.len < sizeof(struct ip) || + m->m_len < sizeof(struct ip)) + panic("pfil_run_hooks: 3: m->m_pkthdr.len %d, " + "m->m_len %d", (int)m->m_pkthdr.len, + (int)m->m_len); } } PFIL_RUNLOCK(ph, &rmpt); --8t9RHnE3ZwKMSgU+-- From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 10:08:34 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2784D106566C; Mon, 4 Jun 2012 10:08:34 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 845488FC12; Mon, 4 Jun 2012 10:08:30 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q54A8Tkn009989 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 12:08:29 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q54A8TVn002927; Mon, 4 Jun 2012 12:08:29 +0200 (MEST) Date: Mon, 4 Jun 2012 12:08:29 +0200 From: Daniel Hartmeier To: Joerg Pulz Message-ID: <20120604100829.GB13069@insomnia.benzedrine.cx> References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> <20120604065344.GA13069@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120604065344.GA13069@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.12-2006-07-14 Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) 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, 04 Jun 2012 10:08:34 -0000 I think I found what might happen in your case. When reading the ipfilter hook previously, I thought that it would return quickly due to fr_running not being enabled, but it's not an 'enabled' flag as set manually with pfctl -e! If you compile in ipfilter (as your kernel config does), it will run a lot of code, even if you don't enable it in rc.conf and configure a ruleset. I noticed that in all your traces so far, the packets always have ip_p=1 (ICMP) and a non-minimal length. There's a very suspicious m_pulldown() call here fr_check_wrapper() fr_check() fr_makefrip() frpr_ipv4hdr() frpr_icmp() for ICMP_SOURCEQUENCH|REDIRECT|TIMEXCEED|PARAMPROB fr_coalesce() fr_pullup() for len > MHLEN (around what, 150?) m_pulldown() where fr_pullup() subsequently even does this while (M_LEN(m) == 0) { m = m->m_next; } i.e. it seems to explicitely deal with the case where the mbuf starts with m_len==0 segments. The problem is, nothing else does, neither other pfil consumers (like ipfw or pf) nor bridge or any other networking code I can find. This could also explain the effects in ipfw (not updating byte order) and pf (panic you originally reported). There are barely any other m_pulldown() calls in the kernel, especially with offp=NULL, and its source is full of warning comments, see /usr/src/sys/kern/uipc_mbuf2.c. So I'm not sure if it's being used wrongly (ignoring its return value certainly looks wrong), or if it shouldn't be used at all. You can possibly trigger the problem by provoking an ICMP TTL exceeded error of size 150-200, either with traceroute -I packetlen or by manually crafting it (with dnet from ports or such). Alternatively, I suspect the problem will no longer show when you disable ipfilter. Daniel From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 10:10:20 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90197106579C for ; Mon, 4 Jun 2012 10:10:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A2ED68FC26 for ; Mon, 4 Jun 2012 10:10:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q54AAHVv086786 for ; Mon, 4 Jun 2012 10:10:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54AAHsx086785; Mon, 4 Jun 2012 10:10:17 GMT (envelope-from gnats) Date: Mon, 4 Jun 2012 10:10:17 GMT Message-Id: <201206041010.q54AAHsx086785@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Daniel Hartmeier Cc: Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Hartmeier 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, 04 Jun 2012 10:10:20 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Daniel Hartmeier To: Joerg Pulz Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Mon, 4 Jun 2012 12:08:29 +0200 I think I found what might happen in your case. When reading the ipfilter hook previously, I thought that it would return quickly due to fr_running not being enabled, but it's not an 'enabled' flag as set manually with pfctl -e! If you compile in ipfilter (as your kernel config does), it will run a lot of code, even if you don't enable it in rc.conf and configure a ruleset. I noticed that in all your traces so far, the packets always have ip_p=1 (ICMP) and a non-minimal length. There's a very suspicious m_pulldown() call here fr_check_wrapper() fr_check() fr_makefrip() frpr_ipv4hdr() frpr_icmp() for ICMP_SOURCEQUENCH|REDIRECT|TIMEXCEED|PARAMPROB fr_coalesce() fr_pullup() for len > MHLEN (around what, 150?) m_pulldown() where fr_pullup() subsequently even does this while (M_LEN(m) == 0) { m = m->m_next; } i.e. it seems to explicitely deal with the case where the mbuf starts with m_len==0 segments. The problem is, nothing else does, neither other pfil consumers (like ipfw or pf) nor bridge or any other networking code I can find. This could also explain the effects in ipfw (not updating byte order) and pf (panic you originally reported). There are barely any other m_pulldown() calls in the kernel, especially with offp=NULL, and its source is full of warning comments, see /usr/src/sys/kern/uipc_mbuf2.c. So I'm not sure if it's being used wrongly (ignoring its return value certainly looks wrong), or if it shouldn't be used at all. You can possibly trigger the problem by provoking an ICMP TTL exceeded error of size 150-200, either with traceroute -I packetlen or by manually crafting it (with dnet from ports or such). Alternatively, I suspect the problem will no longer show when you disable ipfilter. Daniel From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 10:25:46 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64909106564A; Mon, 4 Jun 2012 10:25:46 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id DCDC68FC20; Mon, 4 Jun 2012 10:25:45 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q54APi7a005603 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 12:25:44 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q54APiAp030401; Mon, 4 Jun 2012 12:25:44 +0200 (MEST) Date: Mon, 4 Jun 2012 12:25:44 +0200 From: Daniel Hartmeier To: Joerg Pulz Message-ID: <20120604102544.GC13069@insomnia.benzedrine.cx> References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> <20120604065344.GA13069@insomnia.benzedrine.cx> <20120604100829.GB13069@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120604100829.GB13069@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.12-2006-07-14 Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) 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, 04 Jun 2012 10:25:46 -0000 Here's a patch that directly tests this theory. If correct, it will replace the panics with simple log messages that show when ipfilter left an m_len==0 mbuf. Daniel Index: sys/contrib/ipfilter/netinet/ip_fil_freebsd.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c,v retrieving revision 1.20.4.1 diff -u -r1.20.4.1 ip_fil_freebsd.c --- sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 23 Sep 2011 00:51:37 -0000 1.20.4.1 +++ sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 4 Jun 2012 10:19:04 -0000 @@ -182,8 +182,18 @@ static int fr_check_wrapper(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { + int r; + struct ip *ip = mtod(*mp, struct ip *); - return fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + ASSERT_HOST_BYTE_ORDER(*mp); + r = fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + if (*mp != NULL && (*mp)->m_pkthdr.len >= sizeof(struct ip) && + (*mp)->m_len < sizeof(struct ip)) { + printf("fr_check_wrapper: m_len %d fixed\n", + (int)(*mp)->m_len); + *mp = m_pullup(*mp, sizeof(struct ip)); + } + return r; } # ifdef USE_INET6 From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 10:30:19 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A2F1065673 for ; Mon, 4 Jun 2012 10:30:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 02C958FC17 for ; Mon, 4 Jun 2012 10:30:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q54AUIRo024480 for ; Mon, 4 Jun 2012 10:30:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54AUIvC024477; Mon, 4 Jun 2012 10:30:18 GMT (envelope-from gnats) Date: Mon, 4 Jun 2012 10:30:18 GMT Message-Id: <201206041030.q54AUIvC024477@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Daniel Hartmeier Cc: Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Hartmeier 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, 04 Jun 2012 10:30:19 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Daniel Hartmeier To: Joerg Pulz Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Mon, 4 Jun 2012 12:25:44 +0200 Here's a patch that directly tests this theory. If correct, it will replace the panics with simple log messages that show when ipfilter left an m_len==0 mbuf. Daniel Index: sys/contrib/ipfilter/netinet/ip_fil_freebsd.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c,v retrieving revision 1.20.4.1 diff -u -r1.20.4.1 ip_fil_freebsd.c --- sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 23 Sep 2011 00:51:37 -0000 1.20.4.1 +++ sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 4 Jun 2012 10:19:04 -0000 @@ -182,8 +182,18 @@ static int fr_check_wrapper(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { + int r; + struct ip *ip = mtod(*mp, struct ip *); - return fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + ASSERT_HOST_BYTE_ORDER(*mp); + r = fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + if (*mp != NULL && (*mp)->m_pkthdr.len >= sizeof(struct ip) && + (*mp)->m_len < sizeof(struct ip)) { + printf("fr_check_wrapper: m_len %d fixed\n", + (int)(*mp)->m_len); + *mp = m_pullup(*mp, sizeof(struct ip)); + } + return r; } # ifdef USE_INET6 From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 11:07:45 2012 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD85D10656B5 for ; Mon, 4 Jun 2012 11:07:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 97A768FC23 for ; Mon, 4 Jun 2012 11:07:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q54B7jq8017530 for ; Mon, 4 Jun 2012 11:07:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54B7iqn017528 for freebsd-pf@FreeBSD.org; Mon, 4 Jun 2012 11:07:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jun 2012 11:07:44 GMT Message-Id: <201206041107.q54B7iqn017528@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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, 04 Jun 2012 11:07:45 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/168200 pf [pf] pf crashes when receiving packets from an address o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag s kern/167057 pf [pf] PF firewall version 4.5 in FreeBSD 9.0 & 8.2 nolo o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 52 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 11:52:06 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B109B106564A; Mon, 4 Jun 2012 11:52:06 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDE88FC0A; Mon, 4 Jun 2012 11:52:06 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q54BooOF065328; Mon, 4 Jun 2012 13:50:50 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) (authenticated bits=0) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q54Bonf1065325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jun 2012 13:50:49 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) Date: Mon, 4 Jun 2012 13:50:46 +0200 (CEST) From: Joerg Pulz To: Daniel Hartmeier In-Reply-To: <20120604102544.GC13069@insomnia.benzedrine.cx> Message-ID: References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> <20120604065344.GA13069@insomnia.benzedrine.cx> <20120604100829.GB13069@insomnia.benzedrine.cx> <20120604102544.GC13069@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mailhost.frm2.tum.de [129.187.179.12]); Mon, 04 Jun 2012 13:50:49 +0200 (CEST) Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) 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, 04 Jun 2012 11:52:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Jun 2012, Daniel Hartmeier wrote: > Here's a patch that directly tests this theory. > > If correct, it will replace the panics with simple log messages that > show when ipfilter left an m_len==0 mbuf. Daniel, thanks for all your help and the detailed informations. The system is now running with your latest patches. I was unable to reproduce the panics with netstat(1). Will take a look at dnet later. I will keep you informed about new panics or log messages out of fr_check_wrapper(). Kind regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzKEZSPOsGF+KA+MRAufHAKCJO7tHOUr1tcHEzxarTkQaGdnZfgCguqOP 1eFhcJJ5y8KSc0jxK25TIX8= =3EA1 -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 12:00:34 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C8C7106567B for ; Mon, 4 Jun 2012 12:00:34 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 766A78FC12 for ; Mon, 4 Jun 2012 12:00:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q54C0YhY018278 for ; Mon, 4 Jun 2012 12:00:34 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54C0Yb6018274; Mon, 4 Jun 2012 12:00:34 GMT (envelope-from gnats) Date: Mon, 4 Jun 2012 12:00:34 GMT Message-Id: <201206041200.q54C0Yb6018274@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Joerg Pulz Cc: Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Pulz 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, 04 Jun 2012 12:00:34 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Joerg Pulz To: Daniel Hartmeier Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Mon, 4 Jun 2012 13:50:46 +0200 (CEST) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Jun 2012, Daniel Hartmeier wrote: > Here's a patch that directly tests this theory. > > If correct, it will replace the panics with simple log messages that > show when ipfilter left an m_len==0 mbuf. Daniel, thanks for all your help and the detailed informations. The system is now running with your latest patches. I was unable to reproduce the panics with netstat(1). Will take a look at dnet later. I will keep you informed about new panics or log messages out of fr_check_wrapper(). Kind regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzKEZSPOsGF+KA+MRAufHAKCJO7tHOUr1tcHEzxarTkQaGdnZfgCguqOP 1eFhcJJ5y8KSc0jxK25TIX8= =3EA1 -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Tue Jun 5 06:49:02 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D961E1065673; Tue, 5 Jun 2012 06:49:02 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id 656638FC15; Tue, 5 Jun 2012 06:49:02 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q556mrN6092391; Tue, 5 Jun 2012 08:48:53 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) (authenticated bits=0) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q556mpKt092384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 08:48:51 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) Date: Tue, 5 Jun 2012 08:48:48 +0200 (CEST) From: Joerg Pulz To: Daniel Hartmeier In-Reply-To: <20120604102544.GC13069@insomnia.benzedrine.cx> Message-ID: References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> <20120604065344.GA13069@insomnia.benzedrine.cx> <20120604100829.GB13069@insomnia.benzedrine.cx> <20120604102544.GC13069@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mailhost.frm2.tum.de [129.187.179.12]); Tue, 05 Jun 2012 08:48:52 +0200 (CEST) Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) 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: Tue, 05 Jun 2012 06:49:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Jun 2012, Daniel Hartmeier wrote: > Here's a patch that directly tests this theory. > > If correct, it will replace the panics with simple log messages that > show when ipfilter left an m_len==0 mbuf. Daniel, seems that your patch fixed it. I've seen the following log entry: Jun 5 02:15:33 charon kernel: fr_check_wrapper: m_len 0 fixed No panic and everything is running smooth. I will go and recompile the kernel with all the IPFIREWALL options reenabled to make sure that the byte ordering problem does not appear. I will report back. Thanks for your help. Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzavTSPOsGF+KA+MRArY+AJ43yqTeJ6hb+uCM7xZ8FWTztCz69ACgg1Wx yVCCuNUO0ipvlbPwa0jzZjM= =MGzr -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Tue Jun 5 06:50:13 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25B5B1065672 for ; Tue, 5 Jun 2012 06:50:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1015B8FC0A for ; Tue, 5 Jun 2012 06:50:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q556oCBX092482 for ; Tue, 5 Jun 2012 06:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q556oCeg092481; Tue, 5 Jun 2012 06:50:12 GMT (envelope-from gnats) Date: Tue, 5 Jun 2012 06:50:12 GMT Message-Id: <201206050650.q556oCeg092481@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Joerg Pulz Cc: Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Pulz 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: Tue, 05 Jun 2012 06:50:13 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Joerg Pulz To: Daniel Hartmeier Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Tue, 5 Jun 2012 08:48:48 +0200 (CEST) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Jun 2012, Daniel Hartmeier wrote: > Here's a patch that directly tests this theory. > > If correct, it will replace the panics with simple log messages that > show when ipfilter left an m_len==0 mbuf. Daniel, seems that your patch fixed it. I've seen the following log entry: Jun 5 02:15:33 charon kernel: fr_check_wrapper: m_len 0 fixed No panic and everything is running smooth. I will go and recompile the kernel with all the IPFIREWALL options reenabled to make sure that the byte ordering problem does not appear. I will report back. Thanks for your help. Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzavTSPOsGF+KA+MRArY+AJ43yqTeJ6hb+uCM7xZ8FWTztCz69ACgg1Wx yVCCuNUO0ipvlbPwa0jzZjM= =MGzr -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Tue Jun 5 12:41:29 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06801106564A; Tue, 5 Jun 2012 12:41:29 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6772A8FC16; Tue, 5 Jun 2012 12:41:28 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q55CfOAG008519; Tue, 5 Jun 2012 14:41:24 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) (authenticated bits=0) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id q55CfNNM008515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 14:41:23 +0200 (CEST) (envelope-from Joerg.Pulz@frm2.tum.de) Date: Tue, 5 Jun 2012 14:41:20 +0200 (CEST) From: Joerg Pulz To: Daniel Hartmeier In-Reply-To: Message-ID: References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> <20120604065344.GA13069@insomnia.benzedrine.cx> <20120604100829.GB13069@insomnia.benzedrine.cx> <20120604102544.GC13069@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mailhost.frm2.tum.de [129.187.179.12]); Tue, 05 Jun 2012 14:41:23 +0200 (CEST) Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) 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: Tue, 05 Jun 2012 12:41:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 5 Jun 2012, Joerg Pulz wrote: > On Mon, 4 Jun 2012, Daniel Hartmeier wrote: > >> Here's a patch that directly tests this theory. >> >> If correct, it will replace the panics with simple log messages that >> show when ipfilter left an m_len==0 mbuf. > > Daniel, > > seems that your patch fixed it. > I've seen the following log entry: > > Jun 5 02:15:33 charon kernel: fr_check_wrapper: m_len 0 fixed > > No panic and everything is running smooth. > I will go and recompile the kernel with all the IPFIREWALL options > reenabled to make sure that the byte ordering problem does not appear. > > I will report back. Daniel, as promised here is my report. Your patch resolved all problems and panics. I've seen two log entries since i reenabled all IPFIREWALL options. Jun 5 14:07:19 charon kernel: fr_check_wrapper: m_len 0 fixed Jun 5 14:07:19 charon kernel: fr_check_wrapper: m_len 0 fixed No panics or other messages. Everything is running fine now. Thanks again Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzf5zSPOsGF+KA+MRAvC3AJsFAEf8axpmvfu3VPUiaFprhIT6KwCfSKMI J1Ywq6NYvDeHHXiVjuWSRWw= =k6q6 -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Tue Jun 5 12:50:06 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26329106567B for ; Tue, 5 Jun 2012 12:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 06D048FC1C for ; Tue, 5 Jun 2012 12:50:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q55Co56C004697 for ; Tue, 5 Jun 2012 12:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q55Co59P004696; Tue, 5 Jun 2012 12:50:05 GMT (envelope-from gnats) Date: Tue, 5 Jun 2012 12:50:05 GMT Message-Id: <201206051250.q55Co59P004696@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Joerg Pulz Cc: Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Pulz 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: Tue, 05 Jun 2012 12:50:06 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Joerg Pulz To: Daniel Hartmeier Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Tue, 5 Jun 2012 14:41:20 +0200 (CEST) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 5 Jun 2012, Joerg Pulz wrote: > On Mon, 4 Jun 2012, Daniel Hartmeier wrote: > >> Here's a patch that directly tests this theory. >> >> If correct, it will replace the panics with simple log messages that >> show when ipfilter left an m_len==0 mbuf. > > Daniel, > > seems that your patch fixed it. > I've seen the following log entry: > > Jun 5 02:15:33 charon kernel: fr_check_wrapper: m_len 0 fixed > > No panic and everything is running smooth. > I will go and recompile the kernel with all the IPFIREWALL options > reenabled to make sure that the byte ordering problem does not appear. > > I will report back. Daniel, as promised here is my report. Your patch resolved all problems and panics. I've seen two log entries since i reenabled all IPFIREWALL options. Jun 5 14:07:19 charon kernel: fr_check_wrapper: m_len 0 fixed Jun 5 14:07:19 charon kernel: fr_check_wrapper: m_len 0 fixed No panics or other messages. Everything is running fine now. Thanks again Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPzf5zSPOsGF+KA+MRAvC3AJsFAEf8axpmvfu3VPUiaFprhIT6KwCfSKMI J1Ywq6NYvDeHHXiVjuWSRWw= =k6q6 -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Fri Jun 8 06:17:42 2012 Return-Path: Delivered-To: pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBC9C1065676; Fri, 8 Jun 2012 06:17:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 83E5D8FC0C; Fri, 8 Jun 2012 06:17:39 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q586Hbfb028609; Fri, 8 Jun 2012 10:17:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q586HbGs028608; Fri, 8 Jun 2012 10:17:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 8 Jun 2012 10:17:37 +0400 From: Gleb Smirnoff To: pf@FreeBSD.org Message-ID: <20120608061737.GA28197@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: [CFT] SMP-friendly pf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pf@FreeBSD.org 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: Fri, 08 Jun 2012 06:17:43 -0000 Hello, networkers! [net@ in Cc, but further discussion should go on pf@] As you already probably know, or some may be don't yet know, the pf(4) subsystem in FreeBSD is currently working under a single mutex. This mutex is acquired right at the beginning of any packet processing, and is dropped at the end. While one thread is in pf(4) all other threads are blocked on that mutex. Meanwhile modern computers are getting more and more cores, and modern network cards getting more MSI interrupts, each serviced by a separate kernel thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :), is getting a point of hard contention. Three and a half months ago I've started on a project "SMP-friendly pf", which recently have entered alpha stage. As you see from the subject of this mail, this is call for testing. Willing to test? The code lives in projects/pf/head branch in the SVN, and can be checked out with: svn checkout http://svn.freebsd.org/base/projects/pf/head pflock , where argument "pflock" is just directory name for checked out sources. Then you need to build world and kernel from that branch and install them. The branch projects/pf/head gets head merged to it quite often, so if you run head world with a revision equal (or at least close) to last merge, then you don't need to install world, however rebuilding pfctl and snmp_pf from that branch is necessary. If you are about to run this alpha pf on any important box, then you definitely need to establish safety measures: have a second box running stable/9 or head as carp(4) backup, ready to kick in, in case if new pf panics. pfsync(4) connection should also be established between new and backup boxes. pfsync(4) in the new code is wire compatible with stable/9 or head. I'm already running it on routers with 100k - 200k state entries, and forwarding 20k - 40k pps. If you are brave, you should try, too :) Good luck and report any problems to me! Interested in details? From the very beginning of the project it was clear, that code is going to diverge significantly from original OpenBSD code. OpenBSD has always developed pf without taking into account that code can ever get multithreaded, thus quite a lot needed to be changed. Thus, I've started with removing the "#ifdef __FreeBSD__" from the code, and later I didn't hesitate even a fraction of second if I wanted to toss some code. The pros is that now code is much more readable and understandible then in head, the cons is that diff between us and OpenBSD is huge, although amount of shared code is huge, too. So, later on only manual merging of features from OpenBSD is possible and bulk imports of entire pf into FreeBSD are no longer possible. The locking scheme is the following: - There is an rwlock(9) that protects rules and all kind of data that isn't modified by forwarding threads. Forwarding threads reader lock it, ioctl() and other reconfiguring events write lock it. - The states and key states storage had moved from RB-trees to hashes, with separate mutexes per hash slot. This should give us decent parallelism when forwarding packets. - Source nodes storage moved to hash with per-slot locking. - pfsync(4) got separate mutex. - fragment reassembly got separate mutex. Apart from the above key changes, many other optimisations and fixes done. The entire diff is 22k lines large. You can view the projects history here: http://svnweb.freebsd.org/base/projects/pf/head/?view=log (the beginning is on page 2 now, at r232042) I had tried to make informative commit messages. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Fri Jun 8 10:39:45 2012 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50BDF1065672; Fri, 8 Jun 2012 10:39:45 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E6FB38FC14; Fri, 8 Jun 2012 10:39:44 +0000 (UTC) Received: by ggnm2 with SMTP id m2so1300430ggn.13 for ; Fri, 08 Jun 2012 03:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UqWBRf8NXOxX6AQmXIwKZa64kdwGdY6Ti0JvKj/Rl+M=; b=L0PNZVN9+fNCeAgAAqepw5tIPsKDHwEE+4q/bg79ukggFLyfVUTfYCSBQai9MtHB84 RJO3kU3vy1avj/IKkYL+YGIFl+hzXRO88cFVx9LrzjAGfxb2tvn5MK27tYH3K60efbUl bOFWYJx7ew8UJxh+BeeIVtfs0MLjbnkrCBVJwWDo/CoylAtRGzHyqHrWGYzR42Oh58AC A4PHX2ZiEqSKoP9mHofppN49fiHM8lQahIy8Xx6uqyv8LX9ks13bEUEx+id+MJlEVXrb dUsxDnJwnAA0TTnFLTJsUaq7Cx7bEKPk47umE+nyRZG9tHEVFm7kLue5R0unumbZAUY6 ULWw== MIME-Version: 1.0 Received: by 10.50.51.132 with SMTP id k4mr2659461igo.17.1339151984072; Fri, 08 Jun 2012 03:39:44 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.35.202 with HTTP; Fri, 8 Jun 2012 03:39:43 -0700 (PDT) In-Reply-To: <20120608061737.GA28197@glebius.int.ru> References: <20120608061737.GA28197@glebius.int.ru> Date: Fri, 8 Jun 2012 12:39:43 +0200 X-Google-Sender-Auth: CxwOsRYjloEtZn2JrSrr4FqjHws Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: [CFT] SMP-friendly pf 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: Fri, 08 Jun 2012 10:39:45 -0000 On Fri, Jun 8, 2012 at 8:17 AM, Gleb Smirnoff wrote: > =A0Hello, networkers! > > =A0[net@ in Cc, but further discussion should go on pf@] > > =A0As you already probably know, or some may be don't yet know, the pf(4) > subsystem in FreeBSD is currently working under a single mutex. This mute= x > is acquired right at the beginning of any packet processing, and is dropp= ed > at the end. While one thread is in pf(4) all other threads are blocked on > that mutex. > > =A0Meanwhile modern computers are getting more and more cores, and modern > network cards getting more MSI interrupts, each serviced by a separate ke= rnel > thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :),= is > getting a point of hard contention. > > =A0Three and a half months ago I've started on a project "SMP-friendly pf= ", > which recently have entered alpha stage. As you see from the subject of t= his > mail, this is call for testing. > > > =A0Willing to test? > As i already asked in private wihtout a documentation/schema describing how you protect the various elements in pf(4) this is very hard to review. - What do you do to allow correctness on statistics? - What do you with tables protection, are they under same lock as rules...? - How is if-bound versus floating states maintained? - What is protecting scrub ruleset? - What is protecting nat ruleset? -.... - How you solved synproxy ? Is it scalable? - Do you think you have introduced possiblity of security issues with taskqueues you introduce? There are many how? in this implementation that are difficult to see without you telling! > =A0The code lives in projects/pf/head branch in the SVN, and can be check= ed > out with: > > =A0svn checkout http://svn.freebsd.org/base/projects/pf/head pflock > > , where argument "pflock" is just directory name for checked out sources. > =A0Then you need to build world and kernel from that branch and install t= hem. > The branch projects/pf/head gets head merged to it quite often, so if you > run head world with a revision equal (or at least close) to last merge, t= hen > you don't need to install world, however rebuilding pfctl and snmp_pf fro= m > that branch is necessary. > =A0If you are about to run this alpha pf on any important box, then you > definitely need to establish safety measures: have a second box running > stable/9 or head as carp(4) backup, ready to kick in, in case if new pf > panics. pfsync(4) connection should also be established between new and > backup boxes. pfsync(4) in the new code is wire compatible with stable/9 > or head. > =A0I'm already running it on routers with 100k - 200k state entries, and > forwarding 20k - 40k pps. If you are brave, you should try, too :) Good > luck and report any problems to me! > > > =A0Interested in details? > > =A0From the very beginning of the project it was clear, that code is goin= g > to diverge significantly from original OpenBSD code. OpenBSD has always > developed pf without taking into account that code can ever get > multithreaded, thus quite a lot needed to be changed. Thus, I've started > with removing the "#ifdef __FreeBSD__" from the code, and later I didn't > hesitate even a fraction of second if I wanted to toss some code. The pro= s > is that now code is much more readable and understandible then in head, > the cons is that diff between us and OpenBSD is huge, although amount > of shared code is huge, too. So, later on only manual merging of features > from OpenBSD is possible and bulk imports of entire pf into FreeBSD are > no longer possible. > > =A0The locking scheme is the following: > - There is an rwlock(9) that protects rules and all kind of data that isn= 't > =A0modified by forwarding threads. Forwarding threads reader lock it, ioc= tl() > =A0and other reconfiguring events write lock it. > - The states and key states storage had moved from RB-trees to hashes, wi= th > =A0separate mutexes per hash slot. This should give us decent parallelism > =A0when forwarding packets. > - Source nodes storage moved to hash with per-slot locking. > - pfsync(4) got separate mutex. > - fragment reassembly got separate mutex. > > =A0Apart from the above key changes, many other optimisations and fixes d= one. > The entire diff is 22k lines large. You can view the projects history her= e: > > http://svnweb.freebsd.org/base/projects/pf/head/?view=3Dlog > > (the beginning is on page 2 now, at r232042) I had tried to make informat= ive > commit messages. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Fri Jun 8 19:18:57 2012 Return-Path: Delivered-To: pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DB99106564A; Fri, 8 Jun 2012 19:18:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id DAD588FC12; Fri, 8 Jun 2012 19:18:56 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q58JInGY033782; Fri, 8 Jun 2012 23:18:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q58JInkj033781; Fri, 8 Jun 2012 23:18:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 8 Jun 2012 23:18:49 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120608191849.GD28613@FreeBSD.org> References: <20120608061737.GA28197@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pf@FreeBSD.org Subject: Re: [CFT] SMP-friendly pf 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: Fri, 08 Jun 2012 19:18:57 -0000 Ermal, On Fri, Jun 08, 2012 at 12:39:43PM +0200, Ermal Lu?i wrote: E> On Fri, Jun 8, 2012 at 8:17 AM, Gleb Smirnoff wrote: E> As i already asked in private wihtout a documentation/schema E> describing how you protect the various elements in pf(4) this is very E> hard to review. As I already replied, one should read commit logs as well as some details there are in the email you were replying to. E> - What do you do to allow correctness on statistics? Nothing. Statistics are not precise in the SMP-friendly pf. This is an issue for all counters in our networking stack - counters on ifnets, in ipfw, many others. Using atomic operations to keep them precise is too expensive. We need some solution to make cheap and precise counters. I think this should pcpu data. I already did made some tests proving the effectiveness of this approach. However, to get this to a commitable state I need help from some seniour kernel developers. Anyway cheap+precise counters should be discussed in separate thread. E> - What do you with tables protection, are they under same lock as rules...? Yes, and this was mentioned in the mail you are replying to. E> - How is if-bound versus floating states maintained? Nothing changed for them. Should there be something tricky? E> - What is protecting scrub ruleset? E> - What is protecting nat ruleset? Same lock as rules. I suppose that is quite clear from my mail. E> - How you solved synproxy ? Is it scalable? You know how I solved it, you even commented on that commit: http://lists.freebsd.org/pipermail/svn-src-projects/2012-April/005056.html Can you please explain your concerns on scalability of the approach taken? E> - Do you think you have introduced possiblity of security issues with E> taskqueues you introduce? Can you please explain what security issues do you see in taskqueue? E> There are many how? in this implementation that are difficult to see E> without you telling! I am open to questions. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Sat Jun 9 07:15:06 2012 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6B79106564A for ; Sat, 9 Jun 2012 07:15:06 +0000 (UTC) (envelope-from cmb@pfsense.org) Received: from mail.pfsense.org (unknown [IPv6:2605:8000:d:1::248]) by mx1.freebsd.org (Postfix) with ESMTP id B10418FC0C for ; Sat, 9 Jun 2012 07:15:06 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.pfsense.org (Postfix) with ESMTP id 5105A1FBC3 for ; Sat, 9 Jun 2012 02:15:05 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.pfsense.org Received: from mail.pfsense.org ([127.0.0.1]) by localhost (mail.pfsense.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjMgJODYwzUR for ; Sat, 9 Jun 2012 02:15:04 -0500 (EST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mail.pfsense.org (Postfix) with ESMTPSA id E32171FBB9 for ; Sat, 9 Jun 2012 02:15:03 -0500 (EST) Received: by dadv36 with SMTP id v36so3479443dad.13 for ; Sat, 09 Jun 2012 00:15:02 -0700 (PDT) Received: by 10.68.227.198 with SMTP id sc6mr3233200pbc.138.1339226102970; Sat, 09 Jun 2012 00:15:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.132 with HTTP; Sat, 9 Jun 2012 00:14:42 -0700 (PDT) In-Reply-To: <20120608061737.GA28197@glebius.int.ru> References: <20120608061737.GA28197@glebius.int.ru> From: Chris Buechler Date: Sat, 9 Jun 2012 03:14:42 -0400 Message-ID: To: pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [CFT] SMP-friendly pf 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: Sat, 09 Jun 2012 07:15:07 -0000 On Fri, Jun 8, 2012 at 2:17 AM, Gleb Smirnoff wrote: > =A0Hello, networkers! > > =A0[net@ in Cc, but further discussion should go on pf@] > > =A0As you already probably know, or some may be don't yet know, the pf(4) > subsystem in FreeBSD is currently working under a single mutex. This mute= x > is acquired right at the beginning of any packet processing, and is dropp= ed > at the end. While one thread is in pf(4) all other threads are blocked on > that mutex. > > =A0Meanwhile modern computers are getting more and more cores, and modern > network cards getting more MSI interrupts, each serviced by a separate ke= rnel > thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :),= is > getting a point of hard contention. > > =A0Three and a half months ago I've started on a project "SMP-friendly pf= ", > which recently have entered alpha stage. As you see from the subject of t= his > mail, this is call for testing. > > > =A0Willing to test? > Absolutely. Are there any particular areas specifically that you would like some testing focus on? Obviously testing everything is needed to ensure nothing is broken, and I'm definitely interested in doing some performance comparisons on SMP and non-SMP hardware. But not sure what areas you've already focused on, and what areas you feel need more testing focus than others, if any. Appreciate your work on this! Chris From owner-freebsd-pf@FreeBSD.ORG Sat Jun 9 08:12:53 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B81E210656B3 for ; Sat, 9 Jun 2012 08:12:53 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) by mx1.freebsd.org (Postfix) with ESMTP id 991A58FC1B for ; Sat, 9 Jun 2012 08:12:53 +0000 (UTC) Received: from vivi.cat.pdx.edu (vivi.cat.pdx.edu [131.252.214.6]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 37835E6008 for ; Sat, 9 Jun 2012 01:12:53 -0700 (PDT) Received: from [IPv6:2001:470:8643:970:211:43ff:fe70:5826] (unknown [IPv6:2001:470:8643:970:211:43ff:fe70:5826]) by vivi.cat.pdx.edu (Postfix) with ESMTPSA id 2285424DF1 for ; Sat, 9 Jun 2012 01:12:52 -0700 (PDT) Message-ID: <4FD30582.90506@bluerosetech.com> Date: Sat, 09 Jun 2012 01:12:50 -0700 From: list_freebsd@bluerosetech.com User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPv6 fragments firewall support? 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: Sat, 09 Jun 2012 08:12:53 -0000 There's a sentence at the end of the "Fragment Handling" section of the pf.conf man page: "Currently, only IPv4 fragments are supported and IPv6 fragments are blocked unconditionally." This is in pf.conf(5) for FreeBSD versions using pf 4.1. It looks like we only have pf 4.5 in HEAD and I believe support for IPv6 fragments didn't arrive until OpenBSD 5.0 (after the pf.conf format change). Is IPv6 fragmentation support still an issue? I'm chasing down PMTU issues and came across this. If it's the case, it would explain a lot of the problems I'm having with UDP over IPv6. From owner-freebsd-pf@FreeBSD.ORG Sat Jun 9 21:40:45 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDE0E1065673 for ; Sat, 9 Jun 2012 21:40:45 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4DB8FC17 for ; Sat, 9 Jun 2012 21:40:45 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 12F7B25D387B; Sat, 9 Jun 2012 21:40:43 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BFA24BE84ED; Sat, 9 Jun 2012 21:40:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id l4MpBE9w0q7y; Sat, 9 Jun 2012 21:40:41 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2B411BE84EB; Sat, 9 Jun 2012 21:40:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FD30582.90506@bluerosetech.com> Date: Sat, 9 Jun 2012 21:40:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <65AD7414-BE0E-486A-8FF4-E31E5EFF5B5F@lists.zabbadoz.net> References: <4FD30582.90506@bluerosetech.com> To: list_freebsd@bluerosetech.com X-Mailer: Apple Mail (2.1084) Cc: freebsd-pf@freebsd.org Subject: Re: IPv6 fragments firewall support? 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: Sat, 09 Jun 2012 21:40:45 -0000 On 9. Jun 2012, at 08:12 , list_freebsd@bluerosetech.com wrote: > There's a sentence at the end of the "Fragment Handling" section of = the pf.conf man page: >=20 > "Currently, only IPv4 fragments are supported and IPv6 fragments are = blocked unconditionally." >=20 > This is in pf.conf(5) for FreeBSD versions using pf 4.1. It looks = like we only have pf 4.5 in HEAD and I believe support for IPv6 = fragments didn't arrive until OpenBSD 5.0 (after the pf.conf format = change). >=20 > Is IPv6 fragmentation support still an issue? I'm chasing down PMTU = issues and came across this. If it's the case, it would explain a lot = of the problems I'm having with UDP over IPv6. Yes, it's not there yet; someone needs to cherry pick the commits and = bring it over. Glebius can you do that? You can however unconditionally allow all fragments and trust a (bad) = end host system: pass log quick inet6 proto ipv6-frag all (it has log set for a reason to be able to track them here) /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!