https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872
--- Comment #8 from Mike Andrews ---
At first glance, r303698 does seem to be the culprit. I'll keep running tests
over the next 24 hours.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872
--- Comment #7 from Andrey V. Elsukov ---
Since you use 11.0-RC1, can you try to revert r303698 and build and test?
You can do this with the following commands:
# cd /usr/src
# svn merge -c -303698 ^/stable/11
--
You are receiving this ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872
--- Comment #6 from Mike Andrews ---
(In reply to Andrey V. Elsukov from comment #5)
short answer: ndp -na shows the correct mac addresses even when UDP fails.
Again, this seems to not impact TCP or ICMP at all.
Here's another tcpdump fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211836
--- Comment #13 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Wed Aug 17 20:21:34 UTC 2016
New revision: 304313
URL: https://svnweb.freebsd.org/changeset/base/304313
Log:
Teach netisr_get_cpuid() to limi
On 17 August 2016 at 08:43, Ben RUBSON wrote:
>
>> On 17 Aug 2016, at 17:38, Adrian Chadd wrote:
>>
>> [snip]
>>
>> ok, so this is what I was seeing when I was working on this stuff last.
>>
>> The big abusers are:
>>
>> * so_snd lock, for TX'ing producer/consumer socket data
>> * tcp stack pcb l
Built new kernel, looks good, thanks!
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Joe Holden
> Sent: 17 August 2016 15:34
> To: 'Kristof Provost' ; mail+li...@m.jwh.me.uk
> Cc: freebsd-net@freebsd.org
> Subject: RE: PF
> On 17 Aug 2016, at 17:38, Adrian Chadd wrote:
>
> [snip]
>
> ok, so this is what I was seeing when I was working on this stuff last.
>
> The big abusers are:
>
> * so_snd lock, for TX'ing producer/consumer socket data
> * tcp stack pcb locking (which rss tries to work around, but it again
>
[snip]
ok, so this is what I was seeing when I was working on this stuff last.
The big abusers are:
* so_snd lock, for TX'ing producer/consumer socket data
* tcp stack pcb locking (which rss tries to work around, but it again
doesn't help producer/consumer locking, only multiple sockets)
* for s
Aha, perfect ok then I'll leave you to it!
Thanks
> -Original Message-
> From: Kristof Provost [mailto:k...@freebsd.org]
> Sent: 17 August 2016 12:18
> To: mail+li...@m.jwh.me.uk
> Cc: freebsd-net@freebsd.org
> Subject: Re: PF weirdness
>
> On 17 Aug 2016, at 11:24, mail+li...@m.jwh.me.uk
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872
--- Comment #5 from Andrey V. Elsukov ---
(In reply to Mike Andrews from comment #0)
> 12:46:22.835272 00:25:90:57:21:b3 > 00:25:90:23:be:bc, ethertype IPv6
> (0x86dd), length 232: fdfa::fafa:d53a.53 > fdfa::fafa:d53b.15484: 47157*
> 1/2/4
On 17 Aug 2016, at 11:24, mail+li...@m.jwh.me.uk wrote:
Ok so, I have an ERL that just does PPPoE and NAT via PF, however it
seems
to be modifying the packets passing through the nat filter such that
traceroutes end up like this:
C:\Users\jwh>tracert -d -w 1 8.8.8.8
Tracing route to 8.8.8.8 ov
Hi all,
Ok so, I have an ERL that just does PPPoE and NAT via PF, however it seems
to be modifying the packets passing through the nat filter such that
traceroutes end up like this:
C:\Users\jwh>tracert -d -w 1 8.8.8.8
Tracing route to 8.8.8.8 over a maximum of 30 hops
1 5 ms 1 ms
> On 15 Aug 2016, at 16:49, Ben RUBSON wrote:
>
>> On 12 Aug 2016, at 00:52, Adrian Chadd wrote:
>>
>> Which ones of these hit the line rate comfortably?
>
> So Adrian, I ran tests again using FreeBSD 11-RC1.
> I put iperf throughput in result files (so that we can classify them), as
> well
Den 2016-08-12 kl. 14:00, skrev Alex Povolotsky:
Hello
Is SO_BINDANY supported in FreeBSD 10.3? If not, do any patches exists?
It is indeed. See the source to Pen for an example. File server.c, lines
262ff.
https://github.com/UlricE/pen/blob/master/server.c
Ulric
14 matches
Mail list logo
