FreeBSD-update incorrectly reporting that it is approaching End of Life

2017-04-04 Thread Ed Maste 
FreeBSD-update has outdated release lifetime data, and is emitting a
false warning that the End-of-Life date for FreeBSD 11.0-RELEASE-p8 is
approaching.

| 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.

The warning should be ignored, and will be corrected as soon as possible.
___
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"

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-04 Thread Mike Tancsa 
On 4/4/2017 7:18 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 13:55, Mike Tancsa wrote:
> 
> Yes, you need SA for both directions.
> 
>> The man page for setkey implies I only need one entry.
>>
>> Also, should the SPI always been the same, or unique ?
> 
> SPI is not used by this code, it only needed for compatibility with
> SADB. Better to use unique SPI for each SA, but for TCP-MD5 it will work
> anyway. :)
> 

Perhaps to the man pages, this small change ?

--- sbin/setkey/setkey.8.prev   2017-04-04 15:11:03.312911000 -0400
+++ sbin/setkey/setkey.82017-04-04 15:53:31.296152000 -0400
@@ -696,6 +696,7 @@
 Use TCP MD5 between two numerically specified hosts:
 .Bd -literal -offset indent
 add 10.1.10.34 10.1.10.36 tcp 0x1000 -A tcp-md5 "TCP-MD5 BGP secret" ;
+add 10.1.10.36 10.1.10.34 tcp 0x1000 -A tcp-md5 "TCP-MD5 BGP secret" ;
 .Ed
 .\"
 .Sh SEE ALSO

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

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-04 Thread Mike Tancsa 
On 4/4/2017 7:18 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 13:55, Mike Tancsa wrote:
>>> You have many SAs with the same destination address, it seems to me,
>>> that this should not work with old IPsec code, because it uses SA
>>> lookups using only destination address. So, if you have not the same
>>> password for each SA, it should not work.
>>>
>>> Can you try the attached patch?

Thanks, the patch works!  I am able to load all 42 rules now.  I am
going to test them in the lab against a few VMs prior to deployment.

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

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-04 Thread Andrey V. Elsukov 
On 04.04.2017 13:55, Mike Tancsa wrote:
>> You have many SAs with the same destination address, it seems to me,
>> that this should not work with old IPsec code, because it uses SA
>> lookups using only destination address. So, if you have not the same
>> password for each SA, it should not work.
>>
>> Can you try the attached patch?
>>
> 
> It did. In the past, inbound sigs I think just didnt work, but it was
> uninteresting for the purpose of this app.  In this case, it was for bgp

Yes, I checked stable/10 code, it seems TCP-MD5 always used one SA for
both inbound and outbound direction.

> passwords.  I was more concerned with sending the correct password to
> the peer.  So it was one source IP with many destination addresses (over
> a dozen). For the old config I just had the policy in one direction as
> well.  It seems now with the new ipsec code, I must have the policy in
> both directions ?

Yes, you need SA for both directions.

> The man page for setkey implies I only need one entry.
> 
> Also, should the SPI always been the same, or unique ?

SPI is not used by this code, it only needed for compatibility with
SADB. Better to use unique SPI for each SA, but for TCP-MD5 it will work
anyway. :)

-- 
WBR, Andrey V. Elsukov




signature.asc
Description: OpenPGP digital signature

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-04 Thread Mike Tancsa 
On 4/4/2017 2:24 AM, Andrey V. Elsukov wrote:
> On 04.04.2017 00:39, Mike Tancsa wrote:
> It seems you have encrypted your config, because I don't see IP with 128
> octets :)

:)

> 
> One question, does this even worked before?


> You have many SAs with the same destination address, it seems to me,
> that this should not work with old IPsec code, because it uses SA
> lookups using only destination address. So, if you have not the same
> password for each SA, it should not work.
>
> Can you try the attached patch?
>

It did. In the past, inbound sigs I think just didnt work, but it was
uninteresting for the purpose of this app.  In this case, it was for bgp
passwords.  I was more concerned with sending the correct password to
the peer.  So it was one source IP with many destination addresses (over
a dozen). For the old config I just had the policy in one direction as
well.  It seems now with the new ipsec code, I must have the policy in
both directions ?

The man page for setkey implies I only need one entry.

Also, should the SPI always been the same, or unique ?

compiling the patch now.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

Re: /dev/dri registration

2017-04-04 Thread Claude Buisson 

On 04/03/2017 18:09, Slawa Olhovchenkov wrote:

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"



It seems that you are using the nvidia driver

I have presently 2 systems with this driver, and none of them have a 
/dev/dri,  and this have always been the case as far as I can recall.


Claude Buisson



___
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"

Re: /dev/dri registration

2017-04-04 Thread Boris Samorodov 

Hi Slawa, All!

03.04.2017 19:09, 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


I'm not sure about your original question, but at least that is
suspicious. I'd say that drm and drm2 modules should not be loaded
together.


  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?


HTH
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

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-04 Thread Andrey V. Elsukov 
On 04.04.2017 00:39, Mike Tancsa wrote:
> 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

It seems you have encrypted your config, because I don't see IP with 128
octets :)

One question, does this even worked before?
You have many SAs with the same destination address, it seems to me,
that this should not work with old IPsec code, because it uses SA
lookups using only destination address. So, if you have not the same
password for each SA, it should not work.

Can you try the attached patch?

-- 
WBR, Andrey V. Elsukov
Index: sys/netipsec/key.c
===
--- sys/netipsec/key.c	(revision 316434)
+++ sys/netipsec/key.c	(working copy)
@@ -863,7 +863,8 @@ key_allocsa_tcpmd5(struct secasindex *saidx)
 		kdebug_secash(sah, "  "));
 		if (sah->saidx.proto != IPPROTO_TCP)
 			continue;
-		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0))
+		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0) &&
+		!key_sockaddrcmp(>src.sa, >saidx.src.sa, 0))
 			break;
 	}
 	if (sah != NULL) {
@@ -4962,7 +4963,8 @@ key_getsav_tcpmd5(struct secasindex *saidx, uint32
 	LIST_FOREACH(sah, SAHADDRHASH_HASH(saidx), addrhash) {
 		if (sah->saidx.proto != IPPROTO_TCP)
 			continue;
-		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0))
+		if (!key_sockaddrcmp(>dst.sa, >saidx.dst.sa, 0) &&
+		!key_sockaddrcmp(>src.sa, >saidx.src.sa, 0))
 			break;
 	}
 	if (sah != NULL) {


signature.asc
Description: OpenPGP digital signature

Re: VirtualBox-ose kernel module crashes 10-stable

2017-04-04 Thread Hiroyuki Une 
On Fri, 31 Mar 2017 13:56:54 +0200 (CEST)
Trond Endrestøl  wrote:

> On Fri, 31 Mar 2017 20:07+0900, Hiroyuki Une wrote:
> 
> > Kernel Panic was caused on My 10.3-STABLE r316132 
> > by VirtualBox-ose created by poudriere(8) on my box with DEBUG option.  
> > However, when I was using 10.3-STABLE r315187, 
> > VirtualBox-ose worked without any problem.  
> > 
> > Here is the output by kgdb:
> > 
> > -- start here (output by kgdb)
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain 
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "amd64-marcel-freebsd"...
> > 
> > Unread portion of the kernel message buffer:
> > 
> > !!Assertion Failed!!
> > Expression: RTThreadPreemptIsEnabled(NIL_RTTHREAD)
> > Location  : 
> > /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.1.18/out/freebsd.amd64/debug/bin/src/vboxdrv/r0drv/freebsd/spinlock-r0drv-freebsd.c(78)
> >  int RTSpinlockCreate(PRTSPINLOCK, uint32_t, const char *)
> > 
> > 
> > Fatal trap 3: breakpoint instruction fault while in kernel mode
> > cpuid = 3; apic id = 06
> > instruction pointer = 0x20:0x81dbb3de
> > stack pointer   = 0x28:0xfe0464bfd490
> > frame pointer   = 0x28:0xfe0464bfd4c0
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, IOPL = 0
> > current process = 46465 (VBoxSVC)
> > trap number = 3
> > panic: breakpoint instruction fault
> > cpuid = 3
> > KDB: stack backtrace:
> > #0 0x809bb360 at kdb_backtrace+0x60
> > #1 0x8097c1e6 at vpanic+0x126
> > #2 0x8097c0b3 at panic+0x43
> > #3 0x80d9ce2d at trap_fatal+0x35d
> > #4 0x80d9caaf at trap+0x79f
> > #5 0x80d81d4c at calltrap+0x8
> > #6 0x81d7d591 at supdrvCreateSession+0x91
> > #7 0x81d9355b at vboxdrvFreeBSDOpenCommon+0x2b
> > #8 0x80855a32 at devfs_open+0x122
> > #9 0x80ed8671 at VOP_OPEN_APV+0xa1
> > #10 0x80a3bc34 at vn_open_vnode+0x234
> > #11 0x80a3b803 at vn_open_cred+0x373
> > #12 0x80a348cf at kern_openat+0x26f
> > #13 0x80d9d862 at amd64_syscall+0x452
> > #14 0x80d8203b at Xfast_syscall+0xfb
> > Uptime: 16h16m43s
> > Dumping 3881 out of 16259 
> > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> > #0  doadump (textdump=) at pcpu.h:219
> > 219 pcpu.h: No such file or directory.
> > in pcpu.h
> > (kgdb) bt

(snip)

> > As shown in the above, kernel panic was caused by 
> > assertion RTThreadPreemptIsEnabled(NIL_RTTHREAD) 
> > which tests the following expressions:
> > 
> >   1. curthread->td_critnest is equal to 0, and
> >   2. IF (interrupt flag) on eflag (or rflag ?) is equal to 1.  
> > 
> > This assertion will be successful only if both of above are true.  
> > 
> > As I read the source of VirtualBox, RTThreadPreemptIsEnabled is 
> > a part of test for preemtiveness which is used to create a spinlock.  
> > However, I'm not sure why assertion RTThreadPreemptIsEnabled is required, 
> > and this was failed on 10.3-STABLE r316132.  
> > 
> > I would appreciate any information.  Thanks.  
> 
> emulators/virtualbox-ose needs access to the kernel sources during 
> build. Maybe you should rebuild emulators/virtualbox-ose to match your 
> current source tree.

Thank you for your advise.  I create a new jail for poudriere with 
the most recent 10.3-STABLE source tree, and then rebuild VirtualBox 
and its kernel module by it.  These worked fine.  

However, this shows that there seems to be following problems 
to maintain packages by pkg(8):

(a) STABLE users (both of 10 and 11) can't use kernel modules 
if pkg.FreeBSD.org provides packages which were built with RELEASE 
source tree, or

(b) RELEASE users can't use kernel can't use kernel modules 
if pkg.FreeBSD.org provides packages which were built with recent 
STABLE source tree.   

At least, nvidia-driver caused kernel panic by almost same reason [1].  

[1] https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/087015.html

---
Hiroyuki Une: Hiroshima Kokusai Gakuin University
u...@hkg.ac.jp / harr...@seiryu.id.hkg.ac.jp
___
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"