Re: Userland PCI drivers possible in OpenBSD?
On Fri, Jan 10, 2020 at 07:23:26PM -0500, gwes wrote: On 1/9/20 10:58 PM, Joseph Mayer wrote: Maybe this topic is better suited for tech@, you tell: Is there some way I can implement PCI drivers in userland in OpenBSD? Is there any reason not to write a conventional device driver and build an OS including that driver? You and/or the original poster may want to look at MirageOS: https://mirage.io/ Depending on the application, the custom-unikernel approach may offer an otherwise-impossible combination of performance and security.
Re: What is you motivational to use OpenBSD
Why do I like openbsd? I used linux for several decades and it has become harder and harder to keep up with gratuitous changes and to keep my 20+ machines running and updated. The last straw was usb mounting being broken in the linux kernel for 6 months. Really! The whole linux enterprise seems to be spinning out of control as it gets jerked around by commercial interests. OpenBSD is easy to install and use and retains some of the delightful simplicity of early days UNIX. I can mostly get done what I need to get done and I am working on the rest. The emphasis on security in this increasingly hostile digital world is certainly a plus as well. Dave Raymond On 1/10/20, Christopher Turkel wrote: > On Friday, January 10, 2020, Raul Miller wrote: > >> On Wed, Aug 28, 2019 at 10:41 AM Mohamed salah >> wrote: >> > I wanna put something in discussion, what's your motivational to use >> > OPENBSD what not other bsd's what not gnu/Linux, if something doesn't >> work >> > fine on openbsd and you love this os so much what will do? >> >> I wanted a machine with tcp and udp but which wasn't listening for rpc >> requests, and OpenBSD was the quickest way for me to get there. >> >> Thanks, >> >> -- >> Raul >> >> > It’s the easiest OS I’ve ever used. > -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Re: Userland PCI drivers possible in OpenBSD?
On Fri, Jan 10, 2020 at 03:58:16AM +, Joseph Mayer wrote: > Maybe this topic is better suited for tech@, you tell: > > Is there some way I can implement PCI drivers in userland in OpenBSD? In light of the other responses I think the best you could expect is PCI passthrough to a virtual machine. But you'd first need to add support for IOMMU and SR-IOV to OpenBSD vmm(4). Judging by some passing mailing-list comments, I believe such support is welcome in principle. In some ways such a setup is rather elegant, ignoring the incredible hardware and firmware complexity hidden in the CPU and controllers. You don't get to expose the device through typical subsystem interfaces (unless there's a userland bridge like vscsi(4) or fuse(4)), but the driver could otherwise look and interact like any other process, supporting UNIX domain sockets and other common userland IPC interfaces.
Re: Userland PCI drivers possible in OpenBSD?
On 1/9/20 10:58 PM, Joseph Mayer wrote: Maybe this topic is better suited for tech@, you tell: Is there some way I can implement PCI drivers in userland in OpenBSD? Is there any reason not to write a conventional device driver and build an OS including that driver? While the kernel environment for a device driver is admittedly complex, it's likely that there are enough examples and historical information in published papers and mailing list history to help. There are a lot of drivers to look at for clues. There may be a driver which you could extend or adapt to your needs. Adding an IOCTL, for instance, might suffice. Long established policy is that your driver is not supported in any way. Questions which show full research beforehand and good comprehension of the kernel environment are sometimes answered. Ones showing little diligence beforehand are ignored or laughed at. Geoff Steckel
Re: What is you motivational to use OpenBSD
On Friday, January 10, 2020, Raul Miller wrote: > On Wed, Aug 28, 2019 at 10:41 AM Mohamed salah > wrote: > > I wanna put something in discussion, what's your motivational to use > > OPENBSD what not other bsd's what not gnu/Linux, if something doesn't > work > > fine on openbsd and you love this os so much what will do? > > I wanted a machine with tcp and udp but which wasn't listening for rpc > requests, and OpenBSD was the quickest way for me to get there. > > Thanks, > > -- > Raul > > It’s the easiest OS I’ve ever used.
Re: Userland PCI drivers possible in OpenBSD?
Johannes, Joseph asked a fair question and he got a direct answer and a reason for it from two developers. It may not be the answer that he wanted but the reason for not implementing what very experienced developers and computer scientists determined that usermode PCI drivers like that would introduce an unacceptable security risk for the OS and its users As a user who wants increased performance yeah Usermode PCI drivers sound awesome. DPDK and VPP all that stuff sound awesome for Networking ... but they carry a heightened risk for instance one of the recent Intel CVEs involved using Direct I/O feature which bascally taking packets from a Nic and shoving them directly to CPU Cache ... (one might guess at a glance why such features increase performance but also increase the risk to the OS that happens to be running on that same CPU ) so optimizations / short cuts or using little known or little documented features of hardware which lack the safeguards that the Kernel has built into it is not such a hot idea... again if you can make things secure and more performant and address the inherent risks associated with what is being asked I think having a go at Devs is not the best way forward... Regards, Tom Smyth On Fri, 10 Jan 2020 at 21:08, Johannes Krottmayer wrote: > > On 10.01.20 at 17:26, Theo de Raadt wrote: > > We won't help you because we oppose the lack of a security barrier > > in such designs. > > Detailed explanation (for us stupid users), please. > > The same non-response answer. Same with my (simple) User-Space GPIO > driver. > > Please don't get wrong, but I had the opportunity to use OpenBSD as > embedded OS for my future projects (primary control units). I had to > change the scheduler, for real-time support and some other changes. > > Why at this time OpenBSD? > - For me a good driver base > - good code quality (I have learned much new coding techniques from > the code) > - That's all > > Now without a little help from you? > I started my own kernel. But beware, I start from the "void". Don't > use any existing code from OpenBSD or other projects. Currently I > have enough time to do this. Do you really think I'm stupid for > (referring to other dismissive words to my person from you in the > list) this? Maybe, but beware you don't know any of my other (closed) > projects. > > You want kick me from the lists? Do it. Then I know your nature. > -- Kindest regards, Tom Smyth.
Re: Userland PCI drivers possible in OpenBSD?
Raw physical memory is not exported at all, not even to root. That is not going to change. Johannes Krottmayer wrote: > On 10.01.20 at 17:26, Theo de Raadt wrote: > > We won't help you because we oppose the lack of a security barrier > > in such designs. > > Detailed explanation (for us stupid users), please. > > The same non-response answer. Same with my (simple) User-Space GPIO > driver. > > Please don't get wrong, but I had the opportunity to use OpenBSD as > embedded OS for my future projects (primary control units). I had to > change the scheduler, for real-time support and some other changes. > > Why at this time OpenBSD? > - For me a good driver base > - good code quality (I have learned much new coding techniques from > the code) > - That's all > > Now without a little help from you? > I started my own kernel. But beware, I start from the "void". Don't > use any existing code from OpenBSD or other projects. Currently I > have enough time to do this. Do you really think I'm stupid for > (referring to other dismissive words to my person from you in the > list) this? Maybe, but beware you don't know any of my other (closed) > projects. > > You want kick me from the lists? Do it. Then I know your nature.
Re: Userland PCI drivers possible in OpenBSD?
On 10.01.20 at 17:26, Theo de Raadt wrote: > We won't help you because we oppose the lack of a security barrier > in such designs. Detailed explanation (for us stupid users), please. The same non-response answer. Same with my (simple) User-Space GPIO driver. Please don't get wrong, but I had the opportunity to use OpenBSD as embedded OS for my future projects (primary control units). I had to change the scheduler, for real-time support and some other changes. Why at this time OpenBSD? - For me a good driver base - good code quality (I have learned much new coding techniques from the code) - That's all Now without a little help from you? I started my own kernel. But beware, I start from the "void". Don't use any existing code from OpenBSD or other projects. Currently I have enough time to do this. Do you really think I'm stupid for (referring to other dismissive words to my person from you in the list) this? Maybe, but beware you don't know any of my other (closed) projects. You want kick me from the lists? Do it. Then I know your nature.
Re: What is you motivational to use OpenBSD
On Wed, Aug 28, 2019 at 10:41 AM Mohamed salah wrote: > I wanna put something in discussion, what's your motivational to use > OPENBSD what not other bsd's what not gnu/Linux, if something doesn't work > fine on openbsd and you love this os so much what will do? I wanted a machine with tcp and udp but which wasn't listening for rpc requests, and OpenBSD was the quickest way for me to get there. Thanks, -- Raul
Re: Display flickers after upgrade to 6.6
On Fri, Jan 10, 2020 at 10:18:51AM -0700, Stanislav wrote: I have got weak flickering of XFCE too (after upgrade to 6.6). Mentioned setting the method for vblank does not fix it. Turning on/off compositor does not help too. Any ideas? Have you tried customizing xorg.conf? This /etc/X11/xorg.conf works for me in 6.6 with the Radeon HD 4200 video chipset from my old desktop: Section "Device" Identifier "drm0" Driver "radeon" Option "AccelMethod" "glamor" Option "DRI" "3" Option "TearFree" "On" Option "SWCursor" "true" EndSection Still getting a bit of glitches when resuming, but mostly just for the current window (the terminal) and it's usually enough to change the active "window" in tmux to get rid of it. Rarely do I have to change to console and back with CTRL-ALT-F1 and CTRL-ALT-F5. Had more issues with the older driver (and default settings), so I'm actually happy with the upgrade in this regard.
Re: Display flickers after upgrade to 6.6
I have got weak flickering of XFCE too (after upgrade to 6.6). Mentioned setting the method for vblank does not fix it. Turning on/off compositor does not help too. Any ideas? - Best Regards, Stanislav Gilmulin -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Android (MTP) with OpenBSD: Tiny success story
Let me tell misc@ about this case with Samsung GN7000 (2011). simple-mtpfs does not work with this phone. MTP connection is established but transferring is empty. umass works fine (OpenBSD 6.4, 6.5, 6.6). "Settings" -> "USB Computer Connection". When this mode is activated on the connected phone, the commands are smth might be like these: $ tail /var/log/messages | grep sd2 # disklabel sd2 # mount -t msdos /dev/sd2i /mnt/android devel/adb port can not be installed as is due to "libraries do not match" error (OpenBSD 6.6). Actually I have caught the behavior recently and I have not investigated it yet. - Best Regards, Stanislav Gilmulin -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: What is you motivational to use OpenBSD
I consider my way as quite typical path to become OpenBSD-newbie. 1.5 years ago I decided to remove Windows 10 from my home notebook. Why not Linux? I have own experience in using Linux distros for work/home purposes on many machines. Actually Im not advanced but I pretend to have the confident opinion. At the first stage I made smth like table about well-known modern GNU\Linux distros with the pros and cons. I hoped to catch optimal solution for non-specific purposes. This approach failed due to classical "linux is a mess". I finished the review deciding to install Debian if OpenBSD-try fails on my notebook. Generally "Linux" is practically more convenient distro at the moment, but there are bad trends in linux world too as I see. Second, If I need to explain my final decision based on its esthetic component I declare that I want the elegant system with own straight way according to my understanding. I love holistic and consistent things. Why not FreeBSD? I was running it as desktop in 2007 on my home PC and I had few episodes with maintaining it remotely and as half-dead body in DC. Good modern system. It has own strong features and advantages. But none of them helps to choose FreeBSD as desktop or laptop in 2018 without any doubts. I think its true (IMHO) in 2020 too. Finally, I observe smth like crisis in FreeBSD's growth. Its future is not clear. Of course, future is not absolutely clear always and everywhere, but Im sure you understand what I mean. Sorry, FreeBSD-people. Let me stop to list rejected systems here. The full list of technical points I compared is too boring. And, of course, small note is not good option to tell why I reject each specific distro. OpenBSD was just experiment. I wanted to test it. Now I stay with OpenBSD. It is cool. OK, so, this experiment has the result. I tend to call it positive. The migration from Windows 10 to OpenBSD 6.4 completed successfully in short time (week). I guarantee that the function volume and comfort have not decreased dramatically. What I have got now as profit? First of all, I think it is not correct when one writes similar report in economic terms. OpenBSD project is not commercial. It is not product I think. For me it is interesting project with strong basement consisted of clear principles, strong team, long history, own community and clear future. In Linux area we have got huge size of community, and for practical purposes it is optimal to be with Linux, because scale helps user to find answers, it provides wide spectra of software for every task. In OpenBSD users has got not so rich economics. The obvious fact is "if you want your best system you need to contribute and to do smth for the project". So, what is my profit (vs Windows)? I have old-school transparent OS: https://www.openbsd.org/lyrics.html#46 https://www.openbsd.org/lyrics.html#45 https://www.openbsd.org/lyrics.html#61 My computer works fully on my own tasks; my data is only my data; unix-way; correctness; proactive security; controlled reboot and update; I have not extra and imposed stuff. I thank all participants of the OpenBSD project (developers, devops etc) and all OpenBSD users. I thank OpenBSD Foundation and its contributors for their help. Disclaimer. I love Windows and I continue using it due to current work. Windows is product for certain areas. OpenBSD and Windows are not competitors. But OpenBSD is quite universal instrument and I hope to install it instead of Windows soon where it is depends on me and if it is possible technically and legally. The reason why I will do it is just desire to increase experience for the project. Few words additionally. To be honest I have to say that I use wi-fi via usb-adapter because my on-board card doesn't work here. If you migrate please check you hardware using available information. The situation is very good, you have good chances to launch OpenBSD without appearing troubles. Perhaps, the another option would be to build the best configuration for your OpenBSD-PC. Share your experience ! - Best Regards, Stanislav Gilmulin -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Userland PCI drivers possible in OpenBSD?
We won't help you because we oppose the lack of a security barrier in such designs. Joseph Mayer wrote: > Maybe this topic is better suited for tech@, you tell: > > Is there some way I can implement PCI drivers in userland in OpenBSD? > > On a quick Internet search, see some discussion for Linux and NetBSD > e.g. [1] however nothing in OpenBSD. > > I may be interested in operating some PCI device manually from my own > program (run as root or user) in OpenBSD, and I can see this being of > interest to others also, asking therefore. > > (I could understand if this would require IOMMU support to be safe.) > > OpenBSD overall is totally great so I'd prefer running an userland > driver in OpenBSD over another OS. > > Thanks, > Joseph > > [1] https://wiki.netbsd.org/projects/project/userland_pci/ , > https://news.ycombinator.com/item?id=16671852 >
Re: Fan Art submission
On Fri, Jan 10, 2020 at 02:04:23PM +0100, Peter J. Philipp wrote: > This morning I was doodling with my Wacom tablet on my Workstation running > OpenBSD-current (a few days older). Gimp 2.10 crashed, and I thought I lost > the image forever but then I was able to restore it next run. While showing > it off I merged it (with bucketfill) with a van gogh (I don't know if it's the > real van gogh though, I have it a little different in memory) and it turned > out really attractive. I'd like to turn it over for fan art: > > https://www.centroid.eu/blog/c?article=1578660423 > > and here is the original: > > https://centroid.eu/private/puffy67.png > > Cheers! I did some more research, the "starry night" painting by vincent van gogh is actually in the public domain. And there is a higher resolution painting of this. Feel free to duplicate the process I did (copy into clipboard, bucketfill from clipboard) to get a poster quality. I also give permission to nicen it, to anyone. It was a lost doodle art anyhow due to the segfault of gimp and I didn't expect it to re-appear anymore. Here is the high resolution "starry night" among other paintings of his: https://www.rawpixel.com/board/537381/vincent-van-gogh Thanks! -peter
Fw: Re: openiked.org down?
Hello? https://www.openiked.org/ is still down. Thanks. > Sent: Tuesday, January 07, 2020 at 8:27 PM > From: "lu hu" > To: direct...@openbsdfoundation.org > Subject: Fw: Re: openiked.org down? > > Hello, > > can you please help to bring back > > https://www.openiked.org/ > > to life? someone even updated the wiki page to > https://en.wikipedia.org/wiki/OpenIKED > > > > Sent: Sunday, January 05, 2020 at 3:10 PM > > From: "lu hu" > > To: misc@openbsd.org, t...@openbsd.org > > Subject: Re: openiked.org down? > > > > who can bring up openiked.org to life? > > > > > Sent: Tuesday, December 31, 2019 at 4:14 PM > > > From: "Umgeher Torgersen" > > > To: misc@openbsd.org > > > Subject: Re: openiked.org down? > > > > > > yeah, it's down... > > > > > > ; <<>> DiG 9.4.2-P2 <<>> openiked.org > > > ;; global options: printcmd > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58691 > > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > > > > > ;; QUESTION SECTION: > > > ;openiked.org. IN A > > > > > > ;; AUTHORITY SECTION: > > > openiked.org. 2496IN SOA > > > a.ns.bsws.de. noc.bsws.de. 1577745128 1 3600 604800 86400 > > > > > > ;; Query time: 0 msec > > > ;; SERVER: 10.0.5.5#53(10.0.5.5) > > > ;; WHEN: Tue Dec 31 15:14:22 2019 > > > ;; MSG SIZE rcvd: 82 > > > > > > On Tue, Dec 31, 2019 at 03:08:47PM +0100, lu hu wrote: > > > > Hello, > > > > > > > > did anyone noticed that the https://openiked.org/ is down? > > > > > > > > NO "A" record is associated with the domain? > > > > > > > > Thanks for any infos. > > > > > > > > > > > > > >
Re: Awaiting a diff
Hi, Consus wrote on Fri, Jan 10, 2020 at 12:52:44PM +0300: > On 20:06 Thu 09 Jan, Marc Espie wrote: >> It's been that way for ages. But no-one volunteered >> to work on this. > Anyone even knows about this? Aside from OpenBSD developers (who > have their plates full already) how an average person can find out > that there is rusty piece of code that should be taken care of? I believe it was said before, but it appears to be easily forgotten: Maintaining TODO lists consumes time. For a small system that you do a lot of work on, the time required for the maintenance of a TODO list is not prohibitive; that's why https://cvsweb.bsd.lv/mandoc/TODO exists. But for a large sytem (like OpenBSD as a whole), maintaining a high-quality TODO list is much harder, in particular for a person who doesn't know the details of all the parts inside out. And those few developers who do know (almost) all the parts inside out are those who can least afford to take on yet another job. Besides, the usefulness of public TODO lists is usually vastly overestimated. I have some actual data on that. The above TODO list concerns the implementation of a POSIX.1 utility that, as of today, is included and used by default in eight operating systems (OpenBSD, Alpine Linux, Void Linux, Unleashed, Termux, FreeBSD, NetBSD, illumos), included by default in two more (DragonFly BSD, Minix 3) and available as an optional package for ten more (Debian, Ubuntu, NixOS, Gentoo, Fedora, Arch, Slackware, Crux, openSUSE, MacOS). So it does have a substantial user base. The TODO list has been available online and continuously maintained for more than nine years now, since May 2010. Since October 2013, see below for a complete list of committed patches that were sent in by developers other than Kristaps and myself. The metric that i can easily extract from this data is contributors times releases: if a contributor sent patches during multiple release cycles, they are counted multiple times, but if a contributor sent multiple patches for the same release (which were never more than a handful from anyone) that's counted as just one contribution, simply because i don't have more fine-grained data easily available. There were 34 such contributions for 11 releases during these six years, i.e. on average three outside contributors per release or about five per year. The vast majority came from developers already working on other free software projects: * 22 from (non-mandoc) OpenBSD developers (that's 65%, btw.!) * 3 from FreeBSD developers * 1 from NetBSD developers * 1 from Debian Linux developers * 1 from Void Linux developers * 1 from Alpine Linux developers * 2 from Crux Linux developers * and only 3 from other people As far as i remember, all of these went like "i noticed this bug, here is a patch to fix it" or "i had the idea that this feature addition might be useful, do you like this patch?" I can't remeber a single case that went like "i looked at your TODO list and decided to resolve this item, here is the patch". Not one in ten years as far as i can remember. In conclusion, i'm keeping the TODO list purely for myself. Myself, i do regularly look at it and decide to tackle an item to shorten the list. The only reason for making it public is such that users can distinguish between known and unknown issues in case they find some. Experience shows that it is neither needed nor indeed useful for encouraging contributions. As stsp@ and espie@ already said, that's probably because for people who are able to contribute, it's easy to find the issues they want to fix all by themselves, without any help from me. Yours, Ingo 1.12.3 Dec 13 (2) * Franco Fichtner for a patch to add a minor missing feature. * Tsugutomo ENAMI for a patch to add a minor missing feature. 1.13.1 Aug 14 (0) 1.13.2 Dec 14 (7) * Anthony Bentley (OpenBSD), Baptiste Daroussin (FreeBSD), Daniel Dickman, Doug Hogan, Jason McIntyre, Theo de Raadt (OpenBSD), and Martin Natano (OpenBSD) for source code patches. 1.13.3 Mar 15 (3) * Anthony Bentley, Daniel Dickman, and Ted Unangst (OpenBSD) for source code patches and bug reports. 1.13.4 Jul 16 (7) * Anthony Bentley (OpenBSD) for unifying mandoc.css, two nice patches for man.cgi(8), some documentation patches, some bug reports, and various useful discussions. * Todd Miller (OpenBSD) for lots of help with process group and signal handling, a few patches, some bug reports and some useful discussions. * Svyatoslav Mishyn (Crux Linux) for some patches, several bug reports, and extensive release testing. * Leah Neukirchen (Void Linux) for a number of compatibility patches and suggestions and several bug reports. * Christos Zoulas (NetBSD) for a bug fix patch and some useful suggestions for cleanup. * Florian Obser (OpenBSD) for a bugfix patch and some bug reports. * Michael McConville (OpenBSD) for some simple cleanup patches. 1.14.1 Feb 17 (3) * Michael Stapelberg (Debian
Re: tap(4) performance tuning on (amd64)
Sorry I realised I forgot to mention the version openvpn-2.4.7p1 and OpenBSD6.6 Stable (amd64) running on a 2 core (1socket) Xeon e5v2 KVM Guest with Q35 Vm type with intel ix(4) nics I will test against Current also once I have gotten a baseline on the release+ Patches version Thanks, Tom Smyth On Fri, 10 Jan 2020 at 13:00, Tom Smyth wrote: > > Hi lads, > > I have been doing some testing with tap(4) and openvpn (standard ssl ) > I have been using openvpn with tap and I have been trying with null > encryption. null authentication, > the performance of the tap interface seems to be about 100-150Mb/s on a > system > which can give 3Gb/s-5Gb/s on ix(4) interfaces in Bridge mode and > 4-8Gb/s on tpmr mode > I was wondering is there a sysctl setting that if modified would > improve the tap interface performance. > I have tried with tpmr(4) and bridge(4) > > is there a simple way testing a tap(4) interface throughput / > performance without Openvpn process > > I can try mlvpn and wireguard > but I would love if there was a trick where I can just test the tap(4) > interface with something like pair(4)... > > ix0---bridge0--tap0---someprocess--tap1-bridge1--ix1 > or > ix0--tpmr0--tap0--someprocess--tap1-tpmr1-ix1 > > is there a simple "someprocess" that would provide forwarding packets > between tap0 and tap1 in userland > so that any performance testing on tap(4) interfaces does not have the > distractions of complex userland programs with encryption / > encapsulation overheads > > Thanks for your time > Tom Smyth > > -- > Kindest regards, > Tom Smyth. -- Kindest regards, Tom Smyth.
Fan Art submission
This morning I was doodling with my Wacom tablet on my Workstation running OpenBSD-current (a few days older). Gimp 2.10 crashed, and I thought I lost the image forever but then I was able to restore it next run. While showing it off I merged it (with bucketfill) with a van gogh (I don't know if it's the real van gogh though, I have it a little different in memory) and it turned out really attractive. I'd like to turn it over for fan art: https://www.centroid.eu/blog/c?article=1578660423 and here is the original: https://centroid.eu/private/puffy67.png Cheers! -peter
tap(4) performance tuning on (amd64)
Hi lads, I have been doing some testing with tap(4) and openvpn (standard ssl ) I have been using openvpn with tap and I have been trying with null encryption. null authentication, the performance of the tap interface seems to be about 100-150Mb/s on a system which can give 3Gb/s-5Gb/s on ix(4) interfaces in Bridge mode and 4-8Gb/s on tpmr mode I was wondering is there a sysctl setting that if modified would improve the tap interface performance. I have tried with tpmr(4) and bridge(4) is there a simple way testing a tap(4) interface throughput / performance without Openvpn process I can try mlvpn and wireguard but I would love if there was a trick where I can just test the tap(4) interface with something like pair(4)... ix0---bridge0--tap0---someprocess--tap1-bridge1--ix1 or ix0--tpmr0--tap0--someprocess--tap1-tpmr1-ix1 is there a simple "someprocess" that would provide forwarding packets between tap0 and tap1 in userland so that any performance testing on tap(4) interfaces does not have the distractions of complex userland programs with encryption / encapsulation overheads Thanks for your time Tom Smyth -- Kindest regards, Tom Smyth.
Re: 6.6-current #590 error
On Thu, Jan 09, 2020 at 07:35:17PM +0900, rgc wrote: > misc@ > > just a heads-up #590 has some issues. > > $ uname -a > OpenBSD pcfj10.my.domain 6.6 GENERIC.MP#590 amd64 > > $ pkg_info -mz > Cwd.c: loadable library and perl binaries are mismatched (got handshake key > 0xb70, needed 0xb60) > > yorosiku ~ > misc@ loaded up #594 and had the same issue. but i have another machine that i just updated to the same snapshot. this other machine is running properly. so it is a problem on my setup on this particular laptop. a hint came up after executing LD_DEBUG=1 perl `which pkg_info` doing dtors obj 0x5cb5a122800 @0x5cb0d78b7c0: [/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/Cwd/Cwd.so] after moving the [/usr/local/libdata/perl5] directory, everything went fine. perl seems to have re-created the files with latest versions. yorosiku ~
Re: Awaiting a diff [was: Re: File systems...]
On Fri, Jan 10, 2020 at 11:28:07AM +0100, Stefan Sperling wrote: > On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote: > > On 20:06 Thu 09 Jan, Marc Espie wrote: > > > It's been that way for ages. But no-one volunteered > > > to work on this. > > > > Anyone even knows about this? Aside from OpenBSD developers (who have > > their plates full already) how an average person can find out that there > > is rusty piece of code that should be taken care of? > > Don't start looking at other people's problems before you can help yourself. > Rewriting automounter for Theo as a first contribution is not likely to work. > Find something small that annoys *you* and get involved by fixing that first. > Learn how to approach and debug issues that affect you directly. Ditto. There are lots and lots of pieces in OpenBSD that could use some "obvious" improvements, and not enough developers to do it all these days. Ask anyone with an OpenBSD account how he got it, you'll get the same story: use the OS, get annoyed by a small thing, start sending patches. Very soon, you get to be responsible for some stuff. No magic, just use the OS and scratch the itches.
Re: sysupgrade woes on beaglebone black
On Jan 10 11:01:03, flor...@openbsd.org wrote: > > It seems I am missing out on > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h > > - I can't figure out how to pass the -x option that sets $UU > > (and thus makes the timer reset before each set is installed). > > Those are not the droids you are looking for, you have UU set. > > Line 73: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile?annotate=1.44 On Jan 10 10:06:16, cho...@jtan.com wrote: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile.diff?r1=1.42&r2=1.43 Thank you. The reboot happens around 30 min total though - always in the middle of comp66.tgz, which itself is not taking 30 min (I am measuring it). That makes me think the timer does not really get reset before every set: [timer reset?] > Installing bsd100% |**| 6248 KB00:05 ETA [timer reset?] > Installing bsd.rd 100% |**| 11229 KB00:10 ETA [timer reset?] > Installing base66.tgz 100% |**| 99116 MB - 07:12edT- [timer reset?] > Installing comp66.tgz 83% |* | 45312 KB - > stalledT-syncing disks... done > > rebooting... ... but it's not 30 min from the last reset at this point (i.e., 30 min since the installation of _this_set_ began), it's 30 min from the very beginning. Just to be sure: it's a sysupgrade, not an fresh install. The /autoinstall -x you have kindly showed me above, is that what's run once the /bsd.upgrade kernel reboots? Am I missing something else?
Re: Awaiting a diff [was: Re: File systems...]
On 11:28 Fri 10 Jan, Stefan Sperling wrote: > On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote: > > On 20:06 Thu 09 Jan, Marc Espie wrote: > > > It's been that way for ages. But no-one volunteered > > > to work on this. > > > > Anyone even knows about this? Aside from OpenBSD developers (who have > > their plates full already) how an average person can find out that there > > is rusty piece of code that should be taken care of? > > Don't start looking at other people's problems before you can help yourself. > Rewriting automounter for Theo as a first contribution is not likely to work. > Find something small that annoys *you* and get involved by fixing that first. > Learn how to approach and debug issues that affect you directly. > > How did I get into OpenBSD wifi? > Because my OpenBSD access point stopped accepting new associations after > one about week of usage. It turned out this was one of those problems > which had been known for years and all this time people had been switching > to non-OpenBSD APs to work around it. I had lived with the problem for > about a year or two, resetting the wifi interface on the AP whenever it > happened. > > Then I noticed that 'ifconfig ath0 scan' showed a very long list of known > MAC addresses whenever the problem occurred. So I looked for a way trigger > the problem faster than in one week and succeeded by running this loop > on the client which made the problem appear after a few minutes: > > ifconfig iwn0 up > while sleep 5; do ifconfig iwn0 lladdr random; done > > Looking at the code I found that known MACs never expired! Once the AP had > reached its limit of learned MACs it accepted no new associations because > no room was made for new MAC addresses. Fix was a 3-line diff, which I > could verify with my above test. Neat. Though I'm using OpenBSD only for a router and since issues preventing me from using it on a desktop (or NAS) are pretty huge to be my "good first issues" that's not an option, sadly. So only donations / occasional bug reports from me :D
Re: Awaiting a diff [was: Re: File systems...]
On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote:
> On 20:06 Thu 09 Jan, Marc Espie wrote:
> > It's been that way for ages. But no-one volunteered
> > to work on this.
>
> Anyone even knows about this? Aside from OpenBSD developers (who have
> their plates full already) how an average person can find out that there
> is rusty piece of code that should be taken care of?
Don't start looking at other people's problems before you can help yourself.
Rewriting automounter for Theo as a first contribution is not likely to work.
Find something small that annoys *you* and get involved by fixing that first.
Learn how to approach and debug issues that affect you directly.
How did I get into OpenBSD wifi?
Because my OpenBSD access point stopped accepting new associations after
one about week of usage. It turned out this was one of those problems
which had been known for years and all this time people had been switching
to non-OpenBSD APs to work around it. I had lived with the problem for
about a year or two, resetting the wifi interface on the AP whenever it
happened.
Then I noticed that 'ifconfig ath0 scan' showed a very long list of known
MAC addresses whenever the problem occurred. So I looked for a way trigger
the problem faster than in one week and succeeded by running this loop
on the client which made the problem appear after a few minutes:
ifconfig iwn0 up
while sleep 5; do ifconfig iwn0 lladdr random; done
Looking at the code I found that known MACs never expired! Once the AP had
reached its limit of learned MACs it accepted no new associations because
no room was made for new MAC addresses. Fix was a 3-line diff, which I
could verify with my above test.
---
commit 6bbde753957f0b27c56cfdd15c9af836579d120b
from: stsp
date: Wed Jan 18 14:35:34 2012 UTC
Make it possible to free cached nodes which never associated (e.g. nodes
only scanning for networks). These were never put into COLLECT state and
were thus never evicted from the node cache in hostap mode.
ok jsg@
diff ae44467745d21c295e8ffe38340d662269578502
d62cb122bc6abf011c13400ea5c3f90c56292854
blob - 893de460bfd2a1509205c4e5d837ba6f8d5c2636
blob + 9435a287862a29a9dc79ea09ce8328b8e054c819
--- sys/net80211/ieee80211_node.c
+++ sys/net80211/ieee80211_node.c
@@ -1507,8 +1507,10 @@ ieee80211_node_leave(struct ieee80211com *ic, struct i
* If node wasn't previously associated all we need to do is
* reclaim the reference.
*/
- if (ni->ni_associd == 0)
+ if (ni->ni_associd == 0) {
+ ieee80211_node_newstate(ni, IEEE80211_STA_COLLECT);
return;
+ }
if (ni->ni_pwrsave == IEEE80211_PS_DOZE)
ic->ic_pssta--;
Re: Awaiting a diff [was: Re: File systems...]
On 11:08 Fri 10 Jan, Janne Johansson wrote: > By using the parts that OpenBSD is made up of, and not automatically moving > to other OSes as soon as you leave the comfort zone. I'm not sure, but it seems like from a user perspective there is nothing wrong with amd(8). Only that it keeps using legacy code.
Re: Awaiting a diff [was: Re: File systems...]
Den fre 10 jan. 2020 kl 10:55 skrev Consus : > On 20:06 Thu 09 Jan, Marc Espie wrote: > > It's been that way for ages. But no-one volunteered > > to work on this. > > Anyone even knows about this? Aside from OpenBSD developers (who have > their plates full already) how an average person can find out that there > is rusty piece of code that should be taken care of? > By using the parts that OpenBSD is made up of, and not automatically moving to other OSes as soon as you leave the comfort zone. Guess that is how many ports gets added. $prg exist for $other_os but not OpenBSD, someone does the work to make it run on OpenBSD and there you go. -- May the most significant bit of your life be positive.
Re: sysupgrade woes on beaglebone black
Jan Stary writes: > - I can't figure out how to pass the -x option that sets $UU > (and thus makes the timer reset before each set is installed). You don't. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile.diff?r1=1.42&r2=1.43 Matthew
Re: sysupgrade woes on beaglebone black
On Fri, Jan 10, 2020 at 10:06:41AM +0100, Jan Stary wrote: > It seems it's the SD card that is slow (the machine > is a BeagleBone Black) - will try with a faster one. > > It seems I am missing out on > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h > - I can't figure out how to pass the -x option that sets $UU > (and thus makes the timer reset before each set is installed). Those are not the droids you are looking for, you have UU set. Line 73: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile?annotate=1.44 > > Thank you for the insight. > -- I'm not entirely sure you are real.
Re: Awaiting a diff [was: Re: File systems...]
On 20:06 Thu 09 Jan, Marc Espie wrote: > It's been that way for ages. But no-one volunteered > to work on this. Anyone even knows about this? Aside from OpenBSD developers (who have their plates full already) how an average person can find out that there is rusty piece of code that should be taken care of?
Re: sysupgrade woes on beaglebone black
On Fri, Jan 10, 2020 at 10:06:41AM +0100, Jan Stary wrote: > On Jan 09 11:44:25, h...@stare.cz wrote: > > Installing bsd 100% |**| 6248 KB00:05 ETA > > Installing bsd.rd 100% |**| 11229 KB00:10 ETA > > Installing base66.tgz 100% |**| 99116 MB - > > 07:12edT- > > Installing comp66.tgz83% |* | 45312 KB - > > stalledT-syncing disks... done > > rebooting... > > On Jan 09 14:48:25, dera...@openbsd.org wrote: > > > https://marc.info/?l=openbsd-cvs&m=156889553923923&w=2 > > > Looking at install.sub, it seems that the watchdog timer (30 min) > > > is reset after installing every set. I don't see the watchdog being > > > reset whenever there is "progress" - did you mean the completion > > > of a set (as opposed to just not being -stalled-)? > > > > > > Also, the resets only happen with $UU, which is only set with -x > > > - where should that option be passed? (not in sysupgrade.) > > > > > > Grandpa's analog stopwatch on a chain says > > > that it indeed reboot around the 30 min mark. > > > > This entire design is intentional. > > > > If a machine gets stuck doing an upgrade, we want it to abandon the > > upgrade and go back to the /bsd kernel (which hopefully has not been > > installed yet). > > Well, /bsd is the first thing that gest installed, > and is relatively small compared to the other sets. > In this particular machine, the watchdog timeout hits when > bsd, bsd.rd, base, and half of comp have been installed. > > > Your machine is too slow. > > It seems it's the SD card that is slow (the machine > is a BeagleBone Black) - will try with a faster one. Support for using edma with ommmc(4) is lacking, that would help. > > It seems I am missing out on > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h > - I can't figure out how to pass the -x option that sets $UU > (and thus makes the timer reset before each set is installed). > > Thank you for the insight. > >
Re: Can't select files to upload in a browsers
On 09 Jan 2020, jungle Boogie wrote: > On Fri, Dec 6, 2019, 2:58 AM dmitry.sensei wrote: > > > Firefox and Chromium browser, in the file selection window for upload, > > does not show the contents of directories other than the Downloads > > directory > > > > See here > > https://www.reddit.com/r/openbsd/comments/eh25ma/firefox_how_to_select_file_to_upload/ > Thanks very much for this link, which provided the clue needed for me to get access to ~/Downloads in Firefox. I downloaded a file to this directory and this apparently caused Firefox to know about its existence. Ctrl-o now opens ~/Downloads again and allowss me to see all the files it contains. -- Anthony Campbellhttp://www.acampbell.uk
Re: sysupgrade woes on beaglebone black
On Jan 09 11:44:25, h...@stare.cz wrote: > Installing bsd100% |**| 6248 KB00:05 ETA > Installing bsd.rd 100% |**| 11229 KB00:10 ETA > Installing base66.tgz 100% |**| 99116 MB - 07:12edT- > Installing comp66.tgz 83% |* | 45312 KB - > stalledT-syncing disks... done > rebooting... On Jan 09 14:48:25, dera...@openbsd.org wrote: > > https://marc.info/?l=openbsd-cvs&m=156889553923923&w=2 > > Looking at install.sub, it seems that the watchdog timer (30 min) > > is reset after installing every set. I don't see the watchdog being > > reset whenever there is "progress" - did you mean the completion > > of a set (as opposed to just not being -stalled-)? > > > > Also, the resets only happen with $UU, which is only set with -x > > - where should that option be passed? (not in sysupgrade.) > > > > Grandpa's analog stopwatch on a chain says > > that it indeed reboot around the 30 min mark. > > This entire design is intentional. > > If a machine gets stuck doing an upgrade, we want it to abandon the > upgrade and go back to the /bsd kernel (which hopefully has not been > installed yet). Well, /bsd is the first thing that gest installed, and is relatively small compared to the other sets. In this particular machine, the watchdog timeout hits when bsd, bsd.rd, base, and half of comp have been installed. > Your machine is too slow. It seems it's the SD card that is slow (the machine is a BeagleBone Black) - will try with a faster one. It seems I am missing out on http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h - I can't figure out how to pass the -x option that sets $UU (and thus makes the timer reset before each set is installed). Thank you for the insight.
