Intel DRM error on T 440
uname: OpenBSD 7.3 GENERIC.MP#1125 amd64 I get the following error message when my Thinkpad T440 wakes up: drm:pid73944:intel_dp_aux_wait_done *ERROR* [drm] *ERROR* AUX A/DDI A/PHY A: did not complete or timeout within 10ms (status 0xa01300e1) I have Googled that error message and no fixes turn up. In other respects, my OpenBSD T440 works just great. My rc.conf.local contains this: apmd_flags=-A pf=YES pkg_scripts=messagebus cupsd mysqld xenodm_flags= Any suggestions as to what I may have misconfigured would be helpful. I have loaded the firmware using fw_update. This error did not occur in OpenBSD 7.2. -- Kind regards, Jonathan
Re: IPsec "road warrior" VPN not getting set up properly.
OK, I've sorted out my network issues server but it turns out that I
was misinterpreting the tcpdump output on my VPS. When an external
computer tries to ping my client's virtual IP address, the VPS's
gateway router is *not* forwarding the pings to my server where they
can be shoved into the IPsec tunnel to the client. So it looks like
the iked responder needs to send IPv6 neighbor advertisements for the
allocated address after all. Is there a way to do this?
I have tried two things so far:
1. Manually assign the [randomly allocated] IP address to the
responder's physical network interface so it knows it has ownership
of that address:
# ifconfig vio0 inet6 alias 2001:db8:2::1234:5678
Of course, this breaks the tunnel. When the responder sees packets with
destination 2001:db8:2::1234:5678 it consumes them locally instead of
routing them down the IPsec tunnel.
2. Advertise ownership of the address with rad:
$ cat /etc/rad.conf
interface vio0 {
prefix 2001:db8:2::1234:5678/128 {
autonomous address-configuration no
}
}
This doesn't work either because a router advertisement is not the same
as a neighbor advertisement. But I tried!
A third option would be to use a layer 2 tunnel so that the client
would be responsible for sending its own neighbor advertisements. But
the cost is high: I need to configure a gif(4) interface on the client
and now I'm pushing big fat Ethernet frames across the tunnel instead
of modestly portly IPv6 packets. Worse, if I want non-OpenBSD clients
to connect to the server, I have to figure out how to set up the client
side of a layer 2 tunnel on whatever OS they're using. So much work
just to get a globally-routable IP address!
Here is my vision of a perfect world. It's common for IPv6 nodes to
request a new random IPv6 address every couple of hours; OpenBSD's
inet6 autoconf does this by default. There is no shortage of IPv6
addresses on a LAN, and the process of requesting new ones is pretty
well standardized . So what would be fantastic is if instead of
putting "config address 2001:db8:2::/64" in the responder's iked.conf,
I could put "config inet6 autoconf vio0" instead. Then iked would
make sure that vio0 is using autoconf addresses and, if so, it would
request a new address via SLAAC (preferably randomizing all 64 bits
instead of just the bottom 32 bits like it does right now), assign
that address to the client, configure all the routing, and then would
somehow configure vio0 to claim ownership of that address for
NDP neighbor solicitation purposes, but have the kernel *not* claim
the address for routing purposes. The client config wouldn't change
at all; it would still say "request address any". But since we're
visualizing a perfect world and not just a great world, there would
also be an optional "temporary" flag which causes the client to
request a new address every couple of hours (just like how inet6
autconf does on regular interfaces)---since one of the intended use
cases for this would be concealing your region of origin, it seems
like privacy features should be easy to request.
But since I'm not [currently] offering to figure out how to implement
this myself I'll make do with what I have. Is there a way to make the
the responder/server send neighbor advertisements for the address it
allocated for the client, so that this address will be usable on the
global Internet?
Thanks,
Anthony
Re: IPsec "road warrior" VPN not getting set up properly.
On July 5, 2023 4:35:30 AM GMT+03:00, Anthony Coulter wrote: >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: >DestinationGateway Flags Refs Use Mtu Prio Iface >defaultfe80::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::/64server 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 flow
Re: Restart of syslogd every three hours ?
On 2023-07-04, J Doe wrote: > 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. newsyslog signals syslogd with a HUP when rotating logs. > Is this normal and if so, what is the purpose of the restarts ? > > Thanks, > > -J > > -- Please keep replies on the mailing list.
Re: Inclusion in the list of providers OpenBSD
On Wed, Jul 5, 2023 at 7:39 AM Gerd Theobald wrote: > > [...] > > Dr. Gerd Theobald > Marketing Consultant > > [...] > > 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. > Here's some free marketing advice for Dr. Marketing Consultant: Sending legal threats in two languages is not a good way to start a conversation with potential customers.
