Problem reports for n...@freebsd.org that need special attention

[bugzilla-noreply]

To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status  |Bug Id | Description
+---+---
In Progress |165622 | [ndis][panic][patch] Unregistered use of FPU in k 
In Progress |206581 | bxe_ioctl_nvram handler is faulty 
In Progress |221146 | [ixgbe] Problem with second laggport  
New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi 
New |205592 | TCP processing in IPSec causes kernel panic   
New |206053 | kqueue support code of netmap causes panic
New |209682 | [panic] [netinet] arptimer race   
New |213410 | [carp] service netif restart causes hang only whe 
New |217748 | sys/dev/ixgbe/if_ix.c: PVS-Studio: Assignment to  
Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc 
Open|194485 | Userland cannot add IPv6 prefix routes
Open|194515 | Fatal Trap 12 Kernel with vimage  
Open|202510 | [CARP] advertisements sourced from CARP IP cause  
Open|206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; 
Open|211962 | bxe driver queue soft hangs and flooding tx_soft_ 
Open|213814 | AWS/EC2: no egress traffic stats on ixv(4)

16 problems total for which you should take action.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

QOS/TOS in carp/freebsd in general

[Nick Wolff]

 Hi,

I currently have a review in to make carp use dscp values on outgoing
packets. This will make it easier to preform QOS on modern switches as we
have been able to drive carp insane on 10g links while throwing storage
traffic at it.On an interesting side note apparently after 64k mac address
moves for a single mac address in the cam table arista 7050t  seems to with
out warning give up and stop moving address but leaves it in the table
where ever it last was.

I was originally going to just toggle between cs7 and the old TOS low delay
setting. But it was requested that I just make it a settable Integer value.
In this case I'm planning to do 0-63 to match dscp with a default of 54
(CS7) (Network Control) but you could still set the old value by setting
the sysctl to 4. Anything larger then 64 would be truncated as two shifts
are needed to align with the field leading.

Does anybody do anything anywhere with the old TOS values like low delay in
there networking infrastructure? Should this be updated in other places in
kernel and userland? It's been 20 years since TOS was deprecated and
replaced with DSCP.

Any other comments or thought are always welcome.

References:

Open Review - https://reviews.freebsd.org/D14536
General DSCP reference - https://www.tucny.com/Home/dscp-tos


Thanks,

Nick "darkfiberiru" Wolff
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

[Eugene Grosbein]

15.04.2018 21:19, Rodney W. Grimes wrote:

 It is a website with quite some traffic handles by three webservers behind 
 a pair >of loadbalancers.
 We see a loss of 20% in speed(TTFB reduced by 100ms; sounds not a lot but 
 >Google et al doesn?t like it at all) after upgrading to 11.1 with a 
 combined upgrade >to php7.1. On another server without NFS that upgrade 
 improved performance >considerably (I was told ca 30% by the front end-dev)
>>> One thing you could try is booting the 11.1 kernel on an 10.3 system. Newer
>>> FreeBSD kernels should work with older userland.
>>
>> Though one should remember that some important system utilities
>> may and probably will not work with newer kernel, like /sbin/ipfw, route,
>> ifconfig, netstat etc.
> 
> I thought that as long as the newer kernel has the right
> COMPAT_FREEBSD10 compiled in that all this stuff should work.
> Am I miss understanding this kernel option?

COMPAT_FREEBSD10 does not cover all cases (in-kernel structures etc.)
and bugs can happen, too. You won't be happy if you discover
similar case in /sbin/ipfw or ifconfig as this combination (old ipfw+new kernel)
is not something we test thoroughly.


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

[Rodney W. Grimes]

[ Charset windows-1252 unsupported, converting... ]
> 15.04.2018 19:58, Rick Macklem wrote:
> 
> > Niels Kobschaetzki wrote:
> > [stuff snipped]
> >> It is a website with quite some traffic handles by three webservers behind 
> >> a pair >of loadbalancers.
> >> We see a loss of 20% in speed(TTFB reduced by 100ms; sounds not a lot but 
> >> >Google et al doesn?t like it at all) after upgrading to 11.1 with a 
> >> combined upgrade >to php7.1. On another server without NFS that upgrade 
> >> improved performance >considerably (I was told ca 30% by the front end-dev)
> > One thing you could try is booting the 11.1 kernel on an 10.3 system. Newer
> > FreeBSD kernels should work with older userland.
> 
> Though one should remember that some important system utilities
> may and probably will not work with newer kernel, like /sbin/ipfw, route,
> ifconfig, netstat etc.

I thought that as long as the newer kernel has the right
COMPAT_FREEBSD10 compiled in that all this stuff should work.
Am I miss understanding this kernel option?

> 
> > This would tell you if it is kernel changes or userland changes that are 
> > causing
> > the higher miss rate.
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

[Eugene Grosbein]

15.04.2018 19:58, Rick Macklem wrote:

> Niels Kobschaetzki wrote:
> [stuff snipped]
>> It is a website with quite some traffic handles by three webservers behind a 
>> pair >of loadbalancers.
>> We see a loss of 20% in speed(TTFB reduced by 100ms; sounds not a lot but 
>> >Google et al doesn’t like it at all) after upgrading to 11.1 with a 
>> combined upgrade >to php7.1. On another server without NFS that upgrade 
>> improved performance >considerably (I was told ca 30% by the front end-dev)
> One thing you could try is booting the 11.1 kernel on an 10.3 system. Newer
> FreeBSD kernels should work with older userland.

Though one should remember that some important system utilities
may and probably will not work with newer kernel, like /sbin/ipfw, route,
ifconfig, netstat etc.

> This would tell you if it is kernel changes or userland changes that are 
> causing
> the higher miss rate.

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

[Rick Macklem]

Niels Kobschaetzki wrote:
[stuff snipped]
>It is a website with quite some traffic handles by three webservers behind a 
>pair >of loadbalancers.
>We see a loss of 20% in speed(TTFB reduced by 100ms; sounds not a lot but 
>>Google et al doesn’t like it at all) after upgrading to 11.1 with a combined 
>upgrade >to php7.1. On another server without NFS that upgrade improved 
>performance >considerably (I was told ca 30% by the front end-dev)
One thing you could try is booting the 11.1 kernel on an 10.3 system. Newer
FreeBSD kernels should work with older userland.
This would tell you if it is kernel changes or userland changes that are causing
the higher miss rate.

Good luck with it, rick
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

[Niels Kobschaetzki]

> On 15. Apr 2018, at 01:18, Rick Macklem  wrote:
> 
> Niels Kobschätzki wrote:
>>> On 04/14/2018 03:49 AM, Rick Macklem wrote:
>>> Niels Kobschätzki wrote:
 sorry for the cross-posting but so far I had no real luck on the forum
 or on question, thus I want to try my luck here as well.
>>> I read email lists but don't do the other stuff, so I just saw this 
>>> yesterday.
>>> Short answer, I haven't a clue why cache hits rate would have changed.
>>> 
>>> The code that decides if there is a hit/miss for the attribute cache is in
>>> ncl_getattrcache() and the code hasn't changed between 10.3->11.1,
>>> except the old code did a mtx_lock(), but I can't imagine how that
>>> would affect the code.
>>> 
>>> You might want to:
>>> # sysctl -a | fgrep vfs.nfs
>>> for both the 10.3 and 11.1 systems, to check if any defaults have somehow
>>> been changed. (I don't recall any being changed, but??)
>> 
>> I did that and there did nothing change.
>> 
>>> If you go into ncl_getattrcache() {it's in sys/fs/nfsclient/nfs_clsubs.c}
>>> and add a printf() for "time_second" and "np->n_mtime.tv_sec" near the
>>> top, where it calculates "timeo" from it.
>>> Running this hacked kernel might show you if either of these fields is 
>>> bogus.
>>> (You could then printf() "timeo" and "np->n_attrtimeo" just before the "if"
>>> clause that increments "attrcache_misses", which is where the cache misses
>>> happen to see why it is missing the cache.)
>>> If you could do this for the 10.3 kernel as well, this might indicate why 
>>> the
>>> miss rate has increased?
>> 
>> I will do this next week. On monday we switch for other reasons to other
>> nfs-servers and when we see that they run stable, I will do this next.
> With a miss rate of 2.7%, I doubt printing the above will help. I thought
> you were seeing a high miss rate.

It is low but increased by nearly a factor of 1000 to before. I hope the print 
will help. Just a lot of grepping through wherever I can get this data. 

>> Btw. I calculated now the percentages. The old servers had a attr miss
>> rate of something like 0.004%, while the upgraded one has more like
>> 2.7%. This is till low from what I've read (I remember that you should
>> start adjusting acreg* when you hit more than 40% misses) but far higher
>> than before.
> You could try increasing acregmin, acregmax and see if the misses are reduced.
> (The only risk with increasing the cache timeout is that, if another client 
> changes
> the attributes, then the client will use stale ones for longer. Usually, this 
> doesn't
> cause serious problems.)

I tried that and it had exactly no effect

> To be honest, a Getattr RPC is pretty low overhead, so I doubt the increase
> to 2.7% will affect your application's performance, but it is interesting that
> it increased.

It is a website with quite some traffic handles by three webservers behind a 
pair of loadbalancers. 
We see a loss of 20% in speed(TTFB reduced by 100ms; sounds not a lot but 
Google et al doesn’t like it at all) after upgrading to 11.1 with a combined 
upgrade to php7.1. On another server without NFS that upgrade improved 
performance considerably (I was told ca 30% by the front end-dev)

> You might also try increasing acdirmin, acdirmax in case it is the directory
> attributes that are having cache misses.

I did that, too

> Oh, and check that your time of day clocks are in sync with the server,
> since the caches are time based, since there is no cache coherency protocol
> in NFS.

I checked that. All three frontends are using the same server for ntp

Thanks so far,

Niels
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 225066] CVE-2016-10396 security/ipsec-tools

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225066

--- Comment #4 from commit-h...@freebsd.org ---
A commit references this bug:

Author: eugen
Date: Sun Apr 15 08:51:12 UTC 2018
New revision: 467375
URL: https://svnweb.freebsd.org/changeset/ports/467375

Log:
  MFH: r467313

  security/ipsec-tools: fix CVE-2016-10396

  The racoon daemon in IPsec-Tools 0.8.2 contains a remotely exploitable
  computational-complexity attack when parsing and storing ISAKMP fragments.
  The implementation permits a remote attacker to exhaust computational
  resources on the remote endpoint by repeatedly sending ISAKMP fragment
  packets in a particular order such that the worst-case computational
  complexity is realized in the algorithm utilized to determine
  if reassembly of the fragments can take place.

  The fix obtained from NetBSD CVS head with a command:

  cvs diff -D 2017-01-24 -D 2017-09-01 \
src/racoon/handler.h \
src/racoon/isakmp.c \
src/racoon/isakmp_frag.c \
src/racoon/isakmp_inf.c

  While here, add LICENSE.

  PR:   225066
  Approved by:  ports-secteam (riggs)
  Obtained from:NetBSD
  Security: CVE-2016-10396
  Security:
https://www.vuxml.org/freebsd/974a6d32-3fda-11e8-aea4-001b216d295b.html

Changes:
_U  branches/2018Q2/
  branches/2018Q2/security/ipsec-tools/Makefile
  branches/2018Q2/security/ipsec-tools/files/patch-handler.c
  branches/2018Q2/security/ipsec-tools/files/patch-isakmp.c
  branches/2018Q2/security/ipsec-tools/files/patch-isakmp_frag.c
  branches/2018Q2/security/ipsec-tools/files/patch-isakmp_inf.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"