Re: Dell R630 high interrupts on acpi0
Hi! The below diff extracts the memory range information from ACPI. It looks up all the memory ranges in _CRS and calculates minimal and maximal values for pci_machdep.c. I tested this on two amd64 machines and see no difference in pcidump. Do you think we need to keep the old method in case the ACPI on some machines does not report correct memory ranges? A simple check would be to test if pcimem_range[0] < pcimem_range[1]... Index: sys/arch/amd64/include/pci_machdep.h === RCS file: /cvs/src/sys/arch/amd64/include/pci_machdep.h,v retrieving revision 1.22 diff -u -p -b -r1.22 pci_machdep.h --- sys/arch/amd64/include/pci_machdep.h6 Nov 2013 10:40:36 - 1.22 +++ sys/arch/amd64/include/pci_machdep.h17 Dec 2014 06:00:01 - @@ -64,6 +64,7 @@ extern int pci_mcfg_min_bus, pci_mcfg_ma struct pci_attach_args; +extern uint64_t pcimem_range[2]; extern struct extent *pciio_ex; extern struct extent *pcimem_ex; extern struct extent *pcibus_ex; Index: sys/arch/amd64/pci/pci_machdep.c === RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v retrieving revision 1.60 diff -u -p -b -r1.60 pci_machdep.c --- sys/arch/amd64/pci/pci_machdep.c16 Dec 2014 23:13:20 - 1.60 +++ sys/arch/amd64/pci/pci_machdep.c17 Dec 2014 07:16:47 - @@ -66,6 +66,7 @@ */ #include +#include #include #include #include @@ -592,6 +593,7 @@ pci_intr_disestablish(pci_chipset_tag_t intr_disestablish(cookie); } +uint64_t pcimem_range[2] = {UINT64_MAX, 0}; struct extent *pciio_ex; struct extent *pcimem_ex; struct extent *pcibus_ex; @@ -618,31 +620,25 @@ pci_init_extents(void) if (pcimem_ex == NULL) { /* -* Cover the 36-bit address space addressable by PAE -* here. As long as vendors continue to support -* 32-bit operating systems, we should never see BARs -* outside that region. -* -* Dell 13G servers have important devices outside the -* 36-bit address space. Until we can extract the address -* ranges from ACPI, expand the allowed range to suit. +* Cover the address space extracted from ACPI. */ pcimem_ex = extent_create("pcimem", 0, 0xUL, M_DEVBUF, NULL, 0, EX_NOWAIT); if (pcimem_ex == NULL) return; - extent_alloc_region(pcimem_ex, 0x400UL, - 0xfc00UL, EX_NOWAIT); + extent_alloc_region(pcimem_ex, pcimem_range[1] + 1, + (0xUL - pcimem_range[1]), EX_NOWAIT); for (bmp = bios_memmap; bmp->type != BIOS_MAP_END; bmp++) { /* -* Ignore address space beyond 4G. +* Ignore address space beyond address range +* extracted from ACPI. */ - if (bmp->addr >= 0x1ULL) + if (bmp->addr > pcimem_range[1]) continue; size = bmp->size; - if (bmp->addr + size >= 0x1ULL) - size = 0x1ULL - bmp->addr; + if (bmp->addr + size > pcimem_range[1]) + size = pcimem_range[1] - bmp->addr + 1; /* Ignore zero-sized regions. */ if (size == 0) Index: sys/dev/acpi/acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v retrieving revision 1.277 diff -u -p -b -r1.277 acpi.c --- sys/dev/acpi/acpi.c 9 Dec 2014 06:58:29 - 1.277 +++ sys/dev/acpi/acpi.c 17 Dec 2014 05:59:36 - @@ -385,0 +385,0 @@ TAILQ_HEAD(, acpi_pci) acpi_pcirootdevs int acpi_getpci(struct aml_node *node, void *arg); int acpi_getminbus(union acpi_resource *crs, void *arg); +int acpi_getmemrange(union acpi_resource *crs, void *arg); + +int +acpi_getmemrange(union acpi_resource *crs, void *arg) +{ + int typ = AML_CRSTYPE(crs); + uint64_t *range = arg; /* size 2 */ + uint64_t min, max; + + switch(typ) { + case LR_24BIT: + min = crs->lr_m24._min; + max = crs->lr_m24._max; + break; + case LR_32BIT: + case LR_32BITFIXED: + min = crs->lr_m32._min; + max = crs->lr_m32._max; + break; + case LR_WORD: + min = crs->lr_word._min; + max = crs->lr_word._max; + break; + case LR_DWORD: + min = crs->lr_dword._min; + max = crs->lr_dword._max; + break; +
Re: Dell R630 high interrupts on acpi0
On Tue, Dec 16, 2014 at 2:45 PM, Hrvoje Popovski wrote: > on R630 i have custom bios settings and noticed that even if C states are > disabled in bios i can see them in dmesg > acpicpu0 at acpi0: C1 Uh, ACPI *requires* that C1 exist. The halt instruction is defined as entering C1, so not having C1 would mean your CPU lacks a basic manadatory ia32 instruction. Hopefully the BIOS docs explain that you're just disabling "deep" C-states or something like that. If not, yell at the company that made it. With the exception of "C1E", I wouldn't tell a BIOS to disable C-states unless it was causing the OS to have a problem or you're actively trying to use the computer to heat your house. "C1E" is a cross between C1 and C3; the issue is that bugs in multiple early hardware implementations mean it'll behave poorly depending on exactly how the OS handles it. This is something to test...and then test again with each release you install... > X2Apic is disabled too but in dmesg i see > cpu0: FPU,CPI,...SSE4.1,SSE4.2,x2APIC That just means the CPU has the feature bit set in the CPUID sets. The BIOS is presumably configuring ACPI (which is what OpenBSD pays attention to) to use the original LAPIC tables instead of the x2APIC tables for locating CPUs and interrupts. > R620 have similar settings and can't see C states in dmesg > acpicpu0 at acpi0 That's either insane, or a bug in our acpicpu code, IMO. > R620 bios settings ... > Monitor/Mwait - Disabled I would suggest leaving that on. We ain't using it *right now*, but, well, the source tree on my laptop is, and more than ever. :-) Philip Guenther
Re: "Cannot determine prefetch area" error with OpenBSD current autoinstall
On 12/16/14 22:06, Adriaan wrote: > On Tue, Dec 16, 2014 at 8:26 AM, Raf wrote: >> >> On Tue, Dec 16, 2014 at 01:01:51AM EST, Adriaan wrote: >> >> > An initial interactive install was succesful. A next autonstall using >> > bsd,rd gave a "Cannot determine prefetch area" after selecting the >> > sets. >> > [...] >> > Cannot determine prefetch area. Continue without verification? [no] no >> >> I see that tedu@ already mentioned the fact about your local storage is >> probably too small. I'll only add a link to the FAQ[0] in case you have >> missed it. >> > > With the following custom partition scheme of the same 3GB disk the > verification succeeds: > >> p m > OpenBSD area: 63-6322176; size: 3087.0M; free: 0.0M > #size offset fstype [fsize bsize cpg] > a: 2901.9M 64 4.2BSD 2048 163841 # / > b: 185.1M 5943168swap # none > c: 3093.4M0 unused > ... > So the verification procedure simply needed a larger partition. Look at the install scripts -- it doesn't prefetch just anywhere, it has a few specific places. /tmp, /home I think are two of the choices, may be more (NOTE: I am too tired to bother looking this up myself now, and it would be good experience for you to do so). I don't think /usr is. Thus, your original config, which had nowhere near enough space in /tmp or /home for the prefetch caused it not to. Nick.
Follow up from "What happened...."
Here is a rough dump of the attempted install: cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/5.5/i386/bsd.rd: 6038804+425032 [72+234464+223327]=0x699f80 entry point at 0x200120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5 (RAMDISK_CD) #229: Wed Mar 5 10:13:54 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Celeron(TM) CPU 1300MHz ("GenuineIntel" 686-class) 1.31 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF real mem = 527953920 (503MB) avail mem = 512069632 (488MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/27/02, BIOS32 rev. 0 @ 0xfb4b0, SMBIOS rev. 2.3 @ 0xf0800 (35 entries) bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 02/27/2002 bios0: VIA Technologies, Inc. VT8601 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP acpiprt0 at acpi0: bus 0 (PCI0) bios0: ROM list: 0xc/0xc000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "VIA VT8601 PCI" rev 0x05 ppb0 at pci0 dev 1 function 0 "VIA VT82C601 AGP" rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 "Trident CyberBlade i1" rev 0x6a wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) pcib0 at pci0 dev 7 function 0 "VIA VT82C686 ISA" rev 0x40 pciide0 at pci0 dev 7 function 1 "VIA VT82C571 IDE" rev 0x06: ATA100, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 78167MB, 160086528 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 uhci0 at pci0 dev 7 function 2 "VIA VT83C572 USB" rev 0x1a: irq 5 uhci1 at pci0 dev 7 function 3 "VIA VT83C572 USB" rev 0x1a: irq 5 "VIA VT82C686 SMBus" rev 0x40 at pci0 dev 7 function 4 not configured rl0 at pci0 dev 17 function 0 "Realtek 8139" rev 0x10: irq 11, address 00:01:80:0f:2b:94 rlphy0 at rl0 phy 0: RTL internal PHY isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 "VIA UHCI root hub" rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 "VIA UHCI root hub" rev 1.00/1.00 addr 1 softraid0 at root scsibus1 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/i386 5.5 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? i At any prompt except password prompts you can escape to a shell by typing '!'. Default answers are shown in []'s and are selected by pressing RETURN. You can exit this program at any time by pressing Control-C, but this can leave your system in an inconsistent state. Terminal type? [vt220] System hostname? (short form, e.g. 'foo') foo Available network interfaces are: rl0 vlan0. Which network interface do you wish to configure? (or 'done') [rl0] IPv4 address for rl0? (or 'dhcp' or 'none') [dhcp] Issuing hostname-associated DHCP request for rl0. DHCPDISCOVER on rl0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 192.168.80.254 (80:1f:02:c9:d7:2e) DHCPREQUEST on rl0 to 255.255.255.255 port 67 DHCPACK from 192.168.80.254 (80:1f:02:c9:d7:2e) bound to 192.168.80.251 -- renewal in 43200 seconds. IPv6 address for rl0? (or 'rtsol' or 'none') [none] Available network interfaces are: rl0 vlan0. Which network interface do you wish to configure? (or 'done') [done] Using DNS domainname witworx.com.com Using DNS nameservers at 192.168.80.1 Password for root account? (will not echo) Password for root account? (again) Start sshd(8) by default? [yes] Start ntpd(8) by default? [no] Do you expect to run the X Window System? [yes] no Change the default console to com0? [no] Setup a user? (enter a lower-case loginname, or 'no') [no] What timezone are you in? ('?' for list) [Australia/Sydney] Available disks are: wd0. Which disk is the root disk? ('?' for details) [wd0] Use DUIDs rather than device names in fstab? [yes] Disk: wd0 geometry: 9964/255/63 [160086528 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0:
Re: "Cannot determine prefetch area" error with OpenBSD current autoinstall
On Tue, Dec 16, 2014 at 8:26 AM, Raf wrote: > > On Tue, Dec 16, 2014 at 01:01:51AM EST, Adriaan wrote: > > > An initial interactive install was succesful. A next autonstall using > > bsd,rd gave a "Cannot determine prefetch area" after selecting the > > sets. > > [...] > > Cannot determine prefetch area. Continue without verification? [no] no > > I see that tedu@ already mentioned the fact about your local storage is > probably too small. I'll only add a link to the FAQ[0] in case you have > missed it. > With the following custom partition scheme of the same 3GB disk the verification succeeds: > p m OpenBSD area: 63-6322176; size: 3087.0M; free: 0.0M #size offset fstype [fsize bsize cpg] a: 2901.9M 64 4.2BSD 2048 163841 # / b: 185.1M 5943168swap # none c: 3093.4M0 unused Set name(s)? (or 'abort' or 'done') [done] Get/Verify SHA256.sig 100% |**| 2067 00:00 Signature Verified Get/Verify bsd 100% |**| 10295 KB 00:03 Get/Verify bsd.rd 100% |**| 6773 KB 00:01 Get/Verify base56.tgz 100% |**| 51074 KB 00:15 Installing bsd 100% |**| 10295 KB 00:02 Installing bsd.rd 100% |**| 6773 KB 00:01 Installing base56.tgz 100% |**| 51074 KB 00:56 Extracting etc.tgz 100% |**| 110 KB 00:00 Location of sets? (disk http or 'done') [done] So the verification procedure simply needed a larger partition. > > > failed; check /ai.log > > Have you checked '/ai.log'? > Yes, but that was identical to the serial console output captured by tip. > > > Checksum test for site56.tgz failed. Continue anyway? = yes > > Unverified sets: site56.tgz. Continue without verification? = yes > > Checksum test for site56-andromache.tgz failed. Continue anyway? = yes > > Unverified sets: site56-andromache.tgz. Continue without verification? = > > yes > > Given that the initial installation finishes just fine, I conclude that > the second attempt fails due to your 'site*.tgz'[1] file sets being too > big - try again without them. > Only containing a few scripts and configuration files, the site*tgz file is only 4K: -rw-r--r-- 1 root wheel 4913 Dec 16 03:25 site56.tgz > > [0] http://www.openbsd.org/faq/faq4.html#InstMedia > [1] http://www.openbsd.org/faq/faq4.html#site > Thanks, it has been a while since I read those sections. But it indeeds mentions the "Cannot determine prefetch area" error that I had never seen before. Adding the following to the install.conf file makes an autoinstall with the auto layout succeed: Cannot determine prefetch area. Continue without verification? = yes >From the log: Set name(s)? (or 'abort' or 'done') [done] -all bsd bsd.rd base56.tgz site56.tgz done Cannot determine prefetch area. Continue without verification? [no] yes Installing bsd 100% |**| 10295 KB 00:01 Installing bsd.rd 100% |**| 6773 KB 00:00 Installing base56.tgz 100% |**| 51074 KB 00:45 Extracting etc.tgz 100% |**| 110 KB00:00 So problem has been solved. Just have to verifiy the sets on the local snapshot web server by myself. Adriaan
Re: Dell R630 high interrupts on acpi0
On 16.12.2014. 6:16, Jonathan Matthew wrote: We just got some r630s too, so I spent some time last week figuring out what's going on here. Something in the AML wants to talk to the intel MEI device. Normally this works, but on the new generation of dell machines (we've seen it on r630s and r730s), it's been moved outside the pci memory range we currently allow on amd64. You can see this in your dmesgs: 0:22:0: mem address conflict 0x3303000/0x10 0:22:1: mem address conflict 0x3302000/0x10 The interrupt will keep triggering until it manages to talk to the device, which will never happen. kettenis@ says we can get the pci memory range information we need to deal with this from acpi. Until that happens, expanding the allowed pci memory range makes things work properly. Hi, on R630 i have custom bios settings and noticed that even if C states are disabled in bios i can see them in dmesg acpicpu0 at acpi0: C1 acpicpu1 at acpi0: C1 acpicpu2 at acpi0: C1 acpicpu3 at acpi0: C1 acpicpu4 at acpi0: C1 acpicpu5 at acpi0: C1 acpicpu6 at acpi0: C1 acpicpu7 at acpi0: C1 X2Apic is disabled too but in dmesg i see cpu0: FPU,CPI,...SSE4.1,SSE4.2,x2APIC This is not good, right? R630 bios settings Processor Settings: Logical Processor - Disabled QPI Speed - Maximum data rate Alternate RTID Settings - Disabled Virtualization Technology - Disabled Address Translation Service (ATS) - Disabled (gray) Adjacent Cache Line Prefetch - Enabled Hardware Prefetcher - Enabled DCU Streamer Prefetcher - Enabled DCU IP Prefetcher - Enabled Execute Disabled - Enabled Logical Processor Idling - Disabled Configurable TDP - Nominal X2Apic Mode - Disabled (gray) Dell Controlled Turbo - Enabled System Profile Settings: System Profile - Custom CPU Power Management - Maximum Performance Memory Frequency - Maximum Performance Turbo Boost - Enabled Energy Efficient Turbo - Disabled C1E - Disabled C states - Disabled Collaborative CPU Performance Control - Disabled Memory Patrol Scrub - Standard Memory Refresh Rate - 1x Uncore Frequency - Maximum Energy Efficient Policy - Performance Full dmesg and acpidump from R630 http://kosjenka.srce.hr/~hrvoje/R630_custom_dmesg.txt http://kosjenka.srce.hr/~hrvoje/R630_custom.tgz R620 have similar settings and can't see C states in dmesg acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpicpu4 at acpi0 acpicpu5 at acpi0 R620 bios settings Processor Settings: Logical Processor - Disabled Alternate RTID Settings - Disabled Virtualization Technology - Disabled Adjacent Cache Line Prefetch - Enabled Hardware Prefetcher - Enabled DCU Streamer Prefetcher - Enabled DCU IP Prefetcher - Enabled Logical Processor Idling - Disabled Dell Controlled Turbo - Enabled System Profile Settings: System Profile - Custom CPU Power Management - Maximum Performance Memory Frequency - Maximum Performance Turbo Boost - Enabled C1E - Disabled C states - Disabled Monitor/Mwait - Disabled Memory Patrol Scrub - Standard Memory Refresh Rate - 1x Memory Operating Voltage - Auto Collaborative CPU Performance Control - Disabled Full dmesg and acpidump from R620 http://kosjenka.srce.hr/~hrvoje/R620_custom_dmesg.txt http://kosjenka.srce.hr/~hrvoje/R620_custom.tgz
xfce4-power-manager not updating battery status
Hi, not being satisfied with various Linux flavours on my ThinkPad T440, I have reverted back to OpenBSD. With the exception of non-supported internal wifi card (realtek usb dongle works more or less fine with urtwn), and not having sound over HDMI (I have dedicated another older laptop for HTPC use), I use it without significant problems so far. As a long time xfce user, I got used to monitor my battery status with xfce4-power-manager. Unfortunately, I don't have much use of it, as it does not update battery status in real time. Upon start it shows the correct status, but it does not update afterwards. I need to restart the application in order to update. Any chance for fixing this? Thank you in advance. -- Marko Cupać https://www.mimar.rs/
Re: SUN SPARCstation IPX to give away
All, The machine has been claimed by the project. Kind regards, Mark > -Original Message- > From: Mark Hesselink [mailto:mhess...@alumni.caltech.edu] > Sent: 14 December 2014 11:37 > To: 'misc@openbsd.org' > Subject: SUN SPARCstation IPX to give away > > All, > > Due to lack of free time I would like to give away my SUN SPARCstation > IPX to a good, new home. The machine has the following specifications: > > * 64 MB of internal memory > * COMPAQ BB009222B5 9.1 GB 7200 RPM Wide Ultra 2 68-pin SCSI hard disk > drive including necessary accessories. > * AUI to 10BASE-T converter > * PROM version 2.3 > * Fresh NVRAM, i.e. NVRAM battery is very much alive. > > The machine has been running until very recently in the above > configuration. It is currently offline due to a faulty power supply > unit. Word of warning: Replacement PSUs are available on the Internet > but terribly expensive. > > If the project has a need for this machine, I am happy to cover the > shipping costs as well. Please contact me off-list if you are > interested. > > Kind regards, > > Mark > > P.S. I am UK based.
Re: DigitalOcean's BSD debut is FreeBSD only
FWIW I have an OpenBSD 'box' with rootbsd.net. Never a single issue ever. On Tue, Dec 16, 2014 at 7:10 AM, wrote: > > Hi, > > It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in > the OpenBSD community, are being asked to open up a separate UserVoice vote > for OpenBSD -- despite the fact that we've worked so hard to promote the > existing one. So, please drop by and share your frustrations: > > > https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os > -- I reckon around half the votes are from OpenBSD users. > > Many thanks! > > O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On 17/12/14 05:25, jungle Boogie wrote: > I have not personally tested openBSD on https://www.vultr.com/ but I > have read (tweets, probably) that it will work. I am doing so, twice. Working well. You can use a custom ISO, they do not specifically enable OpenBSD. I have a digital Ocean instance too, but they do not (last time I checked) allow custom ISOs. Worik -- Why is the legal status of chardonnay different to that of cannabis? worik.stan...@gmail.com 021-1680650, (03) 4821804 Aotearoa (New Zealand) I voted for love
Re: DigitalOcean's BSD debut is FreeBSD only
online.net is also a great cloud based server hosting service... -Message d'origine- De : owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] De la part de Gene Envoyé : mardi 16 décembre 2014 19:19 À : Richard E. Thornton Cc : misc Objet : Re: DigitalOcean's BSD debut is FreeBSD only On Mon, Dec 15, 2014 at 11:25 PM, Richard E. Thornton < thornton.rich...@gmail.com> wrote: > So, its a cloud based server farm? What's the point for the typical user? Inexpensive VPS hosting with fast storage. I have one of their small instances (1 vCPU, 512 MB RAM, 20 GB storage) I'm paying $5/mo for. I'm pretty happy with it. $ sudo dd if=/dev/vda of=/dev/null bs=1024k count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 7.31609 s, 294 MB/s On Tue, 16 Dec 2014, openda...@hushmail.com wrote: > > > Hi, > > > > On 16. desember 2014 at 4:17 PM, "Lars" wrote: > > > > > >Says who? Now it's digital ocean - next month it will be somebody > > >else. > > > > > >I seem to fall out of the target group for this. As I don't share > > >your obvious enthusiasm and just don't care - so many rock stars > > >rise and fall. > > > > There's never been anyone as cheap, as well-designed and as quickly > growing as DigitalOcean. Call them The Beatles, The Bob Marley and the > Wailers or what have you. I wrote this thread for the people who do > care, and I know a lot of you are lurking out there. > > > > O.D.
Re: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
I received a request to share my updated configuration, so I thought I would send it to the list in case others might also find it useful. ## Router 1 # cat /etc/hostname.gre0 169.254.0.1 169.254.0.2 netmask 0x link0 up tunnel 172.16.5.1 172.16.5.2 !route add -net 172.16.6.0/24 169.254.0.2 !route add -net 172.16.7.0/24 169.254.0.2 # cat /etc/ipsec.conf ike passive esp transport \ from 172.16.5.1 to 172.16.5.2 \ main auth hmac-sha2-512 enc aes-256 group modp2048 \ quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \ srcid "" \ dstid "" # cat /etc/sysctl.conf net.inet.ip.forwarding=1 net.inet.gre.allow=1 kern.bufcachepercent=50 net.inet.ip.ifq.maxlen=2048 # cat /etc/rc.conf.local ipsec=YES isakmpd_flags="-K -T" # ifconfig gre0: flags=29011 mtu 1476 priority: 0 groups: gre tunnel: inet 172.16.5.1 -> 172.16.5.2 inet 169.254.0.1 --> 169.254.0.2 netmask 0x # ipsecctl -sa FLOWS: flow esp in from 172.16.5.2 to 172.16.5.1 peer 172.16.5.2 srcid dstid type use flow esp out from 172.16.5.1 to 172.16.5.2 peer 172.16.5.2 srcid dstid type require SAD: esp transport from 172.16.5.1 to 172.16.5.2 spi 0x6b898652 auth hmac-sha2-512 enc aes-256-ctr esp transport from 172.16.5.2 to 172.16.5.1 spi 0xf4bff52e auth hmac-sha2-512 enc aes-256-ctr # route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default UGS 1125 6077357 - 8 vlan0 169.254.0.1127.0.0.1 UHl00 - 1 lo0 169.254.0.2169.254.0.1UH 2 100720 - 4 gre0 172.16.5/24link#11UC 10 - 4 vlan7 172.16.5.1 UHLl 00 - 1 lo0 172.16.5.2 UHLc 2 113643 - L 4 vlan7 172.16.6/24169.254.0.2UGS02 - 8 gre0 172.16.7/24169.254.0.2UGS0 5928 - 8 gre0 Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 172.16.5.2/32 0 172.16.5.1/32 0 0 172.16.5.2/esp/use/in 172.16.5.1/32 0 172.16.5.2/32 0 0 172.16.5.2/esp/require/out ## Router 2 # cat /etc/hostname.gre0 169.254.0.2 169.254.0.1 netmask 0x link0 up tunnel 172.16.5.2 172.16.5.1 !route add -net default 169.254.0.1 # cat /etc/ipsec.conf ike esp transport \ from 172.16.5.2 to 172.16.5.1 \ main auth hmac-sha2-512 enc aes-256 group modp2048 \ quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \ srcid "" \ dstid "" # cat /etc/sysctl.conf net.inet.ip.forwarding=1 net.inet.gre.allow=1 kern.bufcachepercent=50 net.inet.ip.ifq.maxlen=1024 # cat /etc/rc.conf.local ipsec=YES isakmpd_flags="-K -T" # ifconfig gre0: flags=29011 mtu 1476 priority: 0 groups: gre egress tunnel: inet 172.16.5.2 -> 172.16.5.1 inet 169.254.0.2 --> 169.254.0.1 netmask 0x # ipsecctl -sa FLOWS: flow esp in from 172.16.5.1 to 172.16.5.2 peer 172.16.5.1 srcid dstid type use flow esp out from 172.16.5.2 to 172.16.5.1 peer 172.16.5.1 srcid dstid type require SAD: esp transport from 172.16.5.1 to 172.16.5.2 spi 0x6b898652 auth hmac-sha2-512 enc aes-256-ctr esp transport from 172.16.5.2 to 172.16.5.1 spi 0xf4bff52e auth hmac-sha2-512 enc aes-256-ctr # route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default169.254.0.1UGS485718 - 8 gre0 169.254.0.1169.254.0.2UH 10 - 4 gre0 169.254.0.2127.0.0.1 UHl00 - 1 lo0 172.16.5/24link#4 UC 20 - 4 vlan0 172.16.5.1 UHLc 285781 - 4 vlan0 172.16.5.2 HLl00 - 1 lo0 172.16.5.3 HLl00 - 1 lo0 172.16.5.21 UHLc 02 - 4 vlan0 172.16.6/24link#5 UC 00 - 4 vlan1 172.16.6.1 HLl00 - 1 lo0 172.16.7/24link#6 UC 00 - 4 vlan2 172.16.7.1 HLl00 - 1 lo0 Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 172.16.5.1/32 0 172.16.5.2/32 0 0 172.16.5.1/esp/use/in 172.16.5.2/32 0 172.16.5.1/32 0 0 172.16.5.1/esp/require/out On Tue, Dec 16, 2014 at 11:05 AM, Joseph Crivello wrote: > > I was able to resolve my own problem. > > The solution I found was to create a gre tunnel between the two routers > using the gre(4) pseudo-device. Once I had that working, I used IPSEC > transport mode to pr
Re: DigitalOcean's BSD debut is FreeBSD only
On 12/16/2014 06:18 PM, openda...@hushmail.com wrote: There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Wanna bet? http://xkcd.com/1102
kvm_mkdb: can't open /dev/ksyms
I just upgraded to the latest amd64 snapshot (Dec 16) on a Soekris 6501 and noticed the following line on the console during startup: kvm_mkdb: can't open /dev/ksyms The kvm_mkdb(8) man page doesn't mention anything about /dev that I can see. Permissions issue of some kind, perhaps? $ ls -al /dev/ksyms crw-r- 1 root kmem 50, 0 Dec 16 08:43 /dev/ksyms Not sure whether this is anything to be concerned, so thought I would ask here. Thanks in advance. dmesg follows. OpenBSD 5.6-current (GENERIC.MP) #696: Tue Dec 16 00:26:02 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056833536 (1007MB) avail mem = 1024901120 (977MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0 acpi at bios0 not configured mpbios0 at bios0: Intel MP Specification 1.4 cpu0 at mainbus0: apid 0 (boot processor) cpu0: Genuine Intel(R) CPU @ 1.00GHz, 1000.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU @ 1.00GHz, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 mpbios0: bus 0 is type PCI mpbios0: bus 64 is type ISA ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins cpu0: unknown Enhanced SpeedStep CPU, msr 0x060e0a1102000a11 cpu0: using only highest and lowest power states cpu0: Enhanced SpeedStep 1000 MHz: speeds: 1000, 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel E600 Host" rev 0x03 pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00 ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01 pci2 at ppb1 bus 2 "Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured "Intel EG20T Ethernet" rev 0x01 at pci2 dev 0 function 1 not configured "Intel EG20T GPIO" rev 0x00 at pci2 dev 0 function 2 not configured ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x01: apic 0 int 19, version 1.0, legacy support ohci1 at pci2 dev 2 function 1 "Intel EG20T USB" rev 0x01: apic 0 int 19, version 1.0, legacy support ohci2 at pci2 dev 2 function 2 "Intel EG20T USB" rev 0x01: apic 0 int 19, version 1.0, legacy support ehci0 at pci2 dev 2 function 3 "Intel EG20T USB" rev 0x01: apic 0 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel EG20T USB Client" rev 0x01 at pci2 dev 2 function 4 not configured sdhc0 at pci2 dev 4 function 0 "Intel EG20T SDIO" rev 0x01: apic 0 int 18 sdmmc0 at sdhc0 sdhc1 at pci2 dev 4 function 1 "Intel EG20T SDIO" rev 0x01: apic 0 int 18 sdmmc1 at sdhc1 ahci0 at pci2 dev 6 function 0 "Intel EG20T AHCI" rev 0x01: msi, AHCI 1.1 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed naa.5001517bb297bc22 sd0: 19087MB, 512 bytes/sector, 39091248 sectors, thin ohci3 at pci2 dev 8 function 0 "Intel EG20T USB" rev 0x01: apic 0 int 16, version 1.0, legacy support ohci4 at pci2 dev 8 function 1 "Intel EG20T USB" rev 0x01: apic 0 int 16, version 1.0, legacy support ohci5 at pci2 dev 8 function 2 "Intel EG20T USB" rev 0x01: apic 0 int 16, version 1.0, legacy support ehci1 at pci2 dev 8 function 3 "Intel EG20T USB" rev 0x01: apic 0 int 16 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel EG20T DMA" rev 0x00 at pci2 dev 10 function 0 not configured puc0 at pci2 dev 10 function 1 "Intel EG20T Serial" rev 0x00: ports: 1 com com4 at puc0 port 0 apic 0 int 19: ti16750, 64 byte fifo puc1 at pci2 dev 10 function 2 "Intel EG20T Serial" rev 0x00: ports: 1 com com5 at puc1 port 0 apic 0 int 19: ti16750, 64 byte fifo puc2 at pci2 dev 10 function 3 "Intel EG20T Serial" rev 0x00: ports: 1 com com6 at puc2 port 0 apic 0 int 19: ti16750, 64 byte fifo puc3 at pci2 dev 10 function 4 "Intel EG20T Serial" rev 0x00: ports: 1 com com7 at puc3 port 0 apic 0 int 19: ti16750, 64 byte fifo "Intel EG20T DMA" rev 0x00 at pci2 dev 12 function 0 not configured "Intel EG20T SPI" rev 0x00 at pci2 dev 12 function 1 not configured "Intel EG20T I2C" rev 0x00 at pci2 dev 12 function 2 not configured "Intel EG20T CAN" rev 0x00 at pci2 dev 12 function 3 not configured "Intel EG20T 1588" rev 0x01 at pci2 dev 12 function 4 not configured usb2 at o
Re: DigitalOcean's BSD debut is FreeBSD only
On Mon, Dec 15, 2014 at 11:25 PM, Richard E. Thornton < thornton.rich...@gmail.com> wrote: > So, its a cloud based server farm? What's the point for the typical user? Inexpensive VPS hosting with fast storage. I have one of their small instances (1 vCPU, 512 MB RAM, 20 GB storage) I'm paying $5/mo for. I'm pretty happy with it. $ sudo dd if=/dev/vda of=/dev/null bs=1024k count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 7.31609 s, 294 MB/s On Tue, 16 Dec 2014, openda...@hushmail.com wrote: > > > Hi, > > > > On 16. desember 2014 at 4:17 PM, "Lars" wrote: > > > > > >Says who? Now it's digital ocean - next month it will be somebody > > >else. > > > > > >I seem to fall out of the target group for this. As I don't share your > > >obvious enthusiasm and just don't care - so many rock stars rise > > >and fall. > > > > There's never been anyone as cheap, as well-designed and as quickly > growing as DigitalOcean. Call them The Beatles, The Bob Marley and the > Wailers or what have you. I wrote this thread for the people who do care, > and I know a lot of you are lurking out there. > > > > O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On 2014-12-16 12:58, openda...@hushmail.com wrote: ...Once that time comes, he or she will most definitely be looking for something like DigitalOcean. Lest we forget ... this mailing list recently had a thread on security implications for data-in=-motion on virtual machines of third party providers. http://marc.info/?t=14181504512&r=1&w=2 --- Disclaimer: I don't know anything about DigitalOcean except that they ignore my LART submissions to their abuse@ address.
Re: DigitalOcean's BSD debut is FreeBSD only
On 16. desember 2014 at 5:46 PM, "Richard E. Thornton" wrote: > >So, its a cloud based server farm? What's the point for the >typical user? I think the typical user will eventually realize that OpenBSD is one of the most valuable assets he or she can use in the pursuit of happiness and livelihood for ones family. Once that time comes, he or she will most definitely be looking for something like DigitalOcean. Thanks. O.D. > > >On Tue, 16 Dec 2014, openda...@hushmail.com wrote: > >> Hi, >> >> On 16. desember 2014 at 4:17 PM, "Lars" wrote: >> > >> >Says who? Now it's digital ocean - next month it will be >somebody >> >else. >> > >> >I seem to fall out of the target group for this. As I don't >share your >> >obvious enthusiasm and just don't care - so many rock stars >rise >> >and fall. >> >> There's never been anyone as cheap, as well-designed and as >quickly growing as DigitalOcean. Call them The Beatles, The Bob >Marley and the Wailers or what have you. I wrote this thread for >the people who do care, and I know a lot of you are lurking out >there. >> >> O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
So, its a cloud based server farm? What's the point for the typical user? On Tue, 16 Dec 2014, openda...@hushmail.com wrote: > Hi, > > On 16. desember 2014 at 4:17 PM, "Lars" wrote: > > > >Says who? Now it's digital ocean - next month it will be somebody > >else. > > > >I seem to fall out of the target group for this. As I don't share your > >obvious enthusiasm and just don't care - so many rock stars rise > >and fall. > > There's never been anyone as cheap, as well-designed and as quickly growing > as DigitalOcean. Call them The Beatles, The Bob Marley and the Wailers or > what have you. I wrote this thread for the people who do care, and I know a > lot of you are lurking out there. > > O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On Tue, Dec 16, 2014 at 05:20:27PM +, openda...@hushmail.com wrote: > Hi, > > On 16. desember 2014 at 4:20 PM, "jungle Boogie" wrote: > > > >I have not personally tested openBSD on https://www.vultr.com/ but > >I have read (tweets, probably) that it will work. > > I'm not so sure about Vultr. Icelandic Greenqloud (https://www.greenqloud.com/) are nice though. I personally use vultr for my OpenBSD vps. Their prices are reasonable, you can install from any ISO, and I have never had a problem. Currently hosting, my website, email, jabber server, and code repositories. > > O.D. > -- Benjamin Scher Purcell PGP: CCB787BA [demime 1.01d removed an attachment of type application/pgp-signature]
Re: DigitalOcean's BSD debut is FreeBSD only
On Tue, Dec 16, 2014 at 05:21:16PM +, openda...@hushmail.com wrote: > Hi, > > On 16. desember 2014 at 4:44 PM, "Lars" wrote: > > > >There are quite a few of them. https://www.transip.eu/vps/ > >officially support OpenBSD and FreeBSD. Also completely SSD enabled. It > >seems > >to be just hype > > I quit using them after they refused to enable virtio for OpenBSD, despite > having enabled it for FreeBSD. > > O.D. That has changed, they now do support virtio. -Otto
Re: DigitalOcean's BSD debut is FreeBSD only
Thanks for sharing this. This is awesome, best news in all day. I was using Debian but when this is ready, I will use FreeBSD. If you're a student I invite you to join ( https://education.github.com/pack ), you get $100 in DO credit. On Tue, Dec 16, 2014 at 8:10 AM, wrote: > Hi, > > It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in > the OpenBSD community, are being asked to open up a separate UserVoice vote > for OpenBSD -- despite the fact that we've worked so hard to promote the > existing one. So, please drop by and share your frustrations: > > https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os > -- I reckon around half the votes are from OpenBSD users. > > Many thanks! > > O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
Hi, On 16. desember 2014 at 4:44 PM, "Lars" wrote: > >There are quite a few of them. https://www.transip.eu/vps/ >officially support OpenBSD and FreeBSD. Also completely SSD enabled. It seems >to be just hype I quit using them after they refused to enable virtio for OpenBSD, despite having enabled it for FreeBSD. O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
Hi, On 16. desember 2014 at 4:20 PM, "jungle Boogie" wrote: > >I have not personally tested openBSD on https://www.vultr.com/ but >I have read (tweets, probably) that it will work. I'm not so sure about Vultr. Icelandic Greenqloud (https://www.greenqloud.com/) are nice though. O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
Hi, On 16. desember 2014 at 4:17 PM, "Lars" wrote: > >Says who? Now it's digital ocean - next month it will be somebody >else. > >I seem to fall out of the target group for this. As I don't share your >obvious enthusiasm and just don't care - so many rock stars rise >and fall. There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Call them The Beatles, The Bob Marley and the Wailers or what have you. I wrote this thread for the people who do care, and I know a lot of you are lurking out there. O.D.
Re: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
I was able to resolve my own problem. The solution I found was to create a gre tunnel between the two routers using the gre(4) pseudo-device. Once I had that working, I used IPSEC transport mode to protect the GRE tunnel. This method eliminates all default encap routes from both routers; which was the root cause of the problem. -Joe -Original Message- From: Joe Crivello [mailto:josephcrive...@gmail.com] Sent: Monday, December 15, 2014 2:24 PM Subject: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN Hello, I am having a problem with a particular aspect of my attempt to establish an IPSEC site-to-site tunnel between two gateways using ISAKMPD/IKEv1. I seem to be doing something wrong, but I have exhausted all of the resources that I know of in my quest to fix the problem (MAN pages, OpenBSD.org FAQ, Google, etc). I am hoping that someone with more OpenBSD experience than myself will be able to help me... either way, thanks so much for your time! The routers in question both run OpenBSD 5.6, situated at either end of long range wifi bridge link. Router "1" also has a interface connecting to an ISP router, which provides a route to the Internet: Internet <==> Router 1 172.16.5.1 || Wifi || 172.16.5.2 Router 2 <==> Local Networks (172.16.6.1/24, 172.16.7.1/24) The intention is to establish an IPSEC tunnel between Router 1 and Router 2, over which Router 2 should send all traffic not destined for one of it's local networks. Accordingly, I set the default route of Router 2 to 172.16.5.1, and I configured the tunnel like so: ## Router 1 ike passive esp \ from any to { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } \ local 172.16.5.1 peer 172.16.5.2 \ main auth hmac-sha2-512 enc aes-256 group modp2048 \ quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \ srcid "" \ dstid "" ## Router 2 ike active esp \ from { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } to any \ local 172.16.5.2 peer 172.16.5.1 \ main auth hmac-sha2-512 enc aes-256 group modp2048 \ quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \ srcid "" \ dstid "" This configuration (correctly) causes six SAs to be established: ## Router 1 # ipsecctl -sa FLOWS: flow esp in from 172.16.5.2 to 0.0.0.0/0 peer 172.16.5.2 srcid dstid type use flow esp out from 0.0.0.0/0 to 172.16.5.2 peer 172.16.5.2 srcid dstid type require flow esp in from 172.16.7.0/24 to 0.0.0.0/0 peer 172.16.5.2 srcid dstid type use flow esp out from 0.0.0.0/0 to 172.16.7.0/24 peer 172.16.5.2 srcid dstid type require flow esp in from 172.16.6.0/24 to 0.0.0.0/0 peer 172.16.5.2 srcid dstid type use flow esp out from 0.0.0.0/0 to 172.16.6.0/24 peer 172.16.5.2 srcid dstid type require SAD: esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x6769c99e auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0xad29e69c auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512 enc aes-256-ctr ## Router 2 # ipsecctl -sa FLOWS: flow esp in from 0.0.0.0/0 to 172.16.5.2 peer 172.16.5.1 srcid dstid type use flow esp out from 172.16.5.2 to 0.0.0.0/0 peer 172.16.5.1 srcid dstid type require flow esp in from 0.0.0.0/0 to 172.16.7.0/24 peer 172.16.5.1 srcid dstid type use flow esp out from 172.16.7.0/24 to 0.0.0.0/0 peer 172.16.5.1 srcid dstid type require flow esp in from 0.0.0.0/0 to 172.16.6.0/24 peer 172.16.5.1 srcid dstid type use flow esp out from 172.16.6.0/24 to 0.0.0.0/0 peer 172.16.5.1 srcid dstid type require SAD: esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x6769c99e auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0xad29e69c auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512 enc aes-256-ctr The problem is that as soon as these flows are established, Router 2 becomes unreachable from all of it's local networks (and vice-versa). This appears to occur because the flows specify that all traffic originating from Router 2's IP addresses (172.16.5.2, 172.16.6.1, and 172.16.7.1) should be protected with ESP. Thus, Router 2 starts to encapsulate all traffic originating from it's IPs, even if it is destined for one of it's lo
Re: DigitalOcean's BSD debut is FreeBSD only
On 16.12.2014 17:25, jungle Boogie wrote: I have not personally tested openBSD on https://www.vultr.com/ but I have read (tweets, probably) that it will work. There are quite a few of them. https://www.transip.eu/vps/ officially support OpenBSD and FreeBSD. Also completely SSD enabled. It seems to be just hype Lars
support update
# This version of the template is a bib-like file with one # line per field except notes, which can be any number of lines. # All I want to get back from you is lines like these (minus the # # character and the tab indent): # 0 This line is a delimiter and must be first (digit zero at the start) # C USA # P Arizona # T Cactus Grove # Z Postal Code # A General Delivery # O Acme Widgets # I Wile E. Coyote # M w.coy...@acme.com # U http://www.acme.com/openbsd # B 555-555-1212 # X 555-555-1213 # N Home of the best Acme # widgets around. # # Do not bother sending this in unless your web site's main page clearly shows # that you are engaged in providing support services for OpenBSD. # We reserve the right to delete listings that no longer do so. # # DELETE ALL # COMMENT LINES BEFORE SUBMITTING # # SEND AS PLAIN TEXT IN THE BODY OF YOUR MAIL: NO MIME OR ATTACHMENTS! # Use html character entities (like è) for accented characters. # We reserve the right to edit any and all submissions as we please. 0 C Canada P Alberta T Edmonton Z T6A-2P7 O Neotext I Duncan Patton a Campbell A 10908-65a st. M campb...@neotext.ca U http://www.neotext.com/ # with trailing slash unless a specific resource B 780 466 0109 X 780 469 0930 N Open Systems Integration and Reverse-Engineering, Legacy Sytems, RealTime AI, Air Traffic Control, Remote Sensing, TestBed/Laboratory Development, Remote/Onsite Support, Wireless, RFID, Tracking/Mapping Systems, Barcoding, Inventory/supply-line, SAP integration, C3I, Web Catalogs, Competitive Intelligence Search Engines, Risk Assessment&Reduction, Motorola, Intermec, Symbol devices. UNIX -- OpenBSD, FreeBSD, HPUX, Solaris/SunOS in Industrial Environments. And PCs: (Minix, Desqview, QNX) 30+ years experience, competence and integrity. secure(ish) contact point -- https://neotext.ca/cgi-bin/getxt -- Ne obliviscaris, vix ea nostra voco.
Re: DigitalOcean's BSD debut is FreeBSD only
Hi OD, On 16 December 2014 at 07:10, wrote: > Hi, > > It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in > the OpenBSD community, are being asked to open up a separate UserVoice vote > for OpenBSD -- despite the fact that we've worked so hard to promote the > existing one. So, please drop by and share your frustrations: > I have not personally tested openBSD on https://www.vultr.com/ but I have read (tweets, probably) that it will work. > https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os > -- I reckon around half the votes are from OpenBSD users. > > Many thanks! > > O.D. > Best, Jungle -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Re: DigitalOcean's BSD debut is FreeBSD only
On 16.12.2014 16:52, openda...@hushmail.com wrote: What is digital ocean? They're touted as the new rock stars of the hosting industry. Says who? Now it's digital ocean - next month it will be somebody else. Cheap SSD-enabled cloud hosting for your apps. You do have apps don't you? I seem to fall out of the target group for this. As I don't share your obvious enthusiasm and just don't care - so many rock stars rise and fall. Lars
Re: DigitalOcean's BSD debut is FreeBSD only
>What is digital ocean? They're touted as the new rock stars of the hosting industry. Cheap SSD-enabled cloud hosting for your apps. You do have apps don't you? O.D. On 16. desember 2014 at 3:43 PM, "Richard E. Thornton" wrote: > >What is digital ocean? > > >On Tue, 16 Dec 2014, openda...@hushmail.com wrote: > >> Hi, >> >> It seems that DigitalOcean's BSD debut is going to be FreeBSD >only. We, in the OpenBSD community, are being asked to open up a >separate UserVoice vote for OpenBSD -- despite the fact that we've >worked so hard to promote the existing one. So, please drop by and >share your frustrations: >> >> https://digitalocean.uservoice.com/forums/136585- >digitalocean/suggestions/3232571-support-bsd-os -- I reckon around >half the votes are from OpenBSD users. >> >> Many thanks! >> >> O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
What is digital ocean? On Tue, 16 Dec 2014, openda...@hushmail.com wrote: > Hi, > > It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in > the OpenBSD community, are being asked to open up a separate UserVoice vote > for OpenBSD -- despite the fact that we've worked so hard to promote the > existing one. So, please drop by and share your frustrations: > > https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os > -- I reckon around half the votes are from OpenBSD users. > > Many thanks! > > O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On Tue, Dec 16, 2014 at 03:10:00PM +, openda...@hushmail.com wrote: Plonk.
DigitalOcean's BSD debut is FreeBSD only
Hi, It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in the OpenBSD community, are being asked to open up a separate UserVoice vote for OpenBSD -- despite the fact that we've worked so hard to promote the existing one. So, please drop by and share your frustrations: https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os -- I reckon around half the votes are from OpenBSD users. Many thanks! O.D.
Re: Dovecot happy on 5.6?
Quoting Rod Whitworth : I have been trying out dovecot for some years and it has always had some irritating "bug" or limitation and I have seen a few gripes from others. It seems to have been very quiet lately so I thought I'd have another attempt to get it running whilst choosing options that look like ones to suit me. Any happy users? Absolute haters who have really tried hard? (Description of problem?) Thanx, *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. I am a very very happy dovecot user -- works great with ypldap, webmail, etc. Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9
Re: Dell R630 high interrupts on acpi0
> Date: Tue, 16 Dec 2014 15:16:58 +1000 > From: Jonathan Matthew > > On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote: > > Hi all, > > > > I have got two new Dell R630 and have current on them from Sun Dec > > 14 15:07:17. Installation went great and very fast. > > The problem is that I see around 11k interrupts on acpi0. First I > > thought that problem is similar to this thread > > http://marc.info/?l=openbsd-misc&m=140551906923931&w=2 > > > > But if in dell bios system profile settings is set to performance or > > to DAPC there are always interrupts on acpi0. > > In links bellow you can find acpidump and dmesg from performance and > > DAPC settings in dell bios. > > We just got some r630s too, so I spent some time last week figuring out what's > going on here. Something in the AML wants to talk to the intel MEI device. > Normally this works, but on the new generation of dell machines (we've seen it > on r630s and r730s), it's been moved outside the pci memory range we currently > allow on amd64. You can see this in your dmesgs: > > 0:22:0: mem address conflict 0x3303000/0x10 > 0:22:1: mem address conflict 0x3302000/0x10 > > The interrupt will keep triggering until it manages to talk to the device, > which will never happen. > > kettenis@ says we can get the pci memory range information we need to deal > with > this from acpi. Until that happens, expanding the allowed pci memory range > makes things work properly. > > ok? ok kettenis@ (although I'd prefer if you did a s/acpi/ACPI/ in the comment). > Index: pci_machdep.c > === > RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v > retrieving revision 1.59 > diff -u -p -u -p -r1.59 pci_machdep.c > --- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59 > +++ pci_machdep.c 16 Dec 2014 04:21:53 - > @@ -622,13 +622,17 @@ pci_init_extents(void) >* here. As long as vendors continue to support >* 32-bit operating systems, we should never see BARs >* outside that region. > + * > + * Dell 13G servers have important devices outside the > + * 36-bit address space. Until we can extract the address > + * ranges from acpi, expand the allowed range to suit. >*/ > pcimem_ex = extent_create("pcimem", 0, 0xUL, > M_DEVBUF, NULL, 0, EX_NOWAIT); > if (pcimem_ex == NULL) > return; > - extent_alloc_region(pcimem_ex, 0x10UL, > - 0xfff0UL, EX_NOWAIT); > + extent_alloc_region(pcimem_ex, 0x400UL, > + 0xfc00UL, EX_NOWAIT); > > for (bmp = bios_memmap; bmp->type != BIOS_MAP_END; bmp++) { > /*
Re: Dovecot happy on 5.6?
On Tue, 16 Dec 2014 01:11:34 -0500, Brad Smith wrote: >On 12/15/14 23:48, Rod Whitworth wrote: >> I have been trying out dovecot for some years and it has always had some >> irritating "bug" or >> limitation and I have seen a few gripes from others. >> >> It seems to have been very quiet lately so I thought I'd have another >> attempt to get it running >> whilst choosing options that look like ones to suit me. >It's been quiet because the bugs in OpenBSD were fixed and it just >works. It works fine for tons of people. That looks like a unanimous vote. Thank you all! *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: What happened when 5.5 met my old reliable box
On Tue, 16 Dec 2014 21:22:35 +1100, Rod Whitworth wrote: Thanks much. A different approach to some others. I'll file them all because I suspect that one method will suit one problem better than others. >On Tue, 16 Dec 2014 07:48:05 +0100, Adriaan wrote: >>From the OpenBSD FAQ: >>At the boot loader prompt, enter >> boot> *set tty com0* >> This will tell OpenBSD to use the first serial port (often called COM1 or >>COMA in PC documentation) as a serial console. The default baud rate is >>9600. >>You set the speed higher by first typing "stty com0 19200" This is >>documented in the boot.conf man page. >>On your workstation you can use tip(1) as terminal emulator. You can easily >>record the session to file by creating a ".tiprc" file: >>beautify >>record='LOGS/serial-log.txt' >>script >>verbose >>Create the LOGS directory, add yourself to the dialer group. With something >>like"tip -v -19200 tty00" you can then start tip. >>If you have an USB->Serial converter you need to use ttyU0 as mentioned in >>ucom(4) >>On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth wrote: >>> >>> On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: >>> >>> >On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: >>> >> I tried 5.5 - crashes there too. >>> >> >>> >> 5.4 and earlier work well. >>> >> >>> >> Clues? I love these low power skinny boxes in my rack and I'm betting >>> that >>> >> the problem >>> >> exists in all the ones I have, but I cannot take the others down until I >>> >> have one to swap in. >>> >>> >>> >>> >1. connect a serial cable or something to record output. >>> >>> I like the idea of getting chars ready to print but how do I get the data >>> going to the rs232 >>> port that is on all of these boxes (luckily!) ? I missed the class that >>> taught that trick. 8-) >>> >>> >>> >>> >>> >2. get a video camera. smartphone should be good enough. >>> >>> >3. brute force. build kernels from source from 5.4 onwards. the good >>> >news is this will only take about seven kernels to find the offending >>> >commit; the bad news is building old snapshot ramdisk kernels is quite >>> >a pain. >>> >>> >>> >>> *** NOTE *** Please DO NOT CC me. I subscribed to the list. >>> Mail to the sender address that does not originate at the list server is >>> tarpitted. The reply-to: address is provided for those who feel compelled >>> to reply off list. Thankyou. >>> >>> Rod/ >>> --- >>> This life is not the real thing. >>> It is not even in Beta. >>> If it was, then OpenBSD would already have a man page for it. >*** NOTE *** Please DO NOT CC me. I subscribed to the list. >Mail to the sender address that does not originate at the list server is >tarpitted. The reply-to: address is provided for those who feel compelled to >reply off list. Thankyou. >Rod/ >--- >This life is not the real thing. >It is not even in Beta. >If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Dell R630 high interrupts on acpi0
On 16.12.2014. 6:16, Jonathan Matthew wrote: On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote: Hi all, I have got two new Dell R630 and have current on them from Sun Dec 14 15:07:17. Installation went great and very fast. The problem is that I see around 11k interrupts on acpi0. First I thought that problem is similar to this thread http://marc.info/?l=openbsd-misc&m=140551906923931&w=2 But if in dell bios system profile settings is set to performance or to DAPC there are always interrupts on acpi0. In links bellow you can find acpidump and dmesg from performance and DAPC settings in dell bios. We just got some r630s too, so I spent some time last week figuring out what's going on here. Something in the AML wants to talk to the intel MEI device. Normally this works, but on the new generation of dell machines (we've seen it on r630s and r730s), it's been moved outside the pci memory range we currently allow on amd64. You can see this in your dmesgs: 0:22:0: mem address conflict 0x3303000/0x10 0:22:1: mem address conflict 0x3302000/0x10 The interrupt will keep triggering until it manages to talk to the device, which will never happen. kettenis@ says we can get the pci memory range information we need to deal with this from acpi. Until that happens, expanding the allowed pci memory range makes things work properly. ok? Index: pci_machdep.c === RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v retrieving revision 1.59 diff -u -p -u -p -r1.59 pci_machdep.c --- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59 +++ pci_machdep.c 16 Dec 2014 04:21:53 - @@ -622,13 +622,17 @@ pci_init_extents(void) * here. As long as vendors continue to support * 32-bit operating systems, we should never see BARs * outside that region. +* +* Dell 13G servers have important devices outside the +* 36-bit address space. Until we can extract the address +* ranges from acpi, expand the allowed range to suit. */ pcimem_ex = extent_create("pcimem", 0, 0xUL, M_DEVBUF, NULL, 0, EX_NOWAIT); if (pcimem_ex == NULL) return; - extent_alloc_region(pcimem_ex, 0x10UL, - 0xfff0UL, EX_NOWAIT); + extent_alloc_region(pcimem_ex, 0x400UL, + 0xfc00UL, EX_NOWAIT); for (bmp = bios_memmap; bmp->type != BIOS_MAP_END; bmp++) { /* Hi, you patch makes acpi0 calm as overeaten grandad :) Thank you. vmstat without your patch # vmstat -i interrupt total rate irq0/clock 103588029 799 irq0/ipi 1025960 irq144/acpi0 157993005512201 irq96/mfii0 69380 irq114/em0 2702502 irq99/ehci0 1310 irq99/ehci1280 Total 168389802713004 vmstat with your patch # vmstat -i interrupt total rate irq0/clock 848873 800 irq0/ipi14085 13 irq144/acpi030 irq96/mfii0 22352 irq114/em0 36853 irq99/ehci0560 irq99/ehci1280 Total 868965 819
Re: What happened when 5.5 met my old reliable box
Thanks much. A different approach to some others. I'll file them all because I suspect that one method will suit one problem better than others. On Tue, 16 Dec 2014 07:48:05 +0100, Adriaan wrote: >From the OpenBSD FAQ: >At the boot loader prompt, enter > boot> *set tty com0* > This will tell OpenBSD to use the first serial port (often called COM1 or >COMA in PC documentation) as a serial console. The default baud rate is >9600. >You set the speed higher by first typing "stty com0 19200" This is >documented in the boot.conf man page. >On your workstation you can use tip(1) as terminal emulator. You can easily >record the session to file by creating a ".tiprc" file: >beautify >record='LOGS/serial-log.txt' >script >verbose >Create the LOGS directory, add yourself to the dialer group. With something >like"tip -v -19200 tty00" you can then start tip. >If you have an USB->Serial converter you need to use ttyU0 as mentioned in >ucom(4) >On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth wrote: >> >> On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: >> >> >On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: >> >> I tried 5.5 - crashes there too. >> >> >> >> 5.4 and earlier work well. >> >> >> >> Clues? I love these low power skinny boxes in my rack and I'm betting >> that >> >> the problem >> >> exists in all the ones I have, but I cannot take the others down until I >> >> have one to swap in. >> >> >> >> >1. connect a serial cable or something to record output. >> >> I like the idea of getting chars ready to print but how do I get the data >> going to the rs232 >> port that is on all of these boxes (luckily!) ? I missed the class that >> taught that trick. 8-) >> >> >> >> >> >2. get a video camera. smartphone should be good enough. >> >> >3. brute force. build kernels from source from 5.4 onwards. the good >> >news is this will only take about seven kernels to find the offending >> >commit; the bad news is building old snapshot ramdisk kernels is quite >> >a pain. >> >> >> >> *** NOTE *** Please DO NOT CC me. I subscribed to the list. >> Mail to the sender address that does not originate at the list server is >> tarpitted. The reply-to: address is provided for those who feel compelled >> to reply off list. Thankyou. >> >> Rod/ >> --- >> This life is not the real thing. >> It is not even in Beta. >> If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: What happened when 5.5 met my old reliable box
On 12/16/14 06:09, Rod Whitworth wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) at the boot prompt: boot> stty com0 9600 boot> set tty com0 Then use cu(1) to do the rest hth Fred
Re: Dovecot happy on 5.6?
On 16.12.2014 05:48, Rod Whitworth wrote: Any happy users? Absolute haters who have really tried hard? (Description of problem?) Yep, running a basic setup (fdm, dovecot, roundcube, opensmtpd) on 5.6 -STABLE (and 5.5 -STABLE before that) without hassle. have a nice day Lars
Re: Dovecot happy on 5.6?
On 12/16/14 05:48, Rod Whitworth wrote: > I have been trying out dovecot for some years and it has always had some > irritating "bug" or > limitation and I have seen a few gripes from others. > > It seems to have been very quiet lately so I thought I'd have another attempt > to get it running > whilst choosing options that look like ones to suit me. > > Any happy users? Absolute haters who have really tried hard? (Description of > problem?) > > Thanx, Happy since June '12 (started with a -current and stayed with -stable since) Marc
Re: how to , apache's ' AuthType Basic '
On Mon, Dec 15, 2014 at 08:14:08PM EST, Ingo Schwarze wrote: > > OpenBSD base also contains nginx. > > That is no longer true, but nginx is available from ports. >From what I can tell, Martin was talking about 5.6, where 'nginx' is still in base. Not everyone's running -current, Ingo ;^) Regards, Raf