Update groups

[Kevin Williams]

> 0 
> C USA
> P Oregon
> T Portland
> F 3rd Thursday, 7pm
> O BSD Pizza Night (group)
> U https://bsd.pizza
> N *BSD

New groups

[Kevin Williams]

0 
C USA
P Oregon
T Portland
F 3rd Thursday, 7pm
O BSD Pizza Night (group)
U https://bsd.pizza 
N *BSD

BSD meetup event

[Kevin Williams]

Not sure if we need to be listed as an official BSD User Group on openbsd.org 
before posting this.

If you're in or visiting Portland Oregon (United States) on Thursday June 29th, 
come join a handful of us for BSD Pizza Night at 7pm at the location linked 
here. https://calagator.org/events/1250480574

Re: error when pkg_add'ing

[Pau A.S.]

thanks so much, Marcus; pkg_check helped to identify a LOT of corrupted
files, which I deleted; after that I ran pkg_add -vu and it looks that one
file survived:


usr/local/share/glib-2.0/schemas/org.gnome.totem.enums.xml:1:1  Error on
line 1 char 1: Document must begin with an element (e.g. ).  This
entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.online-accounts.gschema.xml:1:1
 Error on line 1 char 1: Document must begin with an element (e.g.
).  This entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.totem.gschema.xml:1:1  Error on
line 1 char 1: Document must begin with an element (e.g. ).  This
entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.totem.plugins.opensubtitles.gschema.xml:1:1
 Error on line 1 char 1: Document must begin with an element (e.g.
).  This entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.totem.plugins.pythonconsole.gschema.xml:1:1
 Error on line 1 char 1: Document must begin with an element (e.g.
).  This entire file has been ignored.


 |100%Could not
parse file "/usr/local/share/applications/org.gnome.Adwaita1.Demo.desktop":
Key file contains line recode.mo??
WebKitGTK-4.1.mo???eog.mo?vlc.mo??
  ??gimp30-libgimp.mo which is not a key-value pair, group,
or comment
Could not parse file
"/usr/local/share/applications/org.gnome.RestDemo.desktop": Key file
contains line
?S7_S2_ZN6Window8MainMenuC1EP7QWidgetN3gsl8not_nullIPNS8_17SessionController3$_8ZNS0_orIS7_S2_NS0_29combine_implementation_helperIJNS_?
which is not a key-value pair, group, or comment
-

I will sysupgrade now and re-run pkg_check and pkg_add -vu

thanks again

Missatge de Marcus MERIGHI  del dia ds., 24 de juny
2023 a les 13:52:

> Hello Pau,
>
> lamarededeusen...@googlemail.com (Pau A.S.), 2023.06.24 (Sat) 12:16
> (CEST):
>
> [...]
>
> > In any case, I noticed that when running pkg_add I was finding some
> strange
> > error messages such as:
> >
> > 
> > # pkg_add -u firefox
> > quirks-6.133 signed on 2023-06-23T22:56:27Z
> > No pkgname in packing-list for totem-pl-parser-3.26.6p1
> > No pkgname in packing-list for gom-0.4p1
> > No pkgname in packing-list for libdmapsharing4-3.9.12p0
> > No pkgname in packing-list for libadwaita-1.3.2p0v0
> > No pkgname in packing-list for gnome-online-accounts-3.48.0p0
> > No pkgname in packing-list for libmediaart-1.9.6p0
> > No pkgname in packing-list for uchardet-0.0.8
> > No pkgname in packing-list for grilo-0.3.16
> > No pkgname in packing-list for liboauth-1.0.3
> > quirks-6.133->6.133: ok
> > Can't install python-3.10.12 because of libraries
> > |library util.17.0 not found
> > | /usr/lib/libutil.so.16.0 (system): bad major
>
> For reference, I have, on a machine upgraded to current -current 12
> hours ago:
>
> $ ls -la /usr/lib/libutil.so.*
> -r--r--r--  1 root  bin  222672 Jun 16 16:11 /usr/lib/libutil.so.16.0
> -r--r--r--  1 root  bin  240048 Jun 23 16:51 /usr/lib/libutil.so.17.0
>
> If I were you I'd do a sysupgrade(8) and retry "pkg_add(1) -u"
> afterwards. I'd run pkg_check(8) too, just to be sure.
>
> Marcus
>

Re: Weird pf NAT failure on apu2

[Zack Newman]

On 6/2l/23 9:01, Stephan Neuhaus wrote:

I'm not sure about the Configuring NAT section being
correct. I still maintain that the documentation and
observed behaviour are different.


I was lazy when I said that. I meant the example I quoted from that
section in the original reply is correct. Everything else that says
otherwise (including the two people that said that part was wrong) is
incorrect. Explicitly the following rule _is_ correct:

match out on interface [af] \
from src_addr to dst_addr \
nat-to ext_addr [pool_type] [static-port]
[...]
pass out [log] on interface [af] [proto protocol] \
from ext_addr [port src_port] \
to dst_addr [port dst_port]

There is only so many ways that this can be shown. If the pass out rule
had "src_addr" instead of "ext_addr", it would be wrong. The diff that
"fixes" that example needs to be rejected. It is the _other_ example
that is wrong.

If you tried using the above example to get NAT to work, you will find
that it will work. The last e-mail I sent clearly follows the above
example except I chose to use stateless rules to help show more
thoroughly all the rules that are necessary. Additionally, I prefer
"quick" rules; but the conclusion is very clear: the match out rule
applies and "sticks" which in turn means "src_addr" is replaced with
"ext_addr" which in turn means the pass out rule must have "ext_addr".

Re: error when pkg_add'ing

[Marcus MERIGHI]

Hello Pau, 

lamarededeusen...@googlemail.com (Pau A.S.), 2023.06.24 (Sat) 12:16 (CEST):

[...]

> In any case, I noticed that when running pkg_add I was finding some strange
> error messages such as:
> 
> 
> # pkg_add -u firefox
> quirks-6.133 signed on 2023-06-23T22:56:27Z
> No pkgname in packing-list for totem-pl-parser-3.26.6p1
> No pkgname in packing-list for gom-0.4p1
> No pkgname in packing-list for libdmapsharing4-3.9.12p0
> No pkgname in packing-list for libadwaita-1.3.2p0v0
> No pkgname in packing-list for gnome-online-accounts-3.48.0p0
> No pkgname in packing-list for libmediaart-1.9.6p0
> No pkgname in packing-list for uchardet-0.0.8
> No pkgname in packing-list for grilo-0.3.16
> No pkgname in packing-list for liboauth-1.0.3
> quirks-6.133->6.133: ok
> Can't install python-3.10.12 because of libraries
> |library util.17.0 not found
> | /usr/lib/libutil.so.16.0 (system): bad major

For reference, I have, on a machine upgraded to current -current 12
hours ago:

$ ls -la /usr/lib/libutil.so.*
-r--r--r--  1 root  bin  222672 Jun 16 16:11 /usr/lib/libutil.so.16.0
-r--r--r--  1 root  bin  240048 Jun 23 16:51 /usr/lib/libutil.so.17.0

If I were you I'd do a sysupgrade(8) and retry "pkg_add(1) -u"
afterwards. I'd run pkg_check(8) too, just to be sure.

Marcus

Re: Weird pf NAT failure on apu2

[Stuart Henderson]

On 2023-06-24, Stephan Neuhaus  wrote:
> Hi Zack
>
> On 6/24/23 03:39, Zack Newman wrote:
>> There do appear to be contradictions in documentation as well as the pf
>> book. The Configuring NAT section is correct as you have seen with your
>> own rules.
>
> I'm not sure about the Configuring NAT section being
> correct. I still maintain that the documentation and
> observed behaviour are different.

The pf.conf(5) manual page is the best documentation for PF and that
is expected to be correct.

The pf faq could well be wrong, it's not really had a full
review/update/rewrite since before nat-to was introduced - a relatively
light conversion to the "new" syntax and mostly smaller changes -
no integration of new features in the existing text e.g. the very
useful tag/tagged is relegated to an added on "advanced features"
section).

> I now have the following small ruleset. The rules for
> ports 22 and 53 are just so that I can do my
> experiments over ssh. (Port 53 may not be necessary
> but the blocked packets mess up my logs.) The em0

You can always follow a general "block log" with a "block on port XX"
if you want to log most blocked psckets except for certain ones.

> interface has the IPv4 address 192.168.0.2.
>
> set skip on lo
>
> block log all
>
> pass in on em0 proto tcp to any port 22
> pass out on em0 proto tcp from any port 22
> pass on em0 proto udp from any port 53
> pass on em0 proto udp to any port 53

This allows someone on the internet to bypass your filter rules and
send UDP traffic to any port by simply setting the source port to 53.

Just have "to port 53", reply ("from port 53") packets will match
the state created by the packet that was passed by the "to port 53"
rule.

(You would have the same with TCP except for the direction on the
rule; still "pass out proto tcp from port 22" is probably not quite
what you want).

> I now think that either the documentation is wrong, or
> pf is wrong.  At any rate, there seems to be a rather
> serious disconnect between the two. The FAQ clearly
> says:
>
> When a packet is selected by a match rule, parameters (e.g. nat-to) in 
> that rule are remembered and are applied to the packet when a pass rule 
> matching the packet is reached.

Yes that's wrong. Address changes take effect at the time the match rule
is processed when traversing the ruleset; rules processed later "see"
the rewritten address. As pf.conf(5) says,


   Translation
 Translation options modify either the source or destination address
 and port of the packets associated with a stateful connection.  pf(4)
 modifies the specified address and/or port in the packet and
 recalculates IP, TCP, and UDP checksums as necessary.

 If specified on a match rule, subsequent rules will see packets as
 they look after any addresses and ports have been translated.  These
 rules will therefore have to filter based on the translated address
 and port number.


> I know that the documentation (at this time) ALSO
> says:
>
> match out on interface [af] \
> from src_addr to dst_addr \
> nat-to ext_addr [pool_type] [static-port]
> [...]
> pass out [log] on interface [af] [proto protocol] \
> from ext_addr [port src_port] \
> to dst_addr [port dst_port]
>
> where the pass rule has ext_addr instead of src_addr,
> but at least two people on t...@openbsd.org have
> confirmed that this is a bug and have already
> submitted a diff that replaces ext_addr with src_addr
> in the pass rule, see 
> https://marc.info/?l=openbsd-tech=168714686620055=2

I think that this bit _is_ correct as written, although it's not
particularly useful as it doesn't allow passing just the specific
translated packets.

I think it's the example rules which are wrong, i.e.

match out on tl0 from 192.168.1.0/24 to any nat-to 198.51.100.1
pass on tl0 from 192.168.1.0/24 to any

directly fixing this would be

match out on tl0 from 192.168.1.0/24 to any nat-to 198.51.100.1
pass on tl0 from 198.51.100.1 to any

however this would be a good place to instead show how to use
match...nat-to...tag and pass...tagged, maybe also received-on. Then a)
it's clear what traffic is passed and b) that fits better with the very
common use-case where the external (nat-rewritten) address is dynamic so
you need to use an interface name with parentheses in the nat-to rule.

But when you pull at that thread, the current structure of the pf faq
section starts to unravel, i.e. it doesn't make sense to separate tags
into "advanced", there's a fair bit of information which really isn't
useful at the faq level (flag matching? the bit about using "block
return" instead of a set of 6 different block rules that nobody learning
from the faq would have thought of writing? syn proxy, esoteric scrub
rules, being originally written from a point-of-view of "keep state"
being a special thing and tweaked from that to the current state, ...)
and it becomes a fairly big authoring job.

> Should I be taking this to another mailing 

error when pkg_add'ing

[Pau A.S.]

Dear all,

I recently reported what I thought it was a FS corruption because the
system (-current) was crashing when I was setting a picture or movie on
full screen. For some reason, the fix is to use xcompmgr in .xsession.

This is

# uname -a
OpenBSD aemonius.localhost 7.3 GENERIC.MP#1246 amd64

In any case, I noticed that when running pkg_add I was finding some strange
error messages such as:


# pkg_add -u firefox
quirks-6.133 signed on 2023-06-23T22:56:27Z
No pkgname in packing-list for totem-pl-parser-3.26.6p1
No pkgname in packing-list for gom-0.4p1
No pkgname in packing-list for libdmapsharing4-3.9.12p0
No pkgname in packing-list for libadwaita-1.3.2p0v0
No pkgname in packing-list for gnome-online-accounts-3.48.0p0
No pkgname in packing-list for libmediaart-1.9.6p0
No pkgname in packing-list for uchardet-0.0.8
No pkgname in packing-list for grilo-0.3.16
No pkgname in packing-list for liboauth-1.0.3
quirks-6.133->6.133: ok
Can't install python-3.10.12 because of libraries
|library util.17.0 not found
| /usr/lib/libutil.so.16.0 (system): bad major
Direct dependencies for python-3.10.11p0->3.10.12 resolve to
gettext-runtime-0.21.1 bzip2-1.0.8p0 xz-5.4.3 sqlite3-3.41.2p0 libffi-3.4.4
Full dependency tree is libffi-3.4.4 sqlite3-3.41.2p0 libiconv-1.17
xz-5.4.3 gettext-runtime-0.21.1 bzip2-1.0.8p0
firefox-114.0.2:glib2-2.76.3->2.76.3: ok
firefox-114.0.1p0->114.0.2: ok
Running
tags|*
  |
75%/usr/local/share/glib-2.0/schemas/org.gnome.totem.enums.xml:1:1  Error
on line 1 char 1: Document must begin with an element (e.g. ).  This
entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.online-accounts.gschema.xml:1:1
 Error on line 1 char 1: Document must begin with an element (e.g.
).  This entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.totem.gschema.xml:1:1  Error on
line 1 char 1: Document must begin with an element (e.g. ).  This
entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.totem.plugins.opensubtitles.gschema.xml:1:1
 Error on line 1 char 1: Document must begin with an element (e.g.
).  This entire file has been ignored.
/usr/local/share/glib-2.0/schemas/org.gnome.totem.plugins.pythonconsole.gschema.xml:1:1
 Error on line 1 char 1: Document must begin with an element (e.g.
).  This entire file has been ignored.


***|100%Could not parse file
"/usr/local/share/applications/org.gnome.Adwaita1.Demo.desktop": Key file
contains line recode.mo??
WebKitGTK-4.1.mo??eog.mo?vlc.mo??
 ??gimp30-libgimp.mo which is not a key-value pair,
group, or comment
Could not parse file
"/usr/local/share/applications/org.gnome.RestDemo.desktop": Key file
contains line
?S7_S2_ZN6Window8MainMenuC1EP7QWidgetN3gsl8not_nullIPNS8_17SessionController3$_8ZNS0_orIS7_S2_NS0_29combine_implementation_helperIJNS_?
which is not a key-value pair, group, or comment
===

There seems to be some corruption in that file:

-
# cat /usr/local/share/applications/org.gnome.Adwaita1.Demo.desktop
�   recode.mo�WebKitGTK-4.1.mo�eog.mo�vlc.mo
gimp30-libgimp.mo
xfce4-panel.mo
�#
--

This happens with many other packages, not only when I try to update
firefox.

I have been seeing a lot of crashes of other programs.

Because of the original problem I mentioned, I thought I had a FS
corruption problem in /local/usr.

What I did then was to copy the contents of /local/usr somewhere else, I
ran newfs on it by booting as a single user and restored the contents. This
didn't fix the error, so it is not a FS problem.

I have checked in /var/log/messages but there is no log there.

What could I do to provide you with more information?

This is my dmesg. Thanks in advance.

OpenBSD 7.3-current (GENERIC.MP) #1246: Fri Jun 16 23:57:46 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16856313856 (16075MB)
avail mem = 16325787648 (15569MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x900a2000 (80 entries)
bios0: vendor LENOVO version "R1UET33W (1.10 )" date 10/27/2022
bios0: LENOVO 21B3000KSP
efi0 at bios0: UEFI 2.7
efi0: Lenovo rev 0x1100
acpi0 at bios0: ACPI 6.3
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT
SSDT SSDT SSDT SSDT LPIT WSMT SSDT DBGP DBG2 NHLT MSDM SSDT BATB DMAR SSDT
SSDT SSDT BGRT PHAT UEFI FPDT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) 

Re: Weird pf NAT failure on apu2

[Stephan Neuhaus]

Hi Zack

On 6/24/23 03:39, Zack Newman wrote:

There do appear to be contradictions in documentation as well as the pf
book. The Configuring NAT section is correct as you have seen with your
own rules.


I'm not sure about the Configuring NAT section being
correct. I still maintain that the documentation and
observed behaviour are different.

I now have the following small ruleset. The rules for
ports 22 and 53 are just so that I can do my
experiments over ssh. (Port 53 may not be necessary
but the blocked packets mess up my logs.) The em0
interface has the IPv4 address 192.168.0.2.

set skip on lo

block log all

pass in on em0 proto tcp to any port 22
pass out on em0 proto tcp from any port 22
pass on em0 proto udp from any port 53
pass on em0 proto udp to any port 53

pass in on athn0

match out log on em0 from athn0:network to any nat-to (em0)

#pass out log on em0 from athn0:network to any
pass out log on em0 from 192.168.0.2 to any

This causes packets from athn0 to pass and to be
correctly NATed. If I uncomment the penultimate line
and comment out the last line, the packets get matched
(as before), but then blocked by the catch-all rule 0.
This is consistent with the nat-to being applied
immediately after the match rule matches, EXCEPT that
the blocked packet is logged with a source address
inside athn0:network (192.168.3.0/24 in this case) and
not the NATed-to 192.168.0.2. For example:

Jun 24 10:24:46.498327 rule 0/(match) block out on em0: 
192.168.3.32.54459 > 172.217.168.68.443: S 2479117865:2479117865(0) win 
65535  (DF)


I now think that either the documentation is wrong, or
pf is wrong.  At any rate, there seems to be a rather
serious disconnect between the two. The FAQ clearly
says:

When a packet is selected by a match rule, parameters (e.g. nat-to) in 
that rule are remembered and are applied to the packet when a pass rule 
matching the packet is reached.


This seems to me to imply that the nat-to in my match
rule should not be applied BEFORE the pass rule is
attempted, but only AFTER. This seems also to be the
point of these lines in the documentation:

match
When a packet traverses the ruleset and matches a match rule, any 
optional parameters specified in that rule are remembered for future use 
(made "sticky").


pass
This rule allows the packet to be transmitted. If the packet was 
previously matched by a match rule where parameters were specified, they 
will be applied to this packet. [...]


I know that the documentation (at this time) ALSO
says:

match out on interface [af] \
   from src_addr to dst_addr \
   nat-to ext_addr [pool_type] [static-port]
[...]
pass out [log] on interface [af] [proto protocol] \
   from ext_addr [port src_port] \
   to dst_addr [port dst_port]

where the pass rule has ext_addr instead of src_addr,
but at least two people on t...@openbsd.org have
confirmed that this is a bug and have already
submitted a diff that replaces ext_addr with src_addr
in the pass rule, see 
https://marc.info/?l=openbsd-tech=168714686620055=2


Should I be taking this to another mailing list?
Should I be submitting a bug report? Or am I just
really really dense and am just too stupid to read the
documentation correctly?

Cheers

Stephan