Re: The future of ZFS in FreeBSD

[Eugene M. Zheganin]

Hello,

On 19.12.2018 23:32, Allan Jude wrote:

The biggest thing to remember is that this is still OpenZFS, and still
run by the same developers as it has been. We are just commonizing on
the repo that has the most features integrated into it.


Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because 
there is no such thing in ZoL ?


Eugene.

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

altq and head

[Eugene M. Zheganin]

Hi,

regarding all this stir around ALTQ and igb(4), and mentioning that 
igb(4) doesn't have ALTQ in HEAD - I wanted to ask - is this just igb(4) 
and ixgbe(4) that lost ALTQ in HEAD, or is ALTQ being removed totally 
from FreeBSD ? I did a couple of searches, but seems like I cannot find 
the simple answer.



Thanks.

Eugene.

___
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: [RFC/RFT] projects/ipsec

[Eugene M. Zheganin]

Hi,

On 11.12.2016 4:07, Andrey V. Elsukov wrote:

Hi All,

I am pleased to announce that projects/ipsec, that I started several
months ago is ready for testing and review.
The main goals were:
   * rework locking to make IPsec code more friendly for concurrent
 processing;
   * make lookup in SADB/SPDB faster;
   * revise PFKEY implementation, remove stale code, make it closer
 to RFC;
   * implement IPsec VTI (virtual tunneling interface);
   * make IPsec code loadable as kernel module.

Currently all, except the last one is mostly done. So, I decided ask for
a help to test the what already done, while I will work on the last task.

Well, at last FreeBSD got one of the most anticipated features in it's 
ipsec stack. When I wrote the message in the freebsd-net ML in the 
middle of 2012 
(https://lists.freebsd.org/pipermail/freebsd-net/2012-June/032556.html) 
I had a very little hope that someone will actually implement this, and 
now I'm very grateful that Andrey got the time to do this (and I'm 
really sorry for being such a pain in the ass, I'm saying so because I 
was bothering Andrey all this time in IRC). This isn't definitely a 
feature that every FreeBSD enthusiast will use, and, sadly, even not the 
feature that every network engineer that use ipsec in it's every day 
work will configure (many people still use obsoleted legacy 
interfaceless ipsec approach, not to mention weird and hybrid software 
routers like openvpn), but it's definitely a feature that will be 
appreciated by every skilled L3 VPN engineer that is using FreeBSD in 
it's operating stack. I've ran some tests in my production network and I 
should say that even on it's initial release state if_ipsec is fully 
operational with Juniper st tunnel on the other side, so I'm already 
running one FreeBSD <--> Juniper tunnel at my work:


# ifconfig ipsec0
ipsec0: flags=8051 metric 0 mtu 1400
tunnel inet 128.127.144.19 --> 128.127.146.1
inet 172.16.3.104 --> 172.16.3.105 netmask 0x
inet6 fe80::204:23ff:fec7:194d%ipsec0 prefixlen 64 scopeid 0x9
nd6 options=21
reqid: 16385
groups: ipsec

racoon.conf:
path pre_shared_key "/usr/local/etc/racoon/psk.txt";

padding {
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}

listen {
isakmp 128.127.144.19 [500];
strict_address; # requires that all addresses must be bound.
}

timer {
counter 5;
interval 20 sec;
persend 1;

phase1 30 sec;
phase2 15 sec;
}

#
# SPb, Test
#

remote 128.127.146.1 {
exchange_mode main;
lifetime time 1 hour;
my_identifier address 128.127.144.19;
peers_identifier address 128.127.146.1;
passive off;
proposal_check obey;
dpd_delay 20;
proposal {
encryption_algorithm des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group modp768;
}
}

#
# SPb, Test
#

sainfo address 0.0.0.0/0 [500] any address 0.0.0.0/0 [500] any {
pfs_group modp768;
lifetime time 60 min;
encryption_algorithm des;
authentication_algorithm non_auth;
compression_algorithm deflate;
}

Juniper side:

> show configuration interfaces st0.147
description "Perm, FreeBSD Test Server";
family inet {
mtu 1455;
address 172.16.3.105/32 {
destination 172.16.3.104;
}
}

> show configuration security ike policy kosm65
proposals norma-ike;
pre-shared-key ascii-text 
"$9$-SV4ZUDkqPQUjBIclLXgoJUqf9CuESeAp-w2gGUjHqfQn"; ## SECRET-DATA


> show configuration security ike gateway kosm65-freebsd-test
ike-policy perm-freebsd-test;
address 128.127.144.19;
local-identity inet 128.127.146.1;
remote-identity inet 128.127.144.19;
external-interface reth1.2;

> show configuration security ipsec vpn kosm65-freebsd-test
bind-interface st0.147;
ike {
gateway kosm65-freebsd-test;
ipsec-policy norma-policy;
}

> show configuration security ipsec policy norma-policy
perfect-forward-secrecy {
keys group1;
}
proposals norma-ipsec;

> show configuration security ipsec proposal norma-ipsec
protocol esp;
encryption-algorithm des-cbc;
lifetime-seconds 600;

> show configuration security ike proposal norma-ike
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm md5;
encryption-algorithm des-cbc;

In it's initial state if_ipsec allows to use only one set of encryption 
parameters (because only one sainfo anonyumous is possible), so at this 
time it doesn't allow to create multiple tunnels with VPN hubs that use 
different cipers and/or transform sets, but as far as I understand this 
is subject to change and Andrey is already working on a support of this 
feature from ipsec-tools IKE daemon. But even in this state this feature 
is already useful and I'm excited to see it commited to HEAD and then 
MFC'd 

mountroot error 5

[Eugene M. Zheganin]

Hi.

Today I've upgraded one of my test machines from FreeBSD 9-STABLE to
today's CURRENT.
On a reboot I got:

Solaris: cannot find the pool label for 'zfsroot'
Mounting from zfs:zfsroot failed with error 5.

When I boot from 9.0-RELEASE DVD1 and use Live Disk, I can see that the
pool is available and healthy (version is still 28, I didn't upgrade it).
It can be imported (it's not exported when mountroot tries to mount it)
and read/written.

Can this be resolved somehow ? I recreated cachefile (when on Live CD)
and replaced with it the old one, but this didn't seem to change
anything (still same error).
I've also installed today's CURRENT (from the same obj/src tree) to an
USB stick and when booting from it (on this troubled machine) it claims
there's no zfs pools at all. I think these events may be connected.

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

Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168

[Eugene M. Zheganin]

Hi.

On 02.07.2013 05:10, Pawel Jakub Dawidek wrote:
 On Sun, Jun 30, 2013 at 01:18:36PM +0200, Mateusz Guzik wrote:

 Turns out the bug is quite funny ;)

 Try this:
 diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c
 index 5d8e814..7a4db04 100644
 --- a/sys/kern/uipc_usrreq.c
 +++ b/sys/kern/uipc_usrreq.c
 @@ -1764,8 +1764,8 @@ unp_externalize(struct mbuf *control, struct mbuf 
 **controlp, int flags)
  }
  for (i = 0; i  newfds; i++, fdp++) {
  fde = fdesc-fd_ofiles[*fdp];
 -fde-fde_file = fdep[0]-fde_file;
 -filecaps_move(fdep[0]-fde_caps,
 +fde-fde_file = fdep[i]-fde_file;
 +filecaps_move(fdep[i]-fde_caps,
  fde-fde_caps);
  if ((flags  MSG_CMSG_CLOEXEC) != 0)
  fde-fde_flags |= UF_EXCLOSE;
 Thanks for tracking it down before I had time to get to it!
 The change looks good.

Guys, if this is working, why it's not commited to HEAD ? I'm still
hitting this bug on r251990 and later ones.

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

Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168

[Eugene M. Zheganin]

Hi.

On 15.07.2013 15:16, Eugene M. Zheganin wrote:

 Guys, if this is working, why it's not commited to HEAD ? I'm still
 hitting this bug on r251990 and later ones.

I'm terribly sorry, I should read the revisions more carefully.

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

panic: no init

[Eugene M. Zheganin]

Hi.

I'm using FreeBSD as a desktop. When updating from r251990 to a higher
revision (both GENERIC kernels) I got 'panic: no init' message after
mountroot (I'm using zfs, seems like mountroot was successful). Nothing
changed in my configuration, so I have totally no clue. Right now I'm
running r251990 kernel on a newer world. How can I get rid of this panic
and run newer kernel ?

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

10.x and mpd5

[Eugene M. Zheganin]

Hi.

After an upgrade from 9-STABLE I have a problem with mpd5. It can go to 
an endless loop while accepting a new pptp connection with a probability 
of like 50%. It looks in its log like I show below. The loop starts and 
ends with LCP: LayerUp. This is really an endless loop, because 
neither mpd5 nor windows 7, which I use as a client cannot break it, it 
can last for minutes (the output below was interrupted when I pressed 
'Cancel' button on the client). I don't see any packet drops or other 
network problems. Furthermore, this machine was running fine when on 
9.x. problem appeared after 10.x upgrade. This has nothing to do with a 
pf, which I use to filter the traffic - the problem persists when I 
switch it off. I've also rebuilt the mpd on 10.x, and this didn't help.


===Cut===
Mar 17 14:44:22 taiga mpd: [L-2] Accepting PPTP connection
Mar 17 14:44:22 taiga mpd: [L-2] Link: OPEN event
Mar 17 14:44:22 taiga mpd: [L-2] LCP: Open event
Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Initial -- Starting
Mar 17 14:44:22 taiga mpd: [L-2] LCP: LayerStart
Mar 17 14:44:22 taiga mpd: [L-2] PPTP: attaching to peer's outgoing call
Mar 17 14:44:22 taiga mpd: [L-2] Link: UP event
Mar 17 14:44:22 taiga mpd: [L-2] LCP: Up event
Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Starting -- Req-Sent
Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigReq #1
Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:22 taiga mpd: [L-2] MRU 1500
Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 9d62a962
Mar 17 14:44:22 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2
Mar 17 14:44:22 taiga mpd: [L-2] MP MRRU 2048
Mar 17 14:44:22 taiga mpd: [L-2] MP SHORTSEQ
Mar 17 14:44:22 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c
Mar 17 14:44:22 taiga mpd: [L-2] LCP: rec'd Configure Request #0 (Req-Sent)
Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400
Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5
Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:22 taiga mpd: [L-2] CALLBACK 6
Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigRej #0
Mar 17 14:44:22 taiga mpd: [L-2] CALLBACK 6
Mar 17 14:44:22 taiga mpd: [L-2] LCP: rec'd Configure Request #1 (Req-Sent)
Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400
Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5
Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigAck #1
Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400
Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5
Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Req-Sent -- Ack-Sent
Mar 17 14:44:24 taiga mpd: [L-2] LCP: SendConfigReq #2
Mar 17 14:44:24 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:24 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:24 taiga mpd: [L-2] MRU 1500
Mar 17 14:44:24 taiga mpd: [L-2] MAGICNUM 9d62a962
Mar 17 14:44:24 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2
Mar 17 14:44:24 taiga mpd: [L-2] MP MRRU 2048
Mar 17 14:44:24 taiga mpd: [L-2] MP SHORTSEQ
Mar 17 14:44:24 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c
Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Configure Reject #2 (Ack-Sent)
Mar 17 14:44:24 taiga mpd: [L-2] MP MRRU 2048
Mar 17 14:44:24 taiga mpd: [L-2] MP SHORTSEQ
Mar 17 14:44:24 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c
Mar 17 14:44:24 taiga mpd: [L-2] LCP: SendConfigReq #3
Mar 17 14:44:24 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:24 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:24 taiga mpd: [L-2] MRU 1500
Mar 17 14:44:24 taiga mpd: [L-2] MAGICNUM 9d62a962
Mar 17 14:44:24 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2
Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #2 (Ack-Sent)
Mar 17 14:44:24 taiga mpd: [L-2] MESG: MSRASV5.20
Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #3 (Ack-Sent)
Mar 17 14:44:24 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN
Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #4 (Ack-Sent)
Mar 17 14:44:24 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D
Mar 17 14:44:26 taiga mpd: [L-2] LCP: SendConfigReq #4
Mar 17 14:44:26 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:26 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:26 taiga mpd: [L-2] MRU 1500
Mar 17 14:44:26 taiga mpd: [L-2] MAGICNUM 9d62a962
Mar 17 14:44:26 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2
Mar 17 14:44:26 taiga mpd: [L-2] LCP: rec'd Configure Ack #4 (Ack-Sent)
Mar 17 14:44:26 taiga mpd: [L-2] ACFCOMP
Mar 17 14:44:26 taiga mpd: [L-2] PROTOCOMP
Mar 17 14:44:26 taiga mpd: [L-2] MRU 1500
Mar 17 14:44:26 taiga mpd: [L-2] MAGICNUM 9d62a962
Mar 17 14:44:26 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2
Mar 17 14:44:26 taiga mpd: [L-2] LCP: state change Ack-Sent -- Opened
Mar 17 14:44:26 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP
Mar 17 14:44:26 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21
Mar 17 14:44:26 taiga mpd: [L-2] LCP: LayerUp
Mar 17 14:44:28 taiga mpd: [L-2] LCP: rec'd Configure Request #6 (Opened)
Mar 

Re: Call for bge(4) testers

[Eugene M. Zheganin]

Hi.

On 15.09.2012 03:27, YongHyeon PYUN wrote:

I'm especially interested in whether there is any ASF/IPMI
regression on BCM570x/571x.

There's a reopened bug concerning 8.x releases version of the bge(4) 
driver not working with IPMI ( 
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122252 
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122252 ). I can also 
say that enabling ASF on RELENG_8 still leads to locking and hangups. 
Does this CFT mean that this situation may be improved with the new 
bge(4) version, on 9.x ?


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