Re: assistance request for IKEv2 VPN setup with iked
On Thu, Oct 21, 2021 at 10:23:51AM +0200, Johann Belau wrote: > Dear all, > > I am in desperate need of assistance for setting up an IKEv2 VPN tunnel to a > remote LAN with OpenBSD as my VPN gateway. > > A short outline of what I'm trying to achieve: > > 1. I have a remote private LAN with Windows Servers and one OpenBSD gateway > (gateway has a public IP, the rest of the private LAN don't) > 2. It should be possible to establish an ikev2 VPN tunnel (using iked) to the > private LAN from Windows / Mac OS X clients (road warriers) > 3. After establishing VPN connection to OpenBSD VPN gateway it should be > possible to connect to the Windows Servers in private LAN from Win/Mac > clients using RDP > 4. The Windows Servers in the private LAN and the road warriers should be > able to send traffic to the internet (using unbound for DNS) and be protected > from incoming malicious traffic using some reasonable pf rule sets > > I have tried many things and researched a lot of guides and howtos - but so > far I failed to produce results The setup you describe above is fairly straightforward. What dificulties have you had? Essentially, at the OpenBSD gateway end, you just need to ensure that you have appropriate keys in /etc/iked/, and a /etc/iked.conf something like: ikev2 esp from gateway.vpn.example to client.vpn.example local gateway.public.fqdn peer any dstid expected.remote.client ecdsa384 Where: gateway.vpn.example and client.vpn.example are private IP addresses assigned by you for the vpn endpoints gateway.public.fqdn is the public IP of the gateway, I.E. where the ESP packets are sent from expected.remote.client is the hostname of the remote client. Since the clients have dynamic IPs that the gateway doesn't know, you want to leave the gateway set to passive mode waiting for incoming connections, and the remote peers to active mode. Note that at some point between OpenBSD 6.8 and OpenBSD 6.9, transport mode was broken. I know this first hand, because I was the one who reconfigured all of our transport mode VPNs to use tunnel mode after the upgrade to OpenBSD 6.9. I haven't checked to see if it has been fixed since. In your application you'll almost certainly be using tunnel mode anyway. Some time ago there was also a bug that prevented the keys which are generated automatically by /etc/rc at first boot from working correctly. Generate new ECDSA keys manually with something like: # openssl ecparm -genkey -name secp384r1 -out /etc/iked/private/local.key # openssl ec -in /etc/iked/private/local.key -pubout -out /etc/iked/local.pub # chmod 640 /etc/iked/private/local.key The above should get you started, with IPSEC packets flowing between the gateway and one client.
Re: How does bsd.upgrade work?
tetrahe...@danwin1210.me wrote: > On Mon, Oct 18, 2021 at 07:41:57PM -, Stuart Henderson wrote: > >> I resolved the problem. The solution was to run `sysupgrade -n` to > >> download all the upgrade files, and leave the `bsd.upgrade` kernel in > >> place, next to the `bsd` kernel I usually boot. > >> > >> Then, at the next boot, manually boot the `bsd.upgrade` kernel by > >> specifying its location. > > > >Sounds like you aren't using the correct boot loader. > > That's intentional. Please do away. We do not appreciate people attempting to monopolize other's time the way you are doing.l
Re: Base httpd authentication against RADIUS server?
Federico Giannici(giann...@neomedia.it) on 2021.10.20 08:09:54 +0200: > From the man page It seems that httpd in base can authenticate only > against a standard passwd file. Is there no way (apart from modifying > source and recompiling) to authenticate with something else, like a > RADIUS server? No. But modifying source is always an underappreciated option. /B.
Re: How does bsd.upgrade work?
tetrahe...@danwin1210.me wrote: > On Mon, Oct 18, 2021 at 05:41:26PM +0200, Florian Obser wrote: > >I wouldn't call this "resolved". You are missing the point that > >bsd.upgrade should run automatically. *shrug* > > My setup is not standard, so it's normal that bsd.upgrade not run > automatically. The solution I used, as far as I know, is by far the > simplest and easiest way of resolving the problem. You've been told a few times that your vague "my setup is different" means you shouldn't have asked. If you introspect for more than a few minutes you'll come to the same conclusion. Please stop wasting everyone's time.
assistance request for IKEv2 VPN setup with iked
Dear all, I am in desperate need of assistance for setting up an IKEv2 VPN tunnel to a remote LAN with OpenBSD as my VPN gateway. A short outline of what I'm trying to achieve: 1. I have a remote private LAN with Windows Servers and one OpenBSD gateway (gateway has a public IP, the rest of the private LAN don't) 2. It should be possible to establish an ikev2 VPN tunnel (using iked) to the private LAN from Windows / Mac OS X clients (road warriers) 3. After establishing VPN connection to OpenBSD VPN gateway it should be possible to connect to the Windows Servers in private LAN from Win/Mac clients using RDP 4. The Windows Servers in the private LAN and the road warriers should be able to send traffic to the internet (using unbound for DNS) and be protected from incoming malicious traffic using some reasonable pf rule sets I have tried many things and researched a lot of guides and howtos - but so far I failed to produce results Is there anyone willing to support me? A commercial agreement with a reasonable hourly rate is possible and welcome. The resulting how-to guide will be provided to this list for future use. Regards, Johann
Re: How BSD Authentication Works
Dante Catalfamo wrote: > Hello friends, > > I just published a blog post about the BSD Authentication framework > and I'm very excited to share it with you! > > I'm not an OpenBSD developer but I tried my best to understand the > system and how it works. Please let me know if I got anything wrong. > > https://blog.lambda.cx/posts/how-bsd-authentication-works/ I think many people don't understand what BSD auth is: It is an additional layer of privsep. And whenever we have code that does privsep, we have an additional opportunity to apply pledge/unveil to that process context.
Re: Ifconfig error - SIOCSETPFLOW
It is 'working for you' until we remove dhclient in a future release. ... Antonino Sidoti wrote: > HI, > > I added ‘!dhclient \$if’ to the /etc/hostname.em0 and removed ‘dhcp’. It is > working now with no errors on startup and the interface ‘pflow0’ now working > properly. > > pf enabled > net.inet.ip.forwarding: 0 -> 1 > net.inet6.ip6.forwarding: 0 -> 1 > starting network > em0: no linkgot link > em0: no lease.got lease > em0: 122.199.32.172 lease accepted from 116.255.18.1 (3c:fd:fe:bd:95:13) > reordering libraries: done. > starting early daemons: syslogd pflogd unbound ntpd. > starting RPC daemons:. > savecore: no core dump > checking quotas: done. > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd snmpd dhcpd rad smtpd. > starting package daemons: dhcpcd. > starting local daemons: cron. > Sun Oct 17 12:24:00 AEDT 2021 > > > Many thanks for your help > > Antonino Sidoti > > > > > > On 17 Oct 2021, at 1:12 am, Brian Brombacher wrote: > > > > > > > >> On Oct 15, 2021, at 10:56 PM, Antonino Sidoti wrote: > >> > >> HI, > >> > >> Yes, on my em0 interface I am using ‘dhcp’ and this is the source IP for > >> pflow. The setup is a basic firewall as described in the PF example > >> firewall. > >> > >> Interface em0 = external using dhcp (Static IP assigned by carrier) > >> Interface em1 = internal with static IP (Lan using 10.0.x.x/24) > >> > >> Output from /etc/hostname.pflow0 (Not real IPs) > >> flowdst 203.0.113.1:3001 flowsrc 198.51.100.1 > >> pflowproto 10 > >> > >> Thanks > >> > >> Antonino Sidoti > >> > >> > > > > Thanks for the details. A recent change in 7.0 introduced a change in > > behavior for DHCP configured interfaces. The IP could be assigned after > > other interfaces are configured. You may need to assign the static IP in > > hostname.em0 before the dhcp line, or run dhclient directly from > > hostname.em0 and avoid using “dhcp” in there. > > > >> > On 16 Oct 2021, at 10:39 am, Brian Brombacher > wrote: > > > > > On Oct 15, 2021, at 7:09 PM, Antonino Sidoti wrote: > > HI, > > I am getting this error since upgrading to v7.0; > > pf enabled > net.inet.ip.forwarding: 0 -> 1 > net.inet6.ip6.forwarding: 0 -> 1 > starting network > > ifconfig: SIOCSETPFLOW: Can't assign requested address > ifconfig: SIOCSETPFLOW: Can't assign requested address > > reordering libraries: done. > starting early daemons: syslogd pflogd unbound ntpd. > starting RPC daemons:. > savecore: no core dump > checking quotas: done. > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd snmpd dhcpd rad smtpd. > starting package daemons: dhcpcd. > starting local daemons: cron. > Sat Oct 16 08:06:39 AEDT 2021 > > I am assuming it is related to the interface ‘pflow0’ which was working > fine in version 6.9. The /etc/hostname.pflow0 is exactly the same as the > examples in the man pages only that the source and destination IP > addresses are different. > > Many thanks > > Antonino Sidoti > > > > >>> > >>> Are you using DHCP to configure the interface the source IP is on? > >>> Provide some more details of the network setup. >
Re: Exit status of pkg_add
On Tue, Oct 19, 2021 at 10:42:04AM +0900, Yuichiro NAITO wrote:
> Following patch changes pkg_add to return a error code,
> if a package name is wrong.
>
> diff --git a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> index 7a968cbf05d..39bee874ff1 100644
> --- a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> +++ b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> @@ -403,12 +403,13 @@ sub check_root
> sub choose_location
> {
> my ($state, $name, $list, $is_quirks) = @_;
> if (@$list == 0) {
> if (!$is_quirks) {
> $state->errsay("Can't find #1", $name);
> + $state->{bad}++;
> $state->run_quirks(
> sub {
> my $quirks = shift;
> $quirks->filter_obsolete([$name], $state);
> });
> }
>
> Is it OK?
>
> On 10/18/21 16:53, Yuichiro NAITO wrote:
> > Hi, I have a question about exit status of pkg_add command.
> >
> > When I wrote a package install script which included typo in a package name
> > (of course it's my fault), the script didn't stop in spite of `set -e`.
> >
> > Because pkg_add command returns 0 even if a package name is wrong.
> > Is this exit status intended or design policy of pkg_add command?
> >
> > If not, I want a error status getting returned.
> > It will save my time to look for a typo or similar bug.
> >
> > I can't see 'EXIT STATUS' section in the pkg_add manual of OpenBSD 7.0.
> > So, I e-mailed this question.
> >
Basically, there are a few traps in pkg_add wrt exit status.
The main trap is that making pkg_add error out in cases it didn't requires
testing, because various automated situations that already exist might fail.
I will most probably fix that one, assuming there is no fallout.
Re: httpd(8) - Internal Server error (500) on invalid request
J. K.(openbsd.l...@krottmayer.com) on 2021.10.21 14:10:16 +0200:
> Another question, to httpd(8). Tried the following query.
> Used an invalid HTTP Version number (typo).
>
> $ telnet 10.42.42.183 80
> [Shortened]
> GET / HTTP/1.2
> [content]
>
> httpd provide here the site. Without checking the not existent version
> (1.2) number and the Host. Okay, that's maybe stupid from me to
> start a request with an invalid version number. But should not also
> the server answer with 400 (bad request)?
>
> According to the source only HTTP/1.1 is checked. All other request
> will be accepted. Okay, I'm not a RFC specialist. Still a newbie.
This diff makes httpd return "505 HTTP Version Not Supported"
for < 0.9 and > 1.9 http versions. Anything from 1.1 to 1.9 is
interpreted as 1.1. This is what nginx does too.
ok?
diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
index 6a74f3e45c5..52aaf3711c2 100644
--- usr.sbin/httpd/server_http.c
+++ usr.sbin/httpd/server_http.c
@@ -51,6 +51,7 @@ intserver_http_authenticate(struct server_config
*,
struct client *);
char *server_expand_http(struct client *, const char *,
char *, size_t);
+int http_version_num(char *);
static struct http_method http_methods[] = HTTP_METHODS;
static struct http_errorhttp_errors[] = HTTP_ERRORS;
@@ -198,6 +199,19 @@ done:
return (ret);
}
+int http_version_num(char *version)
+{
+ if (strcmp(version, "HTTP/0.9") == 0)
+ return (9);
+ if (strcmp(version, "HTTP/1.0") == 0)
+ return (10);
+ /* any other version 1.x gets downgraded to 1.1 */
+ if (strncmp(version, "HTTP/1", 6) == 0)
+ return (11);
+
+ return (0);
+}
+
void
server_read_http(struct bufferevent *bev, void *arg)
{
@@ -207,6 +221,7 @@ server_read_http(struct bufferevent *bev, void *arg)
char*line = NULL, *key, *value;
const char *errstr;
size_t size, linelen;
+ int version;
struct kv *hdr = NULL;
getmonotime(>clt_tv_last);
@@ -329,12 +344,29 @@ server_read_http(struct bufferevent *bev, void *arg)
*desc->http_query++ = '\0';
/*
-* Have to allocate the strings because they could
+* We have to allocate the strings because they could
* be changed independently by the filters later.
+* Allow HTTP version 0.9 to 1.1.
+* Downgrade http version > 1.1 <= 1.9 to version 1.1.
+* Return HTTP Version Not Supported for anything else.
*/
- if ((desc->http_version =
- strdup(desc->http_version)) == NULL)
- goto fail;
+
+ version = http_version_num(desc->http_version);
+ if (version == 11) {
+ if ((desc->http_version =
+ strdup("HTTP/1.1")) == NULL)
+ goto fail;
+ } else {
+ if ((desc->http_version =
+ strdup(desc->http_version)) == NULL)
+ goto fail;
+ }
+
+ if (version == 0) {
+ server_abort_http(clt, 505, "bad http version");
+ goto abort;
+ }
+
if (desc->http_query != NULL &&
(desc->http_query =
Re: httpd(8) - Internal Server error (500) on invalid request
On Thu, Oct 21, 2021 at 01:21:33PM +0200, Sebastian Benoit wrote:
> J. K.(openbsd.l...@krottmayer.com) on 2021.10.21 11:55:47 +0200:
> > Hi,
> >
> > I don't know if this is a real issue from OpenBSD's httpd(8).
> > Tried some requests to httpd(8) for the purpose of education.
> >
> > Simple tried the following request:
> >
> > $ telnet 10.42.42.183 80
> > Trying 10.42.42.183...
> > Connected to 10.42.42.183.
> > Escape character is '^]'.
> > GET / HTTP/1.1
> > fasfsdfsfd
> >
> > Here without the colon httpd(8) return an internal server
> > error.
> >
> > Can somebody verify this behavior?
> >
> > Noticed with OpenBSD 7.0. Is this a correct behavior (RFC
> > conform)?
> >
> > Thanks in advance!
> >
> > Kind regrads,
> >
> > J. K.
>
> Hi,
>
> yes. The server should probably answer with a "Bad Request" instead.
>
> Fix below. ok?
OK claudio@
> diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
> index 732add41283..fce3c21af72 100644
> --- usr.sbin/httpd/server_http.c
> +++ usr.sbin/httpd/server_http.c
> @@ -268,8 +268,14 @@ server_read_http(struct bufferevent *bev, void *arg)
> else if (*key == ' ' || *key == '\t')
> /* Multiline headers wrap with a space or tab */
> value = NULL;
> - else
> + else {
> + /* Not a multiline header, should have a : */
> value = strchr(key, ':');
> + if (value == NULL) {
> + server_abort_http(clt, 400, "malformed");
> + goto abort;
> + }
> + }
> if (value == NULL) {
> if (clt->clt_line == 1) {
> server_abort_http(clt, 400, "malformed");
>
--
:wq Claudio
Re: How does bsd.upgrade work?
A couple minutes of looking things up suggest https://marc.info/?l=openbsd-tech=141807224826859 as a plausible starting point for that kind of inquiry. Take care, -- Raul On Thu, Oct 21, 2021 at 8:15 AM wrote: > > On Tue, Oct 19, 2021 at 09:32:21PM +0100, Stuart Henderson wrote: > >> That's intentional. > > > >OK. Since you didn't realise this breaks sysupgrade you might also > >not realise it weakens RNG initialisation, it is not recommended > > Where can I read more about this? >
Re: http(8) - PHP 8.0.11 - excecute shell command return code 127 (not found)
Hi Stuart! Sorry, for my late response. On 19.10.21 13:35, Stuart Henderson wrote: > > You need to provide $CHROOT/bin/sh as well for php's exec() function to work. > Thank you. Solved the issue. Didn't know that. Best regards, J.K.
Re: drmfreeze
On Tue, 2021-10-19 at 18:51 +1300, Avon Robertson wrote: > > Avon Robertson [avo...@xtra.co.nz] wrote Also happens to me on amdgpu/navi10 (even after downgrading the firmware to the 6.8 ones): Oct 18 01:26:36 polaris /bsd: drm:pid0:smu_v11_0_check_fw_version *WARNING* SMU driver if version not matched Oct 18 01:26:36 polaris /bsd: amdgpu0: NAVI10 36 CU rev 0x02 Oct 18 01:26:36 polaris /bsd: amdgpu0: 1920x1080, 32bpp Oct 18 01:26:36 polaris /bsd: wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0 Oct 18 01:26:36 polaris /bsd: wskbd1: connecting to wsdisplay0 Oct 18 01:26:36 polaris /bsd: wskbd2: connecting to wsdisplay0 Oct 18 01:26:36 polaris /bsd: wskbd3: connecting to wsdisplay0 Oct 18 01:26:36 polaris /bsd: wskbd4: connecting to wsdisplay0 Oct 18 01:26:36 polaris /bsd: wskbd5: connecting to wsdisplay0 Oct 18 01:26:36 polaris /bsd: wskbd6: connecting to wsdisplay0 Oct 18 01:26:36 polaris /bsd: wskbd7: connecting to wsdisplay0 Oct 18 01:26:36 polaris /bsd: wsdisplay0: screen 1-5 added (std, vt100 emulation) Oct 18 01:34:24 polaris /bsd: WARNING !(group_idx != 0) failed at /usr/src/sys/dev/pci/drm/amd/display/dc/dcn20/dcn20_hwseq.c:111 Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* Illegal register access in command stream Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* ring gfx_0.0.0 timeout, signaled seq=129772, emitted seq=129774 Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* Process information: process pid 0 thread Xorg pid 84104 Oct 18 01:52:31 polaris /bsd: amdgpu_device_suspend_display_audio: stub Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* ring kiq_2.1.0 test failed (-60) Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* KGQ disable failed Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* ring kiq_2.1.0 test failed (-60) Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* KCQ disable failed Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* failed to halt cp gfx Oct 18 01:52:31 polaris /bsd: drm:pid12742:smu_v11_0_check_fw_version *WARNING* SMU driver if version not matched Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* Illegal register access in command stream Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* ring gfx_0.0.0 timeout, but soft recovered Oct 18 01:52:31 polaris /bsd: [drm] *ERROR* Failed to initialize parser -88! Oct 18 01:53:02 polaris last message repeated 323 times Oct 18 01:53:27 polaris last message repeated 175 times
Re: Issue on RPi4 upgrade to 7.0
Hi,
I gave it a thought and tried to find any options on sysupgrade to roll back,
but I couldn't find no option foe this on its help page. Should I reinstall 6.9
from scratch and config it again?
Thanks,
Matheus
On October 20, 2021 7:44:40 PM GMT-03:00, Noth wrote:
>You're better off rolling back to 6.9. Upgrade when the issue has been
>solved.
>
>On 20/10/2021 16:12, Nenhum_de_Nos wrote:
>> Hi,
>>
>> I just upgraded my RPi4B 4G router to 7.0 and, unlike the RPi3B that
>all worked fine, it fails to boot and the log is:
>>
>> softraid0 at root
>> scsibus2 at softraid0: 256 targets
>> root on sd0a (978f2b14852ab222.a) swap on sd0b dump on sd0b
>> WARNING: CHECK AND RESET THE DATE!
>> gpio0 at bcmgpio0: 58 pins
>> bwfm0: address xx:xx:xx:xx:xx:xx
>> panic: do_el0_error
>> Stopped at panic+0x160:cmp w21, #0x0
>> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
>> *501374 57858 0 0 00 init
>> 7166 1 0 0x2 02K init
>> db_enter() at panic+0x15c
>> panic() at do_el0_error+0x10
>> athub_v2_1_set_clockgating() at handle_el0_error+0x74
>> handle_el0_error() at 0x14bf4fdea8
>> address 0x7d3be8 is invalid
>> https://www.openbsd.org/ddb.html describes the minimum info required
>in bug
>> reports. Insufficient info makes it difficult to find and fix bugs.
>> ddb{0}> reboot
>> rebooting...
>>
>> Searching the internet I got to this:
>https://www.mail-archive.com/bugs@openbsd.org/msg17017.html
>>
>> So I did what was told there, disabled bcmpcie on boot and now the
>USB won't work. I need it for my second NIC. It was all fine on 6.9
>till this morning.
>>
>> It was also mentioned on that mail thread that the U-Boot would
>matter, so mine now is U-Boot 2021.07 (Aug 12 2021 - 02:45:29 -0600)
>Tried to search for new U-Boot for it, no new version found so far.
>Will keep looking.
>>
>> Has anyone seen this issue on updates?
>>
>> Now I am confused if I finish the upgrade by running sysmerge and
>pkg_add -u or if I try to rollback to 6.9 where all worked fine.
>>
>> thanks,
>>
>> matheus
>>
>>
--
"We will call you Cygnus,
the God of balance you shall be."
Re: traceroute losses
Am 13.10.21 09:58 schrieb Peter J. Philipp: > On Wed, Oct 13, 2021 at 08:02:35AM +0200, Michael Hekeler wrote: > > Hello list, > > > > I have question regarding network/routing. However it is not directly > > openbsd related (I can see the same even on windows machines) I decided > > to ask here because I know that there are many experienced admins here > > and there is wealth of expertise on such things on this list. > > > > On my site there are about 10 clients which connects to an internet > > database host. > > From time to time connection gets lost and sometimes the clients > > reconnect after a while but sometimes the database app breaks. > > > > When doing network diagnostics with mtr(8) which combines the > > functionality of traceroute(8) and ping(8) it shows the packets hopping > > through 8 to 9 hosts to reach the destination. > > When running this tool for a few hours it shows that two hosts in this > > route produces packet loss (~20%). > > > > My Question: > > is there anything I can do about that by myself or is only option to > > contact the admin of these hosts and hope that they are willing to fix > > whatever problem there is? > > If you have 9 hops and the packet loss is on hop 4 and 5 but does not carry > over to the destination you can ignore it. If it carries over to the > destination ie. hops 6, 7, 8 and 9, then you should look further at reaching > out. > > The reason is as follows: some routers pass packets through their ASIC's for > forwarding and it doesn't touch their processor at all, it's like offloading > the entire packet forwarding process. Yet when you talk to the IP of the > router directly, which is what ping does then the processor in the router > processes the packet and this may cause packet loss becuase usually they don't > have a fast cpu here. And ICMP doesn't have much priority in this case > either. > > Best regards, > -peter > That's very interesting. Thank you so much. According to the DB hoster the loss showing at traceroute's output on hop 4 and 5 of 9 would provide reliable proof that the connection is the culprit. Now I understand that this conclusion is not automatically true. Hops 6,7,8,9 showed no more than 1% loss.
httpd(8) - Internal Server error (500) on invalid request
Hi, I don't know if this is a real issue from OpenBSD's httpd(8). Tried some requests to httpd(8) for the purpose of education. Simple tried the following request: $ telnet 10.42.42.183 80 Trying 10.42.42.183... Connected to 10.42.42.183. Escape character is '^]'. GET / HTTP/1.1 fasfsdfsfd Here without the colon httpd(8) return an internal server error. Can somebody verify this behavior? Noticed with OpenBSD 7.0. Is this a correct behavior (RFC conform)? Thanks in advance! Kind regrads, J. K.
Re: httpd(8) - Internal Server error (500) on invalid request
On 2021-10-21, J. K. wrote: > A request from me (for this list): > I'm still having troubles with the OpenBSD mailing list. My DKIM key > will always be removed. Don't know why. My DMARC setting is restrict. > No issues with Google as example. > > Don't want to break or spam the list. > > Can somebody tell me how to fix this, please? > I'm really desperate. :( DKIM signatures are stripped because they'll very often fail for emails sent via the list (e.g. in many cases the list modifies mails by converting to text/plain which breaks the set of headers that many people are signing). Except in the case of restrictive DMARC signatures, this is a slight improvement. I think the only ways around this from your side would be to either remove p=quarantine/sp=reject or use a different sender domain that doesn't have restrictive settings. The other way would be if the list config was changed to rewrite >From headers. Some other mailing lists resorted to doing this, but it's not very convenient for the normal list user.
Re: httpd(8) - Internal Server error (500) on invalid request
J. K.(openbsd.l...@krottmayer.com) on 2021.10.21 11:55:47 +0200:
> Hi,
>
> I don't know if this is a real issue from OpenBSD's httpd(8).
> Tried some requests to httpd(8) for the purpose of education.
>
> Simple tried the following request:
>
> $ telnet 10.42.42.183 80
> Trying 10.42.42.183...
> Connected to 10.42.42.183.
> Escape character is '^]'.
> GET / HTTP/1.1
> fasfsdfsfd
>
> Here without the colon httpd(8) return an internal server
> error.
>
> Can somebody verify this behavior?
>
> Noticed with OpenBSD 7.0. Is this a correct behavior (RFC
> conform)?
>
> Thanks in advance!
>
> Kind regrads,
>
> J. K.
Hi,
yes. The server should probably answer with a "Bad Request" instead.
Fix below. ok?
diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
index 732add41283..fce3c21af72 100644
--- usr.sbin/httpd/server_http.c
+++ usr.sbin/httpd/server_http.c
@@ -268,8 +268,14 @@ server_read_http(struct bufferevent *bev, void *arg)
else if (*key == ' ' || *key == '\t')
/* Multiline headers wrap with a space or tab */
value = NULL;
- else
+ else {
+ /* Not a multiline header, should have a : */
value = strchr(key, ':');
+ if (value == NULL) {
+ server_abort_http(clt, 400, "malformed");
+ goto abort;
+ }
+ }
if (value == NULL) {
if (clt->clt_line == 1) {
server_abort_http(clt, 400, "malformed");
Re: How does bsd.upgrade work?
https://marc.info/?l=openbsd-tech=138829898720574=2 and https://marc.info/?l=openbsd-tech=139013674405106=2 might help. Den tors 21 okt. 2021 kl 14:26 skrev Raul Miller : > > A couple minutes of looking things up suggest > https://marc.info/?l=openbsd-tech=141807224826859 as a plausible > starting point for that kind of inquiry. > > Take care, > > -- > Raul > > On Thu, Oct 21, 2021 at 8:15 AM wrote: > > > > On Tue, Oct 19, 2021 at 09:32:21PM +0100, Stuart Henderson wrote: > > >> That's intentional. > > > > > >OK. Since you didn't realise this breaks sysupgrade you might also > > >not realise it weakens RNG initialisation, it is not recommended > > > > Where can I read more about this? > > > -- May the most significant bit of your life be positive.
Re: traceroute losses
On 2021-10-21, Michael Hekeler wrote: > According to the DB hoster the loss showing at traceroute's output on > hop 4 and 5 of 9 would provide reliable proof that the connection is the > culprit. > Now I understand that this conclusion is not automatically true. > Hops 6,7,8,9 showed no more than 1% loss. btw https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf is handy for interpreting traceroute results. -- Please keep replies on the mailing list.
Re: httpd(8) - Internal Server error (500) on invalid request
On Thu, Oct 21, 2021 at 04:38:43PM +0200, Sebastian Benoit wrote:
> J. K.(openbsd.l...@krottmayer.com) on 2021.10.21 14:10:16 +0200:
> > Another question, to httpd(8). Tried the following query.
> > Used an invalid HTTP Version number (typo).
> >
> > $ telnet 10.42.42.183 80
> > [Shortened]
> > GET / HTTP/1.2
> > [content]
> >
> > httpd provide here the site. Without checking the not existent version
> > (1.2) number and the Host. Okay, that's maybe stupid from me to
> > start a request with an invalid version number. But should not also
> > the server answer with 400 (bad request)?
> >
> > According to the source only HTTP/1.1 is checked. All other request
> > will be accepted. Okay, I'm not a RFC specialist. Still a newbie.
>
> This diff makes httpd return "505 HTTP Version Not Supported"
> for < 0.9 and > 1.9 http versions. Anything from 1.1 to 1.9 is
> interpreted as 1.1. This is what nginx does too.
>
> ok?
>
> diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
> index 6a74f3e45c5..52aaf3711c2 100644
> --- usr.sbin/httpd/server_http.c
> +++ usr.sbin/httpd/server_http.c
> @@ -51,6 +51,7 @@ int server_http_authenticate(struct server_config
> *,
> struct client *);
> char *server_expand_http(struct client *, const char *,
> char *, size_t);
> +int http_version_num(char *);
>
> static struct http_method http_methods[] = HTTP_METHODS;
> static struct http_error http_errors[] = HTTP_ERRORS;
> @@ -198,6 +199,19 @@ done:
> return (ret);
> }
>
> +int http_version_num(char *version)
KNF please.
> +{
> + if (strcmp(version, "HTTP/0.9") == 0)
> + return (9);
> + if (strcmp(version, "HTTP/1.0") == 0)
> + return (10);
> + /* any other version 1.x gets downgraded to 1.1 */
> + if (strncmp(version, "HTTP/1", 6) == 0)
> + return (11);
> +
> + return (0);
> +}
> +
> void
> server_read_http(struct bufferevent *bev, void *arg)
> {
> @@ -207,6 +221,7 @@ server_read_http(struct bufferevent *bev, void *arg)
> char*line = NULL, *key, *value;
> const char *errstr;
> size_t size, linelen;
> + int version;
> struct kv *hdr = NULL;
>
> getmonotime(>clt_tv_last);
> @@ -329,12 +344,29 @@ server_read_http(struct bufferevent *bev, void *arg)
> *desc->http_query++ = '\0';
>
> /*
> - * Have to allocate the strings because they could
> + * We have to allocate the strings because they could
>* be changed independently by the filters later.
> + * Allow HTTP version 0.9 to 1.1.
> + * Downgrade http version > 1.1 <= 1.9 to version 1.1.
> + * Return HTTP Version Not Supported for anything else.
>*/
> - if ((desc->http_version =
> - strdup(desc->http_version)) == NULL)
> - goto fail;
> +
> + version = http_version_num(desc->http_version);
I woud prefer if this code would store the version not in
desc->http_version until after the strdup(). The way these strdup work is
just wonky. Especil in the failure cases this may result in calling free
on the wrong thing.
> + if (version == 11) {
> + if ((desc->http_version =
> + strdup("HTTP/1.1")) == NULL)
> + goto fail;
> + } else {
> + if ((desc->http_version =
> + strdup(desc->http_version)) == NULL)
> + goto fail;
> + }
> +
> + if (version == 0) {
> + server_abort_http(clt, 505, "bad http version");
> + goto abort;
> + }
I would prefer to have this as:
if (version == 0) {
} else if if (version == 11) {
} else {
}
--
:wq Claudio
Successfully upgraded RPIv4 to 7.0
Hi, I just wanted to say that I successfully upgraded my RPIv4 to OpenBSD 7.0. I want to share my experience: 1. Wasn't sure if I should hold off or not and after seeing so many FAIL reports I learned off them. Thank you to all those who failed and all those who tried to help them. You helped me a great deal. 2. Backed up my /dev/sd0i which I mounted with mount_msdos -l first. I used cp -R /mnt /root/boot (which I had previously mkdir'ed). 3. Started sysupgrade -r and waited for it to install. 4. At the next boot, booted into bsd.rd and that panic'ed. Aha, so that's what the commotion was about. 5. Turned off RPI, and removed my USB external SSD. Booted my AMD64 netbook and mounted sd1a and sd1i (with -l again) and copied (with cp -R) the boot contents back. 6. Reconnected USB external SSD after unmounting both filesystems, and turned RPIv4 on. 7. Watched it boot into 7.0. After booting into X11 I noticed my root password didn't work. Somehow my key- map was not in german keyboard mode and I have a Y or Z in my root password. These keys are swapped in german keyboards vs. US keyboards. No sweat, I sued and was able to sysmerge, cvs update (/usr/src and /usr/ports), and finally pkg_add -u'ed. That's still runnning while I'm typing this. Thank you OpenBSD and arm64 team! Best regards, -peter
Re: How does bsd.upgrade work?
On Tue, Oct 19, 2021 at 09:32:21PM +0100, Stuart Henderson wrote: That's intentional. OK. Since you didn't realise this breaks sysupgrade you might also not realise it weakens RNG initialisation, it is not recommended Where can I read more about this?
Re: drmfreeze
Emiel Kollof [em...@kollof.nl] wrote: > > Also happens to me on amdgpu/navi10 (even after downgrading the > firmware to the 6.8 ones): > This appears to be a totally different failure than found by Avon. It's also on a different class of hardware. My suggestion to try an older firmware was based on a specific bug report where someone 1. using Linux had a very similar crash 2. on very similar hardware, and decided to 3. downgrade firmware and saw some sort of improvements. > Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* Illegal register access in > command stream > Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* ring gfx_0.0.0 timeout, > signaled seq=129772, emitted seq=129774 > Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* Process information: > process pid 0 thread Xorg pid 84104 > So, what is this? Is this from before you altered the firmware version? Or after? You should report issues like this with debugging information that represents the stock installation first. Chris
xlock doesn't unlock any more
After a reinstall and restore of data and /usr/local (not the rest of /usr, that is from a fresh snapshot) xlock no longer unlocks. I added the +allowroot option: same behavior. Running cwm. .xsession, .cwmrc, and dmesg below. -- Edward Ahlsen-Girard Ft Walton Beach, FL #!/bin/sh # $Xorg: xinitrc.cpp,v 1.3 2000/08/17 19:54:30 cpqbld Exp $ # $OpenBSD: xinitrc.cpp,v 1.2 2006/11/26 17:17:57 matthieu Exp $ # This has been chopped down to a .xsession. I hope. # start some nice programs set fp default for font in /usr/local/share/fonts/* ; do xset fp+ $font done xset fp rehash numlockx xidle -program '/usr/X11R6/bin/xlock -mode flow +allowroot' -timeout 900 & xclock -geometry 120x120-1+1 & xconsole -daemon xterm -geometry 120x36+150+0 & xsetroot -solid steelblue & rox ~ & rox ~/bin & rox ~/Downloads & keepassxc & cwm .cwmrc: borderwidth 2 # Set default Xft(3) fontname "sans-serif:pixelsize=24:bold" color activeborder orange color inactiveborder darkblue gap 0 0 0 120 unbind CM-delete bind CS-Left unmap bind CS-Right unmap bind CS-Up unmap bind CS-Down unmap #bind C-Left unmap #bind C-Right unmap bind M-Left unmap bind M-Right unmap bind C-Up unmap bind C-Down unmap bind 4S-Left bigptrmoveleft bind 4S-Right bigptrmoveright bind 4S-Up bigptrmoveup bind 4S-Down bigptrmovedown bind 4-Left ptrmoveleft bind 4-Right ptrmoveright bind 4-Up ptrmoveup bind 4-Down ptrmovedown # User defined bindings bind 4S-S snip bind CM-r reload bind 4C-l lock command lock '/usr/X11R6/bin/xlock -mode flow' command claws-mail /usr/local/bin/claws-mail command LibreOffice /usr/local/bin/soffice command firefox /usr/local/bin/firefox #command chrome /usr/local/bin/chrome command iridium /usr/local/bin/iridium command keepassxc /usr/local/bin/keepassxc #command KeePass "/usr/local/bin/mono /usr/local/bin/KeePass/KeePass.exe" #command kpcli /usr/local/bin/kpcli command Calibre /usr/local/bin/calibre command xpdf /usr/local/bin/xpdf command zathura /usr/local/bin/zathura command prtscrn "/usr/X11R6/bin/xwd -root -out screenshot.xwd" command snip "/usr/local/bin/import screenshot.png" command mountusb /home/ed/bin/mountusb command umountusb /home/ed/bin/umountusb command RapidFile /usr/local/bin/dosbox command gimp /usr/local/bin/gimp command audacity /usr/local/bin/audacity command vlc /usr/local/bin/vlc command rhp240w /home/ed/bin/rhp240w OpenBSD 7.0-current (GENERIC.MP) #47: Wed Oct 20 22:02:31 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4176125952 (3982MB) avail mem = 4033515520 (3846MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec530 (36 entries) bios0: vendor AMI version "80.06" date 04/01/2015 bios0: Hewlett-Packard 550-036 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MSDM SSDT SSDT MCFG HPET SSDT SSDT DBGP acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.92 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.47 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.46 MHz, 06-3c-03 cpu2:
Re: httpd(8) - Internal Server error (500) on invalid request
Hi, On 21.10.21 13:31, Claudio Jeker wrote: >> >> Hi, >> >> yes. The server should probably answer with a "Bad Request" instead. >> >> Fix below. ok? > > OK claudio@ > Thanks for the quick fix! Another question, to httpd(8). Tried the following query. Used an invalid HTTP Version number (typo). $ telnet 10.42.42.183 80 [Shortened] GET / HTTP/1.2 [content] httpd provide here the site. Without checking the not existent version (1.2) number and the Host. Okay, that's maybe stupid from me to start a request with an invalid version number. But should not also the server answer with 400 (bad request)? According to the source only HTTP/1.1 is checked. All other request will be accepted. Okay, I'm not a RFC specialist. Still a newbie. BTW: A request from me (for this list): I'm still having troubles with the OpenBSD mailing list. My DKIM key will always be removed. Don't know why. My DMARC setting is restrict. No issues with Google as example. Don't want to break or spam the list. Can somebody tell me how to fix this, please? I'm really desperate. :(
Re: httpd(8) - Internal Server error (500) on invalid request
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.10.21 17:19:02 +0200:
> > + version = http_version_num(desc->http_version);
>
> I woud prefer if this code would store the version not in
> desc->http_version until after the strdup(). The way these strdup work is
> just wonky. Especil in the failure cases this may result in calling free
> on the wrong thing.
Yes, this was actually the reason for the convoluted if (version.. ) bits,
because server_abort_http() calls into server_close() to free desc->http_version
and that is a crash when not pointing to the strduped string.
Fixed.
> > + if (version == 11) {
> > + if ((desc->http_version =
> > + strdup("HTTP/1.1")) == NULL)
> > + goto fail;
> > + } else {
> > + if ((desc->http_version =
> > + strdup(desc->http_version)) == NULL)
> > + goto fail;
> > + }
> > +
> > + if (version == 0) {
> > + server_abort_http(clt, 505, "bad http version");
> > + goto abort;
> > + }
>
> I would prefer to have this as:
> if (version == 0) {
> } else if if (version == 11) {
> } else {
> }
Fixed.
ok?
diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
index 6a74f3e45c5..e65a667c556 100644
--- usr.sbin/httpd/server_http.c
+++ usr.sbin/httpd/server_http.c
@@ -51,6 +51,7 @@ intserver_http_authenticate(struct server_config
*,
struct client *);
char *server_expand_http(struct client *, const char *,
char *, size_t);
+int http_version_num(char *);
static struct http_method http_methods[] = HTTP_METHODS;
static struct http_errorhttp_errors[] = HTTP_ERRORS;
@@ -111,7 +112,7 @@ server_httpdesc_free(struct http_descriptor *desc)
desc->http_query = NULL;
free(desc->http_query_alias);
desc->http_query_alias = NULL;
- free(desc->http_version);
+ free(desc->http_version); //XX
desc->http_version = NULL;
free(desc->http_host);
desc->http_host = NULL;
@@ -198,6 +199,20 @@ done:
return (ret);
}
+int
+http_version_num(char *version)
+{
+ if (strcmp(version, "HTTP/0.9") == 0)
+ return (9);
+ if (strcmp(version, "HTTP/1.0") == 0)
+ return (10);
+ /* any other version 1.x gets downgraded to 1.1 */
+ if (strncmp(version, "HTTP/1", 6) == 0)
+ return (11);
+
+ return (0);
+}
+
void
server_read_http(struct bufferevent *bev, void *arg)
{
@@ -206,7 +221,9 @@ server_read_http(struct bufferevent *bev, void *arg)
struct evbuffer *src = EVBUFFER_INPUT(bev);
char*line = NULL, *key, *value;
const char *errstr;
+ char*http_version;
size_t size, linelen;
+ int version;
struct kv *hdr = NULL;
getmonotime(>clt_tv_last);
@@ -317,24 +334,39 @@ server_read_http(struct bufferevent *bev, void *arg)
if (desc->http_path == NULL)
goto fail;
- desc->http_version = strchr(desc->http_path, ' ');
- if (desc->http_version == NULL) {
+ http_version = strchr(desc->http_path, ' ');
+ if (http_version == NULL) {
server_abort_http(clt, 400, "malformed");
goto abort;
}
- *desc->http_version++ = '\0';
+ *http_version++ = '\0';
desc->http_query = strchr(desc->http_path, '?');
if (desc->http_query != NULL)
*desc->http_query++ = '\0';
/*
-* Have to allocate the strings because they could
+* We have to allocate the strings because they could
* be changed independently by the filters later.
+* Allow HTTP version 0.9 to 1.1.
+* Downgrade http version > 1.1 <= 1.9 to version 1.1.
+* Return HTTP Version Not Supported for anything else.
*/
- if ((desc->http_version =
- strdup(desc->http_version)) == NULL)
- goto fail;
+
+ version = http_version_num(http_version);
+
+ if (version == 0) {
+
Re: xlock doesn't unlock any more
On 2021-10-21, Ed Ahlsen-Girard wrote: > After a reinstall and restore of data and /usr/local (not the rest of > /usr, that is from a fresh snapshot) xlock no longer unlocks. I added > the +allowroot option: same behavior. Running cwm. .xsession, .cwmrc, > and dmesg below. Did xlock lose the setgid bit or group ownership? Did /usr/X11R6 gain a nosuid mount option that it shouldn't have? $ ls -l /usr/X11R6/bin/xlock -rwxr-sr-x 1 root auth 1707504 Oct 19 03:30 /usr/X11R6/bin/xlock -- Please keep replies on the mailing list.
Re: drmfreeze
Hello Emiel, Please read my inline and other comments. On Thu, Oct 21, 2021 at 09:55:46AM +0200, Emiel Kollof wrote: > Avon Robertson schreef op 2021-10-20 20:31: > > >As suggested above by Chris? > >1. Downloaded radeondrm-firmware-20181218.tgz to ~/download/. > >2. # rm -fr /etc/firmware/amdgpu/* > >3. # tar -C /etc -xzvf ~/download/radeondrm-firmware-20181218.tgz > > This is not right. Why delete all the amdgpu firmwares? The radeondrm > ones don't replace them. > Why is the above not right? > (btw, downgrading didn't work for my Navi10 card, same freezes, same > errors in dmesg, on 7.0 and on snap) > > Regards, > Emiel -- aer My AMD machine was rock solid stable prior to the change from radeon to amdgpu firmware many months ago. As there have been no further freezes since reverting back to radeon firmware I do not forsee that I will reinstall amdgpu firmware, until I believe, the amdgpu bugs have been fixed. The latest email to you from Chris contains a more helpful reply to and for you than I could. Avon
Re: drmfreeze
Emiel Kollof [em...@kollof.nl] wrote: > Chris Cappuccio schreef op do 21-10-2021 om 07:56 [-0700]: > > > This appears to be a totally different failure than found by Avon. > > It's also on a different class of hardware. > > Is it? The errors seem very similar. Also, Avon's dmesg suggests he's > using amdgpu as well. I wonder why he deletes all the amdgpu firmwares > only to copy over the radeon firmwares. For me, that would break > xenocara. > The errors are totally unrelated in my view. Other than having the same formatting, as they are both generated from the amdgpu framework, they appear to be completely different. Anyways, I didn't even catch that I recommended the wrong firmware. I'm trying to get some traction here so that someone who actually knows more about amdgpu might find a useful report. (A driver bug report with no dmesg is no report!) Under radeondrm, some cards require firmware, most don't. With amdgpu, seems like at least this card doesn't. Avon if you want to try older amdgpu firmwares, 7.0: http://firmware.openbsd.org/firmware/7.0/amdgpu-firmware-20210818.tgz 6.9: http://firmware.openbsd.org/firmware/6.9/amdgpu-firmware-20201218.tgz 6.8: http://firmware.openbsd.org/firmware/6.8/amdgpu-firmware-20200619.tgz 6.7: http://firmware.openbsd.org/firmware/6.7/amdgpu-firmware-20190312.tgz This is not important at this point, it's just another data point in your bug report to know which firmwares succeed and which fail. The right place for the report, including dmesg, is b...@openbsd.org. Chris
Re: drmfreeze
Chris Cappuccio schreef op do 21-10-2021 om 07:56 [-0700]: > This appears to be a totally different failure than found by Avon. > It's also on a different class of hardware. Is it? The errors seem very similar. Also, Avon's dmesg suggests he's using amdgpu as well. I wonder why he deletes all the amdgpu firmwares only to copy over the radeon firmwares. For me, that would break xenocara. > My suggestion to try an older firmware was based on a specific bug > report where someone 1. using Linux had a very similar crash 2. on > very similar hardware, and decided to 3. downgrade firmware and saw > some sort of improvements. Yeah, I tried that. Same result. > > Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* Illegal register access > > in > > command stream > > Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* ring gfx_0.0.0 timeout, > > signaled seq=129772, emitted seq=129774 > > Oct 18 01:52:28 polaris /bsd: [drm] *ERROR* Process information: > > process pid 0 thread Xorg pid 84104 > > > > So, what is this? Is this from before you altered the firmware > version? > Or after? Straight from the most recent snapshot as of the 18th. But I saw the same errors ith downgraded firmware. No need to spam the list with syslog spam since it's the same. > You should report issues like this with debugging information that > represents the stock installation first. I've seen the same error with 7.0 stock, snapshot and snapshot with downgraded hardware. I'm just trying to help pin this down. Right now OpenBSD isn't really useful as a desktop. Regards, Emiel
Re: drmfreeze
On Thu, Oct 21, 2021 at 03:12:33PM -0700, Chris Cappuccio wrote: > Emiel Kollof [em...@kollof.nl] wrote: > > Chris Cappuccio schreef op do 21-10-2021 om 07:56 [-0700]: > > > > > This appears to be a totally different failure than found by Avon. > > > It's also on a different class of hardware. > > > > Is it? The errors seem very similar. Also, Avon's dmesg suggests he's > > using amdgpu as well. I wonder why he deletes all the amdgpu firmwares > > only to copy over the radeon firmwares. For me, that would break > > xenocara. > > > > The errors are totally unrelated in my view. Other than having the > same formatting, as they are both generated from the amdgpu framework, > they appear to be completely different. > > Anyways, I didn't even catch that I recommended the wrong firmware. > I'm trying to get some traction here so that someone who actually > knows more about amdgpu might find a useful report. (A driver bug > report with no dmesg is no report!) > > Under radeondrm, some cards require firmware, most don't. With > amdgpu, seems like at least this card doesn't. > > Avon if you want to try older amdgpu firmwares, > > 7.0: http://firmware.openbsd.org/firmware/7.0/amdgpu-firmware-20210818.tgz > 6.9: http://firmware.openbsd.org/firmware/6.9/amdgpu-firmware-20201218.tgz > 6.8: http://firmware.openbsd.org/firmware/6.8/amdgpu-firmware-20200619.tgz > 6.7: http://firmware.openbsd.org/firmware/6.7/amdgpu-firmware-20190312.tgz > > This is not important at this point, it's just another data point > in your bug report to know which firmwares succeed and which fail. > The right place for the report, including dmesg, is b...@openbsd.org. > > Chris Greetings Chris, My AMD machine was built by me in August 2018. OpenBSD -current was the first OS installed and has been updated every 1-2 weeks since. It caused me random grief from the time that amdgpu firmware was introduced until I removed it the other day (, assuming my memory is still A1-ok). Alas, occasionally it was a number of days between freezes which may be a 'track it down' complication. Considering my August 2018 build date, I will install the 6.7 firmware first and work upwards through the amdgpu firmware, and stop testing them as soon as one creates a freeze. I am sure they all did in the past. Over the next 2-3 days as time permits, I will collate any related information that I can find and submit it to bugs@ as you have suggested. Thanks and regards, Avon -- aer
