Re: support new

2020-11-17 Thread Bryan Steele
On Tue, Nov 17, 2020 at 04:55:55PM +0100, Emre Kal wrote:
> If my request is rejected again, please provide me with the *objective* 
> reasons why I am not allowed to list my services as a OpenBSD consultant.

Yeah, no.

> I believe I am entitled ...

There's your mistake right there.

-Bryan.



Re: Unable to adjust beep volume on ThinkPad X270

2020-11-17 Thread Stuart Henderson
On 2020-11-17, Sine Astris  wrote:
> I've attached the patch I applied to azalia_codec.c, dmesg, pcidump for
> my audio device, and mixerctl output.

This and your other mail are good reports, please send them to
t...@openbsd.org where people working on those areas are more likely
to see them (ideally inline rather than as attachments if your
MTA can do so without line-wrapping).




Unable to adjust beep volume on ThinkPad X270

2020-11-17 Thread Sine Astris
Hi,

I wasn't able to adjust the volume of the keyboard bell via
wsconsctl(8), or the volume of /dev/speaker on my ThinkPad X270.

Additionally, the default spkr_source (mix3) doesn't output the beep.
Changing to mix2, sounds the beep and my existing audio seems fine.

# mixerctl outputs.spkr_source=mix2

I applied the AZ_QRK_WID_BEEP_1D quirk to the Realtek ALC298 codec for
my devices vendor/product ID, and this seems to have resolved the issue.
Keyboard bell and /dev/speaker volume adjusts via wsconsctl(8) /
mixerctl(8)'s inputs.mix_beep=x,x

I've attached the patch I applied to azalia_codec.c, dmesg, pcidump for
my audio device, and mixerctl output.
--- azalia_codec.c  Tue Nov 17 23:03:24 2020
+++ azalia_codec.c.new  Tue Nov 17 23:00:27 2020
@@ -212,6 +212,9 @@
if (this->subid == 0x320019e5 ||
this->subid == 0x320119e5)  /* Huawei Matebook X */
this->qrks |= AZ_QRK_DOLBY_ATMOS;
+   if (this->subid == 0x506217aa) {/* Thinkpad X270 */
+   this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
+   }
break;
case 0x10ec0299:
this->name = "Realtek ALC299";
OpenBSD 6.8-current (GENERIC.MP) #1: Tue Nov 17 11:52:13 GMT 2020
sineast...@heliospan.home:/sys/arch/amd64/compile/GENERIC.MP
real mem = 17054859264 (16264MB)
avail mem = 16522694656 (15757MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xba6f6000 (62 entries)
bios0: vendor LENOVO version "R0IET61W (1.39 )" date 04/20/2020
bios0: LENOVO 20HN0013UK
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB 
SLIC SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT BGRT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4) 
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4) 
RP12(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 3479.83 MHz, 06-8e-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 3479.15 MHz, 06-8e-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus 4 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus -1 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpithinkpad0 at acpi0: version 2.0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "45N1113" serial  4917 type LION oem "LGC"
acpibat1 at acpi0: BAT1 model "45N1127" serial  4804 type LION oem "LGC"

Re: Wrong net in vlan

2020-11-17 Thread Stuart Henderson
On 2020-11-17, Axel Rau  wrote:
>
>
> --Apple-Mail=_AD48A584-E586-4B64-9277-CAE8E8103BC1
> Content-Type: text/plain;
>   charset=utf-8
> Content-Transfer-Encoding: 8bit
>
> Hi all.
>
>> Am 16.11.2020 um 11:09 schrieb Axel Rau :
>> 
>> - - -
>> From /etc/rc.conf.local:
>> - - -
>> dhcpd_flags="em0 em3 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16"
>> - - -
>
> I have still no resolution. dhcpd preovides always an address from the subnet 
> 172.16.11/24 regardless from which vlan comes the request.
> 172.16.11/24 is the subnet associated with the 1st vlan on em3 (vlan11)

Your emails are a bit confusing. You have sent one email showing
current config from ifconfig for vlan11 and vlan13, another email
showing hostname.if files for vlan11 and vlan12, an excerpt from
your dhcpd.conf file showing configs for the subnets you showed
on vlan11 and vlan12, and log from an example request on vlan13.

Check your configuration methodically, make sure you have sections
in dhcpd.conf for all the networks you have told it to listen to
that match the networks configured in hostname.if files.

Is dhcpd.conf just missing a subnet section for 172.16.13.0?

If things may have got confused during testing, restart the system to
make sure the interfaces are configured as set in the files.

> - - -
> hardware-type must be the name of a hardware interface type. Currently, the 
> ethernet, token-ring and fddi physical interface types are recognized, 
> although support for DHCP-over-IPsec virtual interface type ipsec-tunnel is 
> provided. The hardware-address should be a set of colon-separated hexadecimal 
> octets (0-ff) or a hostname that can be looked up in ethers(5) 
>  when the configuration is read.
> - - -

You are unlikely to need to set this. In any event a vlan is an
ethernet interface type.

> Are vlans aresupported by dhcpd at all?

It doesn't need any special support, they just appear as a normal
ethernet-like interface.

>
> Axel
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
>
>
> --Apple-Mail=_AD48A584-E586-4B64-9277-CAE8E8103BC1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
>   filename=signature.asc
> Content-Type: application/pgp-signature;
>   name=signature.asc
> Content-Description: Message signed with OpenPGP
>
>
> --Apple-Mail=_AD48A584-E586-4B64-9277-CAE8E8103BC1--
>
>



Re: limit UDP connection rate with PF pass rule

2020-11-17 Thread Stuart Henderson
On 2020-11-17, mabi  wrote:
> Hello,
>
> On my DNS authoritative servers which are behind an OpenBSD 6.6 firewall I 
> just saw some weird UDP high volume traffic on port 53 my these DNS servers 
> coming from Google (e.g. 74.125.18.1 or 172.253.214.111).
>
> These few IPs generated around 5200 requests/second on my DNS servers so I 
> was wondering if one can also limit the rate of requests in PF on UDP traffic 
> such as can be done with TCP (using max-src-nodes, max-src-conn, etc)?
>
> Looking at the documentation (https://www.openbsd.org/faq/pf/filter.html) it 
> only mentions TCP. So I deduct that it is simply not possible to somehow 
> limit the rate of UDP connections with PF, am I right here?
>
> Regards,
> Mabi
>
>
>
>
>
>

These packets are most likely sent from spoofed source addresses.

Assuming this is the case, the address you are seeing on the packets
would not be the attacker but the victim.

PF doesn't support this type of request rate limiting on UDP
connections. It's a bit dangerous to do so because in many cases it's
trivial to spoof UDP packets and blocking packets from a source on the
basis of this can result in you DoS'ing yourself. This isn't such a
problem with TCP because only someone on the network path between
you and the supposed source address (i.e. someone with access to
the ACK packets) is likely to be able to successfully spoof packets.

To mitigate this you might like to read the manual for your
authoritative nameserver software about RRL (response rate limiting),
many support it directly (including BIND and NSD), if not then you could
front-end with something that can handle it itself like dnsdist.

The DNS RRL techniques typically still reply to a proportion of queries
(either directly with the answer, or with a "retry over TCP" response
code) reducing impact if the source IP is *also* used by real queries as
well as the attack traffic.




Screen flickering on ThinkPad X270

2020-11-17 Thread Sine Astris
Hi,

I was suffering from a subtle (yet annoying once noticed) problem with
screen flickering whilst using xenocara on my ThinkPad X270.

It was only distinctly apparent with certain colours/images being
displayed, generally a darker (but not black) static background with
small bright regions changing. For example I could see a subtle
flicker/brightening of the entire background on each character typed in
an xterm. It also occasionally manifested (apparently randomly) as a
subtle flicker which looked like a quick change of brightness.

After excluding any possible xorg.conf device options, a bit of googling
turned up some people experiencing a similar issue on windows and linux,
and they pointed to a feature of newer Intel GPUs called "PSR" / "Panel
Self Refresh". These issues were resolved via the settings application
on windows, and on linux machines by setting a linux kernel parameter:
i915.enable_psr=0

OpenBSD doesn't appear to expose a mechanism for setting i915
parameters, so I changed the value from use hardware default to
disabled within: sys/dev/pci/drm/i915/i915_params.h.

This resolved the problem completely (which is a great relief, as it's
frequently apparent once you've noticed it), and doesn't appear to have
resulted in any other issues.

I've attached my dmesg and xorg.conf, and the small diff to
i915_params.h is below. When I get time I may see if I am able to make
the required changes to expose this as a flag.

--- sys/dev/pci/drm/i915/i915_params.h  Tue Nov 17 09:50:23 2020
+++ sys/dev/pci/drm/i915/i915_params.h.new Tue Nov 17 09:30:24 2020
@@ -52,7 +52,7 @@
  param(int, vbt_sdvo_panel_type, -1, 0400) \
  param(int, enable_dc, -1, 0400) \
  param(int, enable_fbc, -1, 0600) \
- param(int, enable_psr, -1, 0600) \
+ param(int, enable_psr, 0, 0600) \
  param(int, disable_power_well, -1, 0400) \
  param(int, enable_ips, 1, 0600) \
  param(int, invert_brightness, 0, 0600) \
[61.711] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
(Operation not permitted)
Check that you have set 'machdep.allowaperture=1'
in /etc/sysctl.conf and reboot your machine
refer to xf86(4) for details
[61.711]linear framebuffer access unavailable
[61.732] (--) Using wscons driver on /dev/ttyC4
[61.739] 
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[61.739] Build Operating System: OpenBSD 6.8 amd64 
[61.739] Current Operating System: OpenBSD heliospan.home 6.8 GENERIC.MP#1 
amd64
[61.739] Build Date: 17 November 2020  08:48:50PM
[61.739]  
[61.739] Current version of pixman: 0.38.4
[61.739]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[61.739] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[61.739] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Nov 17 22:33:05 
2020
[61.741] (==) Using config directory: "/etc/X11/xorg.conf.d"
[61.741] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[61.743] (==) No Layout section.  Using the first Screen section.
[61.743] (==) No screen section available. Using defaults.
[61.743] (**) |-->Screen "Default Screen Section" (0)
[61.743] (**) |   |-->Monitor ""
[61.744] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[61.744] (**) |   |-->Device "drm"
[61.744] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[61.744] (==) Automatically adding devices
[61.744] (==) Automatically enabling devices
[61.744] (==) Not automatically adding GPU devices
[61.745] (==) Max clients allowed: 256, resource mask: 0x1f
[61.751] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[61.751] (==) ModulePath set to "/usr/X11R6/lib/modules"
[61.751] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[61.751] (II) Loader magic: 0xaea07e33460
[61.751] (II) Module ABI versions:
[61.751]X.Org ANSI C Emulation: 0.4
[61.751]X.Org Video Driver: 24.1
[61.751]X.Org XInput driver : 24.1
[61.751]X.Org Server Extension : 10.0
[61.751] (--) PCI:*(0@0:2:0) 8086:5916:17aa:5062 rev 2, Mem @ 
0xe000/16777216, 0xc000/536870912, I/O @ 0xe000/64
[61.751] (II) LoadModule: "glx"
[61.754] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
[61.767] (II) Module glx: vendor="X.Org Foundation"
[61.767]compiled for 

Re: Potential ksh bug?

2020-11-17 Thread Jan Stary
On Nov 17 09:01:18, alexan...@beard.se wrote:
> 
> 
> On November 17, 2020 5:04:19 AM GMT+01:00, Jordan Geoghegan 
>  wrote:
> >Hello,
> >
> >I'm not sure if this is a bug, or if it's just a pdksh thing, but I 
> >stumbled upon some interesting behaviour when I was tinkering around 
> >with quoting and using a poor mans array:
> >
> >test=$(cat <<'__EOT'
> ># I'll choose not to close this quote
> >other_stuff
> >__EOT
> >)
> >
> >echo "$test"
> >
> >
> >When I run this command on ash, dash, yash, bash, zsh or ksh93 I get
> >the 
> >following output:
> >
> ># I'll choose not to close this quote
> >other_stuff
> >
> >But when I run it on ksh from base or any pdksh derivative it throws an
> >
> >error about an unclosed quote:
> >
> >test.sh[8]: no closing quote
> 
> I believe this is a known shortcoming of how ksh determines the scope of the 
> $(...).

Does that also mean the 8th line in a 7-line script?



support new

2020-11-17 Thread Emre Kal
0
C Turkey
P
T Istanbul
Z 34330
O Consultant
I Emre Kal
A Levent, Besiktas
M e...@tuta.io
U
B
X
N OpenBSD consulting and support. Experienced in OpenBSD httpd, relayd and 
Packet Filter (PF).

ADDITIONAL INFORMATION

My previous request was rejected by Ingo Schwarze due to subjective objections 
even though I believe my submission satisfied all the criteria listed on 
.

On the other hand, less information about me, so there is a smaller attack 
surface. Therefore, I request a reconsideration of my request by someone other 
than Herr Schwarze.

If my request is rejected again, please provide me with the *objective* reasons 
why I am not allowed to list my services as a OpenBSD consultant.

I believe I am entitled to an equal consideration under the stated criteria for 
inclusion instead of being discriminated against because this particular person 
did not like communicating with me.

Thank you.



Re: Wrong net in vlan

2020-11-17 Thread Axel Rau
Hi all.

> Am 16.11.2020 um 11:09 schrieb Axel Rau :
> 
> - - -
> From /etc/rc.conf.local:
> - - -
> dhcpd_flags="em0 em3 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16"
> - - -

I have still no resolution. dhcpd preovides always an address from the subnet 
172.16.11/24 regardless from which vlan comes the request.
172.16.11/24 is the subnet associated with the 1st vlan on em3 (vlan11)
- - -
gw1# ifconfig vlan11
vlan11: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 13 priority 0 llprio 3
encap: vnetid 11 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.11.1 netmask 0xff00 broadcast 172.16.11.255
inet6 fe80::260:e0ff:fe5a:7543%vlan11 prefixlen 64 scopeid 0xd
inet6 2a05:bec0:26:16:11::a prefixlen 80
gw1# ifconfig vlan13
vlan13: flags=8843 mtu 1500
lladdr 00:60:e0:5a:75:43
index 15 priority 0 llprio 3
encap: vnetid 13 parent em3 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.13.1 netmask 0xff00 broadcast 172.16.13.255
inet6 fe80::260:e0ff:fe5a:7543%vlan13 prefixlen 64 scopeid 0xf
inet6 2a05:bec0:26:16:13::a prefixlen 80
- - -
- - -
DHCPREQUEST for 172.16.11.106 from d6:b5:e4:2a:3a:1c via vlan13
Nov 17 19:00:47 gw1 dhcpd[12274]: DHCPACK on 172.16.11.106 to d6:b5:e4:2a:3a:1c 
via vlan13
- - -
The client receives a IPv6 address from the correct subnet via rad.

In DHCPD.CONF(5), I read:
- - -
hardware-type must be the name of a hardware interface type. Currently, the 
ethernet, token-ring and fddi physical interface types are recognized, although 
support for DHCP-over-IPsec virtual interface type ipsec-tunnel is provided. 
The hardware-address should be a set of colon-separated hexadecimal octets 
(0-ff) or a hostname that can be looked up in ethers(5) 
 when the configuration is read.
- - -

Are vlans aresupported by dhcpd at all?

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP


limit UDP connection rate with PF pass rule

2020-11-17 Thread mabi
Hello,

On my DNS authoritative servers which are behind an OpenBSD 6.6 firewall I just 
saw some weird UDP high volume traffic on port 53 my these DNS servers coming 
from Google (e.g. 74.125.18.1 or 172.253.214.111).

These few IPs generated around 5200 requests/second on my DNS servers so I was 
wondering if one can also limit the rate of requests in PF on UDP traffic such 
as can be done with TCP (using max-src-nodes, max-src-conn, etc)?

Looking at the documentation (https://www.openbsd.org/faq/pf/filter.html) it 
only mentions TCP. So I deduct that it is simply not possible to somehow limit 
the rate of UDP connections with PF, am I right here?

Regards,
Mabi







Re: limit UDP connection rate with PF pass rule

2020-11-17 Thread Ben Jahmine
> On my DNS authoritative servers which are behind an OpenBSD 6.6 firewall I 
> just saw some weird UDP high volume traffic on port 53 my these DNS servers 
> coming from Google (e.g. 74.125.18.1 or 172.253.214.111).
>
> These few IPs generated around 5200 requests/second on my DNS servers so I 
> was wondering if one can also limit the rate of requests in PF on UDP traffic 
> such as can be done with TCP (using max-src-nodes, max-src-conn, etc)?
>
> Looking at the documentation (https://www.openbsd.org/faq/pf/filter.html) it 
> only mentions TCP. So I deduct that it is simply not possible to somehow 
> limit the rate of UDP connections with PF, am I right here?

Would it help to queue the UDP traffic and limit the bandwidth of the queue?

Regards

Ben



Re: [SPAM] Re: APU4 hardware network interfaces tied together

2020-11-17 Thread Stuart Henderson
On 2020-11-17, Mihai Popescu  wrote:
>> The combination of the computer and switch together can be considered a
> router.
>
> I have Mikrotik hAP ac2 in test for a few days. That is exactly something
> like this, 4 cores ARM for routing, switch attached for vlan'ed interfaces,
> plus wifi. And it is a real charm as performance and price. But it does not
> run OpenBSD and I miss the simplity of it mostly. This is how I was able to
> see the big difference compared to ISP router.

Agreed on all counts.. (you will find it hard to beat hAP ac2 for
price:performance, it's sad the hardware is not open).

> I already have a Netgear managed switch around here, with VLAN
> capabilities. I think I will go for RPi4. Mark K. told me on arm@ that it
> lacks storage and hardware acceleration for crypto used in ipsec and maybe
> VPN, but I will not use it. I use only pppoe as a hardware challenger.
>
> Did you run RPi4 in this scenario, is there good throughput, please? What
> do you use as storage?

I haven't run it in this scenario. I've done a bit of network performance
testing on the pi4 I occasionally use for ports work and was very pleasantly
surprised by how well the onboard nic worked.

I might give it a go sometime though, my APU was a bit slow for my
current connection, the slightly faster amd64 I replaced it with makes an
annoying noise ;)

For storage I have uefi firmware on a cheap small microsd, main OpenBSD
install on a usb3 sandisk ultra fit (the small ones) which I'm pretty
happy with. (If I was running Linux on it I'd look for a drive
supporting UASP though that doesn't really matter for a router which
won't be doing all that much disk io).




Re: support new

2020-11-17 Thread Ingo Schwarze
Hi Emre,

Emre Kal wrote on Tue, Nov 17, 2020 at 04:55:55PM +0100:

> If my request is rejected again, please provide me with the *objective*
> reasons why I am not allowed to list my services as a OpenBSD consultant.

That won't happen.

> I believe I am entitled

You are not entitled to anything.  The server www.openbsd.org is a
private server and the OpenBSD project is free to provide the
information it choses.  Just like you are free to advertise your
own services, or the services of other people you choose, on your
own website.  Nobody is entitled to an explanation.

Also note that we do not state the criteria for inclusion, nor are
they written down anywhere.  It's a matter of judgement.

In the past, it was considered whether the page support.html
should be deleted outright, to avoid distracting deevelopers
from development.  Even though i realize that such a page can
never be perfect, i consider it useful, so i committed to maintaining
it as best i can and trying to shield other developers from getting
distracted by it.

I'm not volunteering to follow any formal processes maintaining
it, and i feel convinced there is no need to.

That said, other developers are of course also free to commit
to the page.  But if they choose not to, they don't owe you an
explanation.

Yours,
  Ingo



Re: Multiple USB NICs

2020-11-17 Thread Kenneth Gober
On Tue, Nov 17, 2020 at 8:15 AM Mihai Popescu  wrote:

> Lee Nelson  wrote:
>
> > If I have multiple USB Ethernet adapters of identical make and model,
> > how does OpenBSD distinguish them over time.
>
> Is this happening to APU with same hardware interfaces, too?
>

No, 'wired in' interfaces are initialized in a predictable sequence.  NICs
installed in, e.g., PCI or PCIe slots also get consistent numbering.  If you
have multiple NICs installed the numbering might change if you remove one
(i.e. fxp1 might become fxp0 if you remove the old fxp0).

-ken


Re: [SPAM] Re: APU4 hardware network interfaces tied together

2020-11-17 Thread Mihai Popescu
> The combination of the computer and switch together can be considered a
router.

I have Mikrotik hAP ac2 in test for a few days. That is exactly something
like this, 4 cores ARM for routing, switch attached for vlan'ed interfaces,
plus wifi. And it is a real charm as performance and price. But it does not
run OpenBSD and I miss the simplity of it mostly. This is how I was able to
see the big difference compared to ISP router.

I already have a Netgear managed switch around here, with VLAN
capabilities. I think I will go for RPi4. Mark K. told me on arm@ that it
lacks storage and hardware acceleration for crypto used in ipsec and maybe
VPN, but I will not use it. I use only pppoe as a hardware challenger.

Did you run RPi4 in this scenario, is there good throughput, please? What
do you use as storage?

Thank you.


Re: Multiple USB NICs

2020-11-17 Thread Mihai Popescu
Lee Nelson  wrote:

> If I have multiple USB Ethernet adapters of identical make and model,
> how does OpenBSD distinguish them over time.

Is this happening to APU with same hardware interfaces, too?


Re: vmm-* missing from http://firmware.openbsd.org/firmware/snapshots/

2020-11-17 Thread Stuart Henderson
On 2020-11-17, Mihai Popescu  wrote:
> Recent snapshot install for amd64, first run reports the missing package
> from firmware.

Should be there now.




Re: seafile client doesn't sync files

2020-11-17 Thread Stuart Henderson
On 2020/11/14 21:02, avv. Nicola Dell'Uomo wrote:
> Hi Stuart,
> 
> thank you for your help!
> 
> Now it works (almost).
> 
> The matter here was that login.conf limits were not high enough.
> 
> With my server configuration seafile client opens ~ 43.000 files: I really 
> didn't expect such
> an high limit, so I set it to 8192 in login.conf.
> 
> Now it works, but it definitely wastes an exaggerate amount of resources.
> 
> When I close seafile client, kern.nfiles count drop form ~ 44.000 to ~ 890!

If you have that many files in the monitored directory tree, it's expected.

> Moreover seafile client consume a huge amount of cpu time.

If you have the ports tree installed you can try updating libinotify
- change 20170711 to 20180201 in /usr/ports/devel/libinotify, "make
makesum" and "make update", there are some changes in this that should
reduce memory use and I think maybe also reduce cpu load. If there are
problems or it doesn't help then revert to the version in packages
("pkg_add -r -D downgrade libinotify").



Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap

2020-11-17 Thread Gabriel Garcia

On 16/11/2020 23:03, Juan Francisco Cantero Hurtado wrote:

Try -cpu kvm64.
Thanks, Juan - yup, works similar to the Opteron, but lacks one of the 
flags - not much difference.
I believe Philip is right in the assessment that a) the CPU isn't 
patched with AMD errata in the first place; b) qemu doesn't let the VM 
patch it.
I'll report back in case somebody else is looking to do what I'm doing 
in this hardware (may take some time).




Re: [SPAM] Re: APU4 hardware network interfaces tied together

2020-11-17 Thread Stuart Henderson
On 2020-11-16, Noth  wrote:
> Buy a switch, and buy the APU4. Two ports don't get used, so what?

For starters, that means you at least might as well use APU2 instead
(which is often easier to buy - not all vendors have the APU4 - PCEngines
don't sell direct in some countries other than to business customers).

(and the price *difference* between APU2E0 and APU4 at some vendors
is enough to buy a pi4...)

> It'll be more reliable long term than a RPi4.

Do you have evidence to back this up? People were saying the same about
PCEngines not being reliable compared to Soekris too. It all seems nonsense.
Old rpi 1 and 2 machines are still running fine doing the job they were
intended to do. I'm not claiming there's anything amazing about them but
if they're capable of doing the job in the first place I don't see any
real concern about hardware reliability.

> A router with only one physical port isn't a router, it's a host, no
> matter how many vlans you throw at it.

The combination of the computer and switch together can be considered a
router. Plenty of "hardware" routers just have 1 or 2 real network interfaces
(either on the SOC or a separate device) and run a larger number of ports
off a vlan capable switch chip - sure it's in one box and looks like a
coherent unit, but architecturally no different.

Yes there are drawbacks of doing it this way but some advantages too.

(There are other options like some of the Octeon boxes, which can often be
bought second-hand for similar prices to RPi4, but I don't know what
sort of router performance can be expected from them, and if they don't
work out they're not reusable in nearly as many other roles as RPi4 or
the other arm64 boards supported by OpenBSD would be).




Re: Potential ksh bug?

2020-11-17 Thread Philip Guenther
On Mon, Nov 16, 2020 at 11:04 PM Bodie  wrote:

> On 17.11.2020 05:04, Jordan Geoghegan wrote:
> > Hello,
> >
> > I'm not sure if this is a bug, or if it's just a pdksh thing, but I
> > stumbled upon some interesting behaviour when I was tinkering around
> > with quoting and using a poor mans array:
> >
> > test=$(cat <<'__EOT'
> > # I'll choose not to close this quote
> > other_stuff
> > __EOT
> > )
> >
> > echo "$test"
> >
> >
> > When I run this command on ash, dash, yash, bash, zsh or ksh93 I get
> > the following output:
> >
> > # I'll choose not to close this quote
> > other_stuff
> >
> > But when I run it on ksh from base or any pdksh derivative it throws
> > an error about an unclosed quote:
> >
> > test.sh[8]: no closing quote
> >
> > This snippet works on every POSIX-y shell in the ports tree, and fails
> > on every pdksh variant I tried, including on NetBSD and DragonflyBSD
> > as well.  I don't have the requisite esoteric knowledge regarding
> > pdksh's internal quoting logic, so I'm hoping one of the gurus here
> > can determine whether this is a bug or if I'm just doing something
> > annoying.
> >
> > Any insight that can be provided would be much appreciated.
> >
>
> What exactly are you trying to achieve?
>
> If you will look in sh(1) for 'Command expansion' then there are defined
> rules and your form is not between them.
>

I disagree.  I believe this:

cat <<'__EOT'
# I'll choose not to close this quote
other_stuff
__EOT

matches the syntax for 'command'...once you take into account redirections,
including 'here-docs'.  Or do you believe that's not a valid command on
it's own?  To put another way, I agree with halex@ that this is a (known,
not yet fixed) bug.


So error message about missing closing quote is actually proper
> behavior.
>

Nope.  This is a bug in OpenBSD ksh.



> As well it is good idea to avoid reserved words as a names for variables
> ;-)
> (test)


Hmm?

* 'test' is not a reserved word in the shell
* shell variable names are a completely different namespace than shell
reserved words or commands
* code written to check whether something is a bug is 1000% out-of-bounds
for style comments: either there's a bug or there isn't


Philip Guenther


Re: Potential ksh bug?

2020-11-17 Thread Alexander Hall



On November 17, 2020 5:04:19 AM GMT+01:00, Jordan Geoghegan 
 wrote:
>Hello,
>
>I'm not sure if this is a bug, or if it's just a pdksh thing, but I 
>stumbled upon some interesting behaviour when I was tinkering around 
>with quoting and using a poor mans array:
>
>test=$(cat <<'__EOT'
># I'll choose not to close this quote
>other_stuff
>__EOT
>)
>
>echo "$test"
>
>
>When I run this command on ash, dash, yash, bash, zsh or ksh93 I get
>the 
>following output:
>
># I'll choose not to close this quote
>other_stuff
>
>But when I run it on ksh from base or any pdksh derivative it throws an
>
>error about an unclosed quote:
>
>test.sh[8]: no closing quote

I believe this is a known shortcoming of how ksh determines the scope of the 
$(...).

/Alexander

>
>This snippet works on every POSIX-y shell in the ports tree, and fails 
>on every pdksh variant I tried, including on NetBSD and DragonflyBSD as
>
>well.  I don't have the requisite esoteric knowledge regarding pdksh's 
>internal quoting logic, so I'm hoping one of the gurus here can 
>determine whether this is a bug or if I'm just doing something
>annoying.
>
>Any insight that can be provided would be much appreciated.
>
>Regards,
>
>Jordan