Ubiquiti EdgeRouter 4 U-Boot md5sum
Just want to document in the case people are searching for this. OpenBSD 6.6 has no problems booting of the USB and running on Ubiquiti EdgeRouter 4 (tested only USB installation as I didn't want to nuke 4GB eMMC flash storage). However, in spite of having check_md5sum=no option in U-Boot env, bootloader is checking md5sum and automatic boot fails. The version of U-Boot shipped with my device is 2013.07. I am out of fuel tonight and have no clue how to fix the problem. Any suggestions would be appreciated. Best, Predrag P.S. I am aware of this write up https://openwrt.org/toh/ubiquiti/edgerouter.lite but I have not encountered md5sum problems on ER Lite while running OpenBSD. I will have to check U-Boot settings on working devices next time I have physical access to hardware.
Re: Re-organising partitions without re-installation
On 24/12/19 12:51 pm, Edgar Pettijohn wrote: > > On Dec 23, 2019 4:42 PM, rgci...@disroot.org wrote: >> >> December 24, 2019 4:42 AM, "Dumitru Moldovan" wrote: >> one thing that is useful is sysclean(8) >> >> my process now after a doas sysupgrade is >> 1) doas sysclean; and review the output >> 2) vise /etc/sysclean.ignore; so that sysclean ignores special files i >> created > > Just wanted to emphasize step 2 above or else you will delete stuff you > shouldn't. Yes, I just installed it, and ran it through `tee` so I could review the delete list before I passed it to `rm` (and manually edit it). There were a few configuration directories in `/etc` for non-base stuff (e.g. `collectd`'s password file, `vpnc`, etc) that I had to prune out and add to /etc/sysclean.ignore. That put a dint in the used space: > sjl-router# df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/sd0a 129M 77.8M 44.6M64%/ > /dev/sd0k 472M 28.0K448M 0%/home > /dev/sd0d 198M 50.0K188M 0%/tmp > /dev/sd0f 2.3G1.2G 1022M55%/usr > /dev/sd0h 2.1G324M1.6G16%/usr/local > /dev/sd0j 1.3G2.0K1.2G 0%/usr/obj > /dev/sd0i 1.0G2.0K974M 0%/usr/src > /dev/sd0e 209M 73.2M125M37%/var I can understand the update tool being conservative about what it deletes, who knows what is linked to those .so files without scanning each and every ELF binary? (hello Gentoo revdep-rebuild!) Keeping them there is definitely the KISS approach. I'm just re-running `syspatch` to see if I can get the remainder of the patches in. If this fails, I might see if I can dig up some docs on how this disklabel and ffs stuff works and see if I can teach `gparted` about it. Something tells me it's not the complicated mess that LVM2 is, and it handles that just fine. Many thanks all. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Re-organising partitions without re-installation
On Dec 23, 2019 4:42 PM, rgci...@disroot.org wrote: > > December 24, 2019 4:42 AM, "Dumitru Moldovan" wrote: > > > On Sun, Dec 22, 2019 at 10:56:20AM +1000, Stuart Longland wrote: > > > >> So, a few years ago now, I deployed a router VM with OpenBSD 6.1 AMD64. > >> Later that got updated to 6.2, then 6.3, 6.4… > >> > >> Yesterday I updated it to 6.5, then 6.6… now I'm trying to run syspatch: > > > > I have a similar issue with my desktop. I tried to outsmart the > > automatic installer to squeeze as much space as possible for /home on a > > desktop with an 80GB SSD. Which worked out OK for a few upgrade cycles, > > always from stable version to next stable version. > > > > However, after a couple of years, I had to unbreak an update that didn't > > fit any more in /usr. To my surprise, I had lots of old libs from > > previous releases left on disk. Had to manually remove a few of the > > older unused libs from /usr to be able to redo the update successfully. > > > > My understanding is that this is by design. In an update, some libs are > > overwritten (if they keep the same file name), but others are left on > > disk (theoretically unused) when lib versions are incremented. I can > > see a few ways in which this eases updates for people following > > -current, such as the OpenBSD devs, so it's a small price to pay. > > one thing that is useful is sysclean(8) > > my process now after a doas sysupgrade is > 1) doas sysclean; and review the output > 2) vise /etc/sysclean.ignore; so that sysclean ignores special files i created Just wanted to emphasize step 2 above or else you will delete stuff you shouldn't. > 3) doas sysclean | xargs doas rm -rf > > yorosiku ~ > +1 for sysclean
Re: Re-organising partitions without re-installation
On Mon, Dec 23, 2019 at 3:10 PM Stuart Longland wrote: ... > Where do you get `sysclean` from? I don't seem to have it: > > sjl-router# man sysclean > > > man: No entry for sysclean in the manual. > > sjl-router# which sysclean > > which: sysclean: Command not found. > $ pkg_info sysclean Information for http://mirrors.sonic.net/pub/OpenBSD/snapshots/packages/amd64/sysclean-2.8.tgz Comment: list obsolete files between OpenBSD upgrades Description: sysclean is a script designed to help remove obsolete files between OpenBSD upgrades. sysclean compares a reference root directory against the currently installed files, taking files from both the base system and packages into account. sysclean does not remove any files on the system. It only reports obsolete filenames or packages using out-of-date libraries. Maintainer: Sebastien Marie WWW: https://github.com/semarie/sysclean/ $
Re: s-nail copying deleted imap messages to trash
Jon Fineman wrote in <20191224012038.4azmy%...@fineman.me>: |Steffen Nurpmeso wrote: | |> Even better would be |> |> \copy "$@" /tmp/undelete.mbox |> \delete ` |> |> since the messages are collected only once. | |Thanks. | |I was focused on searching for a built in similiar to the way sent uses |"record", that I didn't consider creating a function. Or really just "commandalias delete move" or so? You can prefix \ if you want the real "delete", without commandalias expansion. S-nail v14.9.10, hopefully before next summer, will bring some updates also to the IMAP code. For v15 IMAP however has to go, at least temporary, until our network code no longer uses blocking I/O and signal(3) caused siglongjmp(3), really. But during that the v14.10.* series will be maintained, at least a little. Ciao! |Jon --End of <20191224012038.4azmy%...@fineman.me> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: s-nail copying deleted imap messages to trash
Steffen Nurpmeso wrote: > Even better would be > > \copy "$@" /tmp/undelete.mbox > \delete ` > > since the messages are collected only once. > Thanks. I was focused on searching for a built in similiar to the way sent uses "record", that I didn't consider creating a function. Jon
Re: Re-organising partitions without re-installation
On 24/12/19 8:42 am, rgci...@disroot.org wrote: >> My understanding is that this is by design. In an update, some libs are >> overwritten (if they keep the same file name), but others are left on >> disk (theoretically unused) when lib versions are incremented. I can >> see a few ways in which this eases updates for people following >> -current, such as the OpenBSD devs, so it's a small price to pay. > one thing that is useful is sysclean(8) > > my process now after a doas sysupgrade is > 1) doas sysclean; and review the output > 2) vise /etc/sysclean.ignore; so that sysclean ignores special files i created > 3) doas sysclean | xargs doas rm -rf > > yorosiku ~ Where do you get `sysclean` from? I don't seem to have it: > sjl-router# man sysclean > > man: No entry for sysclean in the manual. > sjl-router# which sysclean > which: sysclean: Command not found. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Raspberry Pi question
On 24/12/19 6:17 am, Strahil Nikolov wrote: > В неделя, 22 декември 2019 г., 20:15:20 ч. Гринуич+2, Stuart Longland > написа: > On 23/12/19 4:03 am, Strahil Nikolov wrote: >>> did anyone try to install openBSD on Raspberry Pi 4B ? >>> I know it's not supported , but maybe it does work :) >> Or maybe not as it's a very different SoC. > >> Core might be an ARM, but it'll have its peripherals in different places >> to that of the Pi 3 and an OS kernel won't be smart enough to figure >> that out without being told. > > thanks for the reply. > > So far I have been using only x86_64 and everything was "ready to go",and I > have never thought about that. Yep, common issue when someone that's used to IBM PC compatibles starts playing with RISC platforms. Particularly when they start playing with ARM, MIPS, SuperH or Motorola 68k, because those CPUs were widely used in many otherwise incompatible hardware designs. Anyone who had played around with the Apple II and Commodore 64, would have noted that almost no non-trivial programs worked on both platforms unmodified even though both machines sported the MOS6502 CPU as brains. (C64 had the VIC-II graphics IC but the Apple II bit-banged its video output for example.) Basically nearly all x86 computers you see are built around the standard defined by IBM when they released their first PC, so the CPU boots up in "real mode" where it pretends to be an overclocked Intel 8086; there's a "BIOS" in non-volatile storage that provides a consistent environment for an OS (these days just used by the boot-loader) and contains routines for communicating with the peripherals needed. The closest x86 comes to breaking away from that was the Apple MacBook which uses UEFI firmware out-of-the-box and only included BIOS compatibility by way of Apple Bootcamp. > Any ideas if Pi 4B will be supported, or I should stick with Linux. Well, I won't speak for the person/team doing the Raspberry Pi port… It's difficult to say though because Broadcom (who make the SoC in the Raspberry Pi) do not publish much in the way of datasheets unless you've signed an NDA with them, and they won't even enter into an NDA with you unless you're going to be buying their parts in the 10s of thousands. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Re-organising partitions without re-installation
December 24, 2019 4:42 AM, "Dumitru Moldovan" wrote: > On Sun, Dec 22, 2019 at 10:56:20AM +1000, Stuart Longland wrote: > >> So, a few years ago now, I deployed a router VM with OpenBSD 6.1 AMD64. >> Later that got updated to 6.2, then 6.3, 6.4… >> >> Yesterday I updated it to 6.5, then 6.6… now I'm trying to run syspatch: > > I have a similar issue with my desktop. I tried to outsmart the > automatic installer to squeeze as much space as possible for /home on a > desktop with an 80GB SSD. Which worked out OK for a few upgrade cycles, > always from stable version to next stable version. > > However, after a couple of years, I had to unbreak an update that didn't > fit any more in /usr. To my surprise, I had lots of old libs from > previous releases left on disk. Had to manually remove a few of the > older unused libs from /usr to be able to redo the update successfully. > > My understanding is that this is by design. In an update, some libs are > overwritten (if they keep the same file name), but others are left on > disk (theoretically unused) when lib versions are incremented. I can > see a few ways in which this eases updates for people following > -current, such as the OpenBSD devs, so it's a small price to pay. one thing that is useful is sysclean(8) my process now after a doas sysupgrade is 1) doas sysclean; and review the output 2) vise /etc/sysclean.ignore; so that sysclean ignores special files i created 3) doas sysclean | xargs doas rm -rf yorosiku ~
Re: Raspberry Pi question
В неделя, 22 декември 2019 г., 20:15:20 ч. Гринуич+2, Stuart Longland написа: On 23/12/19 4:03 am, Strahil Nikolov wrote: > did anyone try to install openBSD on Raspberry Pi 4B ? > I know it's not supported , but maybe it does work :) >Or maybe not as it's a very different SoC. >Core might be an ARM, but it'll have its peripherals in different places >to that of the Pi 3 and an OS kernel won't be smart enough to figure >that out without being told. >-- >Stuart Longland (aka Redhatter, VK4MSL) >I haven't lost my mind... > ...it's backed up on a tape somewhere. Hi Stuart, thanks for the reply. So far I have been using only x86_64 and everything was "ready to go",and I have never thought about that. Any ideas if Pi 4B will be supported, or I should stick with Linux. Best Regards, Strahil Nikolov
Re: s-nail copying deleted imap messages to trash
Steffen Nurpmeso wrote in <20191223200257.kp4kp%stef...@sdaoden.eu>:
|Jon Fineman wrote in <20191223153845.kcdii%...@fineman.me>:
||For current s-nail is there a way with an imap account to copy messages \
||that I
||delete to my ISPs trash folder like the set record=+Sent command copies \
||sent
||message to my sent folder?
||
||Currently they are being permanently deleted.
|
|I would say there are multiple possibilities, if i understand your
|desire correctly. The easiest would likely be a function plus
|a commandalias (or even a key binding).
|
| define my_delete {
|\copy "$@" /tmp/undelete.mbox
|\delete "$@"
Even better would be
\copy "$@" /tmp/undelete.mbox
\delete `
since the messages are collected only once.
|}
| commandalias d '\call my_delete'
|
|And then you say "d *" as before. Just replace my_delete with
|whatever is your desire, but note that this is inefficient unless
|you stay under the same IMAP account (for a while). You could
|also just use \move instead of \copy, which is likely very much
And "move" is likely what you really want.
|more efficient than the above. But there is no automatic and
|builtin way to say, for example, "just let delete do x and y", no.
|
||Thanks.
|
|Hope this help.
|Merry Christmas ;) i wish from Germany,
Ciao.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: s-nail copying deleted imap messages to trash
Hello.
Jon Fineman wrote in <20191223153845.kcdii%...@fineman.me>:
|For current s-nail is there a way with an imap account to copy messages \
|that I
|delete to my ISPs trash folder like the set record=+Sent command copies \
|sent
|message to my sent folder?
|
|Currently they are being permanently deleted.
I would say there are multiple possibilities, if i understand your
desire correctly. The easiest would likely be a function plus
a commandalias (or even a key binding).
define my_delete {
\copy "$@" /tmp/undelete.mbox
\delete "$@"
}
commandalias d '\call my_delete'
And then you say "d *" as before. Just replace my_delete with
whatever is your desire, but note that this is inefficient unless
you stay under the same IMAP account (for a while). You could
also just use \move instead of \copy, which is likely very much
more efficient than the above. But there is no automatic and
builtin way to say, for example, "just let delete do x and y", no.
|Thanks.
Hope this help.
Merry Christmas ;) i wish from Germany,
Ciao,
|Jon
|
|
--End of <20191223153845.kcdii%...@fineman.me>
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Re-organising partitions without re-installation
On Sun, Dec 22, 2019 at 10:56:20AM +1000, Stuart Longland wrote: So, a few years ago now, I deployed a router VM with OpenBSD 6.1 AMD64. Later that got updated to 6.2, then 6.3, 6.4… Yesterday I updated it to 6.5, then 6.6… now I'm trying to run syspatch: I have a similar issue with my desktop. I tried to outsmart the automatic installer to squeeze as much space as possible for /home on a desktop with an 80GB SSD. Which worked out OK for a few upgrade cycles, always from stable version to next stable version. However, after a couple of years, I had to unbreak an update that didn't fit any more in /usr. To my surprise, I had lots of old libs from previous releases left on disk. Had to manually remove a few of the older unused libs from /usr to be able to redo the update successfully. My understanding is that this is by design. In an update, some libs are overwritten (if they keep the same file name), but others are left on disk (theoretically unused) when lib versions are incremented. I can see a few ways in which this eases updates for people following -current, such as the OpenBSD devs, so it's a small price to pay. But yes, it would be awesome if installations that use -stable would not have to pay this price. After all, only libs from current version of the base system should be needed. If you built something linked to an older lib from a previous OS version, it should be recompiled after an updated. This could also be a security issue if you're sloppy and use binaries linked to old base libs that are no longer updated for security issues. If I missed anything, would love to be corrected! And sorry, I don't have a solution for this. Other than the obvious one of packaging the files in base. Is this a heresy?
Re: Readv and writev failing across ethernet
Ingo Schwarze wrote: > +.Pp > +The driver of the device that is being read from > +may return additional errors. > +Such device-specific errors may be documented > +in the section 4 manual pages of the respective drivers. I'm unhappy with the wording "the driver of the device". It is overly precise and inaccurate. Additional errors may come from drivers, but also from subsystems like netinet, net, scsi, etc. So neither driver nor device applies -- additional errors can percolate upwards from a vast list of underlying code. I also worry that programmers won't know what action to take for specific errors. Some may feel they must expect all error values and handle them in different ways (some to be ignored, others as fatal). What is the correct strategy for handling potentially arbitrary errors? This text is leading pepole to expect anything, that this is the new normal, and it is worrisome. It is sad that so many extra errnos have been exposed over the years. Many low-level errors should have been abstracted into existing higher-level catagories, if the effect and disposition are the same, then map the internal condition to the same errno. Or the low-level error should not exist in the first place, the lower level code is simply being sloppy, and the abstraction is incomplete.
Re: Readv and writev failing across ethernet
Philip Guenther wrote:
> On Mon, Dec 23, 2019 at 5:04 AM Raymond, David wrote:
>
> The "timeout" error was numerically 60. Curiously, boards with RTL
> 8111GR chips did not produce these errors, but those with RTL 8111H
> chips did. Unfortunately, this chipset seems to be in a lot of newer
> motherboards.
>
> I didn't use ktrace/kdump. The openmpi software returned the error
> presented by readv/writev.
>
> It sounds like the simplest solution at this point is to try
> non-Realtek pcie network cards. Any suggestions? How are Intel or
> Broadcom cards?
>
> At this point I think you're clearly in the "device driver is buggy"
> situation. If
> this device has an in-tree driver (and not something you're compiling locally
> into your
> kernel) then you should start a new thread starting with a dmesg and a clear
> description of the involved hardware.
At the head of the ioctl function
/*
* Prevent processes from entering this function while another
* process is tsleep'ing in it.
*/
while ((sc->sc_flags & RTWN_FLAG_BUSY) && error == 0)
error = tsleep(>sc_flags, PCATCH, "rtwnioc", 0);
if (error != 0) {
splx(s);
return error;
}
And then the remainder of the driver is very happy to call tsleep, and
a pile of ETIMEDOUT return values, I expect in at least one case this
is returned upwards
But no ktrace -di was performed to figure out what is happening, so shrug.
Re: Readv and writev failing across ethernet
On Mon, Dec 23, 2019 at 6:07 AM Ingo Schwarze wrote: > Theo de Raadt wrote on Sun, Dec 22, 2019 at 05:34:45PM -0700: > > Philip Guenther wrote: > >> Somebody wrote: > > >>> The man pages for readv and writev don't document the possibility of > >>> such errors. > > >> IMO, weird errnos from devices should be documented in the manpage for > the > >> device. Consider the termios(4) manpage, for example. > > > I agree on that. Otherwise the information-flood is too much. > > > > But I think some of our manual pages are a bit weak indicating there > > are other errors not listed: > > Is the following good enough? > > Or are you saying that *all* section 2 and 3 manual pages should be > reworded to say: "FOOBAR may for example fail if:"? > Not all. For section 2 it's the calls that take an fd that need to be open-ended about errors. Philip Guenther
Re: thank you for 6.6 and bsd.rd
Roderick(hru...@gmail.com) on 2019.12.21 19:50:03 +: > > On Thu, 19 Dec 2019, Theo de Raadt wrote: > > > for 6.5 onwards, all you had to was type > > > > sysmerge > > sysupgrade > > I read somewhere that something like this was coming for 6.6, but > I remember that I followed the instructions for upgrading from 6.5 > to 6.6, and this was to be done manually, I had to delete acording > to the instructions some files. > > Since upgrading twice a year is something like a must for OpenBSD, > this new feature is more than welcome, although manual upgrading > was never something difficult. Thanks. You should still read the upgrade guide and indeed you will have to remove some things yourself, in addition to telling you about config and command option changes. For 65 -> 66 there were instructions to remove some old (perl) manpages and old X drivers as well some include files. Nothing really problematic, the worst thing that can happen is that you read an outdated manpage or some 3rd party software will have problems because of an outdated .h file.
Re: Disabling ACPI permanently
On Mon, Dec 23, 2019 at 5:10 AM Radek wrote: > I'm trying to permanently disable acpi doing the following steps[1]. > After the first reboot OS boots fine. > After the second reboot acpi seems to be re-enabled at boot - I get [2]. > What Am I doing wrong? > First, you should also check whether there's a newer BIOS firmware for this box, as there's a good chance Intel has fixed issues and issued a new one. If so, installing that may totally resolve the issue. If not, or if upgrading the firmware doesn't resolve this, then you should next send a bug report to b...@openbsd.org using sendbug. To get the most data when you do so, disable _just_ the acpipci device (using boot -c) instead of all of acpi and then run sendbug as root on that system. The bug report will then include the data from the ACPI tables, so that the driver can be fixed to deal with this. ... > acpipci0 at acpi0 PCI0panic: malloc: allocation too large, type = 33, size > = 292057776136 > Philip Guenther
Re: Readv and writev failing across ethernet
On Mon, Dec 23, 2019 at 5:04 AM Raymond, David wrote: > The "timeout" error was numerically 60. Curiously, boards with RTL > 8111GR chips did not produce these errors, but those with RTL 8111H > chips did. Unfortunately, this chipset seems to be in a lot of newer > motherboards. > > I didn't use ktrace/kdump. The openmpi software returned the error > presented by readv/writev. > > It sounds like the simplest solution at this point is to try > non-Realtek pcie network cards. Any suggestions? How are Intel or > Broadcom cards? > At this point I think you're clearly in the "device driver is buggy" situation. If this device has an in-tree driver (and not something you're compiling locally into your kernel) then you should start a new thread starting with a dmesg and a clear description of the involved hardware. Philip Guenther
s-nail copying deleted imap messages to trash
For current s-nail is there a way with an imap account to copy messages that I delete to my ISPs trash folder like the set record=+Sent command copies sent message to my sent folder? Currently they are being permanently deleted. Thanks. Jon
Re: Readv and writev failing across ethernet
Hi, Theo de Raadt wrote on Sun, Dec 22, 2019 at 05:34:45PM -0700: > Philip Guenther wrote: >> Somebody wrote: >>> The man pages for readv and writev don't document the possibility of >>> such errors. >> IMO, weird errnos from devices should be documented in the manpage for the >> device. Consider the termios(4) manpage, for example. > I agree on that. Otherwise the information-flood is too much. > > But I think some of our manual pages are a bit weak indicating there > are other errors not listed: Is the following good enough? Or are you saying that *all* section 2 and 3 manual pages should be reworded to say: "FOOBAR may for example fail if:"? Yours, Ingo Index: read.2 === RCS file: /cvs/src/lib/libc/sys/read.2,v retrieving revision 1.36 diff -u -r1.36 read.2 --- read.2 30 Sep 2016 10:53:11 - 1.36 +++ read.2 23 Dec 2019 13:58:41 - @@ -228,6 +228,11 @@ .Fa iov points outside the process's allocated address space. .El +.Pp +The driver of the device that is being read from +may return additional errors. +Such device-specific errors may be documented +in the section 4 manual pages of the respective drivers. .Sh SEE ALSO .Xr dup 2 , .Xr fcntl 2 , Index: write.2 === RCS file: /cvs/src/lib/libc/sys/write.2,v retrieving revision 1.42 diff -u -r1.42 write.2 --- write.2 6 Sep 2019 19:25:08 - 1.42 +++ write.2 23 Dec 2019 13:58:41 - @@ -286,6 +286,11 @@ .It Bq Er ENOBUFS The system lacked sufficient buffer space or a queue was full. .El +.Pp +The driver of the device that is being written to +may return additional errors. +Such device-specific errors may be documented +in the section 4 manual pages of the respective drivers. .Sh SEE ALSO .Xr fcntl 2 , .Xr lseek 2 ,
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
On 2019-12-23, Jan Betlach wrote: > > Isn’t it commented out by default? # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. >> nobody about the $subject? :) >> >> Why isn't ChallengeResponseAuthentication NO in sshd_config by >> default? >> >> It would be more secure, afaik. Would it? On OpenBSD skey is set in /etc/login.conf but skey itself is not enabled unless you follow skeyinit(1) steps. The other challenge-response mechanism (login_token) is not set in default /etc/login.conf. Maybe it's still worth doing, but it's not as important as on OS using PAM where "ChallengeResponseAuthentication yes" can often also result in permitting password-based logins which you might not expect if you've set "PasswordAuthentication no".
Re: Readv and writev failing across ethernet
The "timeout" error was numerically 60. Curiously, boards with RTL 8111GR chips did not produce these errors, but those with RTL 8111H chips did. Unfortunately, this chipset seems to be in a lot of newer motherboards. I didn't use ktrace/kdump. The openmpi software returned the error presented by readv/writev. It sounds like the simplest solution at this point is to try non-Realtek pcie network cards. Any suggestions? How are Intel or Broadcom cards? Dave Raymond On 12/22/19, Theo de Raadt wrote: > Philip Guenther wrote: > >> > The man pages for readv and writev don't document the possibility of >> > such errors. >> >> >> IMO, weird errnos from devices should be documented in the manpage for >> the >> device. Consider the termios(4) manpage, for example. > > I agree on that. Otherwise the information-flood is too much. > > But I think some of our manual pages are a bit weak indicating there > are other errors not listed: > > ERRORS > read(), readv(), pread(), and preadv() will succeed unless: > [...] > In addition, read() and readv() may return the following errors: > [...] > read() and pread() may return the following error: > [...] > pread() and preadv() may return the following errors: > [...] > readv() and preadv() may return one of the following errors: > [...] > SEE ALSO > > Written that way, it is easy for some folk to conclude the list is > complete, and no other errors could pop out. We have more experience > and recognize slightly more unique error returns are valuable. > > Maybe it needs a bit of "Amongst our errors...", can we force jmc or > ingo into a fancy chair to review the situation? > -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Disabling ACPI permanently
Hello, I'm trying to permanently disable acpi doing the following steps[1]. After the first reboot OS boots fine. After the second reboot acpi seems to be re-enabled at boot - I get [2]. What Am I doing wrong? [1] boot -c UKC>disable acpi 444 acpi0 disabled UKC>quit Continuing... [...] mv /bsd /bsd.old config -e -o /bsd /bsd.old OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 01:58:46 MST 2019 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Enter 'help' for information ukc> disable acpi 444 acpi0 disabled ukc> quit Saving modified kernel. [2] OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 01:58:46 MST 2019 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1047724032 (999MB) avail mem = 1003417600 (956MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfcd70 (77 entries) bios0: vendor Intel Corp. version "BA72210A.86B.0228.2005.1122.2349" date 11/22/2005 bios0: MAXDATA PLATINUM 100 I M5 acpi0 at bios0: ACPI 2.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG ASF! WDDT acpi0: wakeup devices PEGP(S4) P0P2(S4) AC97(S4) USB0(S1) USB1(S1) USB2(S1) USB3(S1) USB7(S1) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) AZAL(S4) PWRB(S4) 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) Celeron(R) CPU 3.06GHz, 3067.28 MHz, 0f-04-09 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,DTES64,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR,NXE,LONG,LAHF,MELTDOWN cpu0: 256KB 64b/line 4-way L2 cache mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEGP) acpiprt2 at acpi0: bus 6 (P0P2) acpiprt3 at acpi0: bus 5 (PEX1) acpiprt4 at acpi0: bus 4 (PEX2) acpiprt5 at acpi0: bus 3 (PEX3) acpicpu0 at acpi0: C1(@1 halt!) acpipwrres0 at acpi0: URP1 acpipwrres1 at acpi0: FDDP acpipwrres2 at acpi0: LPTP acpipwrres3 at acpi0: URP2 acpipci0 at acpi0 PCI0panic: malloc: allocation too large, type = 33, size = 292057776136 Stopped at db_enter+0x10: popq%rbp TIDPIDUID PRFLAGS PFLAGS CPU COMMAND * 0 0 0 0x1 0x2000 swapper db_enter(10,82281280,202,8,812c2e00,82281280) at db_ent er+0x10 panic(81c2af40,81c2af40,8007a088,21,0,440008) at pa nic+0x128 malloc(440008,21,9,440008,8642e84c095b2331,8007a088) at malloc+ 0x6d9 aml_parse(8007a088,74,0,8007a088,e233b61729a271c4,8007a 088) at aml_parse+0x1734 aml_parse(8007a088,54,c,8007a088,e233b61729a286b7,8007a 088) at aml_parse+0x54c aml_eval(0,80072608,74,82281700,82281700,0) at aml_eval +0x33f aml_evalnode(800725ac,80072588,4,82281700,82281 820,800725ac) at aml_evalnode+0xb5 acpipci_attach(80021400,80079d80,82281970,80021 400,f736340b0bc20316,80021400) at acpipci_attach+0xf7 config_attach(80021400,81f06328,82281970,81aa8a 50,472b3934561bab9a,80041708) at config_attach+0x1ee acpi_foundhid(80041708,80021400,c02f249ab5605f64,81aabc c0,80021400,80041188) at acpi_foundhid+0x2dc aml_find_node(80041188,81c413d0,81aabcc0,800214 00,c1874c1cd841fb5c,81aabcc0) at aml_find_node+0x84 aml_find_node(80023a88,81c413d0,81aabcc0,800214 00,c1874c1cd841fb5c,81aabcc0) at aml_find_node+0xb1 aml_find_node(81f90200,81c413d0,81aabcc0,800214 00,c1874c1cd8e35490,82281b50) at aml_find_node+0xb1 acpi_attach_common(80021400,f5600,f55897af781bc332,80023180,fff f82281c58,81f31230) at acpi_attach_common+0x7ad end trace frame: 0x82281c40, count: 0 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> -- Radek
Re: What do you use to generate invoices on OpenBSD?
On Sat, 21 Dec 2019 23:57:07 + Mikolaj Kucharski wrote: > Do you generate invoices on OpenBSD? Yes Mikolaj, only about 1~2 some weeks. > What do you recommend? LibreOffice. Then I export the .odt as a .pdf, which is emailed with comments. Low volume, so good enough for me! Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
Isn’t it commented out by default? Jan Hello, nobody about the $subject? :) Why isn't ChallengeResponseAuthentication NO in sshd_config by default? It would be more secure, afaik. Many thanks. Sent: Thursday, December 19, 2019 at 7:58 PM From: "lu hu" To: misc@openbsd.org Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? Sent: Wednesday, December 18, 2019 at 9:49 PM From: "Bodie" To: misc@openbsd.org, owner-m...@openbsd.org Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? On 18.12.2019 18:48, lu hu wrote: Hello, # what am I talking about? https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication ChallengeResponseAuthentication Specifies whether challenge-response authentication is allowed. All authentication styles from login.conf(5) are supported. The default is yes. # what does linux distros use: If I ex.: read: https://access.redhat.com/solutions/336773 then I can see ChallengeResponseAuthentication is NO for security reasons. Ubuntu too. # what else says ChallengeResponseAuthentication should be NO? https://www.openwall.com/lists/oss-security/2019/12/04/5 -> These issues were quickly fixed in OpenBSD as you can see in Security This isn't related to the subject. 1. CVE-2019-19521: Authentication bypass this attack should be more mitigated if ChallengeResponseAuthentication would be by default set to NO. # FIX: from this: cat /etc/ssh/sshd_config ... # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes ... to this: vi /etc/ssh/sshd_config cat /etc/ssh/sshd_config ... # Change to no to disable s/key passwords ChallengeResponseAuthentication no ... But of course by default, without fixing sshd_config it should be NO. Who the hell uses s/key with sshd nowadays? And you are aware that this option is not there just for S/Key, right? It's for example PAM Google authenticator too on Linux and others I think you missed couple of points. Eg.: https://www.openbsd.org/faq/faq10.html#SKey and the fact that login.conf(5) on OpenBSD by default enables S/Key. I checked the https://www.openbsd.org/faq/faq10.html#SKey first step is to have a /etc/skey dir. So checked it: 66# ls /etc/skey ls: /etc/skey: No such file or directory 66# There is no /etc/skey by default. So you have to do the "skeyinit -E" as root, etc. Same for Google authenticator, etc. So ChallengeResponseAuthentication should be only enabled then.. when you set up extra auth methods. So afaik skey isn't enabled by default on OpenBSD, but for still some unkown reason (for me) ChallengeResponseAuthentication is set to yes by default on OpenBSD. Why? So please, can we make the default sshd_config more secure and set the "ChallengeResponseAuthentication to NO"? Some practical examples at hand of the current vulnerability which will make this change reasonable? It is about proactive security, to avoid future possible security issues. Many thanks and whishing a peaceful xmas!
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
Hello, nobody about the $subject? :) Why isn't ChallengeResponseAuthentication NO in sshd_config by default? It would be more secure, afaik. Many thanks. > Sent: Thursday, December 19, 2019 at 7:58 PM > From: "lu hu" > To: misc@openbsd.org > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > > Sent: Wednesday, December 18, 2019 at 9:49 PM > > From: "Bodie" > > To: misc@openbsd.org, owner-m...@openbsd.org > > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > > > > > > > On 18.12.2019 18:48, lu hu wrote: > > > Hello, > > > > > > > > > # what am I talking about? > > > > > > https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication > > > > > > ChallengeResponseAuthentication > > > Specifies whether challenge-response authentication is allowed. All > > > authentication styles from login.conf(5) are supported. The default is > > > yes. > > > > > > > > > # what does linux distros use: > > > > > > If I ex.: read: > > > > > > https://access.redhat.com/solutions/336773 > > > > > > then I can see ChallengeResponseAuthentication is NO for security > > > reasons. Ubuntu too. > > > > > > > > > # what else says ChallengeResponseAuthentication should be NO? > > > > > > https://www.openwall.com/lists/oss-security/2019/12/04/5 > > > -> > > > > These issues were quickly fixed in OpenBSD as you can see in Security > > > > This isn't related to the subject. > > > > > > 1. CVE-2019-19521: Authentication bypass > > > > > > this attack should be more mitigated if > > > ChallengeResponseAuthentication would be by default set to NO. > > > > > > > > > # FIX: > > > > > > from this: > > > cat /etc/ssh/sshd_config > > > ... > > > # Change to no to disable s/key passwords > > > #ChallengeResponseAuthentication yes > > > ... > > > > > > to this: > > > vi /etc/ssh/sshd_config > > > cat /etc/ssh/sshd_config > > > ... > > > # Change to no to disable s/key passwords > > > ChallengeResponseAuthentication no > > > ... > > > > > > But of course by default, without fixing sshd_config it should be NO. > > > > > > Who the hell uses s/key with sshd nowadays? > > > > > > > And you are aware that this option is not there just for S/Key, right? > > It's for example PAM Google authenticator too on Linux and others > > > > I think you missed couple of points. Eg.: > > > > https://www.openbsd.org/faq/faq10.html#SKey > > > > and the fact that login.conf(5) on OpenBSD by default enables S/Key. > > > > I checked the https://www.openbsd.org/faq/faq10.html#SKey > > first step is to have a /etc/skey dir. So checked it: > > 66# ls /etc/skey > ls: /etc/skey: No such file or directory > 66# > > There is no /etc/skey by default. So you have to do the "skeyinit -E" as > root, etc. Same for Google authenticator, etc. So > ChallengeResponseAuthentication should be only enabled then.. when you set up > extra auth methods. > > So afaik skey isn't enabled by default on OpenBSD, but for still some unkown > reason (for me) ChallengeResponseAuthentication is set to yes by default on > OpenBSD. > > Why? > > > > > > > > > > So please, can we make the default sshd_config more secure and set the > > > "ChallengeResponseAuthentication to NO"? > > > > > > > Some practical examples at hand of the current vulnerability which will > > make this change reasonable? > > It is about proactive security, to avoid future possible security issues. > > > > > > Many thanks and whishing a peaceful xmas! > > > > > >
Re: OpenBSD pf - redirect all DNS queries to local DNS server
rdr-to works perfectly! my hair is droppng off from the speed, without
ADs :) Many thanks. Wishing a great year-end for everybody!! Sent: Thursday,
December 19, 2019 at 8:50 PM
From: "Anthony O' Brien"
To: "lu hu"
Cc: misc@openbsd.org
Subject: Re: OpenBSD pf - redirect all DNS queries to local DNS server
Long time reader, first time writing in... > The big question: Is there
any DOC for OpenBSD about this? What pf rules > needed to redirect any
DNS server (ex.: 8.8.8.8 or 1.1.1.1) requests to the > DNS server running
on the ROUTER, coming from the CLIENTS?
You can use rdr-to[0] with pf to redirect all DNS queries to the DNS
resolver running on the router. A rule in pf.conf would look something
like:
pass in on $int_if proto { udp , tcp } from any to any port domain \
rdr-to $dns_server port domain
Ted Unangst has short write-up about turning your network inside out to
do
just this[1].
[0]: https://man.openbsd.org/pf.conf.5#rdr-to
[1]:
https://flak.tedunangst.com/post/turn-your-network-inside-out-with-one-pfconf-trick
