Inclusion in the list of providers OpenBSD

[Gerd Theobald]

Hi there,


We would be happy to be included on your list as a German provider of OpenBSD 
courses and consulting. Here is the completed template:


C Germany
P Baden-Wrttemberg
T Nrnberg
Z D-90411
O New Elements / IT-Schulungen.com
I Dr. Gerd Theobald
A Thurn-und-Taxis-Str. 10
M i...@it-schulungen.com
U https://www.it-schulungen.com/seminare/serversysteme/unix/openbsd/index.html
B +49 911 6500-8222
X +49 911 650083-99
N IT-Schulungen has been offering training and consulting on various topics 
such as OpenBSD, UNIX and other open source topics for over 15 years.


Thanks a lot!

Regards

Gerd


Dr. Gerd Theobald
Marketing Consultant

g.theob...@newelements.de
phone +49-177 7543098
fax+49-911-65008-399

www.it-schulungen.com
Education Center der New Elements GmbH
Thurn-und-Taxis-Straße 10
90411 Nürnberg

Seminare mit gesicherten 
Terminen I Neuigkeiten und 
Angebote I
Geschäftsführer: Atasoy Altinci, Michael Deinhard Dipl.-Kfm. (Uni) I 
Amtsgericht Nürnberg HRB 25042 I USt-IdNr.: DE263750718

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das 
unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail sind nicht 
gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

IPsec "road warrior" VPN not getting set up properly.

[Anthony Coulter]

Short version:

I'm trying to set up a "road warrior"-style VPN like the one described
at https://www.openbsd.org/faq/faq17.html but I'm trying to use IPv6 so
I can have globally-routable addresses (so I'm not using NAT). So far
I've gotten the initiator and the responder to set up a security
association (to be precise, according to "ipsecctl -sa" the
initiator/client sees one SA and zero flows, and the responder/server
sees two SA's and two flows). When I try to ping the client's virtual
IP address from the server, tcpdump running on the egress interfaces of
both the client and the server see appropriately-sized "esp" packets
going from the server to the client as expected, but tcpdump doesn't
see any traffic emerging on the "lo1" loopback interface the FAQ told
me to create, nor does it see any evidence of ping-responses being
sent. When I try to ping from the client to the server, I get
"ping6: sendmsg: Permission denied".


Longer version:

The client is running -current and the server is running 7.3.

The server is a VPS hosted in a datacenter somewhere, and my VPS
provider gives me a whole /64 subnet to work with. My VPS provider
doesn't appear to look at neighbor discovery traffic; it routes all
traffic in that /64 to my VirtIO interface, regardless of which IP
address it is, which seems like a handy feature for what I'm trying to
do.

Here is what I want to do: the client should open an IPsec tunnel to
the server. The client should request an IPv6 address from the server's
enormous /64 subnet. Then, applications running on the client should
have the option to use that "virtual" IPv6 address as though it was
available on a local interface on the client machine. The client would
effectively be multihosted: in addition to its regular physical
Internet connection it would also have this IPsec tunnel that also
connects to the global Internet. My plan right now is to use rdomains
to control which applications use the tunnel and which ones use the
regular egress interface, but I'm not attached to that specific
approach.

The application should be obvious: I'm trying to set up a region-faking
VPN, so that I can have applications appear to connect to the Internet
from different continents.

Both client and server are using the same pf.conf that is installed by
default. I tried adding "pass on enc0" to the client's pf.conf and
"pass on enc0 tagged ROADW" to the server's, but it hasn't made a
difference because (I assume) my existing pf.conf rules weren't
blocking much to begin with.

Here are my config files, with IP addresses and server names changed.
But basically you should see the client at 2001:db8:1::1 connecting to
the server at 2001:db8:2::1 and requesting a random IP address in the
server's subnet, e.g. 2001:db8:2::485b:4ac7. I have also put the
appropriate keys in /etc/iked/pubkeys/fqdn/.

=== Client-side configuration ===
$ cat /etc/hostname.lo1
rdomain 1

$ cat /etc/iked.conf
ikev2 'client_config' active esp \
rdomain 1 \
from dynamic to any \
local 2001:db8:1::1 \
peer  2001:db8:2::1 \
srcid client.example.org \
dstid server.example.org \
request address any \
iface lo1

=== Server-side configuration ===

$ cat /etc/sysctl.conf
net.inet6.ip6.forwarding=1

$ cat /etc/iked.conf
ikev2 'server_config' passive esp \
from any to dynamic \
local 2001:db8:2::1 \
peer  2001:db8:1::1 \
srcid server.example.org \
config address 2001:db8:2::/64 \
tag "ROADW"

=== End of configurations ===

Does it work? Sort of. Here's what I see on the server:

=== Checking status on the server ===

# ipsecctl -sa
FLOWS:
flow esp in from 2001:db8:2::485b:4ac7 to ::/0 peer 2001:db8:1::1 srcid 
FQDN/server.example.org dstid FQDN/client.example.org type require
flow esp out from ::/0 to 2001:db8:2::485b:4ac7 peer 2001:db8:1::1 srcid 
FQDN/server.example.org dstid FQDN/client.example.org type require

SAD:
esp tunnel from 2001:db8:2::1 to 2001:db8:1::1 spi 0x001a3754 enc aes-128-gcm
esp tunnel from 2001:db8:1::1 to 2001:cb8:2::1 spi 0x7634a3b6 enc aes-128-gcm

$ route show
Internet6:
Destination Gateway Flags   Refs  Use   Mtu  Prio Iface
default fe80::1234%vio0 UGS8  578 - 8 vio0 
::/96   localhost   UGRS   00 32768 8 lo0  
localhost   localhost   UHhl  10   90 32768 1 lo0  
:::0.0.0.0/96   localhost   UGRS   00 32768 8 lo0  
2001:db8:2::/64 server  UCn3 3630 - 4 vio0 
2001:db8:2::485b:4ac7   link#1  UHLc   0 3633 - 3 vio0 
...and a whole lot more

=== Checking status on the client ===

# ipsecctl -sa
FLOWS:
No flows

SAD:
esp tunnel from 2001:db8:2::1 to 2600:db8:1::1 spi 0x001a3754 enc aes-128-gcm

$ ifconfig lo1
lo1: flags=8049 rdomain 1 mtu 32768
index 4 priority 0 llprio 3
groups: lo
   

Re: ntpd and ppm

[chohag]

Theo de Raadt writes:
> J Doe  wrote:
>
> > On 2023-07-04 17:27, Martin Schröder wrote:
> > 
> > > Am Di., 4. Juli 2023 um 23:20 Uhr schrieb J Doe 
> > > :
> > >> I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq
> > >> mentions the same unit - "ppm" - it doesn't explain what that means.
> > >>
> > >> What does "ppm" stand for ?
> > > 
> > > microseconds per second.
> > 
> > Hi Martin,
> > 
> > Ah, I see!  From Google there was a link that referenced PPM with a 
> > different: ntpd implementation and it mentioned "Parts Per Million", but 
> > I was confused by that as I have only heard of Parts Per Million with 
> > pollution / chemistry ... but microseconds per second makes sense.
>
> You mean lime "1 in a million" is the same as "microseconds per second"?
>
> There's always jobs for people who can't do simple math.

Is it that time of the month again?

Matthew

Re: ntpd and ppm

[Theo de Raadt]

J Doe  wrote:

> On 2023-07-04 17:27, Martin Schröder wrote:
> 
> > Am Di., 4. Juli 2023 um 23:20 Uhr schrieb J Doe :
> >> I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq
> >> mentions the same unit - "ppm" - it doesn't explain what that means.
> >>
> >> What does "ppm" stand for ?
> > 
> > microseconds per second.
> 
> Hi Martin,
> 
> Ah, I see!  From Google there was a link that referenced PPM with a 
> different: ntpd implementation and it mentioned "Parts Per Million", but 
> I was confused by that as I have only heard of Parts Per Million with 
> pollution / chemistry ... but microseconds per second makes sense.

You mean lime "1 in a million" is the same as "microseconds per second"?

There's always jobs for people who can't do simple math.

Re: ntpd and ppm

[J Doe]

On 2023-07-04 17:27, Martin Schröder wrote:


Am Di., 4. Juli 2023 um 23:20 Uhr schrieb J Doe :

I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq
mentions the same unit - "ppm" - it doesn't explain what that means.

What does "ppm" stand for ?


microseconds per second.


Hi Martin,

Ah, I see!  From Google there was a link that referenced PPM with a 
different: ntpd implementation and it mentioned "Parts Per Million", but 
I was confused by that as I have only heard of Parts Per Million with 
pollution / chemistry ... but microseconds per second makes sense.


Thanks!

-J


Links
=

[1] 
https://support.hpe.com/hpesc/public/docDisplay?cc=at=emr_na-c01534439=de-at

Re: ntpd and ppm

[Martin Schröder]

Am Di., 4. Juli 2023 um 23:20 Uhr schrieb J Doe :
> I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq
> mentions the same unit - "ppm" - it doesn't explain what that means.
>
> What does "ppm" stand for ?

microseconds per second.

Re: ntpd and ppm

[Theo de Raadt]

J Doe  wrote:

> Hi,
> 
> I noticed when: ntpd logs time adjustments in: /var/log/daemon it uses a 
> unit of "ppm":
> 
>  Jun 22 23:22:20 server ntpd[45813]: adjusting clock frequency by 
> -1.127600 to 0.056400ppm
> 
> I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq 
> mentions the same unit - "ppm" - it doesn't explain what that means.
> 
> What does "ppm" stand for ?

Since you can't use a search engine to figure that out, I'll give you
a hint.  ppm means "you are stupid".

ntpd and ppm

[J Doe]

Hi,

I noticed when: ntpd logs time adjustments in: /var/log/daemon it uses a 
unit of "ppm":


Jun 22 23:22:20 server ntpd[45813]: adjusting clock frequency by 
-1.127600 to 0.056400ppm


I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq 
mentions the same unit - "ppm" - it doesn't explain what that means.


What does "ppm" stand for ?

Thanks,

- J

Restart of syslogd every three hours ?

[J Doe]

Hi,

I have a question about an OpenBSD 7.3 host that has syspatches up to 
today (July 4, 2023).


I noticed in: /var/log/messages that the: syslogd process is restarting 
every three hours:


/var/log/messages

Jun 18 11:00:01 server syslogd[83783]: restart
Jun 18 14:00:01 server syslogd[83783]: restart
. . .

I checked: man syslogd and looked at the cron tabs on the system and 
there doesn't appear to be anything related to the restarts.


Is this normal and if so, what is the purpose of the restarts ?

Thanks,

-J

Re: dhcpleased[59824]: sendto: Permission denied

[Zack Newman]

On 7/4/23 12:41, Otto Moerbeek wrote:

That may be true for reading dhcp packets, but in some cases
dhcpleased sends UDP datagram lika any ordinary program, for other
cases it uses BPF for sending. As the error reported is for sending,
it *is* possible that pf plays a role.

-Otto

I know which is why I didn't rule out pf as the problem and only the
specific exchange that rule was referring to. Of course my example that
"proved" you could specifically block the DHCP exchange only pertained
to dhcpcd and not dhcpleased.

Re: dhcpleased[59824]: sendto: Permission denied

[Otto Moerbeek]

On Mon, Jul 03, 2023 at 10:34:24AM -0600, Zack Newman wrote:

> On 7/3/23 11:25, Mark wrote:
> > I'm getting (I think once per day) "dhcpleased[59824]: sendto: Permission
> > denied" error message in my daemon and messages log files.
> > 
> > I think that's happening due to my PF configuration.
> 
> Certainly could be. If this happens consistently around a particular
> time, you can "live dangerously" and allow all traffic temporarily to
> see if the issue is resolved. More safely, use tcpdump(8) to see if you
> can find the problem.
> 
> > I tried to add:
> > pass log quick on $ext_if proto udp from any to any port = 67
> > in my pf.conf file, didn't help.
> 
> Completely useless. DHCP traffic never makes its way to pf(4) due to
> being handled by bpf(4) first, so you don't need such a rule-in fact
> you could explicitly block such traffic, and it won't matter. Proof:

That may be true for reading dhcp packets, but in some cases
dhcpleased sends UDP datagram lika any ordinary program, for other
cases it uses BPF for sending. As the error reported is for sending,
it *is* possible that pf plays a role.

-Otto

> 
> router# cat /etc/pf.conf
> # Options.
> set block-policy drop
> 
> # Macros.
> wan = em0
> 
> # Filtering rules.
> block in quick on $wan inet proto udp to port 68
> block out quick on $wan inet proto udp to port 67
> pass quick
> 
> router# rcctl stop dhcpcd
> dhcpcd(ok)
> router# rm -rf /var/run/dhcpcd/
> router# ifconfig em0 -inet
> router# ifconfig em0 -inet6
> router# ifconfig em0 down
> router# pfctl -f /etc/pf.conf
> router# tcpdump -ntt -i em0 -w pkts.dat 'udp and ip and (dst port 67 or dst 
> port 68)' &
> [1] 98425
> router# tcpdump: listening on em0, link-type EN10MB
> router# rcctl start dhcpcd
> dhcpcd(ok)
> router# pkill -x tcpdump
> 
> 12551 packets received by filter
> 0 packets dropped by kernel
> router# tcpdump -nr pkts.dat
> 10:02:29.663056 0.0.0.0.68 > 255.255.255.255.67:  xid:0x3544268 [|bootp]
> 10:02:32.802098 0.0.0.0.68 > 255.255.255.255.67:  xid:0x3544268 secs:3 
> [|bootp]
> 10:02:32.857942 96.120.140.45.67 > 73.78.65.184.68:  xid:0x3544268 
> Y:73.78.65.184 G:96.120.140.45 [|bootp] [tos 0x10]
> 
> The use of dhcpcd(8) is not relevant. I choose to use it for both DHCPv6
> and DHCP so that I only have one daemon. I am _not_ recommending its
> use over dhcpleased(8). The point is to show that such traffic is
> allowed regardless of what rules you have in pf(4).
> 
> If it is a pf(4) issue, then it not related to that traffic.
> 

Re: dhcpleased[59824]: sendto: Permission denied

[Zack Newman]

On 7/4/23 11:51, Mark wrote:

Hi again, thanks for your detailed and very informative reply, Zack.

Much appreciated!

I wanted to re-try the fact (memories), on FreeBSD 13.2-RELEASE-p1;

I removed the pass line from my pf.conf;
"pass log quick on $ext_if proto udp from any to any port = 67"

reloaded PF, then dmesg -a showed;

Jul  4 04:59:09 myhost dhclient[18366]: send_packet: Permission denied
Jul  4 04:59:33 myhost syslogd: last message repeated 3 times
Jul  4 05:01:43 myhost syslogd: last message repeated 4 times
Jul  4 05:11:29 myhost syslogd: last message repeated 18 times
Jul  4 05:20:11 myhost syslogd: last message repeated 10 times

I then, enabled the line again:
"pass log quick on $ext_if proto udp from any to any port = 67"

Restarted pf.

the "dhclient: send_packet: Permission denied" messages were gone,
disappeared from "dmesg -a" output, and it wasn't produced anymore.

I tried this, again and again. Obviously PF blocks something.

Just my two cents..


That does indeed appear to refute my claim about FreeBSD. I am now
curious. I know pf in FreeBSD has diverged quite a bit from pf in
OpenBSD, so maybe that is relevant. Here is the @misc thread I was
referring to FYI:

https://marc.info/?l=openbsd-misc=167283774627269=2

If you are willing to entertain me, can you have pf.conf(5) contain
the following (and only the following):

set block-policy drop
set skip on lo
ext_if = 
pass out quick on $ext_if inet proto udp to port 67
pass in quick on $ext_if inet proto udp to port 68
block quick

Does dhclient work fine? If so, after removing the two pass lines what
does the following write:

tcpdump -ntt -i  -w pkts.dat 'udp and ip and (dst port 67 or dst 
port 68)' &

Obviously verify the syntax and semantics align with tcpdump on OpenBSD
first. Make sure you restart dhclient after you run the above command.

Feel free to continue this privately in the interest of not flooding
@misc especially since this now concerns an entirely different OS.

Zack

Re: dhcpleased[59824]: sendto: Permission denied

[Mark]

Hi again, thanks for your detailed and very informative reply, Zack.

Much appreciated!

I wanted to re-try the fact (memories), on FreeBSD 13.2-RELEASE-p1;

I removed the pass line from my pf.conf;
"pass log quick on $ext_if proto udp from any to any port = 67"

reloaded PF, then dmesg -a showed;

Jul  4 04:59:09 myhost dhclient[18366]: send_packet: Permission denied
Jul  4 04:59:33 myhost syslogd: last message repeated 3 times
Jul  4 05:01:43 myhost syslogd: last message repeated 4 times
Jul  4 05:11:29 myhost syslogd: last message repeated 18 times
Jul  4 05:20:11 myhost syslogd: last message repeated 10 times

I then, enabled the line again:
"pass log quick on $ext_if proto udp from any to any port = 67"

Restarted pf.

the "dhclient: send_packet: Permission denied" messages were gone,
disappeared from "dmesg -a" output, and it wasn't produced anymore.

I tried this, again and again. Obviously PF blocks something.

Just my two cents..


Subject:Re: dhcpleased[59824]: sendto: Permission denied
From:   Zack Newman 
Date:   2023-07-04 15:41:31
Message-ID: a1d467d7-6a63-00dd-72c3-e9bd8dd7e1a8 () philomathiclife ! com

On 7/3/23 21:14, Mark wrote:
> I really do remember, under FreeBSD, I was having a similar "dmesg -a"
> output
>
> telling about DHCP's permission denied issue, and finally
>
> I solved it with a pass rule like:
>
> "pass log quick on $ext_if proto udp from any to any port = 67 keep state"
>
> in /usr/local/etc/pf.conf file.

Well unfortunately memories are rather unreliable. Additionally, people
often times come to incorrect conclusions. For starters even if that
rule mattered, you should at least have "out" specified since that rule
is only trying to handle traffic sent to the DHCP server. Two, there
should be a corresponding rule for ingress traffic sent to the DHCP
client. Three, "keep state" is irrelevant since the traffic is sent to
255.255.255.255:67, but the response is sent from a DHCP server or relay
server that most certainly doesn't have the IP 255.255.255.255; thus the
state entry is pointless. It's one thing to rely on the default behavior
(i.e., "keep state"), but to explicitly add that is at the very least
bizarre.

> And reading DHCP traffic never makes its way to pf,
>
> surprised me. Perhaps that's valid only on OpenBSD but not on FreeBSD?
>
> Anyways..

It probably surprises many, but it has been that way for a while.
Besides my "proof" that such rules are irrelevant, you can and even
should read more. There was even a recent thread on @misc where someone
inquired why there are DHCP-based rules in rc(8) when such rules don't
matter, and Theo de Raadt explained the historical reason for it.

I also doubt that it's "valid only on OpenBSD but not FreeBSD" despite
what you (mis)remember, but I am not interested enough to spend time
installing FreeBSD just to prove this. I spent a minute searching, and
dhclient(8) (
https://man.freebsd.org/cgi/man.cgi?query=dhclient=8=html)
explicitly talks about BPF, and this very old thread
(https://lists.freebsd.org/pipermail/freebsd-ipfw/2005-April/001756.html)
is about someone not able to block DHCP traffic with ipfw(8) where the
reason given was "dhcpd uses BPF directly (like tcpdump)". I realize
that thread is very old, concerns dhcpd instead of dhclient, and the
individual uses ipfw instead of pf; but those two references in
addition to your dubious rule are enough for me to maintain my
skepticism.

Re: Data source of record.bytes in audioctl

[Ricky Cintron]

On 2023-07-04 12:00, Alexandre Ratchov wrote:

On Mon, Jul 03, 2023 at 05:18:13PM -0400, Ricky Cintron wrote:

While troubleshooting some audio issues, I noticed that the values of
play.bytes and record.bytes in audioctl's output were identical, even
when only playing audio.

1) Is this expected behavior?


yes, by default the device always does DMA in both directions
(synchronously), so record.bytes increases like play.bytes


Great to know! This, along with the other details you've provided, will
help me understand what I'm seeing much more clearly now.

Thank you.


2) What is the source of this data (record.bytes)?



The source is the audio hardware interrupts. The audio(4) driver
handles them and increments its couter. The counter is readable by
userland with the AUDIO_GETPOS ioctl.


I found it interesting that the values were the same, so I took a look
at mixerctl, and noticed that 'line' (which is an output) and 'mix'
(which has line as its only source) were the sources for both
record.adc variables. At that point I figured that simply removing
all sources from those two variables would eliminate all audio data
from those recording channels, but record.bytes continued to match
play.bytes. I even attempted to mute both ADCs and to disable 
recording

in mixerctl (without rebooting), but nothing changed.

I'm probably going to remove 'line' and 'mix' as sources for the ADCs
because they don't make sense there, but I'm still hoping to 
understand

what's going on.



The mixer is a completely different thing and is completely
independent from DMA. It is supposed to control the analog
knobs/selectors, jack sensors, and alike.

Setting the record level to 0 (or removing all sources) would make the
ADC sample silence and produce zeros without affecting how it
works. That's why record.bytes still increases.


# mixerctl -v
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off  [ off on ]
record.adc-0:1=124,124
record.adc-2:3_mute=off  [ off on ]
record.adc-2:3=124,124
inputs.mix_source=line  { line }
inputs.mix_line=120,120
inputs.mix2_source=dac-2:3  { dac-2:3 mix }
inputs.mix3_source=dac-0:1  { dac-0:1 mix }
outputs.spkr_source=mix2  [ mix2 ]
outputs.spkr_mute=on  [ off on ]
outputs.spkr_eapd=on  [ off on ]
outputs.line_source=mix3  [ mix2 mix3 ]
outputs.line_mute=off  [ off on ]
inputs.line=85,85
outputs.line_dir=output  [ none output input input-vr0 input-vr50 
input-vr80

input-vr100 ]
outputs.line_boost=off  [ off on ]
outputs.line_eapd=on  [ off on ]
outputs.hp_source=mix2  [ mix2 mix3 ]
outputs.hp_mute=off  [ off on ]
outputs.hp_boost=off  [ off on ]
outputs.hp_eapd=on  [ off on ]
record.adc-2:3_source=line,mix  { line mix }
record.adc-0:1_source=line,mix  { line mix }
outputs.line_sense=plugged  [ unplugged plugged ]
outputs.hp_sense=unplugged  [ unplugged plugged ]
outputs.spkr_muters=line,hp  { line hp }
outputs.master=126,126
outputs.master.mute=off  [ off on ]
outputs.master.slaves=dac-2:3,dac-0:1,spkr,line,hp  { dac-2:3 dac-0:1 
spkr

line hp }
record.volume=124,124
record.volume.mute=off  [ off on ]
record.volume.slaves=adc-0:1,adc-2:3  { adc-0:1 adc-2:3 line }
record.enable=sysctl  [ off on sysctl ]

Re: OpenBSD 7.3 and some old IA32 CPUs

[Anton Borisov]

On 7/4/23, Scott Cheloha  wrote:
>> On Jun 28, 2023, at 13:26, Anton Borisov  wrote:
>>
>> Hi all,
>>
>> here's sysctl extracts from Rise iDragon, IDT WinChip C6/2A running
>> OpenBSD 7.3. All seems quite stable.
>
> Interesting.  Can you post a full dmesg for each of these?
>
>
OpenBSD 7.3 (GENERIC) #660: Sat Mar 25 11:17:44 MDT 2023
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 536297472 (511MB)
avail mem = 509366272 (485MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 03/24/00, BIOS32 rev. 0 @ 0xfb410
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf/0xb898
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfde60/160 (8 entries)
pcibios0: PCI Exclusive IRQs: 10 11
pcibios0: PCI Interrupt Router at 000:07:0 ("VIA VT82C586 ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x9800 0xd2000/0x800
cpu0 at mainbus0: (uniprocessor)
cpu0: RiseRiseRise  (586-class) 201 MHz, 05-02-01
cpu0: FPU,TSC,MMX
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA VT82C597 PCI" rev 0x04
viaagp0 at pchb0: v2
agp0 at viaagp0: aperture at 0xd000, size 0x1000
ppb0 at pci0 dev 1 function 0 "VIA VT82C598 AGP" rev 0x00
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "VIA VT82C586 ISA" rev 0x47
pciide0 at pci0 dev 7 function 1 "VIA VT82C571 IDE" rev 0x06: ATA33, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <_NEC, DVD_RW ND-3540A, 1.01> removable
cd0(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2
"VIA VT82C586 Power" rev 0x10 at pci0 dev 7 function 3 not configured
pciide1 at pci0 dev 8 function 0 "Promise PDC20268R" rev 0x02: DMA, channel 0 
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using irq 11 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 38204MB, 78242976 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
vga1 at pci0 dev 9 function 0 "TI 3DLabs Permedia 2" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
unknown vendor 0xb00c product 0x001c (class DASP subclass miscellaneous, rev 
0x05) at pci0 dev 11 function 0 not configured
fxp0 at pci0 dev 12 function 0 "Intel 8255x" rev 0x05, i82558: irq 11, address 
00:50:8b:10:ff:5d
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
lm0 at isa0 port 0x290/8: W83781D
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (8caff57a078193c5.a) swap on wd0b dump on wd0b
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
OpenBSD 7.3 (GENERIC) #660: Sat Mar 25 11:17:44 MDT 2023
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 536297472 (511MB)
avail mem = 509366272 (485MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 03/24/00, BIOS32 rev. 0 @ 0xfb410
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf/0xb898
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfde60/160 (8 entries)
pcibios0: PCI Exclusive IRQs: 10 11
pcibios0: PCI Interrupt Router at 000:07:0 ("VIA VT82C586 ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x9800 0xd2000/0x800
cpu0 at mainbus0: (uniprocessor)
cpu0: IDT WinChip 2-3D ("CentaurHauls" 586-class) 201 MHz, 05-08-07
cpu0: FPU,DE,TSC,MSR,MCE,MMX,3DNOW
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA VT82C597 PCI" rev 0x04
viaagp0 at pchb0: v2
agp0 at viaagp0: aperture at 0xd000, size 0x1000
ppb0 at pci0 dev 1 function 0 "VIA VT82C598 AGP" rev 0x00
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "VIA VT82C586 ISA" rev 0x47
pciide0 at pci0 dev 7 function 1 "VIA VT82C571 IDE" rev 0x06: ATA33, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <_NEC, DVD_RW ND-3540A, 1.01> removable
cd0(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2
"VIA VT82C586 Power" rev 0x10 at pci0 dev 7 function 3 not configured
pciide1 at pci0 dev 8 function 0 "Promise 

Re: Block network access completely for certain programs

[Zack Newman]

On 7/4/23 10:16, Kapetanakis Giannis wrote:

pf.conf(5) has option for user

 user user
  This rule only applies to packets of sockets owned by the
  specified user.  For outgoing connections initiated from the
  firewall, this is the user that opened the connection.  For
  incoming connections to the firewall itself, this is the user
  that listens on the destination port.
...


TIL. Very cool. I like to think I am resistant to fanboyism, but pf
challenges that.

Re: Question regarding pf rules: block in on em0: ...

[Zack Newman]

On 7/4/23 10:36, "Why 42? The lists account.":


While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen.

However, running "tcpdump -n -e -ttt -i pflog0" I noticed these block
messages being logged when I click "discover/refresh" in simple-scan:
...
Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 >
192.168.178.255.8612: udp 16 Jul 04 11:23:44.601051 rule 2/(match) block in on 
em0:
192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:44.615516 rule
2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 
Jul 04
11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 >
192.168.178.255.8610: udp 16 Jul 04 11:23:45.147239 rule 2/(match) block in on 
em0:
192.168.178.11.9609 > 255.255.255.255.3289: udp 15 [ttl 1] Jul 04 
11:23:46.155868
rule 2/(match) block in on em0: 192.168.178.11.39413 > 255.255.255.255.1124: 
udp 37


I am guessing you didn't flush the rules after disabling pf since
clearly pf rules are still being used. Run pfctl -F all after disabling
pf. Run pfctl -s all to verify there are no active rules.

Re: Block network access completely for certain programs

[Kapetanakis Giannis]

On 04/07/2023 16:08, r...@danwin1210.de wrote:

How do I block the network access completely for a certain program with a
blacklist or whitelist, whitelist prefered, with OpenBSD's pf(4)? My pdf
reader, music player, video player, vim and much more shouldnt have access
to networking at all. I remember it being possible with the Windows
firewall program to choose a certain program to be completely
networking-less. Is this possible with OpenBSD too? I couldnt find
anything in the man pages or in the FAQ regarding this issue.


pf.conf(5) has option for user

    user user
 This rule only applies to packets of sockets owned by the
 specified user.  For outgoing connections initiated from the
 firewall, this is the user that opened the connection.  For
 incoming connections to the firewall itself, this is the user
 that listens on the destination port.
...


G

Re: Block network access completely for certain programs

[prx]

You may use a different rdomain?

Le 4 juillet 2023 15:08:35 GMT+02:00, r...@danwin1210.de a écrit :
>How do I block the network access completely for a certain program with a
>blacklist or whitelist, whitelist prefered, with OpenBSD's pf(4)? My pdf
>reader, music player, video player, vim and much more shouldnt have access
>to networking at all. I remember it being possible with the Windows
>firewall program to choose a certain program to be completely
>networking-less. Is this possible with OpenBSD too? I couldnt find
>anything in the man pages or in the FAQ regarding this issue.
>

Re: Data source of record.bytes in audioctl

[Alexandre Ratchov]

On Mon, Jul 03, 2023 at 05:18:13PM -0400, Ricky Cintron wrote:
> While troubleshooting some audio issues, I noticed that the values of
> play.bytes and record.bytes in audioctl's output were identical, even
> when only playing audio.
> 
> 1) Is this expected behavior?

yes, by default the device always does DMA in both directions
(synchronously), so record.bytes increases like play.bytes

> 2) What is the source of this data (record.bytes)?
> 

The source is the audio hardware interrupts. The audio(4) driver
handles them and increments its couter. The counter is readable by
userland with the AUDIO_GETPOS ioctl.

> I found it interesting that the values were the same, so I took a look
> at mixerctl, and noticed that 'line' (which is an output) and 'mix'
> (which has line as its only source) were the sources for both
> record.adc variables. At that point I figured that simply removing
> all sources from those two variables would eliminate all audio data
> from those recording channels, but record.bytes continued to match
> play.bytes. I even attempted to mute both ADCs and to disable recording
> in mixerctl (without rebooting), but nothing changed.
> 
> I'm probably going to remove 'line' and 'mix' as sources for the ADCs
> because they don't make sense there, but I'm still hoping to understand
> what's going on.
>

The mixer is a completely different thing and is completely
independent from DMA. It is supposed to control the analog
knobs/selectors, jack sensors, and alike.

Setting the record level to 0 (or removing all sources) would make the
ADC sample silence and produce zeros without affecting how it
works. That's why record.bytes still increases.

> # mixerctl -v
> inputs.dac-2:3=126,126
> inputs.dac-0:1=126,126
> record.adc-0:1_mute=off  [ off on ]
> record.adc-0:1=124,124
> record.adc-2:3_mute=off  [ off on ]
> record.adc-2:3=124,124
> inputs.mix_source=line  { line }
> inputs.mix_line=120,120
> inputs.mix2_source=dac-2:3  { dac-2:3 mix }
> inputs.mix3_source=dac-0:1  { dac-0:1 mix }
> outputs.spkr_source=mix2  [ mix2 ]
> outputs.spkr_mute=on  [ off on ]
> outputs.spkr_eapd=on  [ off on ]
> outputs.line_source=mix3  [ mix2 mix3 ]
> outputs.line_mute=off  [ off on ]
> inputs.line=85,85
> outputs.line_dir=output  [ none output input input-vr0 input-vr50 input-vr80
> input-vr100 ]
> outputs.line_boost=off  [ off on ]
> outputs.line_eapd=on  [ off on ]
> outputs.hp_source=mix2  [ mix2 mix3 ]
> outputs.hp_mute=off  [ off on ]
> outputs.hp_boost=off  [ off on ]
> outputs.hp_eapd=on  [ off on ]
> record.adc-2:3_source=line,mix  { line mix }
> record.adc-0:1_source=line,mix  { line mix }
> outputs.line_sense=plugged  [ unplugged plugged ]
> outputs.hp_sense=unplugged  [ unplugged plugged ]
> outputs.spkr_muters=line,hp  { line hp }
> outputs.master=126,126
> outputs.master.mute=off  [ off on ]
> outputs.master.slaves=dac-2:3,dac-0:1,spkr,line,hp  { dac-2:3 dac-0:1 spkr
> line hp }
> record.volume=124,124
> record.volume.mute=off  [ off on ]
> record.volume.slaves=adc-0:1,adc-2:3  { adc-0:1 adc-2:3 line }
> record.enable=sysctl  [ off on sysctl ]
> 
> 

Re: Block network access completely for certain programs

[Zack Newman]

On 7/4/23 13:08, rat1 wrote:


How do I block the network access completely for a certain program with a
blacklist or whitelist, whitelist prefered, with OpenBSD's pf(4)? My pdf
reader, music player, video player, vim and much more shouldnt have access
to networking at all. I remember it being possible with the Windows
firewall program to choose a certain program to be completely
networking-less. Is this possible with OpenBSD too? I couldnt find
anything in the man pages or in the FAQ regarding this issue.


pf(4) is primarily an IP-based filter. You are looking for a filter
that applies at the application level which will likely require a
program from ports. You might be able to achieve what you want with
pf by having multiple rdomain(4)s, use pf to block traffic based on
rdomain, and execute programs by routing them to use the corresponding
rtable(4); but that is almost certainly not what you want.

Re: dhcpleased[59824]: sendto: Permission denied

[Zack Newman]

On 7/3/23 21:14, Mark wrote:

I really do remember, under FreeBSD, I was having a similar "dmesg -a"
output

telling about DHCP's permission denied issue, and finally

I solved it with a pass rule like:

"pass log quick on $ext_if proto udp from any to any port = 67 keep state"

in /usr/local/etc/pf.conf file.


Well unfortunately memories are rather unreliable. Additionally, people
often times come to incorrect conclusions. For starters even if that
rule mattered, you should at least have "out" specified since that rule
is only trying to handle traffic sent to the DHCP server. Two, there
should be a corresponding rule for ingress traffic sent to the DHCP
client. Three, "keep state" is irrelevant since the traffic is sent to
255.255.255.255:67, but the response is sent from a DHCP server or relay
server that most certainly doesn't have the IP 255.255.255.255; thus the
state entry is pointless. It's one thing to rely on the default behavior
(i.e., "keep state"), but to explicitly add that is at the very least
bizarre.


And reading DHCP traffic never makes its way to pf,

surprised me. Perhaps that's valid only on OpenBSD but not on FreeBSD?

Anyways..


It probably surprises many, but it has been that way for a while.
Besides my "proof" that such rules are irrelevant, you can and even
should read more. There was even a recent thread on @misc where someone
inquired why there are DHCP-based rules in rc(8) when such rules don't
matter, and Theo de Raadt explained the historical reason for it.

I also doubt that it's "valid only on OpenBSD but not FreeBSD" despite
what you (mis)remember, but I am not interested enough to spend time
installing FreeBSD just to prove this. I spent a minute searching, and
dhclient(8) 
(https://man.freebsd.org/cgi/man.cgi?query=dhclient=8=html)
explicitly talks about BPF, and this very old thread
(https://lists.freebsd.org/pipermail/freebsd-ipfw/2005-April/001756.html)
is about someone not able to block DHCP traffic with ipfw(8) where the
reason given was "dhcpd uses BPF directly (like tcpdump)". I realize
that thread is very old, concerns dhcpd instead of dhclient, and the
individual uses ipfw instead of pf; but those two references in
addition to your dubious rule are enough for me to maintain my
skepticism.

Block network access completely for certain programs

[rat1]

How do I block the network access completely for a certain program with a
blacklist or whitelist, whitelist prefered, with OpenBSD's pf(4)? My pdf
reader, music player, video player, vim and much more shouldnt have access
to networking at all. I remember it being possible with the Windows
firewall program to choose a certain program to be completely
networking-less. Is this possible with OpenBSD too? I couldnt find
anything in the man pages or in the FAQ regarding this issue.

Question regarding pf rules: block in on em0: ...

[Why 42? The lists account.]

Hi All,

I just noticed that "simple-scan" no longer discovers my scanner.

While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen.

However, running "tcpdump -n -e -ttt -i pflog0" I noticed these block
messages being logged when I click "discover/refresh" in simple-scan:
...
Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 
255.255.255.255.3289: udp 15 [ttl 1]
Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 
255.255.255.255.1124: udp 37 [ttl 1]
...

192.168.178.11 is my OpenBSD desktop.

I don't understand what I'm seeing here ...

why am I seeing traffic coming _in_ from my own address? Is that not
slightly weird? Is it because it is _to_ the .255 broadcast address?

And why is it being blocked? Do I have explicitly allow broadcast traffic
e.g. with rules to handle broadcast addresses? I don't think I ever
considered doing that before ...

Grateful for any advice!

Yours,
Puzzled in PF-Land


FYI:
This is with a 7.3 snapshot: 7.3 GENERIC.MP#1268 amd64

Output of ifconfig:
4.07 11:23:51 # ifconfig em0
em0: 
flags=a48843
 mtu 1492
lladdr 94:c6:91:aa:16:67
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::96c6:91ff:feaa:1667%em0 prefixlen 64 scopeid 0x1
inet 192.168.178.11 netmask 0xff00 broadcast 192.168.178.255
inet6 2003:ee:1718:b100:39e3:3c67:bd3c:44f4 prefixlen 64 deprecated 
autoconf pltime 0 vltime 5213
inet6 2003:ee:1718:b100:3470:4349:f8d0:e1d2 prefixlen 64 deprecated 
autoconf temporary pltime 0 vltime 5213

Not sure what that "deprecated" means here.

Rule @2 is the "classic" block all rule ...

The contents of pf.conf:
#   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo
set block-policy return
set debug warning

# By default, do not permit remote connections to X11
#block return in log on ! lo0 proto tcp to port 6000:6010
block log on ! lo0 all  # Begin by blocking everything

# Port build user does not need network
block return out log proto {tcp udp} user _pbuild

# Allow all outbound
pass out quick modulate state

# Local subnet ...
local_subnet_v4="{ 192.168.178.0/24 }"

local_subnet_v6="{ fe80::/10 }"
# TODO: Correct ???

# Local systems that I might trust ...
trusted_clients_v4="{ 192.168.178.10, 192.168.178.12, 192.168.178.13, 
192.168.178.14 }"

# Allow ssh in
pass in log inet proto tcp from $trusted_clients_v4 to (egress) port ssh 
modulate state

# Scanner discovery? Allow traffic from Canon pixma TR8550
#scanner_ports="{ 8610, 8612 }"
#passlog inet  proto udp from 192.168.178.85 port $scanner_ports
pass in log inet proto udp from 192.168.178.85 port 8610
pass in log inet proto udp from 192.168.178.85 port 8612
#
# Allow avahi? See: /usr/local/share/doc/pkg-readmes/avahi
pass in log inet  proto udp from any to 224.0.0.251 port mdns allow-opts
pass in log inet6 proto udp from any to ff02::fb port mdns allow-opts
# and for SSDP:
pass in log inet  proto udp from any to 239.255.255.250 port ssdp allow-opts
pass in log inet6 proto udp from any to { ff02::c, ff05::c, ff08::c } port ssdp 
allow-opts
#
# OK, then try allowing multicast in general ...
pass log inet  proto igmp from any allow-opts

# NFS: Allow access to local NFS server
nfs_ports="{ sunrpc, nfsd, 881 }"
#
# But is UDP really still necessary?
#pass in proto udp from $trusted_clients to (egress) port $nfs_ports keep state
#pass out proto udp from (egress) to $trusted_clients port $nfs_ports keep state
#
pass in proto tcp from $trusted_clients_v4 to (egress) port $nfs_ports modulate 
state
pass in proto tcp from (egress) to $trusted_clients_v4 port $nfs_ports modulate 
state

# ICMP: Limit ICMP to allowed types: echorep, unreach, squench, echoreq, timex:
icmp_types = "{ echoreq, echorep, unreach, squench, timex }"
# See also: "man 4 icmp"
pass in log inet proto icmp to (egress) icmp-type $icmp_types label "rule $nr: 
pass: $proto: $icmp_type"

# HTTP: Running http-file-server:
# PORT= bin/http-file-server -u ~/Public/
# 2020/07/13 16:11:35 serving local path "/space/home/robb/Public" on "/Public/"
# 2020/07/13 16:11:35 redirecting to "/Public/" from "/"
# 2020/07/13 16:11:35 http-file-server listening on ":"
fs_port="{  }"
pass in proto tcp from $trusted_clients_v4 to (egress) 

Re: APCI on old Thinkpad

[Michael Hekeler]

Am 03.07.23 22:45 schrieb Claudio Jeker:
> Also keep in mind that laptops that old most often had bad or broken early
> ACPI implementations and it was better to not enable ACPI on those.
> Normally there was some BIOS knob to just use apm(4) which often worked
> much better.

Ah - very interesting. I will have a look...

Re: APCI on old Thinkpad

[Michael Hekeler]

> Jul 3, 2023 14:47:57 Peter N. M. Hansteen :
> 
> 
> I had to look this up, since I had forgotten that Thinkpads used to come
> with model numbers not prefixed and/or postfixed with letters.
> 
> I think one of several issues you will bump into is that the machine is
> almost a quarter century old (released April 1999 if Wikipedia is to be 
> trusted),
> and you may be one of fairly few people who have kept one around this long.

indeed this device is very old 
...and I am aware that it has many issues ;-)

I did run OpenBSD on that thing for a very long time and I was always happy
with it but that was starting maybe 5.x or something (I think there was
a ghostbusters like CD Box).

A while ago my small Netbook broke and I had to buy a new thinkpad . But
this new one is so heavy that I desperately remebered my old slim and
low weigth thinkpad 570.


> > This means in practice that in all likelihood, recent versions of any 
> > now-useful
> > software has been only lightly tested (if at all) on that vintage hardware.

I thought about reading emails with mutt(1).

Re: OpenBSD 7.3 and some old IA32 CPUs

[Scott Cheloha]

> On Jun 28, 2023, at 13:26, Anton Borisov  wrote:
> 
> Hi all,
> 
> here's sysctl extracts from Rise iDragon, IDT WinChip C6/2A running
> OpenBSD 7.3. All seems quite stable.

Interesting.  Can you post a full dmesg for each of these?

Re: unwind[92074]: bad packet: too large?

[Florian Obser]

On 2023-07-04 00:17 +03, Mark  wrote:
> Hi there.
>
> I'm getting this one in daemon/messages log files:
>
> Jul  3 20:52:53 unwind[92074]: bad packet: too large: 65552 -
> 1.0.0.127.bl.blocklist.de. IN A
> Jul  3 20:52:53 last message repeated 4 times
>
> What does that mean?

The nameservers for blocklist.de could not be reached.

>
> This is my mail server and Rspamd running behind, should I worry about
> unwind's message above?

No, this has been fixed in -current. It was an issue with error
reporting. Unwind works correctly in this case.

>
> Best.

-- 
In my defence, I have been left unsupervised.