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: