Looking for dedicated, slightly masochistic BETA testers!

[jkh]

Yay on fixing the OpenSSL bug!

Which OpenSSL bug? There are a LOT of OpenSSL bugs. :( See this list: http://www.openssl.org/news/vulnerabilities.html

FreeNAS has never suffered from CVE-2014-0160 or CVE-2010-5298 or CVE-2014-0198 but this fixes CVE-2014-3470, CVE-2014-0221 and CVE-2014-0224.

This is why you have to be very specific when discussing OpenSSL bugs. There are dozens of CVEs for it and probably 20 versions of OpenSSL in the wild they may or may not apply to.

 

[andyclimb]

So I've been running various nightlies of 9.2.1.6 on my N40L and it has been as stable as a rock. I've been virtualising windows, 7, 8, freenas, pfsense and all has been fine. I tool the plunge to run 9.2.1.6 on my xeon server (specs below) and it has not been so happy. The VMs crash constantly... fresh installations of windows, using NAT instead of bridge (in Vbox), turning of hardware acceleration... just everything seems to cause them to fall over..

This is some output I get from dmesg. I seem to get MCA parity errors coinciding with running the VMs... any ideas anyone... i guess once 9.2.1.6 goes live these issues may get a lot more common.

Freed UMA keg (udp_inpcb) was not empty (40 items). Lost 4 pages of memory.
Freed UMA keg (udpcb) was not empty (504 items). Lost 3 pages of memory.
Freed UMA keg (tcp_inpcb) was not empty (30 items). Lost 3 pages of memory.
Freed UMA keg (tcpcb) was not empty (12 items). Lost 3 pages of memory.
ng node vboxnet1 needs NGF_REALLY_DIE
ng node vboxnet2 needs NGF_REALLY_DIE
hhook_vnet_uninit: hhook_head type=1, id=1 cleanup required
hhook_vnet_uninit: hhook_head type=1, id=0 cleanup required
epair4a: link state changed to DOWN
epair4b: link state changed to DOWN
epair4a: Ethernet address: 02:b3:12:00:0c:0a
epair4b: Ethernet address: 02:b3:12:00:11:0b
epair4a: link state changed to UP
epair4b: link state changed to UP
epair4a: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair4b
ifa_del_loopback_route: deletion failed
Freed UMA keg (udp_inpcb) was not empty (50 items). Lost 5 pages of memory.
Freed UMA keg (udpcb) was not empty (504 items). Lost 3 pages of memory.
Freed UMA keg (tcpreass) was not empty (336 items). Lost 4 pages of memory.
Freed UMA keg (tcptw) was not empty (1950 items). Lost 39 pages of memory.
Freed UMA keg (tcp_inpcb) was not empty (1870 items). Lost 187 pages of memory.
Freed UMA keg (sackhole) was not empty (404 items). Lost 4 pages of memory.
Freed UMA keg (tcpcb) was not empty (104 items). Lost 26 pages of memory.
hhook_vnet_uninit: hhook_head type=1, id=1 cleanup required
hhook_vnet_uninit: hhook_head type=1, id=0 cleanup required
epair8b: promiscuous mode disabled
epair8a: link state changed to DOWN
epair8b: link state changed to DOWN
epair8a: Ethernet address: 02:db:71:00:10:0a
epair8b: Ethernet address: 02:db:71:00:11:0b
epair8a: link state changed to UP
epair8b: link state changed to UP
epair8a: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair8b
epair8b: promiscuous mode enabled
ifa_del_loopback_route: deletion failed
Freed UMA keg (udp_inpcb) was not empty (40 items). Lost 4 pages of memory.
Freed UMA keg (udpcb) was not empty (504 items). Lost 3 pages of memory.
Freed UMA keg (tcpreass) was not empty (336 items). Lost 4 pages of memory.
Freed UMA keg (tcptw) was not empty (2450 items). Lost 49 pages of memory.
Freed UMA keg (tcp_inpcb) was not empty (2300 items). Lost 230 pages of memory.
Freed UMA keg (tcpcb) was not empty (48 items). Lost 12 pages of memory.
ng node vboxnet0 needs NGF_REALLY_DIE
hhook_vnet_uninit: hhook_head type=1, id=1 cleanup required
hhook_vnet_uninit: hhook_head type=1, id=0 cleanup required
tun0: link state changed to DOWN
tun0: link state changed to UP
epair8a: link state changed to DOWN
epair8b: link state changed to DOWN
pid 22144 (VBoxSVC), uid 1001: exited on signal 11
ifa_del_loopback_route: deletion failed
Freed UMA keg (udp_inpcb) was not empty (40 items). Lost 4 pages of memory.
Freed UMA keg (udpcb) was not empty (504 items). Lost 3 pages of memory.
Freed UMA keg (tcptw) was not empty (2250 items). Lost 45 pages of memory.
Freed UMA keg (tcp_inpcb) was not empty (2190 items). Lost 219 pages of memory.
Freed UMA keg (tcpcb) was not empty (64 items). Lost 16 pages of memory.
hhook_vnet_uninit: hhook_head type=1, id=1 cleanup required
hhook_vnet_uninit: hhook_head type=1, id=0 cleanup required
epair8a: Ethernet address: 02:e4:90:00:10:0a
epair8b: Ethernet address: 02:e4:90:00:11:0b
epair8a: link state changed to UP
epair8b: link state changed to UP
epair8a: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair8b
epair8b: promiscuous mode enabled
MCA: Bank 0, Status 0x90000040000f0005
MCA: Global Cap 0x0000000000000c09, Status 0x0000000000000000
MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 6
MCA: CPU 3 COR (1) internal parity error
epair5a: link state changed to DOWN
epair5b: link state changed to DOWN
epair5a: Ethernet address: 02:26:17:00:0d:0a
epair5b: Ethernet address: 02:26:17:00:11:0b
epair5a: link state changed to UP
epair5b: link state changed to UP
epair5a: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair5b
ifa_del_loopback_route: deletion failed
Freed UMA keg (udp_inpcb) was not empty (40 items). Lost 4 pages of memory.
Freed UMA keg (udpcb) was not empty (504 items). Lost 3 pages of memory.
Freed UMA keg (tcp_inpcb) was not empty (20 items). Lost 2 pages of memory.
Freed UMA keg (tcpcb) was not empty (12 items). Lost 3 pages of memory.
hhook_vnet_uninit: hhook_head type=1, id=1 cleanup required
hhook_vnet_uninit: hhook_head type=1, id=0 cleanup required
pid 41697 (VBoxHeadless), uid 1001: exited on signal 11
epair8b: promiscuous mode disabled
pid 64643 (VBoxHeadless), uid 1001: exited on signal 11
MCA: Bank 0, Status 0x90000040000f0005
MCA: Global Cap 0x0000000000000c09, Status 0x0000000000000000
MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 6
MCA: CPU 3 COR (1) internal parity error
epair8a: link state changed to DOWN
epair8b: link state changed to DOWN
epair8a: Ethernet address: 02:f3:3a:00:10:0a
epair8b: Ethernet address: 02:f3:3a:00:11:0b
epair8a: link state changed to UP
epair8b: link state changed to UP
epair8a: promiscuous mode enabled

ng_ether_ifnet_arrival_event: can't re-name node epair8b

 

[cyberjock]

MCA: Bank 0, Status 0x90000040000f0005
MCA: Global Cap 0x0000000000000c09, Status 0x0000000000000000
MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 6
MCA: CPU 3 COR (1) internal parity error

That is a sign of a CPU that has detected an error internally. So it sounds like you have a hardware failure in progress. Most likely it's the CPU, but could be the motherboard or even PSU.

 

[andyclimb]

This is what my research is suggesting....

However, its been fine for 3 weeks or so (all new equipment) only generating these messages on 9.2.1.6 whilst running VirtualBox.. with windows as a VM..

I'm trying a completely fresh install of freenas + virtual box + windows to see if that re-creates it.

guess it might be a warranty job, if it is hardware.

 

[RoboKaren]

Which OpenSSL bug? There are a LOT of OpenSSL bugs. :( See this list: http://www.openssl.org/news/vulnerabilities.html

FreeNAS has never suffered from CVE-2014-0160or CVE-2010-5298 or CVE-2014-0198 but this fixes CVE-2014-3470, CVE-2014-0221 and CVE-2014-0224.

This is why you have to be very specific when discussing OpenSSL bugs. There are dozens of CVEs for it and probably 20 versions of OpenSSL in the wild they may or may not apply to.

Thanks! Glad that it wasn't ever an issue. It'd be handy if this were posted somewhere on the front page for worried ninnies like me.

K

 

[cyberjock]

Thanks! Glad that it wasn't ever an issue. It'd be handy if this were posted somewhere on the front page for worried ninnies like me.

K

Is using the search bar too hard? I'm confused...

I searched and the very first post would have had your answer.

Also, as Heartbleed is now over 2 months old I would not expect it to be "front page news" anymore. That boat sailed 2 months ago.

 

[RoboKaren]

No, not heartbleed but the most recent CVEs that were just patched in the June 5th FreeBSD source. I didn't see any evidence of this being patch on the FreeNAS home page (which is where this type of info should be, rather than in the forums).

Searching for these CVEs didn't reveal anything (even now, except for this thread).



----
FreeBSD-SA-14:14.openssl Security Advisory
The FreeBSD Project

Topic: OpenSSL multiple vulnerabilities

Category: contrib
Module: openssl
Announced: 2014-06-05
Affects: All supported versions of FreeBSD.
Corrected: 2014-06-05 12:32:38 UTC (stable/10, 10.0-STABLE)
2014-06-05 12:33:23 UTC (releng/10.0, 10.0-RELEASE-p5)
2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1)
2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1-p2)
2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8)
2014-06-05 12:33:23 UTC (releng/9.1, 9.1-RELEASE-p15)
2014-06-05 12:32:38 UTC (stable/8, 8.4-STABLE)
2014-06-05 12:33:23 UTC (releng/8.4, 8.4-RELEASE-p12)
CVE Name: CVE-2014-0195, CVE-2014-0221, CVE-2014-0224, CVE-2014-3470

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.

I. Background

FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is
a collaborative effort to develop a robust, commercial-grade, full-featured
Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols as well as a full-strength
general purpose cryptography library.

II. Problem Description

Receipt of an invalid DTLS fragment on an OpenSSL DTLS client or server can
lead to a buffer overrun. [CVE-2014-0195]

Receipt of an invalid DTLS handshake on an OpenSSL DTLS client can lead the
code to unnecessary recurse. [CVE-2014-0221]

Carefully crafted handshake can force the use of weak keying material in
OpenSSL SSL/TLS clients and servers. [CVE-2014-0224]

 

[reqlez]

I've been getting this with versions : FreeNAS-9.2.1.5-RELEASE-x64 (80c1d35) and the one before.
I made a post about it here: http://forums.freenas.org/index.php...alid-failling-back-to-http.20712/#post-124294

I'm wondering if it is something to do with changing the hostname.

This error appears after a reboot, and as I can HTTPS to work by disabling it, and reenabling it, it is not something i keep wanting to do to my server to test, as every reboot requires a bunch of jail configurations... etc...

I'm going to try an run it in a virtual box to test. But you are definitely not alone! my web GUI address is bound to the right IP too, so its not that. I should say that its done it on a fresh install and from upgrades..

I already tested this ... the self-signed freeNAS ssl breaks after a reboot and i found no fix, however ... i created my own certificate from my internal certification authority and that works just fine, so i'm just going to forget about self signed SSL on freenas.

On another note, i have been testing the latest June 11th beta and SMB feels sluggish, i created a windows dataset and use the "default permissions" ( the new method for windows shares that was announced by jordan ) however i'm getting messages in the console when SMB locks up for a while ( some times 1 minute )

winbindd: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-BLAHBLAH

i'm assuming if i say "good bye" to this windows sharing crap and just run unix permissions this will work fine without deadlocks ?

Oh and to add: even if i have 2 files on a dataset, when i right click a file instead of the group name the SID value appears for like 5 seconds before actually giving you the correct group name, i'm assuming that this SID to name translation is broken or inefficient or something.

 

[solarisguy]

@reqlez, try switching back to SMB3 and please report the results. You might have been hit by the reverse of https://bugs.freenas.org/issues/5173

 

[reqlez]

@reqlez, try switching back to SMB3 and please report the results. You might have been hit by the reverse of https://bugs.freenas.org/issues/5173

okay when i checked the "maximum protocol" it was set to SMB3 ... so i changed it to SMB2 restarted samba and my shares are now FLYING! So i'm gussing something wrong with SMB3 ? i'm using windows 8.1 to access ...

Sorry if i confused you, i actually did an upgrade install to this beta build so i guess the setting of SMB3 remained.

On another note i tested vmxnet3 driver by loading and setting up the interface ... vmxnet3 consumes DOUBLE the CPU power than the e1000 driver ... thats pretty bad considering vmxnet3 was "made for virtualization"

 

[reqlez]

okay, so now testing samba and zfs snapshots. set-up a snapshot task ( only 1 naming convention, so no it's not the different names snapshots are not showing up case ), and snapshots are not showing up in "previous versions" on my mounted driver letter. Regarding this topic, is there a way to do this with a mac also ? would be nice if there was a way to show .zfs directory in the root of the share with an option, i tried setting the ifs property on a dataset before to show the .zfs directory but only seems to show up if you access dataset via SCP.

 

[solarisguy]

zfs get snapdir
hidden or visible ?

 

[reqlez]

zfs get snapdir
hidden or visible ?

Yes the snapdir property is hidden by default, and it's currently hidden. I was pretty sure samba was able to access the snapshot directory without having the snapdir visible, or maybe the default behaviour in freenas 8 was to set it as visible when the system created the dataset ... ?

 

[reqlez]

Yes the snapdir property is hidden by default, and it's currently hidden. I was pretty sure samba was able to access the snapshot directory without having the snapdir visible, or maybe the default behaviour in freenas 8 was to set it as visible when the system created the dataset ... ?

so i woke up this morning and the snapshots are visible now AFTER restarting CIFS... does it take a while for snapshot to show up ? i tested it with that field visible and hidden and snapshot still show ... maybe i didn't restart CIFS after enabling snapshot tasks ... is restarting CIFS service a requirement after you enable snapshot tasks ?

By the way, even if you make snapdir visible, the .zfs dir still doesn't show up under finder in mac os x

 

[reqlez]

@reqlez, try switching back to SMB3 and please report the results. You might have been hit by the reverse of https://bugs.freenas.org/issues/5173

Great ... i'm still getting "rid to name" deadlocks and now also "sid to name" deadlocks and my SMB is sluggish again ( thats with SMB version 2 maximum setting ) Yesterday i opened a directory with 10000 items and the items appeared right away ( that was after setting protocol to SMB2 maximum ) ... but today i get the loading bar and items appear 1000 every few seconds in the status bar and there is loading bar again .... then i tried again and its fast ... so it seems its hit and miss, but one way of making the rid to names deadlock show up is as soon as you right click on a file and click "security" the rid to name deadlock message appears in the console instantly. go to another file, right click and hit security... again, message comes up instantly.

Btw, i created a bug report here since i think its indeed a bug for SMB to lock up and be sluggish until you restart the SMB service: https://bugs.freenas.org/issues/5215

 

[solarisguy]

@reqlez, please start a new thread

And report there settings for Show Hidden Files: in Sharing => Windows (CIFS) => Edit

 

[reqlez]

@reqlez, please start a new thread

And report there settings for Show Hidden Files: in Sharing => Windows (CIFS) => Edit

Sorry a new thread for deadlocks or for .zfs directory visible ?

 

[jkh]

Call for testers: http://download.freenas.org/nightlies/9.2.1.6/BETA/20140616/

In the wake of 9.2.1.6-BETA, we have quite a few more fixes to this build, in particular the experimental Kernel iSCSI (CTL) support in this build is substantially improved by these tickets being resolved:

https://bugs.freenas.org/issues/5230
https://bugs.freenas.org/issues/5217
https://bugs.freenas.org/issues/5216
https://bugs.freenas.org/issues/5205
https://bugs.freenas.org/issues/4003
https://bugs.freenas.org/issues/5230
https://bugs.freenas.org/issues/4003
https://bugs.freenas.org/issues/4929

The tl;dr version of the above is that we think that Windows 2012 clustering support now works with Kernel ISCSI and the issue that caused flipping between istgt (userland iSCSI) and CTL to make VMWare think you'd actually changed the LUNs should be fixed (so folks wanting to test the new Kernel iSCSI support with VMWare can do so easily but still revert back to istgt in the event of any problems).

We fixed the GRUB boot loader USB image (https://bugs.freenas.org/issues/5222).

AD / LDAP also now supports I18N characters, so folks like Jürgén Hørnqvôss-Schißtein should be happier trying to log into FreeNAS (https://bugs.freenas.org/issues/5015), but we are somewhat concerned about any possible regressions as a result of this change.

We don’t see any obvious ways in which this might have broken AD/LDAP support for english users, but we would still really appreciate folks taking special care to test this case. If you use AD or LDAP with FreeNAS (particularly if you are outside the US), we would really appreciate you taking some time to test this nightly build!

Thanks!

- The FreeNAS Development Team

 

[reqlez]

Samba 4.1.9 is released with security updates (DoS server crash/memory corruption and CPU loop ), probably too late to integrate into .6 version tho ...