Integrating OpenBSD into Xen/Qubes
A number of people are working on integrating OpenBSD into Qubes. In particular, OpenBSD's hardening and mitigations are potentially very useful in talking to the NIC: Xen vulnerabilities have been repeatedly found that would allow a guest with PCI access to compromise the entire system, and on most machines the network card is a PCI device. Additionally, wireless drivers on Linux leave some things to be desired and the network stack is very exposed to the adversary compared to other aspects of the system. The limited scope of the networking VM in Qubes (it does not need much in the way of bells and whistles, it simply talks to the NIC and passes on data) means that it's much easier to use OpenBSD here than it would be to use OpenBSD for e.g GUI applications. Unfortunately, there are still significant issues (currently good integration requires patching /etc/rc, among other things): https://github.com/QubesOS/qubes-issues/issues/5294#issuecomment-707278609 As the commenter notes, this would be much easier if an OpenBSD committer was interested in helping. Anyone?
Re: Disable touchpad acceleration? (wsmouse)
It is indeed the same thing, the parameter index 36 is for deceleration.
Hysteresis may cause a very small and (hopefully) hardly noticeable delay
when a touch starts moving, or a movement changes its orientation on both
axes. It does not affect speed or directions.
On 10/14/20 8:16 PM, Brennan Vincent wrote:
> I have found something that makes it feel linear, finally.
>
> doas wsconsctl mouse.tp.deceleration=0
>
> With the following patch. Maybe this does the same thing as your mouse0.param
> suggestion? Although I didn't touch the x/y hysteresis values (34/35).
>
> diff --git sbin/wsconsctl/mouse.c sbin/wsconsctl/mouse.c
> index e04642dacbc..0f1594e17e0 100644
> --- sbin/wsconsctl/mouse.c
> +++ sbin/wsconsctl/mouse.c
> @@ -61,6 +61,7 @@ struct field mouse_field_tab[] = {
> { "tp.swapsides", _swapsides, FMT_CFG, FLG_NORDBACK
> },
> { "tp.disable", _disable, FMT_CFG, FLG_NORDBACK },
> { "tp.edges", _edges, FMT_CFG, FLG_NORDBACK },
> + { "tp.deceleration", _decel, FMT_CFG, FLG_NORDBACK },
> { "tp.param", _param, FMT_CFG, FLG_WRONLY },
> /* Add an alias. This field is valid for all wsmouse devices. */
> { "param", _param, FMT_CFG, FLG_WRONLY },
> diff --git sbin/wsconsctl/mousecfg.c sbin/wsconsctl/mousecfg.c
> index 6d52bcbfc9c..6162df5c229 100644
> --- sbin/wsconsctl/mousecfg.c
> +++ sbin/wsconsctl/mousecfg.c
> @@ -109,6 +109,12 @@ struct wsmouse_parameters cfg_revscroll = {
> 1
> };
>
> +struct wsmouse_parameters cfg_decel = {
> + (struct wsmouse_param[]) {
> + { WSMOUSECFG_DECELERATION, 0 }, },
> + 1
> +};
> +
> struct wsmouse_parameters cfg_param = {
> (struct wsmouse_param[]) {
> { -1, 0 },
> diff --git sbin/wsconsctl/mousecfg.h sbin/wsconsctl/mousecfg.h
> index 8e99139d280..97ef153fcb3 100644
> --- sbin/wsconsctl/mousecfg.h
> +++ sbin/wsconsctl/mousecfg.h
> @@ -22,6 +22,7 @@ extern struct wsmouse_parameters cfg_edges;
> extern struct wsmouse_parameters cfg_swapsides;
> extern struct wsmouse_parameters cfg_disable;
> extern struct wsmouse_parameters cfg_revscroll;
> +extern struct wsmouse_parameters cfg_decel;
> extern struct wsmouse_parameters cfg_param;
> extern int cfg_touchpad;
>
>
> On 10/14/20 2:12 PM, Ulf Brosziewski wrote:
>> Could you tell us why it feels weird?
>>
>> If you are really serious about a completely "linear" response, you might
>> want to try
>> $ doas wsconsctl mouse0.param=34:0,35:0,36:0
>> This turns off noise filtering and deceleration (very low speeds are slowed
>> down even further, which may be helpful if you want to hit a 1-pixel window
>> border, for example). What remains is the filtering performed by the
>> firmware,
>> which may be decent nowadays, or not.
>>
>>
>> On 10/14/20 8:22 AM, Brennan Vincent wrote:
>>> On 10/14/20 1:49 AM, Otto Moerbeek wrote:
On Tue, Oct 13, 2020 at 11:38:11PM -0400, Brennan Vincent wrote:
> Hello,
>
> I am using the wsmouse driver with x11, and no amount of googling or
> reading
> man pages has helped me figure out how to disable acceleration and have
> completely flat/linear response. Is this possible?
>
> I know that I can change sensitivity with `mouse.tp.scaling=`,
> but
> I don't think this affects acceleration.
>
>
Check xset (and maybe xinput, but I;ve never used that).
-Otto
>>> Thanks. `xinput --set-prop /dev/wsmouse0 'Device Accel Profile' -1` seems
>>> to have made things a lot better, although it still feels a bit weird. I
>>> could just be imagining it.
>>>
>>> Anyway, thanks for the pointers!
>>>
>>>
>
6.8-current/amd64 on Dell Studio 1535
Mostly works, except the wifi is not recognized: "Broadcom BCM4315" rev 0x01 at pci2 dev 0 function 0 not configured Is that similar to the BCM4318 mentioned in bwi(4)? If so, is there a chance of supporting it? dmesg and pcidump -vxxx below - how can I help debug this? Jan OpenBSD 6.8-current (GENERIC.MP) #0: Wed Oct 14 10:13:11 CEST 2020 h...@ddd.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4268081152 (4070MB) avail mem = 4123676672 (3932MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf7040 (45 entries) bios0: vendor Dell Inc. version "A05" date 07/30/2008 bios0: Dell Inc. Studio 1535 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG SLIC OSFR BOOT SSDT acpi0: wakeup devices PCI0(S5) PCIE(S4) USB1(S0) USB2(S0) USB3(S0) USB4(S0) USB5(S0) EHC2(S0) EHCI(S0) AZAL(S3) RP01(S3) RP02(S3) RP03(S3) RP04(S3) RP05(S3) RP06(S5) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz, 2095.37 MHz, 06-17-06 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 3MB 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 199MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz, 2095.00 MHz, 06-17-06 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpimcfg0: addr 0x0, bus 0-0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PCIE) acpiprt2 at acpi0: bus -1 (AGP_) acpiprt3 at acpi0: bus 11 (RP01) acpiprt4 at acpi0: bus 12 (RP02) acpiprt5 at acpi0: bus -1 (RP03) acpiprt6 at acpi0: bus 13 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus 9 (RP06) acpipci0 at acpi0 PCI0 "ITE8708" at acpi0 not configured acpicmos0 at acpi0 acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "DELL WU9468" serial 20829 type LION oem "Samsung SDI" "PNP0C32" at acpi0 not configured "*pnp0c14" at acpi0 not configured acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 127 degC acpivideo0 at acpi0: VID_ acpivideo1 at acpi0: VID_ acpivideo2 at acpi0: VID2 cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2101, 2100, 1600, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM965 Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 2 int 16, I965GM, gen 4 "Intel GM965 Video" rev 0x03 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 "Intel 82801H USB" rev 0x03: apic 2 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801H USB" rev 0x03: apic 2 int 21 ehci0 at pci0 dev 26 function 7 "Intel 82801H USB" rev 0x03: apic 2 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x03: msi azalia0: codecs: IDT 92HD73C1, CMD Technology/0x1392, using IDT 92HD73C1 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801H PCIE" rev 0x03: msi pci1 at ppb0 bus 11 ppb1 at pci0 dev 28 function 1 "Intel 82801H PCIE" rev 0x03: msi pci2 at ppb1 bus 12 "Broadcom BCM4315" rev 0x01 at pci2 dev 0 function 0 not configured ppb2 at pci0 dev 28 function 3 "Intel 82801H PCIE" rev 0x03: msi pci3 at ppb2 bus 13 ppb3 at pci0 dev 28 function 5 "Intel 82801H PCIE" rev 0x03: msi pci4 at ppb3 bus 9 bge0 at pci4 dev 0 function 0 "Broadcom BCM5784" rev 0x10, BCM5784 A1 (0x5784100): msi, address 00:21:70:73:d6:c0 brgphy0 at bge0 phy 1: BCM5784 10/100/1000baseT PHY, rev. 4 uhci2 at pci0 dev 29 function 0 "Intel 82801H USB" rev 0x03: apic 2 int 20 uhci3 at pci0 dev 29 function 1 "Intel 82801H USB" rev 0x03: apic 2 int 21 uhci4 at pci0 dev 29 function 2 "Intel 82801H USB" rev 0x03: apic 2 int 22 ehci1 at pci0 dev 29 function 7 "Intel 82801H USB"
Re: Disable touchpad acceleration? (wsmouse)
Could you tell us why it feels weird? If you are really serious about a completely "linear" response, you might want to try $ doas wsconsctl mouse0.param=34:0,35:0,36:0 This turns off noise filtering and deceleration (very low speeds are slowed down even further, which may be helpful if you want to hit a 1-pixel window border, for example). What remains is the filtering performed by the firmware, which may be decent nowadays, or not. On 10/14/20 8:22 AM, Brennan Vincent wrote: > > On 10/14/20 1:49 AM, Otto Moerbeek wrote: >> On Tue, Oct 13, 2020 at 11:38:11PM -0400, Brennan Vincent wrote: >> >>> Hello, >>> >>> I am using the wsmouse driver with x11, and no amount of googling or reading >>> man pages has helped me figure out how to disable acceleration and have >>> completely flat/linear response. Is this possible? >>> >>> I know that I can change sensitivity with `mouse.tp.scaling=`, but >>> I don't think this affects acceleration. >>> >>> >> Check xset (and maybe xinput, but I;ve never used that). >> >> -Otto > > Thanks. `xinput --set-prop /dev/wsmouse0 'Device Accel Profile' -1` seems to > have made things a lot better, although it still feels a bit weird. I could > just be imagining it. > > Anyway, thanks for the pointers! > >
Re: Thinkpad T14/T14s - any experiences?
Jan Betlach writes: > I am about to install -current on my new T14s with Ryzen 4750u as > well. > > I have browsed r/openbsd, there are two recent posts related to > this. I have also chatted on Freenode / #openbsd as there are couple > of guys running -current on their AMD Thinkpads. > > It seems that almost everything works. For suspend you need to switch > the option from "Windows" to "Linux" in Bios > (Config/Power/SleepState). Few people still report occasional problems > with suspend. Also, there's no userland clock_gettime on the 4750U > (due to reported tsc skew). Almost everything else works - wifi, > acceleration, etc. > > Will report my own experience as soon as will get to -current > installation. Jan, Thanks for the reply. That is the same machine I have (4750U with 16GB RAM). I got a reply off-list also suggesting that things should "mostly" work. Look forward to hearing how you go. Also wondering if you're going to be testing external displays, USB-C docking, full disk encryption etc? Thanks, - ajf
Re: Disable touchpad acceleration? (wsmouse)
I have found something that makes it feel linear, finally.
doas wsconsctl mouse.tp.deceleration=0
With the following patch. Maybe this does the same thing as your
mouse0.param suggestion? Although I didn't touch the x/y hysteresis
values (34/35).
diff --git sbin/wsconsctl/mouse.c sbin/wsconsctl/mouse.c
index e04642dacbc..0f1594e17e0 100644
--- sbin/wsconsctl/mouse.c
+++ sbin/wsconsctl/mouse.c
@@ -61,6 +61,7 @@ struct field mouse_field_tab[] = {
{ "tp.swapsides", _swapsides, FMT_CFG,
FLG_NORDBACK },
{ "tp.disable", _disable, FMT_CFG,
FLG_NORDBACK },
{ "tp.edges", _edges, FMT_CFG, FLG_NORDBACK },
+ { "tp.deceleration", _decel, FMT_CFG, FLG_NORDBACK },
{ "tp.param", _param, FMT_CFG, FLG_WRONLY },
/* Add an alias. This field is valid for all wsmouse devices. */
{ "param", _param, FMT_CFG, FLG_WRONLY },
diff --git sbin/wsconsctl/mousecfg.c sbin/wsconsctl/mousecfg.c
index 6d52bcbfc9c..6162df5c229 100644
--- sbin/wsconsctl/mousecfg.c
+++ sbin/wsconsctl/mousecfg.c
@@ -109,6 +109,12 @@ struct wsmouse_parameters cfg_revscroll = {
1
};
+struct wsmouse_parameters cfg_decel = {
+ (struct wsmouse_param[]) {
+ { WSMOUSECFG_DECELERATION, 0 }, },
+ 1
+};
+
struct wsmouse_parameters cfg_param = {
(struct wsmouse_param[]) {
{ -1, 0 },
diff --git sbin/wsconsctl/mousecfg.h sbin/wsconsctl/mousecfg.h
index 8e99139d280..97ef153fcb3 100644
--- sbin/wsconsctl/mousecfg.h
+++ sbin/wsconsctl/mousecfg.h
@@ -22,6 +22,7 @@ extern struct wsmouse_parameters cfg_edges;
extern struct wsmouse_parameters cfg_swapsides;
extern struct wsmouse_parameters cfg_disable;
extern struct wsmouse_parameters cfg_revscroll;
+extern struct wsmouse_parameters cfg_decel;
extern struct wsmouse_parameters cfg_param;
extern int cfg_touchpad;
On 10/14/20 2:12 PM, Ulf Brosziewski wrote:
Could you tell us why it feels weird?
If you are really serious about a completely "linear" response, you might
want to try
$ doas wsconsctl mouse0.param=34:0,35:0,36:0
This turns off noise filtering and deceleration (very low speeds are slowed
down even further, which may be helpful if you want to hit a 1-pixel window
border, for example). What remains is the filtering performed by the firmware,
which may be decent nowadays, or not.
On 10/14/20 8:22 AM, Brennan Vincent wrote:
On 10/14/20 1:49 AM, Otto Moerbeek wrote:
On Tue, Oct 13, 2020 at 11:38:11PM -0400, Brennan Vincent wrote:
Hello,
I am using the wsmouse driver with x11, and no amount of googling or reading
man pages has helped me figure out how to disable acceleration and have
completely flat/linear response. Is this possible?
I know that I can change sensitivity with `mouse.tp.scaling=`, but
I don't think this affects acceleration.
Check xset (and maybe xinput, but I;ve never used that).
-Otto
Thanks. `xinput --set-prop /dev/wsmouse0 'Device Accel Profile' -1` seems to
have made things a lot better, although it still feels a bit weird. I could
just be imagining it.
Anyway, thanks for the pointers!
Re: Installation of 6.7 does not start on Lenovo ThinkPad P1 Gen 3
Re: Router advertisements for dynamic IPv6 prefix
On 11/10/20 12:52, Henrik Friedrichsen wrote: Hey, my ISP provides connectivity via PPPoE. An IPv6 prefix is handed out via DHCPv6 PD, which my OpenBSD gateway passes on to clients with the help of router advertisements using rad. This works fine until the ISP disconnects me after 24h (force disconnect on ISP side). The gateway receives a new prefix via prefix delegation and rad advertises it in the local network. So far so good. However, as the old stale prefix is still valid according to the advertised lifetime, clients keep their stale IPv6 addresses. I have already decreased the lifetimes in rad to <24h, which mitigates the problem somewhat, but it's not perfect. Set the VL to 30', and the PL to 15'. You could even set the VL to 15', and the PL to 7.5', if necessary. You may want to have a look at this, too: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-04 And you may also look at this other one, which has recommendations for CPEs, which in your case accounts for your DHCPv6-PD and RA daemons: https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-05 For instance, some clients may receive the advertisement 1h before the disconnect but since the lifetimes are static, the client will assume a validity of ~23h (as set), although the prefix will expire in 1h. There's yet another problem you may face: Consider the case where your ISP's CPE router is connected to a local switch on the LAN side, and the CPE router crashes and reboots. The local hosts will not see the "link down" event (since the switch has been "up"), but if your ISP does dynamic prefixes, your CPE is likely to get a new prefix without the CPE router even noticing. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Router advertisements for dynamic IPv6 prefix
Hi, On 14/10/20 05:18, Stuart Henderson wrote: On 2020-10-11, Henrik Friedrichsen wrote: Hey, my ISP provides connectivity via PPPoE. An IPv6 prefix is handed out via DHCPv6 PD, which my OpenBSD gateway passes on to clients with the help of router advertisements using rad. This works fine until the ISP disconnects me after 24h (force disconnect on ISP side). The gateway receives a new prefix via prefix delegation and rad advertises it in the local network. So far so good. However, as The IPv6 protocol does not have the necessary features to reliably cope with this setup. (Neither does IPv4 for that matter). That's correct. But I'm trying to push work in this area: see https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08 Section 4.5 of the aforementioned document is what would solve the problem. -- ironically, that's the part of the document that received more push-back from the 6man wg of the IETF. (the mitigations that have so far been agreed-upon by the wg are those in: https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-01) the old stale prefix is still valid according to the advertised lifetime, clients keep their stale IPv6 addresses. I have already decreased the lifetimes in rad to <24h, which mitigates the problem somewhat, but it's not perfect. For instance, some clients may receive the advertisement 1h before the disconnect but since the lifetimes are static, the client will assume a validity of ~23h (as set), although the prefix will expire in 1h. After some research I found out that other router advertisement daemons, e.g. radvd, have settings to alleviate this: - DeprecatePrefix will advertise a 0 plt and 2h vlt for the stale prefix - DecrementLifetimes decrements the lifetimes by the number of seconds since the last advertisement These don't really work well either. DeprecatePrefix is only sent once so a device that is asleep will miss it; also it is still advertising the prefix as *valid* just not preferred. I can implement this https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08#section-4.2 into OPenBSD if you wish. -- it has already been commited to the Linux kernel. DecrementLifetimes might work to some extent (but will need to be synchronized with the vltime from the ISP) but hosts are required to ignore this if less than 7200 seconds (2h) unless the new vltime is *higher* than the current one. If there *was* some magic RA to say "immediately stop using the prefix you're currently using", that would be quite a DoS risk. Not really. At the end of the day, the threat model is that you trust RAs. You can already do ND cache poisoning, disable routers (by setting the Router Lifetime to zero), insert more specific routes (via Redirects or RIOs), become a DNS man-in-the-middle (via RDNSS), etc., etc., etc. Honoring PIOs with a Valid Lifetime < 2h will not allow the attacker to do anything he/she can already achirve via other mechanisms. (Remember they are not authenticated, and sent unsolicited so must be listened for all the time. Compare with v4; also not auth'd but at least they're only sent in response to a client query, so an attacker wouldn't be able to kill connectivity for everyone in one go). If you can't get a stable v6 prefix from your ISP and no better ISP is available I would suggest either of: - take the same approach you would have to use in IPv4 if your ISP gave you a routed range that changed every reconnect: use a private prefix (rfc1918 for v4, ULA for v6) and NAT to the current range, - set 7200 vltime, and force an ISP reconnect when nobody is using the network, Set the VL to no more than 1800 (or even a little less). Then set the preferred lifetime to half of that. That's how I (momentarily) deal with this problem while we solve the problem at the protocol level. - ignore the ISP's pseudo-IPv6 setup and get your v6 connectivity via tunnel to HE, as long as you don't need to reach hosts single-homed behind Cogent, Depending on where you are and the availability of POPs, you may get a horrible RTT (and geo-location). Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Thinkpad T14/T14s - any experiences?
Hello, I have a Thinkpad T14s AMD (currently running Loonix) that I'd probably like to move to OpenBSD. I had a look through the archive, and there was mention a few months back that the installer for 6.7 would not even boot on this machine [1]. Wondering if anyone has had a more recent experience with -current? I don't really want to attempt an install unless I have some guarantee that it'll probably work. Thanks, - ajf [1] http://openbsd-archive.7691.n7.nabble.com/ThinkPad-T14-AMD-td397494.html#a397526
Wyse C90 (i386) early panic 'pci_make_tag bad request' after "acpi0: sleep states"
When trying to boot -current i386 from a clean install on the internal flash drive, this thing panics on the same line as the 'acpi sleep states' after 'S5'. As a workaround, I can load pxeboot with a boot.conf to boot bsd. My guess would be that pxeboot passes control to the kernel with some trivial and other"wyse" irrelevant bit or bits different. I made no changes in BIOS between the working and non-working boots, just unplugged the network cable. No serial cable, but pictures, full dmesg from booted with pxeboot, and acpidump, all stored at https://darwinsys.com/tmp/wyse. TIA for any help.
Re: Any experience with 10Gbe?
>I'm supporting a small business who needs more bandwidth due to the >work-from-home >situation. They've asked me to help them do the upgrade to >10Gbe. I'd preferto keep them on an >OpenBSD router, since I love how liuttle >maintenance it needs, but I can't find any accounts of >someone actually >managing to get close to line speed above 1 Gbe. > >I don't want to just buy expensive hardware and hope that it works. Has anyone >here been able >to get close to 10 Gb/s networking with OpenBSD? I don't need >to be able to have more than a >few pf-rules. There is a talk on YouTube about using a few OpenBSD boxes with 10gb, maybe this helps somewhat. https://www.youtube.com/watch?v=veqKM4bHesM
Re: No longer can change brightness
On 13.10.20 13:07, james.lu...@keemail.me wrote: > Hello, > > The latest snapshots (maybe 1 week ago) have made wsconsctl(8) no longer > functional for changing display brightness on my MacBook Pro mid 2014. > > The expected behavior would be to `wsconsctl display.brigthness=X` to change > the value for the desired percentage, but it always return > `display.brightness -> 0.00%` while keeping the brightness at the highest > possible. using xrandr(1)? xrandr --output ... --brightness 1.0
Re: Router advertisements for dynamic IPv6 prefix
On 2020-10-11, Henrik Friedrichsen wrote: > Hey, > > my ISP provides connectivity via PPPoE. An IPv6 prefix is handed out via > DHCPv6 PD, which my OpenBSD gateway passes on to clients with the help > of router advertisements using rad. > > This works fine until the ISP disconnects me after 24h (force disconnect > on ISP side). The gateway receives a new prefix via prefix delegation > and rad advertises it in the local network. So far so good. However, as The IPv6 protocol does not have the necessary features to reliably cope with this setup. (Neither does IPv4 for that matter). > the old stale prefix is still valid according to the advertised > lifetime, clients keep their stale IPv6 addresses. I have already > decreased the lifetimes in rad to <24h, which mitigates the problem > somewhat, but it's not perfect. For instance, some clients may receive > the advertisement 1h before the disconnect but since the lifetimes are > static, the client will assume a validity of ~23h (as set), although the > prefix will expire in 1h. > > After some research I found out that other router advertisement daemons, > e.g. radvd, have settings to alleviate this: > > - DeprecatePrefix will advertise a 0 plt and 2h vlt for the stale prefix > - DecrementLifetimes decrements the lifetimes by the number of seconds > since the last advertisement These don't really work well either. DeprecatePrefix is only sent once so a device that is asleep will miss it; also it is still advertising the prefix as *valid* just not preferred. DecrementLifetimes might work to some extent (but will need to be synchronized with the vltime from the ISP) but hosts are required to ignore this if less than 7200 seconds (2h) unless the new vltime is *higher* than the current one. If there *was* some magic RA to say "immediately stop using the prefix you're currently using", that would be quite a DoS risk. (Remember they are not authenticated, and sent unsolicited so must be listened for all the time. Compare with v4; also not auth'd but at least they're only sent in response to a client query, so an attacker wouldn't be able to kill connectivity for everyone in one go). If you can't get a stable v6 prefix from your ISP and no better ISP is available I would suggest either of: - take the same approach you would have to use in IPv4 if your ISP gave you a routed range that changed every reconnect: use a private prefix (rfc1918 for v4, ULA for v6) and NAT to the current range, - set 7200 vltime, and force an ISP reconnect when nobody is using the network, - ignore the ISP's pseudo-IPv6 setup and get your v6 connectivity via tunnel to HE, as long as you don't need to reach hosts single-homed behind Cogent, - disable v6 towards clients,
sasyncd questions about shared secret
Hi folks, question about sasyncd, because the man page doesn't tell: (Please excuse if I am too blind to see.) Do all sasync daemons on all peers have to share the same secret, or is it just the sasync daemons on the same carp interface? Where would I have to look for error messages indicating an invalid shared secret? Every enlightening comment is highly appreciated. Harri
Re: Disable touchpad acceleration? (wsmouse)
On 10/14/20 1:49 AM, Otto Moerbeek wrote: On Tue, Oct 13, 2020 at 11:38:11PM -0400, Brennan Vincent wrote: Hello, I am using the wsmouse driver with x11, and no amount of googling or reading man pages has helped me figure out how to disable acceleration and have completely flat/linear response. Is this possible? I know that I can change sensitivity with `mouse.tp.scaling=`, but I don't think this affects acceleration. Check xset (and maybe xinput, but I;ve never used that). -Otto Thanks. `xinput --set-prop /dev/wsmouse0 'Device Accel Profile' -1` seems to have made things a lot better, although it still feels a bit weird. I could just be imagining it. Anyway, thanks for the pointers!
