xterm(1) is killed by pledge(2) :)
Hi! I don't know how to reproduce this bug, but here is a little history: I was running GNU Emacs inside tmux(1) and writting UTF-8 mail, meanwhile I frequently and randomly pressed C-x and C-b, after that (don't remember after pressing C-x or after pressing C-b) I accidentally pressed ] and that caused xterm(1) to vanish, after checking dmesg(1) output here's what I got: xterm[90461]: pledge "cpath", syscall 5
Re: how to switch to a snapshot?
hi i usually boot PC by the USB memory of install63.fs ( =snapshots ). the method is dd if=./install63.fs of=/dev/rsd1c bs=1m <-openbsd dd if=./install63.fs of=/dev/sdb bs=32k <-linux and do Upgrade and start snapshots , then pkg_add -u . that's the main stream . --- regards
Different dmesg and sysctl hw.sensors output
Dear Listeners, Just for curiosity: Today I have recognized a surprising difference in dmesg and sysctl hw.sensors output after two times of booting the same kernel on the same machine: After the first boot, I was surprised to see (for the first time as far as I remember) the lines ... lm0 at isa0 port 0x290/8: NCT6776F ... hw.sensors.lm0.fan0=1467 RPM hw.sensors.lm0.fan1=1350 RPM hw.sensors.lm0.fan2=1454 RPM hw.sensors.lm0.fan3=0 RPM hw.sensors.lm0.fan4=0 RPM ... with respect to the lm sensor detection instead of the usual lines ... lm0 at isa0 port 0x290/8: W83627DHG ... hw.sensors.lm0.fan0=1562 RPM hw.sensors.lm0.fan1=1454 RPM hw.sensors.lm0.fan2=1562 RPM ... six ours later after the second boot. Here, you find the full differences and one instance of the dmesg and sysctl.sensors output: $ diff dmesg-70.log dmesg-71.log 4c4 < avail mem = 16627154944 (15856MB) --- > avail mem = 16627150848 (15856MB) 18c18 < cpu0: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.98 MHz --- > cpu0: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.99 MHz 21c21 < acpitimer0: recalibrated TSC frequency 1866735229 Hz --- > acpitimer0: recalibrated TSC frequency 1866741453 Hz 45c45 < acpihpet0: recalibrated TSC frequency 1866743200 Hz --- > acpihpet0: recalibrated TSC frequency 1866741920 Hz 141c141 < lm0 at isa0 port 0x290/8: NCT6776F --- > lm0 at isa0 port 0x290/8: W83627DHG 176,188c176,186 < hw.sensors.cpu0.temp0=30.00 degC < hw.sensors.sdtemp0.temp0=36.50 degC < hw.sensors.sdtemp1.temp0=34.50 degC < hw.sensors.sdtemp2.temp0=35.50 degC < hw.sensors.sdtemp3.temp0=36.75 degC < hw.sensors.lm0.temp0=28.00 degC < hw.sensors.lm0.temp1=28.50 degC < hw.sensors.lm0.temp2=29.00 degC < hw.sensors.lm0.fan0=1467 RPM < hw.sensors.lm0.fan1=1350 RPM < hw.sensors.lm0.fan2=1454 RPM < hw.sensors.lm0.fan3=0 RPM < hw.sensors.lm0.fan4=0 RPM --- > hw.sensors.cpu0.temp0=32.00 degC > hw.sensors.sdtemp0.temp0=44.25 degC > hw.sensors.sdtemp1.temp0=39.50 degC > hw.sensors.sdtemp2.temp0=42.50 degC > hw.sensors.sdtemp3.temp0=44.75 degC > hw.sensors.lm0.temp0=31.00 degC > hw.sensors.lm0.temp1=31.00 degC > hw.sensors.lm0.temp2=33.00 degC > hw.sensors.lm0.fan0=1562 RPM > hw.sensors.lm0.fan1=1454 RPM > hw.sensors.lm0.fan2=1562 RPM $ cat dmesg-70.log OpenBSD 6.3 (GENERIC.MP) #6: Tue Jul 24 13:40:48 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17154113536 (16359MB) avail mem = 16627154944 (15856MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf06f0 (62 entries) bios0: vendor American Megatrends Inc. version "0705" date 06/29/2010 bios0: ASUSTeK Computer INC. P7F-M WS acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT acpi0: wakeup devices BR1E(S4) UAR1(S4) PS2K(S4) EUSB(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4) USB5(S4) USB6(S4) BR21(S4) BR22(S4) BR23(S4) P0P1(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.98 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 1866735229 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,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) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,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) Xeon(R) CPU L3426 @ 1.87GHz, 1866.73 MHz cpu3: 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 7 pa 0xfec0,
tun interface and netmask
Hi All, Problem I want to solve: I would like the tun interface to 'support' more than one host. Right now, when I setup a tun interface, it's only activated on the dest IP, regardless of the netmask used. my /etc/hostname.tun0: inet 192.168.40.10 255.255.255.0 192.168.40.1 A workaround I've done, is adding a route: route add -inet 192.168.40.10/24 192.168.40.10 More info: Wireguard is using tun0 on machine A; I would like machine B and machine C to also access machine A, all on machine A's tun0 interface - without the need for additional tun interfaces. Fortunately the route trick above works. Question: Is the route add the legitimate way to do this? Can tun support more than one host, or is truly point-to-point? Thanks!
..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
On April 25, 2018 7:08 PM, Jonathan Gray wrote: .. > > The Radeon GPU:s are important in OpenBSD's ecosystem as they are the > > only way to increase graphics functionality, that not involves changing > > CPU to Intel's latest, and hence change motherboard and other hardware. > > Do you have plans to port amdgpu? > > Would particular hardware donations or other donations be of help? > > I have no plans regarding amdgpu. > > Most people seem to be interested from the point of view of polaris/vega > which are not supported in linux 4.4. Ignoring the parts of the shared > drm/ttm code that would have to be updated the latest > drivers/gpu/drm/amd in linux has over 1.5 million lines of code. Which > is multiple times larger than the complete OpenBSD kernel source... Hi Jonathan, Thank you for your previous response. I have talked to Alex Deucher (he's on #radeon FreeNode IRC, agd5f) as well as hwentlan who both work for AMD in depth about the AMDGPU driver, and they clarify that this is where AMD will give all future efforts, so from what I understand over time porting AMDGPU will become more and more relevant and at some point a pushing priority. >From talking to them, the most important features in AMDGPU appear to be: * GPU scheduler, splits GPU resources between processes The GPU scheduler helps load-balance both memory bandwidth and rendering work within the GPU between different programs that use 3D concurrently, shown on display at same time. E.g., say you have two processes submitting work to the GPU. If one is submitting work very fast, it's jobs can will get lined up and it will monopolize the GPU time if it's first come first server. The scheduler makes sure both processes get access to the GPU. (No such thing in the old driver) * Display handling code (called "DC" in the AMDGPU codebase): Lots more display features compared to Radeon: atomic modesetting framework on Linux, DP MST, FBC, etc., GPU scheduler, fine grained clock and voltage control (similar to wattman in windows), more power features supported, etc. (DC is the name of the display handling code in AMDGPU.) * Fine grained control of the power states (minor tweaks to voltages or clocks, etc.) (Radeon supported dynamic power management, where the GPU clocks could be changed dynamically based on demand, but not fine grained.) * Support for MST hubs (so more monitors connected to an MST hub, get identified as separate monitors by the computer) * 8K monitor support via MST based on 2x displayport connectors * DP MST in the old Radeon driver is experimental and doesn't work that well, in AMDGPU done well. * DRM sync objects support, which enabled a bunch of OGL and EGL extensions * AMDGPU may get support for freesync/adaptive sync/vrr in the future and in the more distant future support for HDR, as in up to 16 bits per color. hwentlan explains, "for the consumer it means that brights are brighter, darks are darker, and you still see tons of details in the shadows, even though your screen might show you glare in other areas. There are many different HDR formats and ways of tonemapping image data into those formats. This requires new interfaces between kernel and user-mode, and requires the kernel display driver to understand and be able to program the HW to output the required formats". Joseph
Re: Probelm when building QGIS
Rashad Kanavath wrote > On Thu, Jul 26, 2018 at 12:36 AM tao > uponmyword@ > wrote: > >> Hello, >> >> I am in OpenBSD6.3. QGIS 2.18.17 in packages can not render style just >> like >> things in >> >> http://openbsd-archive.7691.n7.nabble.com/qgis-bug-since-last-security-update-under-stable-td339707.html >> >> So, I am trying to build QGIS 2.18.17 from source. >> Succeeded to ccmake the source. But get error when make. >> Here is the message: >> >> tao$ make >> [ 0%] Built target version >> make: don't know how to make >> /home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea >> (prerequisite of: src/core/qgsexpression_texts.cpp) >> Stop in . >> *** Error 2 in . (CMakeFiles/Makefile2:1165 >> 'src/core/CMakeFiles/qgis_core.dir/all') >> *** Error 1 in /home/tao/Software/qgis/build-2.18.22 (Makefile:163 'all') >> >> >> Tried to find the file mentioned above >> "/home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea ", >> but could not find anything. >> >> Anyone has an idea? >> > > could you try gmake instead of make? > make != gmake (unless you simlink or alias it) That sounds make sense, I will check and try that tonight. Report later. Thanks! Tao Rashad Kanavath wrote >> >> >> >> >> -- >> Sent from: >> http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html >> >> > > -- > Regards, >Rashad -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Moving filesystems around
Hello Jay, jh...@kevla.org (Jay Hart), 2018.07.27 (Fri) 04:42 (CEST): > > Hello, > > jh...@kevla.org (Jay Hart), 2018.07.25 (Wed) 21:31 (CEST): > >> Running a stock 6.3 machine. I just bought a new server and hope to > >> move this drive over, but think I need to move two partitions around > >> at get more space. > > > > I'm not sure you need to... > > My /usr is just 895M. Yours is fuller because you have /usr/local on the > > same slice? > > If so, I'd consider this the problem. > > You'd have slices left after your wd0i[1], but is there unassigned > > space left on the disk? > > If so, I'd create a new slice and put /usr/local there. > > > > More info would have been helpful, show output of mount(8) and df(1), > > disklabel, fdisk, dmesg, perhaps? > > > > [1] what, a wd(4)?! ;-) > > > > Marcus > > > > Actually, I have a separate /usr/local partition, just didn't mention > it. Why has your /usr twice as much on it than mine, then? /usr/src? /usr/ports? du -sh /usr/*? > Your post got me thinking (as did some of the others). I've been > upgrading this box since 5.6 or > so and maybe its time to wipe it and start fresh on the new box. Just > copy over my config files after I'm done. I've recently upgraded an equally outdated box and sysmerge(8) was no fun. Lots of differences in config files after such a looong time makes merging hard. Thus installing might be the right thing. > Since I just follow stable releases, I don't bother downloading the > source code and building patches, so /usr should stay small and clean > with syspatch and sysclean, unless I'm very wrong about how they work. I think you got it right. /usr is rather static, unless it grows rapidly, like recently for /usr/share/relink/. syspatch(8) gives you patches for errata for the latest release and one version before, IIRC. sysclean(8) gives you a list of files not required by the installed base system and the installed ports. Marcus > >> I have one drive installed, with about 6 partitions. > >> > >> /var is a 6.3G partition (wd0e) using 50M of space > >> /usr is a 2.0G partition (wd0f) using 1.6G of space > >> > >> Last partition number is wd0i. > >> > >> What would the recommended procedure to use to swap these two partitions?
Fwd: pf(4) queuing and interfaces
Resending now that the hackathon has died down.
—david
-- Forwarded message -
From: David Higgs
Date: Sun, Jul 15, 2018 at 2:12 PM
Subject: pf(4) queuing and interfaces
To: misc@openbsd.org
My wireless AP puts traffic from each WiFi network (trusted, guests,
etc.) into a separate VLAN, which are then picked up by my OpenBSD
router and filtered appropriately via pf rules.
In other words:
em1 is for untagged traffic to the AP itself
vlan100 has parent em1 and is for my "trusted" WLAN
vlan200 also has parent em1 and is for my "guest" WLAN
pf.conf includes the following line:
queue wlan_q on em1 bandwidth 50M max 50M flows 1024 qlimit 1024 default
When I specify only the queuing rule as shown above, is traffic sent
on vlanXXX also receive this queuing policy?
If not, should I divide the physical bandwidth between logical
interfaces? Does FQ-CoDel work correctly if they are each assigned
the full physical bandwidth? Or should I be dividing one or both of
the configurable interface rates?
And lastly, if I define a queue as below - does this expand into two
different queues with the same name or one queue with bandwidth shared
between two interfaces? Running "pfctl -vsq" indicates the former,
but I'd like to be sure.
queue some_q on { em2, em3 } bandwidth 95M max 95M flows 1024 qlimit
1024 default
Thanks.
--david
Re: Probelm when building QGIS
On 27-07-18 14:03, tao wrote: Rashad Kanavath wrote On Thu, Jul 26, 2018 at 12:36 AM tao uponmyword@ wrote: Hello, I am in OpenBSD6.3. QGIS 2.18.17 in packages can not render style just like things in http://openbsd-archive.7691.n7.nabble.com/qgis-bug-since-last-security-update-under-stable-td339707.html So, I am trying to build QGIS 2.18.17 from source. Succeeded to ccmake the source. But get error when make. Here is the message: tao$ make [ 0%] Built target version make: don't know how to make /home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea (prerequisite of: src/core/qgsexpression_texts.cpp) Stop in . *** Error 2 in . (CMakeFiles/Makefile2:1165 'src/core/CMakeFiles/qgis_core.dir/all') *** Error 1 in /home/tao/Software/qgis/build-2.18.22 (Makefile:163 'all') Tried to find the file mentioned above "/home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea ", but could not find anything. Anyone has an idea? could you try gmake instead of make? make != gmake (unless you simlink or alias it) Could not find gmake. And also could not use cmake to build it. I think make is the right one. I have to give up ^ \^ snapshots already have qgis 3, so you can upgrade to current to get all the latest. since there is a port, you should start from there (eg. upgrade the qgis source version and start with that) -m
Re: Probelm when building QGIS
Rashad Kanavath wrote > On Thu, Jul 26, 2018 at 12:36 AM tao > uponmyword@ > wrote: > >> Hello, >> >> I am in OpenBSD6.3. QGIS 2.18.17 in packages can not render style just >> like >> things in >> >> http://openbsd-archive.7691.n7.nabble.com/qgis-bug-since-last-security-update-under-stable-td339707.html >> >> So, I am trying to build QGIS 2.18.17 from source. >> Succeeded to ccmake the source. But get error when make. >> Here is the message: >> >> tao$ make >> [ 0%] Built target version >> make: don't know how to make >> /home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea >> (prerequisite of: src/core/qgsexpression_texts.cpp) >> Stop in . >> *** Error 2 in . (CMakeFiles/Makefile2:1165 >> 'src/core/CMakeFiles/qgis_core.dir/all') >> *** Error 1 in /home/tao/Software/qgis/build-2.18.22 (Makefile:163 'all') >> >> >> Tried to find the file mentioned above >> "/home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea ", >> but could not find anything. >> >> Anyone has an idea? >> > > could you try gmake instead of make? > make != gmake (unless you simlink or alias it) Could not find gmake. And also could not use cmake to build it. I think make is the right one. I have to give up ^ \^ Rashad Kanavath wrote >> >> >> >> >> -- >> Sent from: >> http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html >> >> > > -- > Regards, >Rashad -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Is BCM4360 802.11ac (on MacBook Air 6.1) supported?
On Fri, Jul 27, 2018 at 08:33:27AM +0200, Stefan Sperling wrote: > On Thu, Jul 26, 2018 at 09:33:43PM +0200, MiKi wrote: > > Hi, > > > > I installed OpenBSD 6.3 in a MacBook Air 6.1 everything works fine but > > except the wireless card. > > > > It have a Broadcom BCM4360 802.11ac (rev3) card, the device is showed on > > dmesg but left undetected as a device in ifconfig, I take a look on bwi(4) > > and this exact model wasn't listed. > > > > I also checked the new driver bwfm(4) that seems a newer driver for Broadcom > > AC cards, but it haven't any listing. > > > > Also I have nothing pending to install with fw_update > > > > So, is this card definitely unsupported? if not, can someone give me some > > pointers to get it work? > > This card might be supported by bwfm(4) in -current. > It is not. It looks like this is a SoftMAC chip which can not be supported by the bwfm(4) FullMAC driver. Even FreeBSD, who have worked on improving their SoftMAC support, do not seem to support that chip.
Re: pf - NAT not working after systemboot
On Fri, 27 Jul 2018 12:33:01 +0300 Ville Valkonen wrote: > On 26 July 2018 at 13:01, Thomas Huber wrote: > > Hi misc, > > > > my current pf setup works fine but I face the problem, that NAT > > does not work directly after system boot. Only when a do a > > > > # pfctl -f /etc/pf.conf > > > > after the booting things a working correctly. > > Note: I don´t make any changes to pf.conf. > > as Solene mentioned, it's because the interface is not ready. > > Maybe something like this (adapted from iked.conf manual page): > all rules that have pppoe mentioned, append (if-bound). I am using pf with pppoe for more than a decade on dozens of boxes and never got into a problem with NAT not working. On some crappy providers it is not unusual to wait for 10 minutes after reboot for pppoe to negotiate and get IP address. Also, sometimes pppoe link goes down and don't come back for hours. None of this requires reloading of pf rules, it just waits until pppoe reconnects, box usually gets different public IP adress, and after that NATs to new address. Am I missing something? -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: pf - NAT not working after systemboot
On 26 July 2018 at 13:01, Thomas Huber wrote:
> Hi misc,
>
> my current pf setup works fine but I face the problem, that NAT does not
> work directly after system boot. Only when a do a
>
> # pfctl -f /etc/pf.conf
>
> after the booting things a working correctly.
> Note: I don´t make any changes to pf.conf.
>
> Anybody any idea?
>
> General Setup:
> Hardware: PCengines APU2c4
> 2x vlan(4): vlan32 (private) vlan64 (wifi-guests)
> 2x pppoe(4): ADSL-uplink.
>
> Thanks!
>
> Here is the pf.conf:
>
> table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
>172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
>192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
>203.0.113.0/24 }
> set block-policy drop
> set skip on lo0
> match in all scrub (no-df random-id max-mss 1440)
> match out on pppoe0 from vlan:network nat-to (pppoe0)
> match out on pppoe1 from vlan:network nat-to (pppoe1)
> block in quick on pppoe from to any
> block return out quick on pppoe from any to
> block all
> pass out quick inet
>
> pass out on vlan to vlan:network
> pass in quick on vlan from vlan:network to vlan
>
> pass in on vlan route-to {(pppoe0 pppoe0:network), (pppoe1 pppoe1:network)}
> least-states sticky-address
> pass in on vlan proto tcp to port https route-to {(pppoe0 pppoe0:network),
> (pppoe1 pppoe1:network)} source-hash
>
> block return in on vlan from vlan64:network to vlan32:network
> block return in on vlan inet proto tcp from any to any port 25
> pass in on egress inet proto icmp all
> pass in on egress inet proto tcp from any to (egress) port ssh
Hello,
as Solene mentioned, it's because the interface is not ready.
Maybe something like this (adapted from iked.conf manual page):
all rules that have pppoe mentioned, append (if-bound).
--
Regards,
Ville
Re: How to implement CARP master/backup with IPv6 RAs from OpenBSD firewall pair?
On Thu, Jul 26, 2018 at 04:57:09PM -0400, Martin Gignac wrote: > Hi, > > How does one implement a redundant OpenBSD firewall pair with IPv6? > > With IPv4 I would use CARP to have one of the boxes be the > master/active while the other one is backup/standby. But with IPv6 I > want to use Router Advertisements so that hosts on the internal > network can use SLAAC for IPv6 address autoconfiguration. Therefore > hosts will receive RAs from both OpenBSD boxes and set both as > possible default GWs in their routing table. > > In that case, how do I get the internal hosts to send all traffic to > the "primary" firewall? I've configured the CARP interface on the box > with IPv6, but the RAs are still sent from both boxes (master and > backup) so the RA-configured hosts don't end up using the IPv6 CARP > VIP at all and I seem to end up with possible asymmetric firewall > flows. > > Thanks, > -Martin rtadvd will only start on the master, because the interface has to be active. With ifstated, you can automate this (starting, stopping). I don't know, if rad is also dependent on the interface, but once you have the ifstated in place, you would just need to change the name of the daemon and restart ifstated. hth, Marc
Re: POWER9 hardware donation
On Tue, Jul 24, 2018 at 09:21:09PM +0200, Peter J. Philipp wrote: > Hi, > > I'm working on a powerpc64 port, I've been at it 2 weeks non-stop.?? I don't > know if I'll finish.?? But I gotta say hey! this is a generous offer. > > Since I'm focusing on the big endian machine byte order and on PowerPC 970's > it would need to be ported again to little endian afaik.?? If it's possible > to run on a Power9 in big endian mode this would be cool. > > I believe I am not worthy of such a machine and only worthy if I port > OpenBSD to my PowerPC 970FX cpu.?? Let's take our time and wait to see if I > or anyone else moves in a positive direction in this area. > > BTW I've been working on a cross-compiler to powerpc64 today.?? I used > kevlo's riscv cross compiler port and modified it. Unfortunately I started > before sunrise and it's sunset now and i haven't managed to get cross-gcc > working.?? I may succeed tomorrow. > > Regards, > > -peter > > > On 07/24/18 20:27, Pascal de Kloe wrote: > > I'm offering my brand new IBM 9006-22P with two 16-core 2.9GHZ CPUs to > > the OpenBSD project for free. Who can make the hardware port happen? > > Serious attempts only. Hi, I'm CC'ing p...@openbsd.org because that's where I started the 64-bit PowerPC thread. I want to say that I succeeded building a cross-compiler for 64 bit PowerPC. I haven't tested its functionality yet but the packaging/port is complete. If you want to help, download this tarball, extract to /usr/ports/devel/ examine it, and install on your system. Look for breakages. I'll get into some detail later. http://centroid.eu/private/powerpc64-openbsd-elf.tgz This will build binutils and gcc in /usr/local and /usr/local/powerpc64-unknown-openbsd/*. Since I based this off kevlo@openbsd's riscv port there was a conflict for .la files that installed into /usr/local/lib ... I had to really damage the Makefile.in's of gcc's libcc1 in order for it not to install those .la files. But it caught some other libcc1 relevant files too, so I don't know if the cross compiler even works. Here is some eye candy for the packages that I have installed on my xeon system to show there is no conflict I'm including riscv port: beta$ pkg_info | grep -e powerpc64 -e riscv powerpc64-elf-binutils-2.30 binutils for powerpc64-elf cross-development powerpc64-elf-gcc-8.1.0 gcc for powerpc64-elf cross-development riscv-elf-binutils-2.30 binutils for riscv-elf cross-development riscv-elf-gcc-8.1.0 gcc for riscv-elf cross-development riscv-elf-newlib-3.0.0 newlib for riscv-elf cross-development One thing to know about this powerpc64 compiler is it cannot build userland OpenBSD (not even init) but with a kernel it should be OK. This is because I did not include the includes (haven't built those fully yet). When the time comes when my tree is complete I'll try to revisit this and remove the: patch-libgcc_enable_mprotect:+#if 0 patch-gcc_tsystem_h:+#define inhibit_libc 1 This patch does not look for include files such as sys/mman.h which are a dependency for the gcc 8.1.0 rs6000 machine target. This was a painful week because it was really hot in Germany where I develop, and building this cross-compiler was frustrating too. I once asked on IRC for people to help me, but I did only get moral support. Thank you to kevlo@openbsd for providing something to work with... (I'm thankful it was in the ports tree). I'm looking for people to come forward and help me. It is lonely doing this alone. First state that you want to help, look on p...@openbsd.org archives on what I've done (64-bit PowerPC thread) and look where you can help. If you have a G5 macppc machine this would help as I'm basing it off that. I need someone to look into making a 64 bit ofwboot available, as I need to boot a first OpenBSD/aim64 kernel some day with a 64 bit loader. (This week was a setback, I didn't think this cross compiler would rob so much time). I may have 4-8 more weeks in august and september to work on this. Regards, -peter
Re: Is BCM4360 802.11ac (on MacBook Air 6.1) supported?
On Thu, Jul 26, 2018 at 09:33:43PM +0200, MiKi wrote: > Hi, > > I installed OpenBSD 6.3 in a MacBook Air 6.1 everything works fine but > except the wireless card. > > It have a Broadcom BCM4360 802.11ac (rev3) card, the device is showed on > dmesg but left undetected as a device in ifconfig, I take a look on bwi(4) > and this exact model wasn't listed. > > I also checked the new driver bwfm(4) that seems a newer driver for Broadcom > AC cards, but it haven't any listing. > > Also I have nothing pending to install with fw_update > > So, is this card definitely unsupported? if not, can someone give me some > pointers to get it work? This card might be supported by bwfm(4) in -current.
