Re: svn commit: r315514 - in stable/11: . contrib/netcat lib/libipsec sbin/ifconfig sbin/ipfw sbin/setkey share/man/man4 sys/conf sys/libkern sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/n

2017-04-03 Thread Mike Tancsa 
Hi,
I ran into a strange problem when migrating a box that makes use of tcp
md5 signatures. Having these two policies that have IPs which happen to
be 128 octets apart get rejected


add 10.50.34.158 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

Similarly, if I have the entries

add 10.50.34.159 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

it errors out as well
# setkey -F ; setkey -FP ; setkey -F ; setkey -f test.ipsec.2
The result of line 2: File exists.
The result of line 4: File exists.

# cat test.ipsec.2
add 10.50.34.158 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
add 10.50.34.159 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

But if the IPs are not 128 apart, its fine

# cat test.ipsec.3
add 10.50.34.157 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.30 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;
add 10.50.34.160 10.50.34.18 tcp 0x101c -A tcp-md5 "test14" ;
add 10.50.34.31 10.50.34.18 tcp 0x1002 -A tcp-md5 "test1" ;

# setkey -F ; setkey -FP ; setkey -F ; setkey -f test.ipsec.3
#



On 3/18/2017 6:04 PM, Andrey V. Elsukov wrote:
> Author: ae
> Date: Sat Mar 18 22:04:20 2017
> New Revision: 315514
> URL: https://svnweb.freebsd.org/changeset/base/315514
> 
> Log:
>   MFC r304572 (by bz):
> Remove the kernel optoion for IPSEC_FILTERTUNNEL, which was deprecated
> more than 7 years ago in favour of a sysctl in r192648.
>   
>   MFC r305122:
> Remove redundant sanity checks from ipsec[46]_common_input_cb().
>   
> This check already has been done in the each protocol callback.
>   
>   MFC r309144,309174,309201 (by fabient):
> IPsec RFC6479 support for replay window sizes up to 2^32 - 32 packets.
>   
> Since the previous algorithm, based on bit shifting, does not scale
> with large replay windows, the algorithm used here is based on
> RFC 6479: IPsec Anti-Replay Algorithm without Bit Shifting.
> The replay window will be fast to be updated, but will cost as many bits
> in RAM as its size.
>   
> The previous implementation did not provide a lock on the replay window,
> which may lead to replay issues.
>   
> Obtained from:emeric.pou...@stormshield.eu
> Sponsored by: Stormshield
> Differential Revision:https://reviews.freebsd.org/D8468
>   
>   MFC r309143,309146 (by fabient):
> In a dual processor system (2*6 cores) during IPSec throughput tests,
> we see a lot of contention on the arc4 lock, used to generate the IV
> of the ESP output packets.
>   
> The idea of this patch is to split this mutex in order to reduce the
> contention on this lock.
>   
> Update r309143 to prevent false sharing.
>   
> Reviewed by:  delphij, markm, ache
> Approved by:  so
> Obtained from: emeric.pou...@stormshield.eu
> Sponsored by: Stormshield
> Differential Revision:https://reviews.freebsd.org/D8130
>   
>   MFC r313330:
> Merge projects/ipsec into head/.
>   
>  Small summary
>  -
>   
> o Almost all IPsec releated code was moved into sys/netipsec.
> o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel
>   option IPSEC_SUPPORT added. It enables support for loading
>   and unloading of ipsec.ko and tcpmd5.ko kernel modules.
> o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by
>   default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type
>   support was removed. Added TCP/UDP checksum handling for
>   inbound packets that were decapsulated by transport mode SAs.
>   setkey(8) modified to show run-time NAT-T configuration of SA.
> o New network pseudo interface if_ipsec(4) added. For now it is
>   build as part of ipsec.ko module (or with IPSEC kernel).
>   It implements IPsec virtual tunnels to create route-based VPNs.
> o The network stack now invokes IPsec functions using special
>   methods. The only one header file 
>   should be included to declare all the needed things to work
>   with IPsec.
> o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed.
>   Now these protocols are handled directly via IPsec methods.
> o TCP_SIGNATURE support was reworked to be more close to RFC.
> o PF_KEY SADB was reworked:
>   - now all security associations stored in the single SPI namespace,
> and all SAs MUST have unique SPI.
>   - several hash tables added to speed up lookups in SADB.
>   - SADB now uses rmlock to protect access, and concurrent threads
> can do SA lookups in the same time.
>   - many PF_KEY message handlers were reworked to reflect changes
> in SADB.
>   - SADB_UPDATE message was extended to support new PF_KEY headers:
>

/dev/dri registration

2017-04-03 Thread Slawa Olhovchenkov 
I am have strange issuse on stable/10:

# devinfo -v
nexus0
  apic0
  ram0
  acpi0
[...]
pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
  pci0
hostb0 pnpinfo vendor=0x8086 device=0xd130 subvendor=0x1014 
subdevice=0x03ce class=0x06 at slot=0 function=0 dbsf=pci0:0:0:0
pcib1 pnpinfo vendor=0x8086 device=0xd138 subvendor=0x1014 
subdevice=0x03ce class=0x060400 at slot=3 function=0 dbsf=pci0:0:3:0 
handle=\_SB_.PCI0.P0P2
  pci1
vgapci0 pnpinfo vendor=0x10de device=0x0a20 subvendor=0x1458 
subdevice=0x34d6 class=0x03 at slot=0 function=0 dbsf=pci0:1:0:0
  drm0
  drmn0
  nvidia0

But /dev/dri don't exist!

# kldstat 
Id Refs AddressSize Name
 1   80 0x8020 17e87f8  kernel
 21 0x819e9000 309780   zfs.ko
 32 0x81cf3000 6040 opensolaris.ko
 41 0x81cfa000 7aa58if_em.ko
 51 0x81d75000 29bd0drm.ko
 61 0x81d9f000 82898drm2.ko
 72 0x81e22000 6298 iicbus.ko
 81 0x81e29000 1c650uart.ko
 91 0x82011000 56f3 fdescfs.ko
101 0x82017000 a681 linprocfs.ko
113 0x82022000 7522 linux_common.ko
121 0x8202a000 5673 linsysfs.ko
131 0x8203 364c ums.ko
141 0x82034000 10226snd_uaudio.ko
151 0x82045000 2ba8 uhid.ko
163 0x82048000 4e626vboxdrv.ko
172 0x82097000 2b82 vboxnetflt.ko
182 0x8209a000 ba2f netgraph.ko
191 0x820a6000 414f ng_ether.ko
201 0x820ab000 3fd4 vboxnetadp.ko
212 0x820af000 3d5dalinux.ko
221 0x820ed000 964496   nvidia.ko

What is wrong in may setup?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-04-03 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #27 from Cassiano Peixoto  ---
(In reply to Mateusz Guzik from comment #26)
Hi Mateuz, i can confirm only on stable/10. Maybe someone else can confirm it
to you. After the patch is running 13 days without crash. Thanks.

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

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-04-03 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #26 from Mateusz Guzik  ---
So, can I please get confirmation that the problem is still present in current
and still present in stable/11 past r315395? There were several changes which
could have make the apparent cpu problem stop manifesting itself.

If so, I'll simply merge them to stable/10 as well.

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

freebsd-update: 11.0 approaching EOL?

2017-04-03 Thread Marko Cupać 
Hi,

I just got the following message after running freebsd-update:

...
WARNING: FreeBSD 11.0-RELEASE-p8 is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

I guess this should be fixed.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"