bgpctl not showing rib entries, pftables empty
Hi all,
I’ve set up bgpd for use with bgp-spamd.net’s servers. As far as I can tell,
the BGP connection and transfer is working fine:
--8<--
elisheva:~$ cat /etc/bgpd.conf
spam_rs1="64.142.121.62"
spam_rs2="217.31.80.170"
spam_asn="65066"
AS 65500
fib-update no
group "spam-bgp" {
remote-as $spam_asn
multihop 64
export none
neighbor $spam_rs1
neighbor $spam_rs2
}
match from group "spam-bgp" community $spam_asn:42 set pftable
"bgp_spamd_bypass"
match from group "spam-bgp" community $spam_asn:666 set pftable "bgp_spamd"
elisheva:~$ bgpctl show
Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd
217.31.80.170 65066410322 0 02:39:41 37096
64.142.121.62 65066460318 0 01:25:30 37096
elisheva:~$ bgpctl show rib memory
RDE memory statistics
37096 IPv4 unicast network entries using 1.4M of memory
37096 rib entries using 2.3M of memory
74192 prefix entries using 6.8M of memory
10 BGP path attribute entries using 1.1K of memory
2 BGP AS-PATH attribute entries using 82B of memory,
and holding 10 references
7 BGP attributes entries using 280B of memory
and holding 10 references
7 BGP attributes using 48B of memory
RIB using 10.5M of memory
RDE hash statistics
path hash: size 131072, 10 entires
min 0 max 2 avg/std-dev = 0.000/0.000
aspath hash: size 131072, 2 entires
min 0 max 1 avg/std-dev = 0.000/0.000
attr hash: size 16384, 7 entires
min 0 max 1 avg/std-dev = 0.000/0.000
--8<--
However, despite the entry counts being shown by `bgpctl show rib memory`, no
other command lists entries as one might expect, and the pf tables are empty:
--8<--
elisheva:~$ bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
elisheva:~$ bgpctl show rib community 65066:42
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
elisheva:~$ doas pfctl -Ts -t bgp_spamd
elisheva:~$ doas pfctl -Ts -t bgp_spamd_bypass
elisheva:~$
--8<--
Any hints as to how to further diagnose? I’ve tried most conceivable
additional arguments to `bgpctl show rib` and I haven’t found a way to list
entries yet. Log entries are benign ((re)configuration success messages).
Thanks,
Ashe
Monit logs vfprintf %s NULL in "%s" all the time
I'm running Monit to look at few services on OpenBSD 6.3 and I'm logging to syslog. In my /var/log/messages I routinely observe the following log entries: Oct 27 22:00:01 alpha syslogd[97814]: restart Oct 27 22:00:02 alpha monit: vfprintf %s NULL in "%s" Oct 27 22:00:32 alpha last message repeated 11 times Oct 27 22:02:32 alpha last message repeated 24 times Oct 27 22:12:33 alpha last message repeated 120 times Oct 27 22:22:33 alpha last message repeated 120 times ...and so on... Monit is installed from ports. $ monit --version This is Monit version 5.25.1 Built with ssl, with ipv6, with compression, without pam and with large files Does anybody know what does it mean? This log is not very useful, but it looks like some kind of bug. Best regards, Chris
Re: Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
Hi ivpgbe@, Thanks for the details! Yes, it was not my intention to indicate anything; but since I saw those reports of bricked machines during the last days (and having Thinkpads myself) I wanted to be rather safe than sorry. regards, Robert On Sun, 28 Oct 2018 07:15:10 -0700 ivp...@eml.cc wrote: > Hi Robert, > > I'm certainly not trolling (although I'm not sure what would be a protocol to > prove it, other than posting a video that shows all mentioned BIOS settings > and than a successful boot), and I'm sure you are not trolling either, as I > can see a number of postings to this mailing list and your first one is from > 10 years ago. [1] A never considered a threat model where a malicious user > posts knowingly bad BIOS settings to brick other users machines, thank you > for being vigilant. If anyone else thinks that posting a video with my BIOS > settings and a successful boot would be useful, I'm happy to do that. > > In addition to double-checking my settings, I also looked at 4 links you've > provided (I don't read German and can't check the last one). > > The first one is a very similar machine (the difference, from what I > understand, is that all Yoga's have a multi-touch screen), but the post is > from 7/13, and whatever the issue they encountered, I'm using a later BIOS > (version 1.31 from 9/15). > > The second one is posted on 9/15, but the author and few others with similar > problems have P52, which is a different machine - dual graphics with NVIDIA > chip and a different CPUs - either i8750H or i8850H 6-core processors, while > I have a i8550U. However, what is similar, is that enabling the BIOS Assist > Mode does indeed require a 15-sec or so reboot, as the author describes, and > that seemed to be a step that bricked their machine. > > The third author also has a different machine (P1, also with NVIDIA > graphics), and they refer to BIOS version 1.12 from 10/12 release - again, a > different BIOS. They also post a solution for their problem [2], however it > requires extracting firmware and flushing it to EEPROM, so you better know > what you are doing. > > The fourth author has a P72 (also a machine with NVIDIA graphics), and they > did say they changed something in BIOS although they never specify what > exactly. > > Thanks! > > [1] https://marc.info/?l=openbsd-misc=128033208924257=2 > [2] > https://www.reddit.com/r/thinkpad/comments/9rnimi/ladies_and_gentlemen_i_present_to_you_the/ > > On Sun, Oct 28, 2018, at 4:47 AM, Robert wrote: > > WARNING: > > > > I do not know if the orginal author is serious, or if he is trolling. > > > > But there are known issues with the stated Thunderbolt setting in BIOS > > that can brick your Thinkpad beyond repair (or BIOS reset). > > > > See here: > > https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Thinkpad-X1-Yoga-3rd-Gen-Stuck-at-Black-Screen-After-Enabling/td-p/4106952/page/3 > > https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Lenovo-P52-bricked-by-selecting-BIOS-thunderbolt-support-for/td-p/4207538 > > https://www.reddit.com/r/thinkpad/comments/9qmqd2/thinkpad_p1_serious_issue_with_bricked_bios/ > > https://www.reddit.com/r/thinkpad/comments/9nb3zo/new_thinkpad_p72_biosuefi_corrupted_just_black/ > > > > (german) > > https://www.notebookcheck.com/Lenovo-Einige-aktuelle-ThinkPads-koennen-scheinbar-durch-eine-UEFI-Einstellung-zerstoert-werden.346101.0.html > > > > /Robert > > > > > > On Sun, 28 Oct 2018 00:50:03 -0700 > > ivp...@eml.cc wrote: > > > > > Hello, > > > > > > several people reported about various problems with Lenovo Thinkpad X1 > > > Carbon 6th gen (X1C6), when performance become sluggish and fan goes > > > wild. [1] [2] [3] > > > > > > I had similar problem (system OK, become sluggish with high CPU > > > utilization after sleep/wake), but was able to completely and reliably > > > fix it by updating to latest Lenovo BIOS (2018-09-17, version 1.31), and > > > setting the following settings in the BIOS: > > > > > > * UEFI Secure Boot: Off > > > * Power -> Sleep State: Linux > > > * Startup -> UEFI/Legacy Boot: UEFI Only > > > * Startup -> CSM Support: Yes > > > * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable > > > * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable > > > > > > It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my > > > problem. (In the BIOS itself, it recommends to set this option to Enable > > > for Linux systems). Everything is perfect now with my system. > > > > > > I'm running -current: > > > > > > thor$ dmesg | grep OpenBSD > > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > > > > > I'm happy to assist other OpenBSD users or developers if you need help > > > further investigating this issue. I have described my adventure, along > > > with dmesg and other details, here [4]. My dmesg is below. > > > > > > [1] https://www.youtube.com/watch?v=lb7mDXHGDFk >
Re: Old OpenBSD 6.1 Diagnosing alloc_subregion: can't allocate region and resource shortage: 1 pages of swap lost
Le 28 octobre 2018 11:55:20 GMT+01:00, Tom Smyth a écrit : >Hello, > >I have have a box terminating openVPN connections and after an >upstream router rebooted suddenly > >I salw a klog error followed by an alloc_subregion error followed by >extent_alloc_subregion error > >the OpenBSD Box ram s ram (according to the hypervisor) was not >completely used up... > >is there any other reason why the error below can occur ... > >are there any sysctl settings changes I need to condsider to avoid >this error in future ... > > >Thanks > >Tom Smyth It may be a bug in oenbsd or openvpn. You are 18 months behind regarding to updates, this may has been fixed since 6.1.
Re: acme-client memory setup failure
On October 28, 2018 12:09:02 AM EDT, "연락 연락" wrote: >Thank you indeed for your reply, trondd. >Yes, I added certificate(s) to cert.pem, probably more than one time so >far. >But the size looks not much bigger than normal one that I see from >another host. >size of the cert.pem modified(?): 357*** >size of cert.pem I see from another host where I didn't add anything to > >the cert.pem: 349*** > >Do you think 357*** is too big? >How did you solve the issue? >What can I do if something went wrong when I added certificates or when > >upgrading openbsd and adding the certificates again? > Put the original cert.pem back and see if it solves the issue first. >If the router/gateway before the host has been changed so the cert.pem >of the gateway is not the same of the previous one, can it be also a >matter? > > The cert.pem only matters on the machine making the SSL connection. >On 28/10/2018 04:54, trondd wrote: >> On Sat, October 27, 2018 6:19 am, ì*°ë*½ ì*°ë*½ wrote: >>> Dear misc, >>> >>> I am getting an error saying "ssl verify memory setup failure" >whenever >>> I try to renew existing certificates on a host -- Openbsd 6.3, >httpd, >>> acme-client. >>> Recently there were changes in a few configurations, including >network, >>> name servers, etc. >>> >>> The below is all I get when I try command acme-clilent -vv >example.com: >>> >>> ..domain key >>> ..account key >>> ..cert ...days left >>> ..directory >>> ..DNS: (some ip) >>> (some ip):tls_connect_socket: acme-v01.api.letsencrypt.org, ssl >verify >>> memory setup failure >>> ..bad comm >>> bad exit... >>> >>> Could someone let me know what could cause the ssl verify memory >setup >>> failure, or if the memory setup failure could be some kind of common >>> error, such as something occurred by memory configuration, such as >in >>> login.conf? >>> >>> For your information, those worked before. Recently thinking about >>> hardware issues, especially for RAM. >>> Because I can't share detailed configurations, names, etc., I am >>> wondering if someone could kindly give some advice on the above >>> information. >>> >>> Any help and your time would be greatly appreciated indeed. >>> >> >> Did you modify certs.pem? I've run into this when accidentally >adding >> certs multiple times growing the file too big or writing a DOS >formatted >> cert to it. >>
Re: Redistributing between bgpd and ospfd
Henry Bonath(he...@thebonaths.com) on 2018.10.27 19:21:15 -0400: > Claudio - > > One use case where I personally ran into this need in the past is in an > MPLS PE-CE where OSPF is running between the Provider and Customer. (L3VPN) > One would want to redistribute the Customers OSPF routes into BGP as VPNv4 > prefixes into the customers VRF in the provider network. > > We typically run Cisco on our CPE's and do exactly this with our customers, > with a redistribute ospf statement under "address-family vpnv4 vrf > cusomerVRF" > I'd *love* to be able to do the same with OpenBSD and not have to fork out > Cisco money at the customer premise. This should already be possible (as described my mail) with network inet priority 32 > That being said, EIGRPD would also benefit here, as I have customers that > run EIGRP and want to use that on their CE's. same there, use priority 28 /Benno > Thanks for everything that you do, and keep up the great work! > > On Mon, Oct 15, 2018 at 8:37 AM Claudio Jeker > wrote: > > > On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote: > > > On 15.10.18 12:58, Sebastian Benoit wrote: > > > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > > > > > Hello, > > > > > > > > > > I am trying to get bgpd and ospfd play nicely with route > > redistribution. > > > > > > > > > > So far the only way I have found that suits my need is to use > > > > > bgpd.conf network statements and rtlabels. > > > > > > > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in > > bgpd.conf: > > > > > match from set rtlabel from_bgpd > > > > > > > > > > And in ospfd.conf: > > > > > redistribute rtlabel from_bgpd > > > > > > > > > > > > > > > So far so good. But the other way around, to bake bgpd learn from > > > > > ospfd it becomes a bit more tedious. The only way I have found to > > make > > > > > bgpd announce ospf originated routes (to its bgp peers) is via > > network > > > > > statements in bgpd.conf. These network statements are not conditional > > > > > on the availability of such a route in ospf though so they are not > > > > > very dynamic anymore. > > > > > > > > > > I understand that it according to standard > > > > > (https://tools.ietf.org/html/rfc1364) should be something that is > > > > > explicit for type 1 and 2 LSAs. > > > > > > > > > > What is the recommended way to achieve dynamic explicit route > > > > > redistribution in both directions? > > > > Network statements are the correct way. > > > > > > > > You can use > > > > > > > > network (inet|inet6) priority ... > > > > network (inet|inet6) rtlabel ... > > > > > > > > So with > > > > > > > >network inet priority 32 > > > > > > > > you should be able to redistribute all ospf routes into bgp. > > > > > > > > If this does not help, please explain your problem further (and > > include your > > > > config). > > > > > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) > > for > > > > this as there was at least a bugfix for route-labels.) > > > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > > > setting them per area, or per interface where a route was learned. > > > just wondering why is it not implemented yet. is that too complex > > change? or > > > just not necessary? > > > > > > > Until now there has not been a need for this. In general and probably best > > common practice is to not mix BGP and OSPF. Instead OSPF is building the > > underlaying network to run BGP on top of. This is why benno@ was asking > > for the use case. > > > > By the way, because of the nature of OSPF it does not make sense to tag > > routes by interface, doing it by area could be an option but that comes > > with some edge cases that need further inspection. > > > > -- > > :wq Claudio > > > > > --
Re: Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
Hi Robert, I'm certainly not trolling (although I'm not sure what would be a protocol to prove it, other than posting a video that shows all mentioned BIOS settings and than a successful boot), and I'm sure you are not trolling either, as I can see a number of postings to this mailing list and your first one is from 10 years ago. [1] A never considered a threat model where a malicious user posts knowingly bad BIOS settings to brick other users machines, thank you for being vigilant. If anyone else thinks that posting a video with my BIOS settings and a successful boot would be useful, I'm happy to do that. In addition to double-checking my settings, I also looked at 4 links you've provided (I don't read German and can't check the last one). The first one is a very similar machine (the difference, from what I understand, is that all Yoga's have a multi-touch screen), but the post is from 7/13, and whatever the issue they encountered, I'm using a later BIOS (version 1.31 from 9/15). The second one is posted on 9/15, but the author and few others with similar problems have P52, which is a different machine - dual graphics with NVIDIA chip and a different CPUs - either i8750H or i8850H 6-core processors, while I have a i8550U. However, what is similar, is that enabling the BIOS Assist Mode does indeed require a 15-sec or so reboot, as the author describes, and that seemed to be a step that bricked their machine. The third author also has a different machine (P1, also with NVIDIA graphics), and they refer to BIOS version 1.12 from 10/12 release - again, a different BIOS. They also post a solution for their problem [2], however it requires extracting firmware and flushing it to EEPROM, so you better know what you are doing. The fourth author has a P72 (also a machine with NVIDIA graphics), and they did say they changed something in BIOS although they never specify what exactly. Thanks! [1] https://marc.info/?l=openbsd-misc=128033208924257=2 [2] https://www.reddit.com/r/thinkpad/comments/9rnimi/ladies_and_gentlemen_i_present_to_you_the/ On Sun, Oct 28, 2018, at 4:47 AM, Robert wrote: > WARNING: > > I do not know if the orginal author is serious, or if he is trolling. > > But there are known issues with the stated Thunderbolt setting in BIOS > that can brick your Thinkpad beyond repair (or BIOS reset). > > See here: > https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Thinkpad-X1-Yoga-3rd-Gen-Stuck-at-Black-Screen-After-Enabling/td-p/4106952/page/3 > https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Lenovo-P52-bricked-by-selecting-BIOS-thunderbolt-support-for/td-p/4207538 > https://www.reddit.com/r/thinkpad/comments/9qmqd2/thinkpad_p1_serious_issue_with_bricked_bios/ > https://www.reddit.com/r/thinkpad/comments/9nb3zo/new_thinkpad_p72_biosuefi_corrupted_just_black/ > > (german) > https://www.notebookcheck.com/Lenovo-Einige-aktuelle-ThinkPads-koennen-scheinbar-durch-eine-UEFI-Einstellung-zerstoert-werden.346101.0.html > > /Robert > > > On Sun, 28 Oct 2018 00:50:03 -0700 > ivp...@eml.cc wrote: > > > Hello, > > > > several people reported about various problems with Lenovo Thinkpad X1 > > Carbon 6th gen (X1C6), when performance become sluggish and fan goes wild. > > [1] [2] [3] > > > > I had similar problem (system OK, become sluggish with high CPU utilization > > after sleep/wake), but was able to completely and reliably fix it by > > updating to latest Lenovo BIOS (2018-09-17, version 1.31), and setting the > > following settings in the BIOS: > > > > * UEFI Secure Boot: Off > > * Power -> Sleep State: Linux > > * Startup -> UEFI/Legacy Boot: UEFI Only > > * Startup -> CSM Support: Yes > > * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable > > * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable > > > > It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my > > problem. (In the BIOS itself, it recommends to set this option to Enable > > for Linux systems). Everything is perfect now with my system. > > > > I'm running -current: > > > > thor$ dmesg | grep OpenBSD > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > > > I'm happy to assist other OpenBSD users or developers if you need help > > further investigating this issue. I have described my adventure, along with > > dmesg and other details, here [4]. My dmesg is below. > > > > [1] https://www.youtube.com/watch?v=lb7mDXHGDFk > > [2] https://marc.info/?l=openbsd-bugs=154070079630478 > > [3] https://marc.info/?l=openbsd-bugs=153770491811274=2 > > [4] > > https://www.reddit.com/r/openbsd/comments/9q8atz/thinkpad_x1c6_heats_up_dramatically_drops/ > > > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 16912433152 (16128MB) > > avail mem = 16390590464 (15631MB) > > mpath0 at root > > scsibus0 at mpath0: 256
Re: ikev2 and road warriors setup
Hello,
I really need your help.
I am still trying to configure Ikev2 VPN Gateway (A.B.C.77/23) for road
warriors clients (Windows).
The problem is that it works ONLY if clients are in the same subnet as VPN
Gateway (A.B.C.0/23).
Clients from out of the gateway's subnet (!A.B.C.0/23) can not establish the
connection (809 Error). It does not matter if they are behind NAT or not, tried
different ISP - the same.
Current tested client is Win7 (1.2.3.119). It works from A.B.C.0/23
I do not know what I am doing wrong.
Can anyone please help me with solving this problem?
Thank you.
This is a fresh 6.3/i386 install:
# syspatch -l
001_perl
002_libtls
003_arp
004_gif
005_httpd
006_ipseclen
007_libcrypto
008_ipsecout
009_libcrypto
011_perl
012_execsize
013_ipsecexpire
014_amdlfence
015_ioport
WAN:
# cat /etc/hostname.vr0
inet A.B.C.77 255.255.254.0
LAN:
# cat /etc/hostname.vr3
inet 172.16.0.254 255.255.255.0 NONE
group lan
# cat /etc/hostname.enc0
inet 10.0.1.1 255.255.255.0 10.0.1.255
up
# cat /etc/iked.conf
ikev2 "test" passive esp \
from 0.0.0.0/0 to 0.0.0.0/0 \
local A.B.C.77 peer any \
srcid A.B.C.77 \
config address 10.0.1.0/24 \
config name-server 8.8.8.8 \
tag "IKED"
# cat /etc/pf.conf
set skip on {lo, enc}
match in all scrub (no-df random-id max-mss 1310)
match out on egress from lan:network to any nat-to egress
match out on egress from enc0:network to any nat-to egress
block log all
pass in on egress proto udp from any to any port {isakmp,ipsec-nat-t}
pass in on egress proto {ah,esp}
pass out on egress
pass on lan
pass in on egress proto tcp from { 1.2.3.119 A.B.C.0/23 } to port ssh
icmp_types = "{ echoreq, unreach }"
pass inet proto icmp all icmp-type $icmp_types
# ikectl show ca vpn certificates
subject= /C=PL/ST=ZP/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com
SHA1 Fingerprint=37:2F:33:EA:C4:9C:45:0A:80:38:EC:0E:A6:F8:8B:EA:10:84:71:CB
notBefore=Oct 25 12:23:53 2018 GMT
notAfter=Oct 25 12:23:53 2019 GMT
subject= /C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com
SHA1 Fingerprint=4C:AE:A5:C6:E3:71:81:09:C0:73:BF:03:5F:E2:02:CE:48:BF:03:78
notBefore=Oct 25 12:27:35 2018 GMT
notAfter=Oct 25 12:27:35 2019 GMT
subject= /C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=win7/emailAddress=t...@123.com
SHA1 Fingerprint=E2:C1:96:F3:26:0F:CA:CD:49:0A:33:65:58:0E:07:B7:A7:90:D4:18
notBefore=Oct 25 12:32:31 2018 GMT
notAfter=Oct 25 12:32:31 2019 GMT
subject= /C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=w520/emailAddress=w...@123.com
SHA1 Fingerprint=00:ED:49:7B:CE:AF:46:25:BE:39:B6:51:AD:3E:06:91:99:58:50:C9
notBefore=Oct 27 08:54:14 2018 GMT
notAfter=Oct 27 08:54:14 2019 GMT
# iked -vvd
ikev2 "test" passive esp inet from 0.0.0.0/0 to 0.0.0.0/0 local A.B.C.77 peer
any ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth
hmac-sha2-256,hmac-sha1 group modp2048,modp1536,modp1024 childsa enc
aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 srcid A.B.C.77 lifetime
10800 bytes 536870912 signature config address 10.0.1.0 config name-server
8.8.8.8 tag "IKED"
/etc/iked.conf: loaded 1 configuration rules
ca_privkey_serialize: type RSA_KEY length 1193
ca_pubkey_serialize: type RSA_KEY length 270
ca_privkey_to_method: type RSA_KEY method RSA_SIG
ca_getkey: received private key type RSA_KEY length 1193
ca_getkey: received public key type RSA_KEY length 270
ca_dispatch_parent: config reset
config_getpolicy: received policy
config_getpfkey: received pfkey fd 3
config_getcompile: compilation done
config_getsocket: received socket fd 4
config_getsocket: received socket fd 5
config_getsocket: received socket fd 6
ca_reload: loaded ca file ca.crt
config_getsocket: received socket fd 7
config_getmobike: mobike
ca_reload: loaded crl file ca.crl
ca_reload: /C=PL/ST=ZP/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com
ca_reload: loaded 1 ca certificate
ca_reload: loaded cert file A.B.C.77.crt
ca_validate_cert:
/C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com ok
ca_reload: local cert type X509_CERT
config_getocsp: ocsp_url none
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_recv: IKE_SA_INIT request from initiator 1.2.3.119:500 to A.B.C.77:500
policy 'test' id 0, 528 bytes
ikev2_recv: ispi 0x683d59d10fbe4a9e rspi 0x
ikev2_policy2id: srcid IPV4/A.B.C.77 length 8
ikev2_pld_parse: header ispi 0x683d59d10fbe4a9e rspi 0x
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 528
response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 256
ikev2_pld_sa: more 2 reserved 0 length 40 proposal #1 protoid IKE spisize 0
xforms 4 spi 0
ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1
ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024
Re: Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
WARNING: I do not know if the orginal author is serious, or if he is trolling. But there are known issues with the stated Thunderbolt setting in BIOS that can brick your Thinkpad beyond repair (or BIOS reset). See here: https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Thinkpad-X1-Yoga-3rd-Gen-Stuck-at-Black-Screen-After-Enabling/td-p/4106952/page/3 https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Lenovo-P52-bricked-by-selecting-BIOS-thunderbolt-support-for/td-p/4207538 https://www.reddit.com/r/thinkpad/comments/9qmqd2/thinkpad_p1_serious_issue_with_bricked_bios/ https://www.reddit.com/r/thinkpad/comments/9nb3zo/new_thinkpad_p72_biosuefi_corrupted_just_black/ (german) https://www.notebookcheck.com/Lenovo-Einige-aktuelle-ThinkPads-koennen-scheinbar-durch-eine-UEFI-Einstellung-zerstoert-werden.346101.0.html /Robert On Sun, 28 Oct 2018 00:50:03 -0700 ivp...@eml.cc wrote: > Hello, > > several people reported about various problems with Lenovo Thinkpad X1 Carbon > 6th gen (X1C6), when performance become sluggish and fan goes wild. [1] [2] > [3] > > I had similar problem (system OK, become sluggish with high CPU utilization > after sleep/wake), but was able to completely and reliably fix it by updating > to latest Lenovo BIOS (2018-09-17, version 1.31), and setting the following > settings in the BIOS: > > * UEFI Secure Boot: Off > * Power -> Sleep State: Linux > * Startup -> UEFI/Legacy Boot: UEFI Only > * Startup -> CSM Support: Yes > * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable > * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable > > It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my problem. > (In the BIOS itself, it recommends to set this option to Enable for Linux > systems). Everything is perfect now with my system. > > I'm running -current: > > thor$ dmesg | grep OpenBSD > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > I'm happy to assist other OpenBSD users or developers if you need help > further investigating this issue. I have described my adventure, along with > dmesg and other details, here [4]. My dmesg is below. > > [1] https://www.youtube.com/watch?v=lb7mDXHGDFk > [2] https://marc.info/?l=openbsd-bugs=154070079630478 > [3] https://marc.info/?l=openbsd-bugs=153770491811274=2 > [4] > https://www.reddit.com/r/openbsd/comments/9q8atz/thinkpad_x1c6_heats_up_dramatically_drops/ > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16912433152 (16128MB) > avail mem = 16390590464 (15631MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x4f057000 (63 entries) > bios0: vendor LENOVO version "N23ET56W (1.31 )" date 09/17/2018 > bios0: LENOVO 20KHCTO1WW > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT > SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM > DMAR NHLT ASF! FPDT UEFI > acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) > RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) > PXSX(S4) RP07(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1393.14 MHz, 06-8e-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 23MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1138.49 MHz, 06-8e-0a > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4
Old OpenBSD 6.1 Diagnosing alloc_subregion: can't allocate region and resource shortage: 1 pages of swap lost
Hello, I have have a box terminating openVPN connections and after an upstream router rebooted suddenly I salw a klog error followed by an alloc_subregion error followed by extent_alloc_subregion error the OpenBSD Box ram s ram (according to the hypervisor) was not completely used up... is there any other reason why the error below can occur ... are there any sysctl settings changes I need to condsider to avoid this error in future ... Thanks Tom Smyth Oct 28 08:03:20 persistent02 /bsd: klog: dropped 906578 bytes, message buffer full Oct 28 08:03:36 persistent02 /bsd: alloc_subregion: can't allocate region descriptor Oct 28 08:03:36 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't
Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
Hello, several people reported about various problems with Lenovo Thinkpad X1 Carbon 6th gen (X1C6), when performance become sluggish and fan goes wild. [1] [2] [3] I had similar problem (system OK, become sluggish with high CPU utilization after sleep/wake), but was able to completely and reliably fix it by updating to latest Lenovo BIOS (2018-09-17, version 1.31), and setting the following settings in the BIOS: * UEFI Secure Boot: Off * Power -> Sleep State: Linux * Startup -> UEFI/Legacy Boot: UEFI Only * Startup -> CSM Support: Yes * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my problem. (In the BIOS itself, it recommends to set this option to Enable for Linux systems). Everything is perfect now with my system. I'm running -current: thor$ dmesg | grep OpenBSD OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 I'm happy to assist other OpenBSD users or developers if you need help further investigating this issue. I have described my adventure, along with dmesg and other details, here [4]. My dmesg is below. [1] https://www.youtube.com/watch?v=lb7mDXHGDFk [2] https://marc.info/?l=openbsd-bugs=154070079630478 [3] https://marc.info/?l=openbsd-bugs=153770491811274=2 [4] https://www.reddit.com/r/openbsd/comments/9q8atz/thinkpad_x1c6_heats_up_dramatically_drops/ OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16912433152 (16128MB) avail mem = 16390590464 (15631MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x4f057000 (63 entries) bios0: vendor LENOVO version "N23ET56W (1.31 )" date 09/17/2018 bios0: LENOVO 20KHCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR NHLT ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1393.14 MHz, 06-8e-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1138.49 MHz, 06-8e-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 950.25 MHz, 06-8e-0a cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 897.90 MHz, 06-8e-0a cpu3:
