bhyve with lagg failover doesn't work on wifi

[Randy Westlund]

I'm using bhyve on 11.0-BETA2, bridging tap0 to lagg0, a failover
between wifi and ethernet.  The bhyve VM's networking only works I'm
using ethernet.

> # Lagg config.
> ifconfig_em0="up"
> create_args_wlan0="wlanaddr 3c:97:0e:46:70:ca"
> wlans_iwn0="wlan0"
> ifconfig_wlan0="WPA"
> cloned_interfaces="lagg0 bridge0 tap0"
> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"
> # tap0 and bridge0 are for bhyve.
> ifconfig_bridge0="addm lagg0 addm tap0"

With the ethernet cable connected, the VM's networking works.  But when
I remove the ethernet cable and lagg0 fails over to wifi, the VM can no
longer use the network.

I can use tcpdump to see the DHCP packets going along this path:
vtnet0 -> tap0 -> bridge0 -> lagg0 -> wlan0

The DHCP requests appear on wlan0.  But the router never sees them.

Here's the ifconfig output when wlan0 is active:

> em0: flags=8943 metric 0 mtu 
> 1500
> 
> options=4219b
> ether 3c:97:0e:46:70:ca
> nd6 options=29
> media: Ethernet autoselect
> status: no carrier
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> inet 127.0.0.1 netmask 0xff00
> nd6 options=21
> groups: lo
> wlan0: flags=8943 metric 0 
> mtu 1500
> ether 3c:97:0e:46:70:ca
> nd6 options=29
> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
> status: associated
> ssid neural_network channel 1 (2412 MHz 11g ht/40+) bssid 
> c4:04:15:90:f5:fd
> regdomain FCC country US authmode WPA2/802.11i privacy ON
> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 bmiss 10
> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8
> -amsdutx amsdurx shortgi -stbc wme roaming MANUAL
> groups: wlan
> lagg0: flags=8943 metric 0 
> mtu 1500
> ether 3c:97:0e:46:70:ca
> inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255
> nd6 options=29
> media: Ethernet autoselect
> status: active
> groups: lagg
> laggproto failover lagghash l2,l3,l4
> laggport: em0 flags=1
> laggport: wlan0 flags=4
> bridge0: flags=8843 metric 0 mtu 1500
> ether 02:4a:6b:6e:fc:00
> nd6 options=9
> groups: bridge
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: tap0 flags=143
> ifmaxaddr 0 port 6 priority 128 path cost 200
> member: lagg0 flags=143
> ifmaxaddr 0 port 4 priority 128 path cost 55
> tap0: flags=8943 metric 0 mtu 
> 1500
> options=8
> ether 00:bd:ea:f0:f6:00
> nd6 options=29
> media: Ethernet autoselect
> status: active
> groups: tap
> Opened by PID 1322



signature.asc
Description: PGP signature

Re: wpa_supplicant doesn't work with lagg

[Randy Westlund]

On Fri, Jul 29, 2016 at 12:02:56AM +0200, Ronald Klop wrote:
> I had the same problem a while ago.
> For some reason you need to use this construction to set the MAC now.
> 
> create_args_wlan0="wlanaddr 00:26:b9:12:34:56 country NL"
> 
> I don't know why this changed.

Thanks, that works.  I've filed a PR to update the handbook:

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


signature.asc
Description: PGP signature

freebsd-update and portsnap users still at risk of compromise

[Martin Schroeder]

On July 18, John Leyden, security editor at The Register, tweeted a link
to a libarchive ticket that had been sitting without a response for
almost a week.

tweet: https://twitter.com/jleyden/status/755016810865582081
libarchive ticket: https://github.com/libarchive/libarchive/issues/743

The ticket creator quoted an AV researcher who was likely posting to one
of the many early-alert vendor lists in the age of infosec balkanization
(IOW, a "courtesy heads-up" to FreeBSD users forking them money):

[QUOTE]
Our AV researchers have analyzed the following link that was cloud-
submitted as suspect:

https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f

The document is from an unknown author and describes "non-cryptanalytic
attacks against FreeBSD update components." The affected components are
the portsnap and freebsd-update tools, both directly and indirectly.

From what we can tell, the text file is part of a larger stash of
documents, all with the same attack-defense style. We have other
documents, dated 2014 and 2015, detailing attacks against the update
systems of multiple Linux distributions and the corresponding defenses
against "the adversary."

We believe this to be the work of an MITM-capable advanced threat actor.

Full details of our findings will be released in the coming weeks. This
is a courtesy heads-up to FreeBSD users.
[/QUOTE]

Another poster confirmed some of the attacks:

[QUOTE]
Here via John Leyden's tweet.

I don't have the time to test the portsnap attacks, but I can confirm
that the libarchive/tar and bspatch attacks work on our 10.x machines,
and I'm happy to test any libarchive/tar fixes.

Judging by the painstaking amount of work put into the bspatch exploit
especially, I think it's highly unlikely that the creator lacks the
means to deploy it via mitm. Otherwise, I've never seen anything like
this in terms of apparent work/reward. It would be comical if it weren't
so horrifying. Think of all those locked-down fbsd machines that have no
external-facing daemons/services and that perform only updates. Our
telecommunications floor alone has several dozen.

Someone needs to alert the fbsd mailing lists (-current, -security?)
pronto. I'd rather not mail them myself from work. And we should also
get more details on the linux distributions.
[/QUOTE]

I've been analyzing the document extensively since then. The targets are
as follows:

[1] portsnap via portsnap vulnerabilities
[2] portsnap via libarchive & tar anti-sandboxing vulnerabilities
[3] portsnap via bspatch vulnerabilities
[4] freebsd-update via bspatch vulnerabilities

Nothing has appeared in any official FreeBSD source about [1]. The
libarchive developers have finally confirmed [2] and are presumably
working on fixes.

A FreeBSD advisory just appeared for [3] & [4] (bspatch), but users
should be aware that running freebsd-update exposes their machines to
the very vulnerability it's correcting (a not insignificant fact that
was omitted from the advisory). Here's why:

[QUOTE]
 * The bspatch(1) utility is executed before SHA256 verification in both
 * freebsd-update(8) and portsnap(8).
[/QUOTE]

Even worse, the patch in the FreeBSD advisory is insufficient to prevent
heap corruption. I compared the patch in the FreeBSD advisory with the
"defense" patch in the document, and the former contains only a subset
of the checks in the latter. The document patch is in some ways cautious
to an insanely paranoid degree, mistrusting the error-checking stability
of system libraries and defending against compiler quirks that probably
won't exist in compiler optimization intelligence for many years, if
ever, though as a developer of clang-based static analyzers, I did take
an interest in one of the more usual integer-overflow culprits:

[ADVISORY PATCH - CONTAINS ONLY A SUBSET OF DOCUMENT PATCH]
/* Sanity-check */
+   if ((ctrl[0] < 0) || (ctrl[1] < 0))
+   errx(1,"Corrupt patch\n");
+
+   /* Sanity-check */
if(newpos+ctrl[0]>newsize)
errx(1,"Corrupt patch\n");
[/ADVISORY PATCH]

[DOCUMENT PATCH - THE CORRESPONDING PORTION]
/* Sanity-check */
-   if(newpos+ctrl[0]>newsize)
-   errx(1,"Corrupt patch\n");
+   if((ctrl[0]<0) || (ctrl[0]>INT_MAX) ||
+   (newpos>OFF_MAX-ctrl[0]) || (newpos+ctrl[0]>newsize))
+   errx(1,"Corrupt patch\n");

-   /* Read diff string */
+   /* Read diff string - 4th arg converted to int */
lenread = BZ2_bzRead(, dpfbz2, new + newpos, ctrl[0]);
if ((lenread < ctrl[0]) ||
((dbz2err != BZ_OK) && (dbz2err != BZ_STREAM_END)))
errx(1, "Corrupt patch\n");
[/DOCUMENT PATCH]

The ctrl[1] checks in the document patch are similar.

The basic idea is that for

if(newpos+ctrl[0]>newsize)

and

Jenkins build is still unstable: FreeBSD_HEAD #494

[jenkins-admin]

See 

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

Re: IWM(7260), no connect

[Adrian Chadd]

+imre,

Hi! Larry is having issues with r303418. Would you be able to help him out?

(If it's not too bad, can we back this out until you figure out what's
going on?)

Thanks!


-a


On 28 July 2016 at 18:05, Larry Rosenman  wrote:
> On 2016-07-28 20:02, Adrian Chadd wrote:
>>
>> Hi,
>>
>> Which commit(s) did you revert?
>>
>>
>>
>> -a
>
>
> revert r303418
>
> and now it connects again.
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: IWM(7260), no connect

[Larry Rosenman]

On 2016-07-28 20:02, Adrian Chadd wrote:

Hi,

Which commit(s) did you revert?



-a


revert r303418

and now it connects again.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: IWM(7260), no connect

[Adrian Chadd]

Hi,

Which commit(s) did you revert?



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

Jenkins build is unstable: FreeBSD_HEAD #493

[jenkins-admin]

See 

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

Re: IWM(7260), no connect

[Larry Rosenman]

That  seems to fix it, and I'm sorry I missed this in my Inbox earlier. 


On Thu, Jul 28, 2016 at 12:12:42PM +0300, Andriy Voskoboinyk wrote:
> Thu, 28 Jul 2016 05:39:55 +0300   Larry Rosenman  
> :
> 
> Try to revert r303418 (as I can see, r303416 and/or r303413 are not the  
> reason
> of this).
> 
> In case, if this will not help, you can try to add
> wlandebug_wlan0="state+scan+auth+assoc"
> into rc.conf to see where it fails.
> 
> > I'm running today's top of tree, and it doesn't seem to want to connect:
> >
> >
> > re0: flags=8843 metric 0 mtu 1500
> > 
> > options=8209b
> > ether 20:47:47:73:07:5f
> > inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
> > inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf
> > inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255
> > nd6 options=23
> > media: Ethernet autoselect (1000baseT )
> > status: active
> > lo0: flags=8049 metric 0 mtu 16384
> > options=63
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> > inet 127.0.0.1 netmask 0xff00
> > nd6 options=21
> > groups: lo
> > wlan0: flags=8c43 metric  
> > 0 mtu 1500
> > ether 58:91:cf:1a:45:69
> > inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3
> > nd6 options=23
> > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
> > status: no carrier
> > ssid "" channel 8 (2447 MHz 11g)
> > regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
> > deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
> > roaming MANUAL
> > groups: wlan
> >
> >
> > hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086  
> > rev=0x07 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Skylake Host Bridge/DRAM Registers'
> > class  = bridge
> > subclass   = HOST-PCI
> > pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086  
> > rev=0x07 hdr=0x01
> > vendor = 'Intel Corporation'
> > device = 'Skylake PCIe Controller (x16)'
> > class  = bridge
> > subclass   = PCI-PCI
> > pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086  
> > rev=0x07 hdr=0x01
> > vendor = 'Intel Corporation'
> > device = 'Skylake PCIe Controller (x8)'
> > class  = bridge
> > subclass   = PCI-PCI
> > vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086  
> > rev=0x06 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'HD Graphics 530'
> > class  = display
> > subclass   = VGA
> > none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086  
> > rev=0x07 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Skylake Processor Thermal Subsystem'
> > class  = dasp
> > xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H USB 3.0 xHCI Controller'
> > class  = serial bus
> > subclass   = USB
> > none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H Thermal subsystem'
> > class  = dasp
> > none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H Serial IO I2C Controller'
> > class  = dasp
> > none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H CSME HECI'
> > class  = simple comms
> > ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H SATA Controller [AHCI mode]'
> > class  = mass storage
> > subclass   = SATA
> > pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 chip=0xa1108086  
> > rev=0xf1 hdr=0x01
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H PCI Express Root Port'
> > class  = bridge
> > subclass   = PCI-PCI
> > pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 chip=0xa1148086  
> > rev=0xf1 hdr=0x01
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H PCI Express Root Port'
> > class  = bridge
> > subclass   = PCI-PCI
> > pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 chip=0xa1158086  

Re: IWM(7260), no connect

[Baptiste Daroussin]

On Thu, Jul 28, 2016 at 06:10:26PM -0500, Larry Rosenman wrote:
> negative.  no reponse (except for this one) at all.
> :(
> 
He did reply:

https://lists.freebsd.org/pipermail/freebsd-wireless/2016-July/006897.html

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: IWM(7260), no connect

[Larry Rosenman]

negative.  no reponse (except for this one) at all.
:(


On 2016-07-28 18:07, Adrian Chadd wrote:

Hi,

Andriy responded?


-adrian


On 28 July 2016 at 16:04, Larry Rosenman  wrote:

Anyone?


On 2016-07-27 21:39, Larry Rosenman wrote:


I'm running today's top of tree, and it doesn't seem to want to 
connect:



re0: flags=8843 metric 0 mtu 
1500


options=8209b
ether 20:47:47:73:07:5f
inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 
autoconf
inet 192.168.200.246 netmask 0xfc00 broadcast 
192.168.203.255

nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21
groups: lo
wlan0: flags=8c43
metric 0 mtu 1500
ether 58:91:cf:1a:45:69
inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 
0x3

nd6 options=23
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 8 (2447 MHz 11g)
regdomain FCC country US authmode WPA1+WPA2/802.11i privacy 
ON
deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS 
wme

roaming MANUAL
groups: wlan


hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 
chip=0x19108086

rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Host Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 
chip=0x19018086

rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x16)'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 
chip=0x19058086

rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x8)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 
chip=0x191b8086

rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 530'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 card=0x07061028 
chip=0x19038086

rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Processor Thermal Subsystem'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 
chip=0xa12f8086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:  class=0x118000 card=0x07061028 
chip=0xa1318086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:  class=0x118000 card=0x07061028 
chip=0xa1608086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none3@pci0:0:22:0:  class=0x078000 card=0x07061028 
chip=0xa13a8086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 
chip=0xa1038086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 
chip=0xa1108086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 
chip=0xa1148086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 
chip=0xa1158086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 
chip=0xa1168086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 card=0x07061028 
chip=0xa14e8086

rev=0x31 

Re: IWM(7260), no connect

[Adrian Chadd]

Hi,

Andriy responded?


-adrian


On 28 July 2016 at 16:04, Larry Rosenman  wrote:
> Anyone?
>
>
> On 2016-07-27 21:39, Larry Rosenman wrote:
>>
>> I'm running today's top of tree, and it doesn't seem to want to connect:
>>
>>
>> re0: flags=8843 metric 0 mtu 1500
>>
>> options=8209b
>> ether 20:47:47:73:07:5f
>> inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
>> inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf
>> inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255
>> nd6 options=23
>> media: Ethernet autoselect (1000baseT )
>> status: active
>> lo0: flags=8049 metric 0 mtu 16384
>> options=63
>> inet6 ::1 prefixlen 128
>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>> inet 127.0.0.1 netmask 0xff00
>> nd6 options=21
>> groups: lo
>> wlan0: flags=8c43
>> metric 0 mtu 1500
>> ether 58:91:cf:1a:45:69
>> inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3
>> nd6 options=23
>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>> status: no carrier
>> ssid "" channel 8 (2447 MHz 11g)
>> regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
>> deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
>> roaming MANUAL
>> groups: wlan
>>
>>
>> hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086
>> rev=0x07 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Skylake Host Bridge/DRAM Registers'
>> class  = bridge
>> subclass   = HOST-PCI
>> pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086
>> rev=0x07 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Skylake PCIe Controller (x16)'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086
>> rev=0x07 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Skylake PCIe Controller (x8)'
>> class  = bridge
>> subclass   = PCI-PCI
>> vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'HD Graphics 530'
>> class  = display
>> subclass   = VGA
>> none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086
>> rev=0x07 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Skylake Processor Thermal Subsystem'
>> class  = dasp
>> xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H USB 3.0 xHCI Controller'
>> class  = serial bus
>> subclass   = USB
>> none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H Thermal subsystem'
>> class  = dasp
>> none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H Serial IO I2C Controller'
>> class  = dasp
>> none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H CSME HECI'
>> class  = simple comms
>> ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H SATA Controller [AHCI mode]'
>> class  = mass storage
>> subclass   = SATA
>> pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 chip=0xa1108086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 chip=0xa1148086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 chip=0xa1158086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 chip=0xa1168086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel 

Re: IWM(7260), no connect

[Larry Rosenman]

Anyone?

On 2016-07-27 21:39, Larry Rosenman wrote:
I'm running today's top of tree, and it doesn't seem to want to 
connect:



re0: flags=8843 metric 0 mtu 
1500


options=8209b
ether 20:47:47:73:07:5f
inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf
inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21
groups: lo
wlan0: flags=8c43
metric 0 mtu 1500
ether 58:91:cf:1a:45:69
inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3
nd6 options=23
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 8 (2447 MHz 11g)
regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
roaming MANUAL
groups: wlan


hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Host Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086
rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x16)'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086
rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x8)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 530'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Processor Thermal Subsystem'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 chip=0xa1108086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 chip=0xa1148086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 chip=0xa1158086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 chip=0xa1168086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 card=0x07061028 chip=0xa14e8086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H LPC Controller'
class  = bridge
subclass   = PCI-ISA
none4@pci0:0:31:2:  class=0x058000 card=0x07061028 chip=0xa1218086
rev=0x31 hdr=0x00

Re: wpa_supplicant doesn't work with lagg

[Ronald Klop]

I had the same problem a while ago.
For some reason you need to use this construction to set the MAC now.

create_args_wlan0="wlanaddr 00:26:b9:12:34:56 country NL"

I don't know why this changed.

Regards,
Ronald.


On Thu, 28 Jul 2016 21:41:46 +0200, Randy Westlund   
wrote:



I'm having trouble using the lagg driver with wpa_supplicant.  When I
boot with this standard configuration, my wifi works fine:


# Normal config.
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
ifconfig_em0="DHCP"


But when I boot with a lagg configuration, wpa_supplicant can't connect.


# Lagg config.
ifconfig_em0="up"
ifconfig_iwn0="ether 3c:97:0e:46:70:ca"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"


The system spends a full 5 minutes during boot trying to send DHCP
requests before finally giving up.  After boot, ifconfig shows that
wlan0 has the right ssid, but the status is 'no carrier':

wlan0: flags=8843 metric 0 mtu  
1500

ether 3c:97:0e:46:70:ca
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid neural_network channel 1 (2412 MHz 11g ht/40+)
regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS
ampdulimit 8k -amsdutx amsdurx shortgi -stbc wme roaming MANUAL
groups: wlan


If I then manually kill wpa_supplicant and restart it with the same
command, it works fine.

/usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant.conf -D  
bsd -P /var/run/wpa_supplicant/wlan0.pid


wlan0: flags=8843 metric 0 mtu  
1500

ether 3c:97:0e:46:70:ca
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid neural_network channel 1 (2412 MHz 11g ht/40+) bssid  
c4:04:15:90:f5:fd

regdomain FCC country US authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid  
60
protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx  
shortgi

-stbc wme roaming MANUAL
groups: wlan


/var/log/messages shows:


Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
Jul 28 15:22:09 mako kernel: wlan0: link state changed to UP
Jul 28 15:22:09 mako kernel: lagg0: link state changed to UP
Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
Jul 28 15:22:09 mako kernel: wlan0: link state changed to UP
Jul 28 15:22:09 mako kernel: lagg0: link state changed to UP
Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
Jul 28 15:22:09 mako kernel: wlan0: link state changed to UP
Jul 28 15:22:09 mako kernel: lagg0: link state changed to UP
Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
[snip]
Jul 28 15:22:23 mako wpa_supplicant[329]: wlan0:  
CTRL-EVENT-SSID-REENABLED id=2 ssid="neural_network"
Jul 28 15:22:23 mako wpa_supplicant[329]: wlan0: Trying to associate  
with c4:04:15:90:f5:fd (SSID='neural_network' freq=2412 MHz)

Jul 28 15:22:23 mako kernel: wlan0: link state changed to UP
Jul 28 15:22:23 mako kernel: lagg0: link state changed to UP
Jul 28 15:22:23 mako wpa_supplicant[329]: wlan0: Associated with  
c4:04:15:90:f5:fd
Jul 28 15:22:23 mako dhclient[533]: send_packet: No buffer space  
available
Jul 28 15:22:27 mako dhclient[533]: send_packet: No buffer space  
available

Jul 28 15:22:27 mako kernel: wlan0: link state changed to DOWN
Jul 28 15:22:27 mako kernel: lagg0: link state changed to DOWN
Jul 28 15:22:27 mako wpa_supplicant[329]: wlan0:  
CTRL-EVENT-DISCONNECTED bssid=c4:04:15:90:f5:fd reason=0
Jul 28 15:22:27 mako wpa_supplicant[329]: wlan0:  
CTRL-EVENT-SSID-TEMP-DISABLED id=2 ssid="neural_network"  
auth_failures=7 duration=90 reason=CONN_FAILED

Jul 28 15:22:28 mako login: ROOT LOGIN (root) ON ttyv0
Jul 28 15:22:31 mako dhclient[533]: send_packet: Network is down
Jul 28 15:23:06 mako last message repeated 4 times


This is my hardware:

iwn0@pci0:3:0:0:class=0x028000 card=0x13118086 chip=0x00858086  
rev=0x34 hdr=0x00

vendor = 'Intel Corporation'
device = 'Centrino Advanced-N 6205 [Taylor Peak]'
class  = network



I know I had this working at one point on 10.2-RELEASE, but recently
I've tried both 11.0-BETA2 and 12-CURRENT and get this behavior.  Any
advice for debugging?

___
freebsd-current@freebsd.org mailing list

Re: Boot environments and zfs canmount=noauto

[Ultima]

Is this actually required? Instead of the extra steps, how about just
moving/creating each dataset into each BE (or at least the ones desired)
and setting them to mountpoint=inherit. With zfs_enable="YES" this should
mount the dataset appropriately. Only the root BE should need
canmount=noauto because if the parent dataset is not mounted the child will
inherently not mount.

Is this not sufficient?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: FreeBSD_HEAD #492

[jenkins-admin]

o_args  ->  passed  
[0.074s]
[192.168.10.2] out: libexec/atf/atf-sh/integration_test:set_e  ->  passed  
[0.086s]
[192.168.10.2] out: libexec/atf/atf-sh/normalize_test:main  ->  passed  [0.088s]
[192.168.10.2] out: libexec/atf/atf-sh/tc_test:default_status  ->  passed  
[0.154s]
[192.168.10.2] out: libexec/atf/atf-sh/tc_test:missing_body  ->  passed  
[0.065s]
[192.168.10.2] out: libexec/atf/atf-sh/tp_test:srcdir  ->  passed  [0.161s]
[192.168.10.2] out: 
[192.168.10.2] out: Results file id is usr_tests.20160728-203950-917866
[192.168.10.2] out: Results saved to 
/root/.kyua/store/results.usr_tests.20160728-203950-917866.db
[192.168.10.2] out: 
[192.168.10.2] out: 5724/5725 passed (1 failed)
[192.168.10.2] out: 

Warning: run() received nonzero return code 1 while executing 'kyua test'!


[192.168.10.2] run: kyua report --verbose --results-filter 
passed,skipped,xfail,broken,failed  --output test-report.txt
[192.168.10.2] run: kyua report-junit --output=test-report.xml
[192.168.10.2] run: shutdown -p now
[192.168.10.2] out: Shutdown NOW!
[192.168.10.2] out: shutdown: [pid 82451]
[192.168.10.2] out: 

kyuatestprompt # lock order reversal:
 1st 0xf80009d5f9a0 ufs (ufs) @ 
/builds/workspace/FreeBSD_HEAD/src/sys/kern/vfs_mount.c:1244
 2nd 0xf80009d509a0 devfs (devfs) @ 
/builds/workspace/FreeBSD_HEAD/src/sys/ufs/ffs/ffs_vfsops.c:1590
stack backtrace:
#0 0x80aa9e60 at witness_debugger+0x70
#1 0x80aa9d54 at witness_checkorder+0xe54
#2 0x80a22f02 at __lockmgr_args+0x4c2
#3 0x80af9bec at vop_stdlock+0x3c
#4 0x81018410 at VOP_LOCK1_APV+0xe0
#5 0x80b1ac9a at _vn_lock+0x9a
#6 0x80d0b3b2 at ffs_sync+0x2f2
#7 0x80b1c370 at vfs_write_suspend+0x180
#8 0x80b1c5b7 at vfs_write_suspend_umnt+0x47
#9 0x80d0ac74 at ffs_unmount+0x54
#10 0x80b03784 at dounmount+0x6f4
#11 0x80b02ffd at sys_unmount+0x35d
#12 0x80ebbb7b at amd64_syscall+0x2db
#13 0x80e9be0b at Xfast_syscall+0xfb
GEOM_CONCAT: Device concat.0qRhLH created (id=710705534).
GEOM_CONCAT: Disk md0 attached to concat.0qRhLH.
GEOM_CONCAT: Disk md1 attached to concat.0qRhLH.
GEOM_CONCAT: Disk md2 attached to concat.0qRhLH.
GEOM_CONCAT: Device concat/concat.0qRhLH activated.
GEOM_CONCAT: Disk md2 removed from concat.0qRhLH.
GEOM_CONCAT: Device concat/concat.0qRhLH deactivated.
GEOM_CONCAT: Disk md1 removed from concat.0qRhLH.
GEOM_CONCAT: Disk md0 removed from concat.0qRhLH.
GEOM_CONCAT: Device concat.0qRhLH destroyed.
GEOM_CONCAT: Device concat.AJR9Cw created (id=1589844515).
GEOM_CONCAT: Disk md0 attached to concat.AJR9Cw.
GEOM_CONCAT: Disk md1 attached to concat.AJR9Cw.
GEOM_CONCAT: Disk md2 attached to concat.AJR9Cw.
GEOM_CONCAT: Device concat/concat.AJR9Cw activated.
GEOM_CONCAT: Disk md2 removed from concat.AJR9Cw.
GEOM_CONCAT: Device concat/concat.AJR9Cw deactivated.
GEOM_CONCAT: Disk md1 removed from concat.AJR9Cw.
GEOM_CONCAT: Disk md0 removed from concat.AJR9Cw.
GEOM_CONCAT: Device concat.AJR9Cw destroyed.
GEOM_ELI: Device md0.eli created.
GEOM_ELI: EnTraceback (most recent call last):
  File "freebsd-ci/scripts/test/run-tests.py", line 207, in 
main(sys.argv)
  File "freebsd-ci/scripts/test/run-tests.py", line 79, in main
runTest()
  File "freebsd-ci/scripts/test/run-tests.py", line 187, in runTest
child2.expect(pexpect.EOF, timeout=1000)
  File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, 
in expect
timeout, searchwindowsize)
  File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, 
in expect_list
timeout, searchwindowsize)
  File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, 
in expect_loop
raise TIMEOUT(str(err) + '\n' + str(self))
pexpect.TIMEOUT: Timeout exceeded.

version: 3.3
command: /usr/sbin/bhyve
args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', 
u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', 
u'2:0,virtio-net,tap10,mac=58:9c:fc:00:00:2e', u'-s', 
u'3:0,ahci-hd,/net/jenkins-10.freebsd.org//builds/workspace/FreeBSD_HEAD/image/src/test.img',
 u'-l', u'com1,stdio', u'vm_test']
searcher: 
buffer (last 100 chars): 'R9Cw.\r\nGEOM_CONCAT: Device concat.AJR9Cw 
destroyed.\r\nGEOM_ELI: Device md0.eli created.\r\nGEOM_ELI: En'
before (last 100 chars): 'R9Cw.\r\nGEOM_CONCAT: Device concat.AJR9Cw 
destroyed.\r\nGEOM_ELI: Device md0.eli created.\r\nGEOM_ELI: En'
after: 
match: None
match_index: None
exitstatus: None
flag_eof: False
pid: 70886
child_fd: 4
closed: False
timeout: 30
delimiter: 
logfile: ', mode 'w' at 0x800671150>
logfile_read: None
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0.05
delayafterclose: 0.1
delayafterterminate: 0.1
[Pipeline] }
[Pipeline] // node
[Pipeline] node
Running on master in /usr/local/jenkins/workspace/FreeBSD_HEAD
[Pipeline] {
[Pipeline] step
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Call for testing on vagrant-bhyve

[Tong Li]

Hello Everyone,

As part of this year's GSoC, we created a project named vagrant-bhyve
which enables bhyve as a backend
of Vagrant so that we can use Vagrant to manage bhyve VMs. Now most of
fundamental functions are working, including booting up a box, providing
network access to a box, getting ssh into a box (you can check status in
details on GitHub). My mentors and I have done some testes, but we still
need more hands to help us find bugs. We also need more users' feedbacks to
help us confirm most needed functions other than basical ones and
prioritize their implementation. So, please help us. I have documented a
step by step guide on how to test vagrant-bhyve, you can follow that. When
you find some problems or need some new features, feel free to open an
issue. All your testing and feedback will be much appreciated. :)

Here is another thing. I am using PF to porvide NAT and port forwarding
(thanks to vm-bhyve's hints), but got two problems. One is about PF anthor
and another is about port forwarding. I opened two issues for them, please
also help me figure out these two problems if you have met them before.
Thanks a lot.

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

Re: Boot environments and zfs canmount=noauto

[Randy Westlund]

On Thu, Jul 28, 2016 at 01:34:03PM +0300, Andriy Gapon wrote:
> Locally I have the following rc script to handle subordinate datasets of
> a boot environment: http://dpaste.com/0Q0JPGN.txt
> It is designed for exactly the scenario described above.
> The script is automatically enabled when zfs_enable is enabled.
> 
> It would probably make sense to include the script into the OS after
> some testing and a review.

Awesome, thanks.  I'll play with this over the weekend.

Maybe someday we'll be able to set something like canmount=with-parent,
which could be like noauto, except that it would mount when its parent
mounts.


signature.asc
Description: PGP signature

wpa_supplicant doesn't work with lagg

[Randy Westlund]

I'm having trouble using the lagg driver with wpa_supplicant.  When I
boot with this standard configuration, my wifi works fine:

> # Normal config.
> wlans_iwn0="wlan0"
> ifconfig_wlan0="WPA DHCP"
> ifconfig_em0="DHCP"

But when I boot with a lagg configuration, wpa_supplicant can't connect.

> # Lagg config.
> ifconfig_em0="up"
> ifconfig_iwn0="ether 3c:97:0e:46:70:ca"
> wlans_iwn0="wlan0"
> ifconfig_wlan0="WPA"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"

The system spends a full 5 minutes during boot trying to send DHCP
requests before finally giving up.  After boot, ifconfig shows that
wlan0 has the right ssid, but the status is 'no carrier':

> wlan0: flags=8843 metric 0 mtu 1500
> ether 3c:97:0e:46:70:ca
> nd6 options=29
> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
> status: no carrier
> ssid neural_network channel 1 (2412 MHz 11g ht/40+)
> regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
> deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS
> ampdulimit 8k -amsdutx amsdurx shortgi -stbc wme roaming MANUAL
> groups: wlan

If I then manually kill wpa_supplicant and restart it with the same
command, it works fine.

> /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant.conf -D bsd -P 
> /var/run/wpa_supplicant/wlan0.pid

> wlan0: flags=8843 metric 0 mtu 1500
> ether 3c:97:0e:46:70:ca
> nd6 options=29
> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
> status: associated
> ssid neural_network channel 1 (2412 MHz 11g ht/40+) bssid 
> c4:04:15:90:f5:fd
> regdomain FCC country US authmode WPA2/802.11i privacy ON
> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi
> -stbc wme roaming MANUAL
> groups: wlan

/var/log/messages shows:

> Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
> Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
> Jul 28 15:22:09 mako kernel: wlan0: link state changed to UP
> Jul 28 15:22:09 mako kernel: lagg0: link state changed to UP
> Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
> Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
> Jul 28 15:22:09 mako kernel: wlan0: link state changed to UP
> Jul 28 15:22:09 mako kernel: lagg0: link state changed to UP
> Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
> Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
> Jul 28 15:22:09 mako kernel: wlan0: link state changed to UP
> Jul 28 15:22:09 mako kernel: lagg0: link state changed to UP
> Jul 28 15:22:09 mako kernel: wlan0: link state changed to DOWN
> Jul 28 15:22:09 mako kernel: lagg0: link state changed to DOWN
> [snip]
> Jul 28 15:22:23 mako wpa_supplicant[329]: wlan0: CTRL-EVENT-SSID-REENABLED 
> id=2 ssid="neural_network"
> Jul 28 15:22:23 mako wpa_supplicant[329]: wlan0: Trying to associate with 
> c4:04:15:90:f5:fd (SSID='neural_network' freq=2412 MHz)
> Jul 28 15:22:23 mako kernel: wlan0: link state changed to UP
> Jul 28 15:22:23 mako kernel: lagg0: link state changed to UP
> Jul 28 15:22:23 mako wpa_supplicant[329]: wlan0: Associated with 
> c4:04:15:90:f5:fd
> Jul 28 15:22:23 mako dhclient[533]: send_packet: No buffer space available
> Jul 28 15:22:27 mako dhclient[533]: send_packet: No buffer space available
> Jul 28 15:22:27 mako kernel: wlan0: link state changed to DOWN
> Jul 28 15:22:27 mako kernel: lagg0: link state changed to DOWN
> Jul 28 15:22:27 mako wpa_supplicant[329]: wlan0: CTRL-EVENT-DISCONNECTED 
> bssid=c4:04:15:90:f5:fd reason=0
> Jul 28 15:22:27 mako wpa_supplicant[329]: wlan0: 
> CTRL-EVENT-SSID-TEMP-DISABLED id=2 ssid="neural_network" auth_failures=7 
> duration=90 reason=CONN_FAILED
> Jul 28 15:22:28 mako login: ROOT LOGIN (root) ON ttyv0
> Jul 28 15:22:31 mako dhclient[533]: send_packet: Network is down
> Jul 28 15:23:06 mako last message repeated 4 times

This is my hardware:

> iwn0@pci0:3:0:0:class=0x028000 card=0x13118086 chip=0x00858086 
> rev=0x34 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Centrino Advanced-N 6205 [Taylor Peak]'
> class  = network


I know I had this working at one point on 10.2-RELEASE, but recently
I've tried both 11.0-BETA2 and 12-CURRENT and get this behavior.  Any
advice for debugging?


signature.asc
Description: PGP signature

Jenkins build is still unstable: FreeBSD_HEAD #491

[jenkins-admin]

See 

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

Jenkins build is still unstable: FreeBSD_HEAD #490

[jenkins-admin]

See 

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

Re: EARLY_AP_STARTUP hangs during boot

[John Baldwin]

On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote:
> On Wed, 27 Jul 2016 14:43:36 -0700
> John Baldwin  wrote:
> 
> > On Tuesday, June 07, 2016 12:06:54 PM Gary Jennejohn wrote:
> > > On Tue, 31 May 2016 13:10:06 -0700
> > > John Baldwin  wrote:
> > >   
> > > > On Saturday, May 28, 2016 02:11:41 PM Gary Jennejohn wrote:  
> > > > > On Fri, 27 May 2016 09:50:05 +0200
> > > > > Gary Jennejohn  wrote:
> > > > > 
> > > > > > On Thu, 26 May 2016 16:54:35 -0700
> > > > > > John Baldwin  wrote:
> > > > > > 
> > > > > > > On Tuesday, May 17, 2016 06:47:41 PM Gary Jennejohn wrote:  
> > > > > > > > On Mon, 16 May 2016 10:54:19 -0700
> > > > > > > > John Baldwin  wrote:
> > > > > > > > 
> > > > > > > > > On Monday, May 16, 2016 12:22:42 PM Gary Jennejohn wrote: 
> > > > > > > > >
> > > > > > > > > > I tried out EARLY_AP_STARTUP, but the kernel hangs and I 
> > > > > > > > > > can't
> > > > > > > > > > break into DDB.
> > > > > > > > > > 
> > > > > > > > > > I did a verbose boot and the last lines I see are related 
> > > > > > > > > > to routing
> > > > > > > > > > MSI-X to various local APIC vectors.  I copied the last few 
> > > > > > > > > > lines and
> > > > > > > > > > they look like this:
> > > > > > > > > > 
> > > > > > > > > > msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> > > > > > > > > > msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> > > > > > > > > > msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> > > > > > > > > > msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
> > > > > > > >  ^^^ Assigning
> > > > > > > > > > 
> > > > > > > > > > I tried disabling msi and msix in /boot/loader.conf, but 
> > > > > > > > > > the settings
> > > > > > > > > > were ignored (probabaly too early).  
> > > > > > > > > 
> > > > > > > > > No, those settings are not too early.  However, the routing 
> > > > > > > > > to different
> > > > > > > > > CPUs now happens earlier than it used to.  What is the line 
> > > > > > > > > before the
> > > > > > > > > MSI lines?  You can take a picture with your phone/camera if 
> > > > > > > > > that's simplest.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Here a few lines before the MSI routing happens:
> > > > > > > > 
> > > > > > > > hpet0:  iomem 0xfed0-0xfed003ff 
> > > > > > > > irq 0,8 on acpi0
> > > > > > > > hpet0: vendor 0x4353, rev 0x1, 14318180 Hz, 3 timers, legacy 
> > > > > > > > route
> > > > > > > > hpet0: t0 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > > > hpet0: t1 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > > > hpet0: t2 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > > > Timecounter "HPET" frequency 14318180 Hz quality 950
> > > > > > > 
> > > > > > > The assigning message means it is in the loop using
> > > > > > > bus_bind_intr() to setup per-CPU timers.  Can you please try
> > > > > > > setting 'hint.hpet.0.per_cpu=0' at the loader prompt to see if
> > > > > > > disabling the use of per-CPU timers allows you to boot?
> > > > > > >   
> > > > > > 
> > > > > > Something has changed since the last time I generated a kernel with
> > > > > > this option.
> > > > > > 
> > > > > > Now I get a NULL-pointer dereference in the kernel, doesn't matter
> > > > > > whether I set the hint or not.
> > > > > > 
> > > > > 
> > > > > OK, now that the startup has been fixed, I tried setting the hint at
> > > > > the loader prompt, but the kenel hangs in exactly the same place as
> > > > > before.  I actually booted twice to make certain I hadn't made a
> > > > > typo when setting the hint.
> > > > 
> > > > Humm, it shouldn't be calling bus_bind_intr() if the hint is set.  
> > > > Actually,
> > > > I guess it just binds them all to first CPU if per-CPU timers aren't 
> > > > set.
> > > > Can you add debug printfs to hpet_attach() in 
> > > > sys/dev/acpica/acpi_hpet.c to
> > > > narrow down which line in that function it hangs after?
> > > > 
> > > > Another option to try is to add the following to your kernel config:
> > > > 
> > > > options KTR
> > > > options KTR_COMPILE=KTR_PROC
> > > > options KTR_MASK=KTR_PROC
> > > > options KTR_VERBOSE=1
> > > > 
> > > > this will spew a lot of crap to the screen, but if it stops spewing 
> > > > when it
> > > > hangs then it might be tell us where the system is hung.  If you have 
> > > > any way
> > > > to configure a serial console then this would also be useful even if it 
> > > > spews
> > > > constantly when it is hung (assuming you could log the output of the 
> > > > serial
> > > > console).
> > > >   
> > > 
> > > I used the KTR options.
> > > 
> > > After the Timecounter "HPET" frequency 14318180 Hz quality 950 I see
> > > 
> > > cpu0 mi_switch: old thread 1 (swapper)
> > > cpu0 mi_switch: new thread 10022 (if_config_tqg_0)
> > > cpu0 

Jenkins build is still unstable: FreeBSD_HEAD #489

[jenkins-admin]

See 

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

Re: Boot environments and zfs canmount=noauto

[Miroslav Lachman]

Andriy Gapon wrote on 07/28/2016 14:44:


I also would like to add, just in case, that I never set a BE's
mountpoint to '/'.  I leave it at its default value like
/pond/ROOT/foobar.  When the BE is active it would be mounted at /
anyway.  And when it is not active and I want to access it for some
modifications, etc, then I can mount it simply with zfs mount and have
it at a non-interfering location.  Ditto for its subordinate datasets.

I am saying this, because it seems that that is not how the FreeBSD
installer ("zfsboot") configures the default BE that it creates.  I am
not sure what sysutils/beadm expects and configures in this regard.  I
use my own custom script for doing beadm-like things.


beadm works with the following layout

NAME   USED  AVAIL  REFER  MOUNTPOINT
sys   10.8G  3.63G96K  none
sys/ROOT  1.45G  3.63G96K  none
sys/ROOT/b4pupg_20160516 8K  3.63G   606M  /
sys/ROOT/b4pupg_20160523 8K  3.63G   621M  /
sys/ROOT/b4pupg_20160531 8K  3.63G   643M  /
sys/ROOT/b4pupg_20160616 8K  3.63G   649M  /
sys/ROOT/b4pupg_20160627 8K  3.63G   655M  /
sys/ROOT/b4supd_20160523 8K  3.63G   621M  /
sys/ROOT/b4supd_20160728 8K  3.63G   664M  /
sys/ROOT/default  1.45G  3.63G   663M  /
sys/tmp104K  3.63G   104K  /tmp
sys/usr   7.42M  3.63G96K  none
sys/usr/home  6.72M  3.63G  6.72M  /usr/home
sys/usr/obj 96K  3.63G96K  /usr/obj
sys/usr/ports  428K  3.63G   332K  /usr/ports
sys/usr/ports/distfiles 96K  3.63G96K  /usr/ports/distfiles
sys/usr/src 96K  3.63G96K  /usr/src
sys/var   9.31G  3.63G96K  none
sys/var/audit   96K  3.63G96K  /var/audit
sys/var/log   9.31G  3.63G  9.31G  /var/log
sys/var/tmp152K  3.63G   152K  /var/tmp


Note mountpoint "none" on sys/usr and sys/var. They are not mounted 
intermediate directories, because /usr and /var should be part of the 
BE, but some subdirectories should not be part of BE.


BEs under sys/ROOT have this properties

# zfs get all | grep mount
sys  mounted  no-
sys  mountpoint   none  local
sys  canmount ondefault
sys/ROOT mounted  no-
sys/ROOT mountpoint   none  inherited from sys
sys/ROOT canmount ondefault
sys/ROOT/b4pupg_20160516 mounted  no-
sys/ROOT/b4pupg_20160516 mountpoint   / local
sys/ROOT/b4pupg_20160516 canmount off   local
sys/ROOT/b4pupg_20160523 mounted  no-
sys/ROOT/b4pupg_20160523 mountpoint   / local
sys/ROOT/b4pupg_20160523 canmount off   local
sys/ROOT/b4pupg_20160531 mounted  no-
sys/ROOT/b4pupg_20160531 mountpoint   / local
sys/ROOT/b4pupg_20160531 canmount off   local
sys/ROOT/b4pupg_20160616 mounted  no-
sys/ROOT/b4pupg_20160616 mountpoint   / local
sys/ROOT/b4pupg_20160616 canmount off   local
sys/ROOT/b4pupg_20160627 mounted  no-
sys/ROOT/b4pupg_20160627 mountpoint   / local
sys/ROOT/b4pupg_20160627 canmount off   local
sys/ROOT/b4supd_20160523 mounted  no-
sys/ROOT/b4supd_20160523 mountpoint   / local
sys/ROOT/b4supd_20160523 canmount off   local
sys/ROOT/b4supd_20160728 mounted  no-
sys/ROOT/b4supd_20160728 mountpoint   / local
sys/ROOT/b4supd_20160728 canmount off   local
sys/ROOT/default mounted  yes   -
sys/ROOT/default mountpoint   / local
sys/ROOT/default canmount ondefault

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

Re: Boot environments and zfs canmount=noauto

[Andriy Gapon]

I also would like to add, just in case, that I never set a BE's
mountpoint to '/'.  I leave it at its default value like
/pond/ROOT/foobar.  When the BE is active it would be mounted at /
anyway.  And when it is not active and I want to access it for some
modifications, etc, then I can mount it simply with zfs mount and have
it at a non-interfering location.  Ditto for its subordinate datasets.

I am saying this, because it seems that that is not how the FreeBSD
installer ("zfsboot") configures the default BE that it creates.  I am
not sure what sysutils/beadm expects and configures in this regard.  I
use my own custom script for doing beadm-like things.

On 28/07/2016 13:34, Andriy Gapon wrote:
> On 28/07/2016 05:18, Allan Jude wrote:
>> On 2016-07-27 22:05, Randy Westlund wrote:
>>> I'm trying to follow Michael Dexter's post about using bhyve with boot
>>> environments.  It involves moving all child datasets under
>>> zroot/ROOT/default, so that you can have entirely independent systems.
>>>
>>> http://callfortesting.org/bhyve-boot-environments/
>>>
 Let's change the datasets with "canmount on" to "canmount noauto":
 [snip]
 Considering that this setting is harmless to a system with a single
 boot environment, I would not object to it being the default. Hint
 hint. 
>>>
>>> When I set all the datasets with canmount=on to canmount=noauto, only
>>> zroot/ROOT/default gets mounted on next boot.  It's my understanding
>>> that 'zfs mount -a' doesn't mount datasets with canmount=noauto, but if
>>> I leave them with canmount=on, they will try to mount regardless of
>>> which BE is active.
>>>
>>> I'm trying this with 11.0-BETA2.  Can sometime tell me what I'm missing?
>>>
>>
>> You are not missing anything. This is why the default is to have all
>> files that are specific to a BE be in the root dataset, and only files
>> that are global (like home directory, etc) be outside of the BE.
> 
> Locally I have the following rc script to handle subordinate datasets of
> a boot environment: http://dpaste.com/0Q0JPGN.txt
> It is designed for exactly the scenario described above.
> The script is automatically enabled when zfs_enable is enabled.
> 
> It would probably make sense to include the script into the OS after
> some testing and a review.
> 


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

FreeBSD_HEAD_amd64_gcc - Build #1453 - Failure

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc - Build #1453 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1453/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1453/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1453/console

Change summaries:

303429 by mav:
Once more refactor KPI between NTB hardware and consumers.

New design allows hardware resources to be split between several consumers.
For example, one BAR can be dedicated for remote memory access, while other
resources can be used for packet transport for virtual Ethernet interface.
And even without resource split, this code allows to specify which consumer
driver should attach the hardware.

>From some points this makes the code even closer to Linux one, even though
Linux does not provide the described flexibility.

303428 by ed:
Add NI_NUMERICSCOPE.

POSIX also declares NI_NUMERICSCOPE, which makes getnameinfo() return a
numerical scope identifier. The interesting thing is that support for
this is already present in code, but #ifdef disabled. Expose this
functionality by placing a definition for it in .

While there, remove references to NI_WITHSCOPEID, as that got removed 11
years ago.

303427 by ed:
Change type of MB_CUR_MAX and MB_CUR_MAX_L() to size_t.

POSIX requires that MB_CUR_MAX expands to an expression of type size_t.
It currently expands to an int. As these are already macros, don't
change the underlying type of these functions. There is no ned to touch
those.

Differential Revision:  https://reviews.freebsd.org/D6645

303426 by kib:
Rewrite subr_sleepqueue.c use of callouts to not depend on the
specifics of callout KPI.  Esp., do not depend on the exact interface
of callout_stop(9) return values.

The main change is that instead of requiring precise callouts, code
maintains absolute time to wake up.  Callouts now should ensure that a
wake occurs at the requested moment, but we can tolerate both run-away
callout, and callout_stop(9) lying about running callout either way.

As consequence, it removes the constant source of the bugs where
sleepq_check_timeout() causes uninterruptible thread state where the
thread is detached from CPU, see e.g. r234952 and r296320.

Patch also removes dual meaning of the TDF_TIMEOUT flag, making code
(IMO much) simpler to reason about.

Tested by:  pho
Reviewed by:jhb
Sponsored by:   The FreeBSD Foundation
MFC after:  1 month
Differential revision:  https://reviews.freebsd.org/D7137

303425 by kib:
Extract the calculation of the callout fire time into the new function
callout_when(9).  See the man page update for the description of the
intended use.

Tested by:  pho
Reviewed by:jhb, bjk (man page updates)
Sponsored by:   The FreeBSD Foundation
MFC after:  1 month
X-Differential revision:https://reviews.freebsd.org/D7137

303424 by kib:
Fix typo in comment.

MFC after:  3 days

303423 by kib:
When a debugger attaches to the process, SIGSTOP is sent to the
target.  Due to a way issignal() selects the next signal to deliver
and report, if the simultaneous or already pending another signal
exists, that signal might be reported by the next waitpid(2) call.
This causes minor annoyance for debuggers, which must be prepared to
take any signal as the first event, then filter SIGSTOP later.

More importantly, for tools like gcore(1), which attach and then
detach without processing events, SIGSTOP might leak to be delivered
after PT_DETACH.  This results in the process being unintentionally
stopped after detach, which is fatal for automatic tools.

The solution is to force SIGSTOP to be the first signal reported after
the attach.  Attach code is modified to set P2_PTRACE_FSTP to indicate
that the attaching ritual was not yet finished, and issignal() prefers
SIGSTOP in that condition.  Also, the thread which handles
P2_PTRACE_FSTP is made to guarantee to own p_xthread during the first
waitpid(2).  All that ensures that SIGSTOP is consumed first.

Additionally, if P2_PTRACE_FSTP is still set on detach, which means
that waitpid(2) was not called at all, SIGSTOP is removed from the
queue, ensuring that the process is resumed on detach.

In issignal(), when acting on STOPing signals, remove the signal from
queue before suspending.  Otherwise parallel attach could result in
ptracestop() acting on that STOP as if it was the STOP signal from the
attach.  Then SIGSTOP from attach leaks again.

As a minor refactoring, some bits of the common attach code is moved
to new helper proc_set_traced().

Reported by:markj
Reviewed by:jhb, markj
Tested by:  pho
Sponsored by:   The FreeBSD Foundation
MFC after:  2 weeks
Differential revision:  https://reviews.freebsd.org/D7256

303422 by sephe:
hyperv/vmbus: Inclusion cleanup

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7334

303421 by sephe:
hyperv/vmbus: Avoid unnecessary mb()

MFC after:  1 week

Re: Boot environments and zfs canmount=noauto

[Andriy Gapon]

On 28/07/2016 05:18, Allan Jude wrote:
> On 2016-07-27 22:05, Randy Westlund wrote:
>> I'm trying to follow Michael Dexter's post about using bhyve with boot
>> environments.  It involves moving all child datasets under
>> zroot/ROOT/default, so that you can have entirely independent systems.
>>
>> http://callfortesting.org/bhyve-boot-environments/
>>
>>> Let's change the datasets with "canmount on" to "canmount noauto":
>>> [snip]
>>> Considering that this setting is harmless to a system with a single
>>> boot environment, I would not object to it being the default. Hint
>>> hint. 
>>
>> When I set all the datasets with canmount=on to canmount=noauto, only
>> zroot/ROOT/default gets mounted on next boot.  It's my understanding
>> that 'zfs mount -a' doesn't mount datasets with canmount=noauto, but if
>> I leave them with canmount=on, they will try to mount regardless of
>> which BE is active.
>>
>> I'm trying this with 11.0-BETA2.  Can sometime tell me what I'm missing?
>>
> 
> You are not missing anything. This is why the default is to have all
> files that are specific to a BE be in the root dataset, and only files
> that are global (like home directory, etc) be outside of the BE.

Locally I have the following rc script to handle subordinate datasets of
a boot environment: http://dpaste.com/0Q0JPGN.txt
It is designed for exactly the scenario described above.
The script is automatically enabled when zfs_enable is enabled.

It would probably make sense to include the script into the OS after
some testing and a review.

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

Jenkins build is unstable: FreeBSD_HEAD #488

[jenkins-admin]

See 

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

Re: Fwd: Failed to boot -Current snapshot memstick img with EFI

[Howard Su]

It turns out a USB driver problem. the usb disk size is not correctly
detected. But the disk works fine in BIOS.

Here is dmesg information:
ugen7.2:  at usbus7
umass0:  on
usbus7
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Removable Direct Access SPC-4 SCSI
device
da0: Serial Number 137161312223005B
da0: 40.000MB/s transfers
da0: 0MB (1 512 byte sectors)  <
da0: quirks=0x2
GEOM_PART: integrity check failed (da0, MBR)
GEOM_PART: integrity check failed (diskid/DISK-137161312223005B, MBR)

Anyone has idea how this happen?

-Howard

On Wed, Jul 27, 2016 at 12:21 PM Howard Su  wrote:

> 8GB
>
> Allan Jude 于2016年7月27日周三 上午11:35写道：
>
>> On 2016-07-26 23:33, Howard Su wrote:
>> > The same issue is still there in 11-BETA2. I tried the memstick image
>> for
>> > amd64. I got the exact same error (with boot -v).
>> > ​GEOM_PART: last LBA is below first LBA: 0 < 32
>> > GEOM_PART: integrity check failed (da0, MBR)
>> >
>> > This make mem stick image totally useless. Anyone take a look? I am
>> happy
>> > to provide more information.
>> >
>> > Thanks,
>> >
>> > Howard
>> >
>> > -- Forwarded message --
>> > From: Howard Su 
>> > Date: Sat, Apr 23, 2016 at 10:40 PM
>> > Subject: Failed to boot -Current snapshot memstick img with EFI
>> > To: "freebsd-current@freebsd.org" 
>> >
>> >
>> > The issue is partition table in img is wrong so that GEOM cannot
>> discover
>> > the partitions.
>> >
>> > Detailed error:
>> > ​​
>> > GEOM_PART: last LBA is below first LBA: 0 < 32
>> > GEOM_PART: integrity check failed (da0, MBR)
>> >
>> > I tried this month and last month memstick img. both has same problem.
>> Any
>> > idea on the issue?
>> >
>> > -Howard
>> >
>>
>> The last LBA is being reported as 0, which is obviously bogus.
>>
>> How big is the USB device you have written the memstick to?
>>
>> --
>> Allan Jude
>>
>> --
> -Howard
>
-- 
-Howard
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: IWM(7260), no connect

[Andriy Voskoboinyk]

Thu, 28 Jul 2016 05:39:55 +0300 було написано Larry Rosenman  
:


Try to revert r303418 (as I can see, r303416 and/or r303413 are not the  
reason

of this).

In case, if this will not help, you can try to add
wlandebug_wlan0="state+scan+auth+assoc"
into rc.conf to see where it fails.


I'm running today's top of tree, and it doesn't seem to want to connect:


re0: flags=8843 metric 0 mtu 1500

options=8209b
ether 20:47:47:73:07:5f
inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf
inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21
groups: lo
wlan0: flags=8c43 metric  
0 mtu 1500

ether 58:91:cf:1a:45:69
inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3
nd6 options=23
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 8 (2447 MHz 11g)
regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
roaming MANUAL
groups: wlan


hostb0@pci0:0:0:0:	class=0x06 card=0x07061028 chip=0x19108086  
rev=0x07 hdr=0x00

vendor = 'Intel Corporation'
device = 'Skylake Host Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:	class=0x060400 card=0x20158086 chip=0x19018086  
rev=0x07 hdr=0x01

vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x16)'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:	class=0x060400 card=0x07061028 chip=0x19058086  
rev=0x07 hdr=0x01

vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x8)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0:	class=0x03 card=0x07061028 chip=0x191b8086  
rev=0x06 hdr=0x00

vendor = 'Intel Corporation'
device = 'HD Graphics 530'
class  = display
subclass   = VGA
none0@pci0:0:4:0:	class=0x118000 card=0x07061028 chip=0x19038086  
rev=0x07 hdr=0x00

vendor = 'Intel Corporation'
device = 'Skylake Processor Thermal Subsystem'
class  = dasp
xhci0@pci0:0:20:0:	class=0x0c0330 card=0x07061028 chip=0xa12f8086  
rev=0x31 hdr=0x00

vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:	class=0x118000 card=0x07061028 chip=0xa1318086  
rev=0x31 hdr=0x00

vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:	class=0x118000 card=0x07061028 chip=0xa1608086  
rev=0x31 hdr=0x00

vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none3@pci0:0:22:0:	class=0x078000 card=0x07061028 chip=0xa13a8086  
rev=0x31 hdr=0x00

vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:	class=0x010601 card=0x07061028 chip=0xa1038086  
rev=0x31 hdr=0x00

vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib3@pci0:0:28:0:	class=0x060400 card=0x07061028 chip=0xa1108086  
rev=0xf1 hdr=0x01

vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:	class=0x060400 card=0x07061028 chip=0xa1148086  
rev=0xf1 hdr=0x01

vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:	class=0x060400 card=0x07061028 chip=0xa1158086  
rev=0xf1 hdr=0x01

vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:	class=0x060400 card=0x07061028 chip=0xa1168086  
rev=0xf1 hdr=0x01

vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:	class=0x060100 card=0x07061028 chip=0xa14e8086  
rev=0x31 hdr=0x00

Re: SafeStack in base

[Ed Schouten]

Hi Conrad,

2016-07-28 2:02 GMT+02:00 Conrad Meyer :
> The problem appears to be an upstream limitation of
> -fsanitize=safe-stack: "Most programs, static libraries, or individual
> files can be compiled with SafeStack as is. … Linking a DSO with
> SafeStack is not currently supported." [0]

I'm not sure, but I thought the reason for this is due to the fact
that SafeStack uses some kind of additional library to wrap around
pthread_create() to create threads that have SafeStack properly set
up.

If we were to actually integrate this functionality into our C
runtime/pthread library to create threads with two stacks by default,
then I couldn't think of a reason why it shouldn't work with DSOs.
SafeStack merely depends on an additional TLS variable -- nothing
else.

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SafeStack in base

[David Chisnall]

On 27 Jul 2016, at 23:55, Shawn Webb  wrote:
> 
> I'm interested in getting SafeStack working in FreeBSD base. Below is a
> link to a simplistic (maybe too simplistic?) patch to enable SafeStack.
> The patch applies against HardenedBSD's hardened/current/master branch.
> Given how simple the patch is, it'd be extremely easy to port over to
> FreeBSD (just line numbers would change).

We’ve worked with the authors of the SafeStack work.  There are some changes to 
libc and a few other support libraries needed for it to work, which are in the 
GitHub repository.  They’ve also done some work to address issues of things 
like Firefox and v8 that need to be able to walk the stack, allocate their own 
stacks for userspace threads, and so on.

It was not enabled for FreeBSD 11 because SafeStack imposes a lot of long-term 
ABI constraints that it’s not clear we want to support indefinitely given the 
‘Missing the point(er)’ Oakland paper last year.  It does increase the work 
factor for attackers, so has some security benefit, but if bypassing it is 
something that’s going to be added to exploit toolkits then it’s little 
practical benefit.

One middle-ground that we’ve considered is only supporting it for statically 
linked binaries.  This absolves us of the need to support the ABI indefinitely, 
and still provides a lot of the benefit.

David



smime.p7s
Description: S/MIME cryptographic signature