Re: Weird pf NAT failure on apu2
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. Here is the minimum set of stateless rules that allows ICMP traffic between my laptop and Cloudflare. # Options. set block-policy drop # Macros. wan = em0 wifi = vlan4 external = 76.154.165.21 laptop = 192.168.6.2 cflare = 1.1.1.1 # NAT. match out on $wan inet proto icmp from $laptop nat-to $external static-port # Filtering rules. pass in quick on $wifi inet proto icmp from $laptop to $cflare no state pass out quick on $wan inet proto icmp from $external to $cflare keep state (if-bound) pass out quick on $wifi inet proto icmp from $cflare to $laptop no state block quick The second filter rule _must_ be stateful in order for the router to map the ICMP Query ID back to the original source IP (i.e., my laptop). When relying on only stateful rules, we can remove the last pass rule- since the first filter rule when hit will allow the returning Echo Response. If instead of using match rules for NAT, you use pass out; then pf will fail to load pf.conf(5) if the second rule is stateless: /etc/pf.conf:13: nat-to and rdr-to require keep state /etc/pf.conf:13: skipping rule due to errors /etc/pf.conf:13: rule expands to no valid combination pfctl: Syntax error in config file: pf rules not loaded If you want to easily distinguish traffic sourced from your router leaving em0 from traffic sourced from your (V)LAN devices, then you will need to have a separate rule. For example: pass out quick log on em0 inet from (em0) match out log on em0 inet from athn0:network nat-to (em0) pass out log quick on em0 inet
Re: veb and vport on apu2 -- config feedback
looks good to me after a quick read.
> On 23 Jun 2023, at 12:15, Amarendra Godbole
> wrote:
>
> I am planning to experiment with veb on my PC Engines apu2e4 board. It
> has three ports (em0, 1 and 2). Current configuration has em0 hooked
> up to cable modem, while em1 and em2 are internal LAN. I don't have a
> good ability to troubleshoot via a serial console, since the apu board
> sits in the garage on top of a cabinet -- running serial cable to a
> laptop is challenging, though not impossible. So I am looking for
> feedback so as to keep this troubleshooting time minimal.
>
> Any feedback is welcome. Configs below. Thanks in avance.
>
> -Amarendra
>
> $ cat hostname.em1
> mtu 9000
> up
>
> $ cat hostname.em2
> mtu 9000
> up
>
> $ cat hostname.veb0
> add em1
> add em2
> add vport0
> link0
> up
>
> $ cat hostname.vport0
> inet 192.168.1.1 255.255.255.0 192.168.1.255
> mtu 9000
> group internal
> up
>
> $ cat pf.conf
> ruckus= "192.168.1.10"
>
> table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
> 172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
> 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
> 203.0.113.0/24 }
>
> set block-policy drop
> set loginterface egress
> set skip on lo0
> match in all scrub (no-df random-id max-mss 1440)
>
> # spoof protection
> antispoof quick for egress
> block in from no-route
> block in quick from urpf-failed
>
> # block martians!
> block in quick on egress from to any
> block return out quick on egress from any to
>
> # default deny
> block all
>
> # allow icmp
> match in on egress inet proto icmp icmp-type { echoreq } tag ICMP_IN
> block drop in on egress proto icmp
> pass in proto icmp tagged ICMP_IN max-pkt-rate 100/10
> pass in on egress inet proto icmp icmp-type { 3 code 4, 11 code 0}
>
> pass out quick on egress inet from internal nat-to (egress)
> pass out quick inet
> pass in on internal inet
>
> # block dns queries that are not destined for our dns server.
> block return in quick on internal proto { udp tcp } to ! internal port
> { 53 853 }
>
> # block Ruckus AP from "phoning home"
> block in quick on internal from $ruckus
>
pkg_bundle - Create "relocatable" package bundles on OpenBSD
Hello there, I personally disliked when a large software package needed to spam my /usr/local with dependencies. At the same time I quite liked how Solaris had separate prefixes for different software collections (i.e /usr/sfw, /opt/csw, /usr/csw, etc). So as a compromise, I developed* pkg_bundle[1] which basically works with the existing OpenBSD compiled package infrastructure to fetch and apply "tweaks" to ensure packages can run when encapsulated within a simple directory that can be moved anywhere around the system. For example /opt/gimp, /home/kpedersen/libreoffice, etc. The following is a list of software currently tested because I regularly use them myself. - blender - chromium - dia - firefox - gcc, g++, gdb, gmake - gimp - git - libreoffice - vlc - wpa_supplicant However do note that only OpenBSD 7.3 is tested. When I get to 7.4 once it is released, it will likely require an additional set of tweaks. From past experiences, this tends to be fairly minor and I just do them as I encounter them day to day. The whole setup is fairly flexible to add new software as needed and can even work out of the box with many packages. Very few require patching of the binary (unveil/pledge, icu, blender, etc). Usage should be pretty simple (create bundle, copy to (i.e) /opt, run): $ pkg_bundle libreoffice # cp -RP libreoffice /opt/office $ /opt/office/libreoffice (You can also run bin/pkg_bundle straight out of its tarball, no installation needed). I perhaps don't recommend using this for *all* software. However you might want to consider it for some of the bigger packages that you only plan to use periodically. I hope someone might find this useful and would be very interested in hearing feedback. Not many people seem to take this approach. Personally I find it alleviates my general dislike of large software packages. Best regards, Karsten *I really just cleaned up a bunch of ratty scripts I had cobbled together over the years (probably from before 5.x). [1] https://github.com/osen/pkg_bundle
IP6 redirects through relayd no longer working reliably
Hi all
(Sorry for flooding, this seems related to the question I asked earlier.
Please bear with me.)
I am using relayd on 7.3-release as an IP loadbalancer in front of some
dualstack backend hosts. This setup has worked for some years now.
After upgrading to 7.3 about 4 weeks ago I noticed a steady decline of
IPv6 sessions coming into the backend servers, up to the point where
none arrive at all (for 2 days now).
Now users start complaining that their connections to the servers
(public IP) are either timing out or are established only after a very
long time (usually the tcp start timeout when the client switches from
IPv6 to trying IPv4). The IPv4 connections succeed immediately.
pflog shows that the IPv6 SYN-ACK replies from the backend servers are
being dropped by pf. But weirdly the blocks are logged over 30 seconds
after the SYN is allowed through:
Jun 20 14:12:49.489707 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50210 > [Server.IP6].443:
S 2508622700:2508622700(0) win 64800 <[|tcp]> [flowlabel 0xd4400] (len
32, hlim 52)
Jun 20 14:12:49.493267 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50211 > [Server.IP6].443:
S 806421981:806421981(0) win 64800 <[|tcp]> [flowlabel 0x162e5] (len 32,
hlim 52)
Jun 20 14:12:49.507508 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50212 > [Server.IP6].443:
S 3945655871:3945655871(0) win 64800 <[|tcp]> [flowlabel 0x8abc6] (len
32, hlim 52)
Jun 20 14:12:49.517783 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50213 > [Server.IP6].443: S 1191028748:1191028748(0)
win 64800 <[|tcp]> [flowlabel 0xa7d6] (len 32, hlim 52)
Jun 20 14:13:20.943370 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50213: S 3650589557:3650589557(0)
ack 209077342 win 64800 <[|tcp]> [flowlabel 0xd922c] (len 32, hlim 64)
Jun 20 14:13:20.943433 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50212: S 2068945110:2068945110(0)
ack 2313561433 win 64800 <[|tcp]> [flowlabel 0xf8c9c] (len 32, hlim 64)
Jun 20 14:13:20.943476 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50211: S 3395939328:3395939328(0)
ack 1849611325 win 64800 <[|tcp]> [flowlabel 0xb519e] (len 32, hlim 64)
Jun 20 14:13:20.943518 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50210: S 106368970:106368970(0)
ack 1534267447 win 64800 <[|tcp]> [flowlabel 0xca19a] (len 32, hlim 64)
(The rule 2 that is logged is the rule number of the relayd/* anchor.)
tcpdump on vlanX shows the backend server sends the SYN-ACK immediately.
The IPv4 addresses are natted from public to rfc-1918 space and work.
For IPv6, the address of backend server.A is used as the public IP
(service.pub). Only if server.A becomes unavailable, are packets
redirected to server.B.
relayd.conf:
...
table {
Server.A.IP6 retry 2
}
table {
Server.B.IP6 retry 2
}
redirect "service.pub.80.v6" {
listen on Server.A.IP6 tcp port 80 interface trunk0
forward to port 80 \
check http "/" host "server.A" code 200
forward to port 80 \
check http "/" host "server.B" code 200
}
redirect "service.pub.443.v6" {
listen on Server.A.IP6 tcp port 443 interface trunk0
forward to port 443 \
check https "/" host "server.A" code 200
forward to port 443 \
check https "/" host "server.B" code 200
}
I am not 100% sure that the IPv6 failover actually worked before, but
the connections to Server.A.IP6 were definitely working.
I do see the http and https checks succeed on both backend servers.
I've tried flushing the states and rebooting the firewall, to no avail.
relayctl shows all redirects/tables as active and all hosts as up:
2 redirectservice.pub.80.v6 active
3 table server.A:80active (1 hosts)
3 hostServer.A.IP6 100.00% up
4 table server.B:80active (1 hosts)
4 hostServer.B.IP6 100.00% up
3 redirectservice.pub.443.v6 active
5 table server.A:443 active (1 hosts)
5 hostServer.A.IP6 100.00% up
6 table server.B:443 active (1 hosts)
6 hostServer.B.IP6 100.00% up
Now I'm out of ideas on how to debug this further.
Has anyone been experiencing something similar?
Has something fundamental changed in relayd or pf that could cause this?
Does anybody spot an error in my configuration?
Thanks for any pointer!
Best regards
Markus
All packets logged with relayd/* anchor rule number
Hi all I am using relayd on 7.3-release as an incoming IP loadbalancer and therefore have this line near the beginning of the filter section of pf.conf: anchor "relayd/*" It shows up as rule number 2 in pfctl -vv -s rules: @0 match all scrub (no-df reassemble tcp) [ Evaluations: 89452 Packets: 545363Bytes: 161423157 States: 1772 ] [ Inserted: uid 0 pid 59061 State Creations: 0 ] @1 match out all scrub (random-id) [ Evaluations: 89452 Packets: 295160Bytes: 98671558 States: 921 ] [ Inserted: uid 0 pid 59061 State Creations: 0 ] @2 anchor "relayd/*" all [ Evaluations: 89452 Packets: 576068Bytes: 163171696 States: 1772 ] [ Inserted: uid 0 pid 59061 State Creations: 58739 ] But now all packets get logged with rule no. 2 in pflog, regardless of whether or not they match any relayd redirect. Here's an example of an outgoing natted NTP query, which has nothing whatsoever to do with the relayd rules/redirects: # tcpdump -e -vvv -ttt -n -i pflog0 port ntp Jun 23 20:07:56.377848 rule 2/(match) [uid 0, pid 59061] pass in on vlanX: 192.168.x.y.123 > a.b.c.d.123: v4 client strat 2 poll 10 prec -24 dist 0.006881 disp 0.034591 ref a.b.c.d@3896531217.384170621 orig 3896531389.381188988 [|ntp] (DF) [tos 0xb8] (ttl 64, id 1236, len 76) Jun 23 20:07:56.377928 rule 2/(match) [uid 0, pid 59061] pass out on trunk0: [rewritten: src n.m.p.o:55798, dst a.b.c.d:123] 192.168.x.y.123 > a.b.c.d.123: v4 client strat 2 poll 10 prec -24 dist 0.006881 disp 0.034591 ref a.b.c.d@3896531217.384170621 orig 3896531389.381188988 [|ntp] [tos 0xb8] (ttl 63, id 1236, len 76, bad ip cksum dd99! -> de99) Is this the expected behaviour? Is there any way to get the actual rule numbers back? I am quite sure this was different in earlier releases. Thank you in advance Markus
Re: Weird pf NAT failure on apu2
Just wanted to reply that that was an excellent rebuttal. Looks like I should have put my foot in my mouth. I am now keenly interested-and disappointed in my (lack) of knowledge. I will practice with pf on my machine to better understand what is happening. If/when I have something meaningful to say, I will send another e-mail. Thanks for the information.
Re: Weird pf NAT failure on apu2
On 6/23/23 18:29, Zack Newman wrote:
On 6/23/23 11:19, Stephan Neuhaus wrote:
# Rule 5
match out log on em0 from athn0:network to any nat-to (em0)
# Rule 6
pass out log on em0 from athn0:network to any
Rule 5 replaces the source IP address with the IP address assigned to
em0-as well as replaces the source port (for TCP and UDP) with an
ephemeral port. Rule 6 does _not_ pass traffic out of em0 from the IP
address assigned to em0 but instead passes traffic where the IP address
is from athn0:network, so of course it won't work.
Thanks for replying!
What you say may well be true, but if it is, it is in
conflict with the documentation and IMO the match/pass
combo is much less useful.
To make my first point, the pf FAQ says the following
about match/pass:
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. [...]
This makes it very clear (to me at least) that the
nat-to in the match rule is "remembered for
future use" in the match, and is applied to the packet
only when it is finally subject to a pass rule.
The FAQ also has the following example:
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
This is what I meant when I said that I took my code
"almost verbatim" from the FAQ.
Also, "The Book of pf", 3rd ed., has a similar match/pass combo on p.53:
match out on $ext_if inet from $localnet nat-to ($ext_if)
pass quick inet proto { tcp, udp } from $localnet to port $udp_services
(See how the "from" address in the pass rule is
$localnet, which would match the packet's original
source address, and not $(ext_if)?)
To make my second point, If the packet would
immediately change its effective source address to
that of the outgoing interface, it would for example
become very hard in later rules to distinguish between
NATed packets and packets originating on the firewall, at least in pass
out rules.
It would be a lot easier to just have a pass out rule and only filter
ingress traffic.
Agreed, but at this stage, I'm only trying to understand what's going on.
Is there anything you see in these rules, especially
in rules 5 and 6, that is not correct? I don't think
so, I've taken this almost verbatim from the pf FAQ
https://www.openbsd.org/faq/pf/nat.html.
You did not read that FAQ carefully enough, so I wouldn't say you
have followed it "almost verbatim". Under Configuring NAT, the example
shows
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]
Notice the pass out rule which states "from *ext_addr*" _not_ "from
src_addr".
Agreed! These very lines were the subject of a previous post of mine,
and two people from t...@openbsd.org said that it was a typo and that
the ext_addr in the pass rule should be changed to src_addr. See
https://marc.info/?l=openbsd-tech=168714686620055=2 Note also that
these lines are in conflict with the example that comes later in the
FAQ, and which I have quoted above.
You are also not specifying the IP version which you likely should since
you probably don't want to rely on NAT for IPv6. For example
match out log on em0 inet from athn0:network nat-to (em0)
pass out
Fair point, thanks.
Cheers
Stephan
Re: Weird pf NAT failure on apu2
On 6/23/23 11:19, Stephan Neuhaus wrote: # Rule 5 match out log on em0 from athn0:network to any nat-to (em0) # Rule 6 pass out log on em0 from athn0:network to any Rule 5 replaces the source IP address with the IP address assigned to em0-as well as replaces the source port (for TCP and UDP) with an ephemeral port. Rule 6 does _not_ pass traffic out of em0 from the IP address assigned to em0 but instead passes traffic where the IP address is from athn0:network, so of course it won't work. It would be a lot easier to just have a pass out rule and only filter ingress traffic. Is there anything you see in these rules, especially in rules 5 and 6, that is not correct? I don't think so, I've taken this almost verbatim from the pf FAQ https://www.openbsd.org/faq/pf/nat.html. You did not read that FAQ carefully enough, so I wouldn't say you have followed it "almost verbatim". Under Configuring NAT, the example shows 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] Notice the pass out rule which states "from *ext_addr*" _not_ "from src_addr". You are also not specifying the IP version which you likely should since you probably don't want to rely on NAT for IPv6. For example match out log on em0 inet from athn0:network nat-to (em0) pass out
Re: Weird pf NAT failure on apu2
On 6/23/23 13:19, Stephan Neuhaus wrote:
[...]
Some people have replied to this post off-list and
have made the entirely reasonable conjecture that the
packet changes its effective source address the moment
the match rule matches. With the changed source
address, the pass rule no longer matches. That is
entirely possible and agrees with all the experimental
evidence I have.
Still, I don't think that this is what's going on, for
the following reasons.
1. It is in conflict with the documentation. The FAQ
http://www.openbsd.org/faq/pf/nat.html says
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. [...]
This makes it very clear that the nat-to in the match
rule is only "remembered for future use", and is
applied to the packet only when it is finally subject
to a pass rule.
Similarly, "The Book of pf", 3rd ed., has a match/pass
combo on p.53 that goes
match out on $ext_if inet from $localnet nat-to ($ext_if)
pass quick inet proto { tcp, udp } from $localnet to port $udp_services
As you can see, the pass rule has the packet's
original source specification $localnet, not the
natted-to $(ext_if).
2. The match/pass combo would be much less useful. If
the packet would immediately change its effective
source address to that of the outgoing interface, it
would for example become very hard in later rules to
distinguish between NATed packets and packets
originating on the firewall.
Cheers
Stephan
Re: Weird pf NAT failure on apu2
On 6/23/23 13:19, Stephan Neuhaus wrote: Hi list [...] In other words, now the same packets that weren't passed using the match/pass combo are not passed when the nat-to is part of the pass rule. That should have been "...combo are NOW passed...". Sorry. Cheers Stephan
Weird pf NAT failure on apu2
Hi list I am using a PC Engines apu2 board as a firewall. Or rather, I want to use it as one, but it doesn't work as I think it should. First up, some information about my system. It has three gigabit wired Ethernet interfaces, em0, em1, and em2, as well as an 802.11n interface, athn0. Only em0 and athn0 will be relevant for this case. # uname -a OpenBSD my.host.name 7.3 GENERIC.MP#1125 amd64 # ifconfig em0 # I've zeroed out the lladdr em0: flags=8843 mtu 1500 lladdr 00:00:00:00:00:00 description: egress interface index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause) status: active inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 # ifconfig athn0 # I've zeroed out the lladdr, bssid and changed the nwid. athn0: flags=8843 mtu 1500 lladdr 00:00:00:00:00:00 description: wireless interface index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect mode 11n hostap status: active ieee80211: nwid mynw chan 56 bssid 00:00:00:00:00:00 -67dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 192.168.3.2 netmask 0xff00 broadcast 192.168.3.255 What I want to do is NAT the wireless interface to the egress interface. I have this experimental pf setup, which has many problems, and which therefore has a big comment at the top: # PF configuration file to test matching and NAT # # DO NOT USE IN PRODUCTION # set skip on lo block log all # Rule 0 pass in on em0 proto tcp to any port 22# Rule 1 pass out on em0 proto tcp from any port 22 # Rule 2 pass out on em0 proto udp to any port 53 # Rule 3 pass in on athn0 # Rule 4 # Rule 5 match out log on em0 from athn0:network to any nat-to (em0) # Rule 6 pass out log on em0 from athn0:network to any Rules 1--3 are there so I can do my experiments over SSH. These rules affect the rule numbering as shown by pflog, but are otherwise not the point. Is there anything you see in these rules, especially in rules 5 and 6, that is not correct? I don't think so, I've taken this almost verbatim from the pf FAQ https://www.openbsd.org/faq/pf/nat.html. When I connect my phone to the wireless network on athn0, this is what I see: # doas tcpdump -n -e -ttt -i pflog0 tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG Jun 23 12:48:28.349710 rule def/(ip-option) pass in on athn0: :: > ff02::16: HBH multicast listener report v2, 1 group record(s) [hlim 1] Jun 23 12:48:28.714929 rule 5/(match) match out on em0: 192.168.3.32.54151 > 172.217.168.68.443: S 940430546:940430546(0) win 65535 (DF) Jun 23 12:48:28.714932 rule 0/(match) block out on em0: 192.168.3.32.54151 > 172.217.168.68.443: S 940430546:940430546(0) win 65535 (DF) Jun 23 12:48:28.716461 rule 5/(match) match out on em0: 192.168.3.32.37973 > 216.58.215.227.80: S 2291102750:2291102750(0) win 65535 (DF) Jun 23 12:48:28.716463 rule 0/(match) block out on em0: 192.168.3.32.37973 > 216.58.215.227.80: S 2291102750:2291102750(0) win 65535 (DF) Jun 23 12:48:29.728732 rule 5/(match) match out on em0: 192.168.3.32.54151 > 172.217.168.68.443: S 940430546:940430546(0) win 65535 (DF) Jun 23 12:48:29.728736 rule 0/(match) block out on em0: 192.168.3.32.54151 > 172.217.168.68.443: S 940430546:940430546(0) win 65535 (DF) As you can see, the packet is being matched by the match rule (rule 5) but then NOT matched by the pass rule (rule 6) and consequently by the block-all rule (rule 0). When I remove rule 5 and change rule 6 to this (making it the new rule 5): pass out log on em0 from athn0:network to any nat-to (em0) this is what I see in the logs: Jun 23 12:50:59.791736 rule def/(ip-option) pass in on athn0: :: > ff02::16: HBH multicast listener report v2, 1 group record(s) [hlim 1] Jun 23 12:51:00.091647 rule def/(ip-option) pass in on athn0: :: > ff02::16: HBH multicast listener report v2, 1 group record(s) [hlim 1] Jun 23 12:51:00.152530 rule 5/(match) pass out on em0: 192.168.3.32.37988 > 216.58.215.227.80: S 749016608:749016608(0) win 65535 (DF) Jun 23 12:51:00.152614 rule 5/(match) pass out on em0: 192.168.3.32.54168 > 172.217.168.68.443: S 2019795291:2019795291(0) win 65535 (DF) In other words, now the same packets that weren't passed using the match/pass combo are not passed when the nat-to is part of the pass rule. No matter how I read the docs, there is no way I can explain what's happening. Yet my setup is so simple that I MUST be doing something wrong, right? Can you help me see what's going on? Cheers Stephan PS: I didn't want to make this message even longer by including a dmesg, but it is of course available on request.
Re: lidaction on an M1 macbook
On Jun 22 16:57:45, tobias.hei...@stusta.de wrote:
> > > > The arm64 default for the machdep.lidaction is 1, making the
> > > > system suspend when the lid is closed.
> >
> > On this M1 macbook (dmesg below), I see no difference
> > between lidaction=0 and lidaction=1; with both,
> > closing and opening the lid does this:
> >
> Is this still the case?
Yes.
> For me lidaction=0 seems to only disable the screen which is inteded,
> lidaction=1 triggers a suspend.
For me, both lidaction=0 and lidaction=1
turn the screen off, but do not suspend.
Only apm -z suspends.
closing the lid with machdep.lidaction=0
Jun 23 10:33:40 mb /bsd: uhub0 detached
Jun 23 10:33:40 mb /bsd: uhub1 detached
Jun 23 10:34:57 mb /bsd: wsdisplay_switch2: not switching
Jun 23 10:34:57 mb /bsd: cpu0: 1 wakeup events
Jun 23 10:34:57 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:34:57 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:34:57 mb /bsd: cpu7: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu4: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu6: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu5: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu1: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu2: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu3: 1 wakeup events
Jun 23 10:34:57 mb root: running /etc/apm/resume
Jun 23 10:35:03 mb apmd: system resumed from sleep
Jun 23 10:35:03 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
closing the lid with machdep.lidaction=1
Jun 23 10:35:56 mb /bsd: uhub0 detached
Jun 23 10:35:56 mb /bsd: uhub1 detached
Jun 23 10:36:47 mb /bsd: wsdisplay_switch2: not switching
Jun 23 10:36:47 mb /bsd: cpu0: 1 wakeup events
Jun 23 10:36:47 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:36:47 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:36:47 mb /bsd: cpu7: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu5: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu4: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu6: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu3: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu1: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu2: 1 wakeup events
Jun 23 10:36:47 mb root: running /etc/apm/resume
Jun 23 10:36:53 mb apmd: system resumed from sleep
Jun 23 10:36:53 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
running apm -z
Jun 23 10:37:16 mb apmd: system suspending
Jun 23 10:37:16 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
Jun 23 10:37:16 mb root: running /etc/apm/suspend
Jun 23 10:37:17 mb /bsd: uhub0 detached
Jun 23 10:37:17 mb /bsd: uhub1 detached
Jun 23 10:38:00 mb /bsd: wsdisplay_switch2: not switching
Jun 23 10:38:00 mb /bsd: cpu0: 1 wakeup events
Jun 23 10:38:00 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:38:00 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:38:00 mb /bsd: cpu7: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu4: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu5: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu6: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu1: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu3: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu2: 1 wakeup events
Jun 23 10:38:01 mb root: running /etc/apm/resume
Jun 23 10:38:06 mb apmd: system resumed from sleep
Jun 23 10:38:06 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
Jan
/etc/apm/{suspend,resume} are the same file:
#!/bin/sh
logger running $0
dmesg:
OpenBSD 7.3-current (GENERIC.MP) #2170: Thu Jun 22 14:47:18 MDT 2023
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem = 8001478656 (7630MB)
avail mem = 7634296832 (7280MB)
random: good seed from bootblocks
mainbus0 at root: Apple MacBook Air (M1, 2020)
cpu0 at mainbus0 mpidr 0: Apple Icestorm r1p1
cpu0: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache
cpu0: 4096KB 128b/line 16-way L2 cache
cpu0:
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR
cpu1 at mainbus0 mpidr 1: Apple Icestorm r1p1
cpu1: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache
cpu1: 4096KB 128b/line 16-way L2 cache
cpu1:
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR
cpu2 at mainbus0 mpidr 2: Apple Icestorm r1p1
cpu2: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache
cpu2: 4096KB 128b/line 16-way L2 cache
