From notifications at soundcloudmail.com Sun Mar 1 00:26:00 2015 From: notifications at soundcloudmail.com (SoundCloud Notifications) Date: Sun, 1 Mar 2015 01:25:52 +0100 Subject: New message from SoundCloud PR Message-ID: <0e3013725e3f1bb4d7a03f720014d781@soundcloudmail.com> [letter.png] Hey, [1]SoundCloudPR sent you a message: The SoundCloud Promotional Service offers Artists, DJs, Singers and Managers a simple, cost-effective way to reach targeted followers, sales, comments, plays and downloads on SoundCloud. We target like-minded users who are interested in your new tracks, releases and sets. This means that each new user we will follow, will receive a notification from you (like this message), saying that you have followed him or her. In return, these users will check out your profile, follow you back, play, comment, and download your music. By increasing your visibility on SoundCloud, you also improve your chances of getting noticed by records labels, club owners and talent scouts, who might all be looking for the next big catch. Many of our clients have signed records deals, DJ gigs, or simply found new collaboration partners after using our services. Artists that generate a lot of honest consistent feedbacks and traffic to their profiles are the ones who stand out from the crowd. To check this new service, go directly to the [2]SoundCloud Promotion Page ----- ? 2007 - 2015 SoundCloud Ltd. All rights reserved [postman-email-convo-message_sent] [3]Unsubscribe[4] | Manage Notifications | [5]Support | [6]Terms of Use | [7]Community Guidelines | [8]Imprint | [9]Privacy Policy References 1. http://bit.ly/soundcloud-now 2. http://bit.ly/soundcloud-now 3. http://bit.ly/sc-unsubscribe 4. http://soundcloud.com/settings/email 5. http://help.soundcloud.com/ 6. http://soundcloud.com/terms-of-use 7. http://soundcloud.com/community-guidelines 8. http://soundcloud.com/imprint 9. https://soundcloud.com/pages/privacy From jjasen at gmail.com Fri Mar 6 13:46:35 2015 From: jjasen at gmail.com (John Jasen) Date: Fri, 06 Mar 2015 08:46:28 -0500 Subject: Bug 198315 - net/relayd does not work with ssl services Message-ID: <54F9AFB4.8020407@gmail.com> For general information, in case anyone else bumped/bumps into this: As an executive summary, relayd from pkg won't work with SSL/TLS enabled services. Adding SSL options in /etc/make.comf and installing from ports seems to resolve this issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198315 From jjasen at gmail.com Fri Mar 6 13:49:28 2015 From: jjasen at gmail.com (John Jasen) Date: Fri, 06 Mar 2015 08:49:25 -0500 Subject: Bug 195407 - relayd crashes kernel under 10.1-RELEASE Message-ID: <54F9B065.9060709@gmail.com> Also, for general information. relayd is, by all appearances, unusable under FreeBSD 10.1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195407 From jjasen at gmail.com Fri Mar 6 18:07:37 2015 From: jjasen at gmail.com (John Jasen) Date: Fri, 06 Mar 2015 13:07:33 -0500 Subject: Bug 195407 - relayd crashes kernel under 10.1-RELEASE In-Reply-To: <54F9B065.9060709@gmail.com> References: <54F9B065.9060709@gmail.com> Message-ID: <54F9ECE5.60309@gmail.com> More accurately, relayd from pkg install is unsafe to use. Again, like the SSL issue I also encountered, relayd from ports appears to be fine. On 03/06/2015 08:49 AM, John Jasen wrote: > Also, for general information. > > relayd is, by all appearances, unusable under FreeBSD 10.1. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195407 From bugzilla-noreply at freebsd.org Sat Mar 7 15:00:19 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Sat, 07 Mar 2015 15:00:19 +0000 Subject: [Bug 193620] Problem with igb multiqueue together with pf In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193620 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-pf at FreeBSD.org Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-noreply at freebsd.org Tue Mar 10 01:46:40 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 10 Mar 2015 01:46:39 +0000 Subject: [Bug 193568] PF rdr rule with ipv6 does not work In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193568 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Mar 10 01:49:20 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 10 Mar 2015 01:49:19 +0000 Subject: [Bug 196699] pf starts blocking traffic from jails (with VIMAGE) needs to be stooped and reloaded In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196699 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Mar 10 01:57:30 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 10 Mar 2015 01:57:30 +0000 Subject: [Bug 197484] fix pf 3whs ACK handling In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197484 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org Summary|pf 3whs ACK handling |fix pf 3whs ACK handling Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Mar 10 02:11:35 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 10 Mar 2015 02:11:35 +0000 Subject: [Bug 196087] pf loses states during rdr In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196087 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Tue Mar 10 02:16:03 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 10 Mar 2015 02:16:03 +0000 Subject: [Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From kristof at sigsegv.be Wed Mar 11 08:39:24 2015 From: kristof at sigsegv.be (Kristof Provost) Date: Wed, 11 Mar 2015 09:39:16 +0100 Subject: [PATCH] Fix panic with pf fastroute In-Reply-To: <1426064691-1238-1-git-send-email-kristof@sigsegv.be> References: <1426064691-1238-1-git-send-email-kristof@sigsegv.be> Message-ID: <20150311083916.GQ1975@vega.codepro.be> Set up a pf ruleset with at least the following rule > pass out fastroute inet6 proto icmp6 all icmp6-type echoreq Send out an icmp6 echo request (i.e. ping6 2001:db8::1). This causes a panic in ip6_output() when comparing the old and new destination addresses (IN6_ARE_ADDR_EQUAL()) just after the netpfil hook. The cause is the fastroute option, which means that the mbuf is handed off to ip6_output() from pf itself and should no longer be processed by the ip6_output() which called pf in the first place. The pf code in pf_route6() neglected to set the mbuf pointer to NULL after the call to ip6_output(). As a result we end up trying to continue processing on an mbuf which has already been freed. --- sys/netpfil/pf/pf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c index b32288b..7c3ddb8 100644 --- a/sys/netpfil/pf/pf.c +++ b/sys/netpfil/pf/pf.c @@ -5470,6 +5470,7 @@ pf_route6(struct mbuf **m, struct pf_rule *r, int dir, struct ifnet *oifp, PF_STATE_UNLOCK(s); m0->m_flags |= M_SKIP_FIREWALL; ip6_output(m0, NULL, NULL, 0, NULL, NULL, NULL); + *m = NULL; return; } From bu7cher at yandex.ru Wed Mar 11 09:51:33 2015 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed, 11 Mar 2015 12:50:23 +0300 Subject: [PATCH] Fix panic with pf fastroute In-Reply-To: <20150311083916.GQ1975@vega.codepro.be> References: <1426064691-1238-1-git-send-email-kristof@sigsegv.be> <20150311083916.GQ1975@vega.codepro.be> Message-ID: <55000FDF.10007@yandex.ru> On 11.03.2015 11:39, Kristof Provost wrote: > The pf code in pf_route6() neglected to set the mbuf pointer to NULL > after the call to ip6_output(). As a result we end up trying to continue > processing on an mbuf which has already been freed. > --- > sys/netpfil/pf/pf.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c > index b32288b..7c3ddb8 100644 > --- a/sys/netpfil/pf/pf.c > +++ b/sys/netpfil/pf/pf.c > @@ -5470,6 +5470,7 @@ pf_route6(struct mbuf **m, struct pf_rule *r, int dir, struct ifnet *oifp, > PF_STATE_UNLOCK(s); > m0->m_flags |= M_SKIP_FIREWALL; > ip6_output(m0, NULL, NULL, 0, NULL, NULL, NULL); > + *m = NULL; > return; > } It looks like there are some code paths that do a copy of original mbuf. Are you sure this doesn't introduce mbuf leak? -- WBR, Andrey V. Elsukov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From kristof at sigsegv.be Wed Mar 11 12:50:55 2015 From: kristof at sigsegv.be (Kristof Provost) Date: Wed, 11 Mar 2015 13:50:50 +0100 Subject: [PATCH] Fix panic with pf fastroute In-Reply-To: <55000FDF.10007@yandex.ru> References: <1426064691-1238-1-git-send-email-kristof@sigsegv.be> <20150311083916.GQ1975@vega.codepro.be> <55000FDF.10007@yandex.ru> Message-ID: <20150311125050.GR1975@vega.codepro.be> On 2015-03-11 12:50:23 (+0300), Andrey V. Elsukov wrote: > It looks like there are some code paths that do a copy of original mbuf. > Are you sure this doesn't introduce mbuf leak? > I'll check again in the morning when I'm less drunk and jet lagged, but I'm pretty confident this is correct. There are only two exit points from pf_route6(), this one only happens in case of FASTROUTE, not DUPTO (which is the one that duplicates). Regards. Kristof From kristof at sigsegv.be Thu Mar 12 00:16:53 2015 From: kristof at sigsegv.be (Kristof Provost) Date: Thu, 12 Mar 2015 01:16:47 +0100 Subject: [PATCH] Fix panic with pf fastroute In-Reply-To: <20150311125050.GR1975@vega.codepro.be> References: <1426064691-1238-1-git-send-email-kristof@sigsegv.be> <20150311083916.GQ1975@vega.codepro.be> <55000FDF.10007@yandex.ru> <20150311125050.GR1975@vega.codepro.be> Message-ID: <20150312001647.GS1975@vega.codepro.be> On 2015-03-11 13:50:50 (+0100), Kristof Provost wrote: > On 2015-03-11 12:50:23 (+0300), Andrey V. Elsukov wrote: > > It looks like there are some code paths that do a copy of original mbuf. > > Are you sure this doesn't introduce mbuf leak? > > > I'll check again in the morning when I'm less drunk and jet lagged, but > I'm pretty confident this is correct. > There are only two exit points from pf_route6(), this one only happens > in case of FASTROUTE, not DUPTO (which is the one that duplicates). > So, yes, the duplication is only done if r->rt == PF_DUPTO and the case I fixed is r->rt == PF_FASTROUTE. Regards, Kristof From bugzilla-noreply at freebsd.org Thu Mar 12 04:42:14 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:42:14 +0000 Subject: [Bug 197566] Wrong comparsion in pflogd In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197566 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:42:39 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:42:39 +0000 Subject: [Bug 197511] BPF --> Interactions with Dhclient, Tcpdump, and Network Connections (Ping) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197511 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:42:55 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:42:54 +0000 Subject: [Bug 196314] pf nested inline anchors does not work In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196314 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:43:20 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:43:20 +0000 Subject: [Bug 192774] PF_KEY ACQUIRE missing port and protocol info In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192774 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:43:48 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:43:48 +0000 Subject: [Bug 192677] pfctl iotcl buffer to small for bigger spamd blacklists In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192677 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:44:37 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:44:37 +0000 Subject: [Bug 186251] authpf(8) always fails with "error removing stale rulesets" on 10.0-RELEASE In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186251 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:45:21 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:45:20 +0000 Subject: [Bug 145727] [pf.conf] pf rules not applied on boot if using inet6 :network modifier In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=145727 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-pf at FreeBSD.org Assignee|freebsd-bugs at FreeBSD.org |freebsd-rc at FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:45:48 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:45:48 +0000 Subject: [Bug 16644] [bpf] [patch] Bad comparison expression in bpf_filter.c In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=16644 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:48:32 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:48:31 +0000 Subject: [Bug 192426] [bpf] [panic] [patch]: Kernel panic when using BPF In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192426 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-net at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 04:48:45 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 04:48:45 +0000 Subject: [Bug 175267] [pf] [tap] pf + tap keep state problem In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175267 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 12 13:48:26 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 12 Mar 2015 13:48:26 +0000 Subject: [Bug 192426] [bpf] [panic] [patch]: Kernel panic when using BPF In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192426 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-pf at FreeBSD.org |ae at FreeBSD.org CC| |ae at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Mar 13 00:39:49 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 13 Mar 2015 00:39:49 +0000 Subject: [Bug 197511] BPF --> Interactions with Dhclient, Tcpdump, and Network Connections (Ping) In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197511 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-pf at FreeBSD.org |freebsd-net at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Mar 13 00:40:26 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 13 Mar 2015 00:40:26 +0000 Subject: [Bug 16644] [bpf] [patch] Bad comparison expression in bpf_filter.c In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=16644 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-pf at FreeBSD.org |freebsd-net at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Fri Mar 13 00:41:52 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Fri, 13 Mar 2015 00:41:52 +0000 Subject: [Bug 191916] pflogd(8) eats cpu and hangs with net.bpf.zerocopy_enable=0 In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191916 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-pf at FreeBSD.org |freebsd-net at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From kristof at sigsegv.be Sat Mar 14 02:05:07 2015 From: kristof at sigsegv.be (Kristof Provost) Date: Sat, 14 Mar 2015 03:05:01 +0100 Subject: PF IPv6 fragments handling In-Reply-To: <20150209232416.GB37777@vega.codepro.be> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> Message-ID: <20150314020500.GW1975@vega.codepro.be> On 2015-02-10 00:24:16 (+0100), Kristof Provost wrote: > On 2015-02-03 21:25:20 (+0100), Kristof Provost wrote: > > Two of my systems are currently running them, seemingly without > > problems. > > > The initial patch set had problems refragmenting in forwarding > scenarios. That should be fixed with the update to > https://reviews.freebsd.org/D1767 and the extra patch in > https://reviews.freebsd.org/D1815 > Status update: all these patches other than D1815 have been committed. There's one crash I know about in forwarding scenarios (and scrub on output). There's a fix which will be committed as soon as it's had a bit more testing. The blocking point is D1815. There's no consensus on it right now, so I'd like to go over the problem and the two possible solutions I see. The problematic scenario is when we're forwarding fragmented IPv6 packets. Right now the fragmented packets are gathered up on the ip6_input() netpfil hook (through pf_test6() -> pf_normalize_ip6() -> pf_reassemble6()). When we've found all of the fragments pf_reassemble6() will create a reassembled fragment and tag it as having been reassembled. pf_test6() then returns the reassembled packet to the IP stack. That passes through ip6_input() and is handed to ip6_forward(). At that point we run into the packet size check, which in ip6_forward() is done before the pfil(PFIL_OUT) hook. That means that we'll send an ICMP6_PACKET_TOO_BIG error rather than forwarding the packet. The proposed fix in D1815 is to simply move the size check after the pfil(PFIL_OUT) hook so pf has the chance to refragment the packet (which it does in pf_test6() -> pf_refragment6() because the packet has the PF_REASSEMBLED tag). That's also what the OpenBSD stack does. In the D1815 review Gleb Smirnoff proposed a different solution. Instead of returning a reassembled packet from pfil(PFIL_IN) in ip6_input() we could change netpfil so we could return multiple packets. That means we'd reassemble and immediately refragment on the input, and then do the same on the output side. I have a preference for the solution in D1815 for two reasons: - it's less work for me. It's a relatively small change in ip6_output() and nothing else. Changing netpfil so it can return multiple packets is a more invasive change and will impact other firewalls too. - it's less work for the kernel when forwarding. Not only do we only reassemble and refragment once, but we also only need to do ip6_forward() processing on a single packet, rather than for each fragment. Thoughts? Regards, Kristof From vangyzen at FreeBSD.org Mon Mar 16 13:52:31 2015 From: vangyzen at FreeBSD.org (Eric van Gyzen) Date: Mon, 16 Mar 2015 09:51:55 -0400 Subject: PF IPv6 fragments handling In-Reply-To: <20150314020500.GW1975@vega.codepro.be> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> Message-ID: <5506DFFB.7050302@FreeBSD.org> On 03/13/2015 22:05, Kristof Provost wrote: > At that point we run into the packet size check, which in ip6_forward() > is done before the pfil(PFIL_OUT) hook. That means that we'll send an > ICMP6_PACKET_TOO_BIG error rather than forwarding the packet. > > The proposed fix in D1815 is to simply move the size check after the > pfil(PFIL_OUT) hook so pf has the chance to refragment the packet (which > it does in pf_test6() -> pf_refragment6() because the packet has the > PF_REASSEMBLED tag). > That's also what the OpenBSD stack does. > > In the D1815 review Gleb Smirnoff proposed a different solution. Instead > of returning a reassembled packet from pfil(PFIL_IN) in ip6_input() we > could change netpfil so we could return multiple packets. That means > we'd reassemble and immediately refragment on the input, and then do the > same on the output side. > > > I have a preference for the solution in D1815 for two reasons: > - it's less work for me. It's a relatively small change in ip6_output() > and nothing else. Changing netpfil so it can return multiple packets > is a more invasive change and will impact other firewalls too. > - it's less work for the kernel when forwarding. Not only do we only > reassemble and refragment once, but we also only need to do > ip6_forward() processing on a single packet, rather than for each > fragment. Here is a brainstorm that might give the best of both: Return the reassembled packet from PFIL_IN, but with the original fragment chain stashed in metadata. Most of the stack operates on the single, reassembled packet. ip6_output() sends the original fragment chain. Sure, it uses more memory, but reduced CPU time might be worth it. I am sure there are numerous challenges. When the stack modifies the packet, it will need to modify the fragment chain to match. Size checks would probably need to look at the fragment chain instead of the reassembled packet. This could be a maintenance problem when people forget to handle the rare case of the fragment chain. Like I said, it is a brainstorm. Treat it accordingly. Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: OpenPGP digital signature URL: From kristof at sigsegv.be Tue Mar 17 01:15:12 2015 From: kristof at sigsegv.be (Kristof Provost) Date: Tue, 17 Mar 2015 02:15:08 +0100 Subject: PF IPv6 fragments handling In-Reply-To: <5506DFFB.7050302@FreeBSD.org> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org> Message-ID: <20150317011507.GC2036@vega.codepro.be> On 2015-03-16 09:51:55 (-0400), Eric van Gyzen wrote: > Here is a brainstorm that might give the best of both: Return the > reassembled packet from PFIL_IN, but with the original fragment chain > stashed in metadata. Most of the stack operates on the single, > reassembled packet. ip6_output() sends the original fragment chain. > Sure, it uses more memory, but reduced CPU time might be worth it. > It's an interesting idea. There are a number of advantages (like not modifying the fragment ID or the sizes of each packet). It won't reduce CPU usage though because we'd have to copy the packet which is something we don't do at the moment. In addition to that there's the concern you pointed out that we'd forget to adapt them both, or that we'd end up checking the wrong one at any point in the stack. Regards, Kristof From bugzilla-noreply at freebsd.org Tue Mar 17 14:24:46 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Tue, 17 Mar 2015 14:24:46 +0000 Subject: [Bug 185617] pfctl(8): armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185617 guyyur at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|pfctl(8): 10.0-RC1, armv6: |pfctl(8): armv6: "pfctl -s |"pfctl -s state" crashes on |state" crashes on |BeagleBone Black due to |BeagleBone Black due to |unaligned access |unaligned access Hardware|Any |arm Version|unspecified |11.0-CURRENT --- Comment #2 from guyyur at gmail.com --- Patch that breaks backward compatibility by separating the pfsync and pfioc state structures and uses host order for pfioc fields except for id and creatorid. pfsync_state_import is duplicated to pfioc_state_import. pfioc_state_export is duplicated to pfsync_state_export. pfsync_alloc_scrub_memory is duplicated to pfioc_alloc_scrub_memory. https://github.com/guyyur/freebsd-src_patches/blob/master/pfctl_arm_segbus__ver2_part1.patch -- You are receiving this mail because: You are the assignee for the bug. From dave at horsfall.org Tue Mar 17 17:33:23 2015 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 18 Mar 2015 04:14:31 +1100 (EST) Subject: Hints on rate limiting Message-ID: FreeBSD 9.3-RELEASE-p5 (GENERIC) #0: Mon Nov 3 22:02:57 UTC 2014 fxp0: (on board) I'm having trouble with getting rate limiting to work i.e. so many connections from the same source in so many seconds (what we in the anti-spam community call "woodpeckers"). Does it actually work on FreeBSD 9? I know that PF doesn't work at all on FreeBSD 8 (at least, with the NIC above), and if it does indeed work then what would be a good starting point? Note that a complicating factor is that I have configured a "greet pause" of 10 seconds i.e. after the connection I wait for that long before issuing the SMTP greeting (and woe betide you if you don't wait in turn). And before anyone asks me why aren't I running 10.x, I will as soon as my new server arrives; the current box is going to fail soon (the electrolytic capacitors are starting to bulge) so it's not worth the hassle. And anyway, I've screwed up the ports area Yet Again from a failure to read simple instructions :-( -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From bc979 at lafn.org Wed Mar 18 00:59:23 2015 From: bc979 at lafn.org (Doug Hardie) Date: Tue, 17 Mar 2015 17:50:47 -0700 Subject: Hints on rate limiting In-Reply-To: References: Message-ID: > On 17 March 2015, at 10:14, Dave Horsfall wrote: > > FreeBSD 9.3-RELEASE-p5 (GENERIC) #0: Mon Nov 3 22:02:57 UTC 2014 > > fxp0: (on board) > > I'm having trouble with getting rate limiting to work i.e. so many > connections from the same source in so many seconds (what we in the > anti-spam community call "woodpeckers"). > > Does it actually work on FreeBSD 9? I know that PF doesn't work at all on > FreeBSD 8 (at least, with the NIC above), and if it does indeed work then > what would be a good starting point? > > Note that a complicating factor is that I have configured a "greet pause" > of 10 seconds i.e. after the connection I wait for that long before > issuing the SMTP greeting (and woe betide you if you don't wait in turn). > > And before anyone asks me why aren't I running 10.x, I will as soon as my > new server arrives; the current box is going to fail soon (the > electrolytic capacitors are starting to bulge) so it's not worth the > hassle. And anyway, I've screwed up the ports area Yet Again from a > failure to read simple instructions :-( You might want to provide some details on which approach to rate limiting you are using. There are at least two that I am aware of. Also, are your sure that you are having a large number of connections from each IP, or are they using one connection and trying many different ids and passwords? I see lots of the latter on several mail servers I run. I don?t recall seeing one IP making many connection attempts. Rate limiting won?t help if they are using one connection. From jjasen at gmail.com Wed Mar 18 02:00:31 2015 From: jjasen at gmail.com (John Jasen) Date: Tue, 17 Mar 2015 22:00:26 -0400 Subject: bug in tftp-proxy, unable to write rdr rules Message-ID: <5508DC3A.4070603@gmail.com> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198674 In FreeBSD 10.1-RELEASE-p6, a rule similar to the below will result in no tftp connection, and entries in /var/log/messages such as: "Mar 17 23:38:28 vm-fbd-fw-02 tftp-proxy[28376]: pf connection lookup failed (no rdr?)" rdr pass log on em0 proto udp from 10.0.0.0/24 to 10.0.0.5 port 69 \ -> 127.0.0.1 port 6969 The error comes from: /usr/src/contrib/pf/tftp-proxy.c: " /* find the un-rdr'd server and port the client wanted */ if (server_lookup((struct sockaddr *)&from, (struct sockaddr *)&proxy, (struct sockaddr *)&server, IPPROTO_UDP) != 0) { syslog(LOG_ERR, "pf connection lookup failed (no rdr?)"); exit(1); } " This did not happen in FreeBSD 10.0. From bugzilla-noreply at freebsd.org Thu Mar 19 20:44:17 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 19 Mar 2015 20:44:17 +0000 Subject: [Bug 198674] [pf] [tftp-proxy] tftp-proxy cannot write rdr rules In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198674 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org Keywords| |regression -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 19 20:46:47 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 19 Mar 2015 20:46:48 +0000 Subject: [Bug 198674] [pf] [tftp-proxy] tftp-proxy cannot write rdr rules In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198674 jjasen at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #1 from jjasen at gmail.com --- Closing bug, user error. -- You are receiving this mail because: You are the assignee for the bug. From list_freebsd at bluerosetech.com Sat Mar 21 22:11:49 2015 From: list_freebsd at bluerosetech.com (list_freebsd at bluerosetech.com) Date: Sat, 21 Mar 2015 15:11:32 -0700 Subject: PF IPv6 fragments handling In-Reply-To: <20150317011507.GC2036@vega.codepro.be> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org> <20150317011507.GC2036@vega.codepro.be> Message-ID: <550DEC94.4040805@bluerosetech.com> On 2015-03-16 18:15, Kristof Provost wrote: > On 2015-03-16 09:51:55 (-0400), Eric van Gyzen wrote: >> Here is a brainstorm that might give the best of both: Return the >> reassembled packet from PFIL_IN, but with the original fragment chain >> stashed in metadata. Most of the stack operates on the single, >> reassembled packet. ip6_output() sends the original fragment chain. >> Sure, it uses more memory, but reduced CPU time might be worth it. >> > It's an interesting idea. There are a number of advantages (like not > modifying the fragment ID or the sizes of each packet). > > It won't reduce CPU usage though because we'd have to copy the packet > which is something we don't do at the moment. Why would you need to copy the packet in order to store a list of fragment IDs and offsets? You need that information anyway for refragmentation because an IPv6 router is not supposed to fragments. I'd interpret that to mean the fragmentation pattern coming out of pf should match what went in. A later hop wouldn't be able to send back a meaningful PTB message otherwise. From kristof at sigsegv.be Sun Mar 22 00:48:57 2015 From: kristof at sigsegv.be (Kristof Provost) Date: Sun, 22 Mar 2015 09:48:46 +0900 Subject: PF IPv6 fragments handling In-Reply-To: <550DEC94.4040805@bluerosetech.com> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org> <20150317011507.GC2036@vega.codepro.be> <550DEC94.4040805@bluerosetech.com> Message-ID: <7EA47C5D-E783-408B-8A70-9F02F5348839@sigsegv.be> > On 22 Mar 2015, at 07:11, list_freebsd at bluerosetech.com wrote: > > On 2015-03-16 18:15, Kristof Provost wrote: >> On 2015-03-16 09:51:55 (-0400), Eric van Gyzen wrote: >>> Here is a brainstorm that might give the best of both: Return the >>> reassembled packet from PFIL_IN, but with the original fragment chain >>> stashed in metadata. Most of the stack operates on the single, >>> reassembled packet. ip6_output() sends the original fragment chain. >>> Sure, it uses more memory, but reduced CPU time might be worth it. >>> >> It's an interesting idea. There are a number of advantages (like not >> modifying the fragment ID or the sizes of each packet). >> >> It won't reduce CPU usage though because we'd have to copy the packet >> which is something we don't do at the moment. > > Why would you need to copy the packet in order to store a list of fragment IDs and offsets? > That?s how I read Eric?s suggestion. We could indeed limit ourselves to storing just the fragment IDs and offsets. That?d be an improvement over copying the packet. > You need that information anyway for refragmentation because an IPv6 router is not supposed to fragments. I'd interpret that to mean the fragmentation pattern coming out of pf should match what went in. A later hop wouldn't be able to send back a meaningful PTB message otherwise. > Agreed. We actually already do it mostly that way. It?s just that we only store the size of the largest fragment. That?s not quite as good as storing all fragment sizes, but it does mean we don?t break Path MTU. I?ll see if I can take a stab at doing things that way, so we can see if that?s an improvement over my current proposal (i.e. delay the size check until after the pfil hook in ip6_output()). Regards, Kristof From xuegao at mail.com Tue Mar 24 10:34:02 2015 From: xuegao at mail.com (Harry) Date: Tue, 24 Mar 2015 08:35:34 +0100 Subject: Are you interested in photo retouching? Message-ID: <73c51ba38f7a3466097b5c215befc776@lowes.com> How are you? Are you interested in photo retouching or other photo editing solutions? We specialize in providing below photo retouching services: Photoshop photos editing/retouching Jewelry photos retouching Ecommerce products photo editing Photo cutting out/clipping path Beauty/skin retouching, Wedding photo editing and photo background manipulation. You can send us a photo for free testing and check our quality Waiting for your soonest response. Best regards, Harry Email: markedit at tom.com From bugzilla-noreply at freebsd.org Wed Mar 25 02:09:02 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Wed, 25 Mar 2015 02:09:01 +0000 Subject: [Bug 198868] pf brakes tcp checksum if enabled for ue adapter In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198868 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs at FreeBSD.org |freebsd-pf at FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From bugzilla-noreply at freebsd.org Thu Mar 26 01:29:02 2015 From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org) Date: Thu, 26 Mar 2015 01:29:01 +0000 Subject: [Bug 193568] PF rdr rule with ipv6 does not work In-Reply-To: References: Message-ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193568 j.david.lists at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |j.david.lists at gmail.com --- Comment #1 from j.david.lists at gmail.com --- This is a duplicate of 179392. FreeBSD 9 + PF + IPv6 has been hopelessly broken for years and nobody cares. A fix for this particular issue was eventually developed, but is currently not available available in any released version. To resolve this issue, your choices are to downgrade to 8.4 or upgrade to 10-STABLE. The fix should be in 10.2 in late 2015 / early 2016. -- You are receiving this mail because: You are the assignee for the bug. From phabric-noreply at FreeBSD.org Thu Mar 26 15:33:27 2015 From: phabric-noreply at FreeBSD.org (rodrigc (Craig Rodrigues)) Date: Thu, 26 Mar 2015 15:33:26 +0000 Subject: [Differential] [Updated] D1944: PF and VIMAGE fixes In-Reply-To: References: Message-ID: rodrigc added a reviewer: kristof. REVISION DETAIL https://reviews.freebsd.org/D1944 To: nvass-gmx.com, gnn, bz, zec, trociny, glebius, rodrigc, kristof Cc: freebsd-virtualization, freebsd-pf, freebsd-net From phabric-noreply at FreeBSD.org Thu Mar 26 21:24:34 2015 From: phabric-noreply at FreeBSD.org (kristof (Kristof Provost)) Date: Thu, 26 Mar 2015 21:24:34 +0000 Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes In-Reply-To: References: Message-ID: <226eb16e55155e86f5e53ae2f8d94159@localhost.localdomain> kristof added inline comments. INLINE COMMENTS sys/netpfil/pf/pf_ioctl.c:325 It's not clear to me why this is done here, rather than in pf_unload(). The initialisation is done in pf_load() after all. sys/netpfil/pf/pf_ioctl.c:3725 Don't we still need to do all of this somewhere? REVISION DETAIL https://reviews.freebsd.org/D1944 To: nvass-gmx.com, gnn, bz, zec, trociny, glebius, rodrigc, kristof Cc: freebsd-virtualization, freebsd-pf, freebsd-net From mohsen at pahlevanzadeh.org Thu Mar 26 23:34:40 2015 From: mohsen at pahlevanzadeh.org (Mohsen Pahlevanzadeh) Date: Fri, 27 Mar 2015 02:03:01 +0430 Subject: ip_conntarck in FreeBSD Message-ID: <55147B0D.60506@pahlevanzadeh.org> Dear All, I need to equivalen of ip_conntarck of netfilter in FreeBSD, Specially, maximum connections. Specially two variable net.ipv4.netfilter.ip_conntrack_count and net.ipv4.netfilter.ip_conntrack_max --Regards Mohsen From fjo-lists at ogris.de Fri Mar 27 08:17:41 2015 From: fjo-lists at ogris.de (Felix J. Ogris) Date: Fri, 27 Mar 2015 09:17:29 +0100 Subject: ip_conntarck in FreeBSD In-Reply-To: <55147B0D.60506@pahlevanzadeh.org> References: <55147B0D.60506@pahlevanzadeh.org> Message-ID: <02332EEA-6695-497E-AB5C-E6D135BAF589@ogris.de> > On 26 Mar 2015, at 22:33, Mohsen Pahlevanzadeh wrote: > > Dear All, > > I need to equivalen of ip_conntarck of netfilter in FreeBSD, Specially, maximum connections. > Specially two variable net.ipv4.netfilter.ip_conntrack_count and net.ipv4.netfilter.ip_conntrack_max Hi, pfctl -si | grep current pfctl -sm | grep states or with bsnmpd running and snmp_pf.so loaded: snmpget enterprises.12325.1.200.1.3.1 snmpget enterprises.12325.1.200.1.5.1 br, Felix > --Regards > Mohsen > _______________________________________________ > freebsd-pf at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org" From roldanlemus at cdc.co.cu Fri Mar 27 18:02:10 2015 From: roldanlemus at cdc.co.cu (=?ISO-8859-1?Q?Rold=E1n?= Lemus =?ISO-8859-1?Q?Garc=EDa?=) Date: Fri, 27 Mar 2015 13:59:17 -0400 Subject: freebsd-pf Digest, Vol 456, Issue 4 In-Reply-To: References: Message-ID: <1427479157.26039.6.camel@overmind.drydock.local> new From jrm at ftfl.ca Tue Mar 31 21:30:21 2015 From: jrm at ftfl.ca (Joseph Mingrone) Date: Tue, 31 Mar 2015 18:28:11 -0300 Subject: tcpdump of pflog to show pid Message-ID: <86a8ysvous.fsf@gly.ftfl.ca> Hi, On OpenBSD, a tcpdump of the pflog can show the pid for locally generated traffic. PFLOG(4) sugggests FreeBSD's pflog also records this information. Is that the case? Can FreeBSD's tcpdump show this information? I see a similar question from 2008, but no response. https://lists.freebsd.org/pipermail/freebsd-pf/2008-April/004307.html Joseph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From jhellenthal at dataix.net Tue Mar 31 22:58:46 2015 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 31 Mar 2015 17:58:41 -0500 Subject: tcpdump of pflog to show pid In-Reply-To: <86a8ysvous.fsf@gly.ftfl.ca> References: <86a8ysvous.fsf@gly.ftfl.ca> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Run tcpdump -vvve -i pflog0 ??? on a FreeBSD machine ? Should yield your answer. This isn?t necessarily something to do with tcpdump(8) than it is for the inclusion of pf(4) into the FreeBSD kernel. Specific versions of tcpdump(8) and configured options might yield different results.. try base and ports. On Mar 31, 2015, at 16:28, Joseph Mingrone wrote: Hi, On OpenBSD, a tcpdump of the pflog can show the pid for locally generated traffic. PFLOG(4) sugggests FreeBSD's pflog also records this information. Is that the case? Can FreeBSD's tcpdump show this information? I see a similar question from 2008, but no response. https://lists.freebsd.org/pipermail/freebsd-pf/2008-April/004307.html Joseph - -- Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal at DataIX.net JJH48-ARIN -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVGyahAAoJEDLu+wRc4KcIctIIAJbKj3HSFOk4MZdfYMDBpFad cShOti2xIRK728w7SHzevoGx7PvBHcl+8MjqV47NwX30FF7GoWjBQw/Hm0M6TqCP 2FaNuBHWMGRptgGuaNjQ0MMX39Vp2lclNu9anLvU3WlIxQz3gijEQonIeQQie+es TM0u/7YCtY9/YouW4KzBXAEj8TCnfRb+J9uM1Eh7udB6IMM8UFR6fSBLh3u/6Wrn A7Ni2qWNAbmH/jPWx/MPO/PdkwOUwJLIbYKn6mCscBQxTWx3ile0Jiqtom01htag WKl2AkGCZAPhP8cbFFstmKkzKRzkYiPAJiJ4GTNiu6WA4GfLEoSOkxDU8d5BaKM= =rs+o -----END PGP SIGNATURE----- From jrm at ftfl.ca Tue Mar 31 23:31:05 2015 From: jrm at ftfl.ca (Joseph Mingrone) Date: Tue, 31 Mar 2015 20:30:00 -0300 Subject: tcpdump of pflog to show pid References: <86a8ysvous.fsf@gly.ftfl.ca> Message-ID: <86ego4u4nb.fsf@gly.ftfl.ca> Jason Hellenthal writes: > Run tcpdump -vvve -i pflog0 ??? on a FreeBSD machine ? > Should yield your answer. This isn?t necessarily something to do with > tcpdump(8) than it is for the inclusion of pf(4) into the FreeBSD > kernel. Specific versions of tcpdump(8) and configured options might > yield different results.. try base and ports. I had tried that, but not with tcpdump from ports. Unfortunately grepping for pid only returns lots of "baiduspider". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: