Re: athn(4) WPA2-PSK software crypto CPU loading
On Wed, Dec 24, 2014 at 09:15:03PM +0100, Christian Weisgerber wrote: Jonathan Thornburg: I have no experience with that configuration, but I had a broadly comparable setup where a Soekris net5501 (same CPU as the ALIX) did IPsec for a .11g network. What was the bandwidth of that network? .11g, 54 Mbit/s. Something like 2 Mbyte/s throughput into the wired network. Generally, it makes no sense to expect the maximum wifi throughput as a matter of course. You'll see it under optimal conditions which depend on a lot of factors. Most of the time a lower rate will be used to prevent excessive packet loss and retransmits. This is a balancing act. Our net80211 stack selects the rate using AMRR (Adaptive Multi Rate Retry). Our implementation of AMRR describes itself as naive, which probably means it's not optimised much. It also differs from what many other OSs do. ifconfig output indicates the currently selected data rate, e.g. mine has currently settled at 18Mbit/s: media: IEEE802.11 autoselect (OFDM18 mode 11g) Data transmit rate selection happens at both ends of the wifi link independently and can vary for each individual frame. The transmission rate for the data part of a frame is announced in the frame header (the header is usually transmitted at fixed 1MBit/s). Some 11n devices have more tricks up their sleeves (e.g. beam forming) but OpenBSD doesn't support any of those.
Upgrading issues (i386 on PPro class) 5.4-5.5 leaving system horked
Well, I've never cared much for the holidays... So I figured, while everybody else was busy with them, what a perfect time for me to take down my BBS and other services and upgrade the system at least from 5.4-5.5. I've done multiple upgrades in a day before when I've gotten behind like this, and they've never been much of a problem, though I've run into an issue here and there before. That was before I ran into the removal of packages and reinstallation process that is necessary for this upgrade. Right off the bat I got issues about 'Can't locate object method filter_obsolete via package OpenBSD::Quirks1 at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 351'. This was at the 'final step', and there had been no hiccups during the sysmerging process that I wasn't used to. After this issue, I started having packages that the system was trying to reinstall but totally horked on. I'm not totally sure if this is comprehensive at this point, but here are the packages and what I had to do with them: * apcupsd - had to manually remove from pkg_list_manual * cups - ditto * fedora-base - ditto * ntop - ditto * hylafax smsmail or whatever - ditto I then ran into a bunch that I had to install unsigned, finally just hitting the 'a'll so as to stop having to manually intervene and say 'y'es on each one. These started with metaauto*, autoconf-2.69p0*, bash-4.2.45, beave, and then I lost track of the rest with the 'a'll install specified. My system won't run like 90% of the binaries on it. I have upgrades of my home directory, BBS directory, and SQL dumps of most everything except my most recent changes, but I'm really hoping to avoid that... Does anybody have any tips? Would an install over the top straight to 5.6 maybe work? I've never had the install process leave me with such a lobotomized system before. Usually it's just something like mediawiki not working with latex math markup any more or wordpress breaking. :( This is my primary server, and it pains me significantly to have it down, and I really love OpenBSD, despite the hiccups at times. Does anybody have any suggestions? Any help or pointers in the right direction would be greatly appreciated. Thanks in advance.
Re: Upgrading issues (i386 on PPro class) 5.4-5.5 leaving system horked
On 12/25/14 22:04, Damon Getsman wrote: Well, I've never cared much for the holidays... So I figured, while everybody else was busy with them, what a perfect time for me to take down my BBS and other services and upgrade the system at least from 5.4-5.5. I've done multiple upgrades in a day before when I've gotten behind like this, and they've never been much of a problem, though I've run into an issue here and there before. That was before I ran into the removal of packages and reinstallation process that is necessary for this upgrade. you don't mention WHEN you did this, but I can guess.. Right off the bat I got issues about 'Can't locate object method filter_obsolete via package OpenBSD::Quirks1 at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 351'. This was at the 'final step', and there had been no hiccups during the sysmerging process that I wasn't used to. After this issue, I started having packages that the system was trying to reinstall but totally horked on. ... My system won't run like 90% of the binaries on it. such as...? I'm assuming you mean add-on packages, not base utilities like tar or more. If more is screwed up, you didn't unpack in the right directory. I have upgrades of my home directory, BBS directory, and SQL dumps of most everything except my most recent changes, but I'm really hoping to avoid that... should be fixable. Does anybody have any tips? Would an install over the top straight to 5.6 maybe work? No, you have a fundamental problem that needs to be fixed, and another upgrade won't help (probably won't really hurt, either) I've never had the install process leave me with such a lobotomized system before. Usually it's just something like mediawiki not working with latex math markup any more or wordpress breaking. :( This is user error. This upgrade *IS* trickier than most, but that's why we carefully document things -- if you follow the process, it works fine. This is my primary server, and it pains me significantly to have it down, and I really love OpenBSD, despite the hiccups at times. Does anybody have any suggestions? Any help or pointers in the right direction would be greatly appreciated. Thanks in advance. Well, you didn't provide many details of what you actually did, but it is pretty obvious you did not uninstall all packages BEFORE you did the upgrade. Sucks to be you, but I bet you read the instructions more carefully next time. :) Good news, should be recoverable. The fact that you have binaries that don't run proves you didn't remove the packages before upgrade. The other options are your kernel and userland are out of sync (i.e., forgot to upgrade kernel or userland) or you unpacked your userland to a different location, but either of those would probably be far worse situations. At this point, packages will have to be forcibly removed. See the options of pkg_delete -- the existing removal scripts may well fail, and you may well have your dependencies screwed up, and a -q to skip over verifying signatures would probably be good, too, set options accordingly. Once you do that, you should have no old binaries left to run on your system, and you should be back to 100% functional base OpenBSD install. You can now reinstall your packages, or since you have another upgrade to go, upgrade the base system to 5.6 first. Nick.
Discovering the keycode of key.
Hello folks! May someone point to me how do I can obtain, in the console, the keycode of any particular key, in OpenBSD? thanks Eduardo Lopes.
Re: Discovering the keycode of key.
Eduardo Lopes wrote: May someone point to me how do I can obtain, in the console, the keycode of any particular key, in OpenBSD? in gforth (a port) you can do KEY . -- Jack Woehr # There's too much emphasis on things Box 51, Golden CO 80402 # like pawn structure in modern chess. http://www.softwoehr.com # Checkmate ends the game. - N. Short
Adding encryption support to vi(1)
vim (in ports) offers an encryption option ( http://vimdoc.sourceforge.net/htmldoc/editing.html#encryption) Invoking vim with -x prompts for a key and then encrypts the file on save. It appears to do the right thing as far as encrypting the .swp (temporary recovery) file as well. If you later edit the file (without the -x option) it will detect the file is encrypted based on a magic it prepends and prompt for a key. Unfortunately, by default vim uses the 'zip' algorithm which is quite insecure, though you can optionally specify blowfish as your preferred algorithm. The nice thing about this versus a gpg decrypt/edit/re-encrypt cycle is that you don't have an unencrypted file temporarily lying around (or an unencrypted vi-recover file for that matter). I'm wondering if there is any interest in adding this feature to vi(1) given OpenBSD's interest in integrated crypto? Unfortunately, as a US citizen/resident, it's not clear to me that I would be able to contribute code (beyond an implementation that uses the zip algorithm) so it is probably a moot point unless one of the devs is interested but...I figured there was no harm in mentioning it. -- andrew fabbro and...@fabbro.org blog: https://raindog308.com
Re: Adding encryption support to vi(1)
vim (in ports) offers an encryption option ( http://vimdoc.sourceforge.net/htmldoc/editing.html#encryption) Invoking vim with -x prompts for a key and then encrypts the file on save. It appears to do the right thing as far as encrypting the .swp (temporary recovery) file as well. If you later edit the file (without the -x option) it will detect the file is encrypted based on a magic it prepends and prompt for a key. Unfortunately, by default vim uses the 'zip' algorithm which is quite insecure, though you can optionally specify blowfish as your preferred algorithm. The nice thing about this versus a gpg decrypt/edit/re-encrypt cycle is that you don't have an unencrypted file temporarily lying around (or an unencrypted vi-recover file for that matter). I'm wondering if there is any interest in adding this feature to vi(1) given OpenBSD's interest in integrated crypto? So you describe something which is shit. Why would we want to add something shit to vi? It would fool people into bad practices. Who benefits? Exactly. Can I ask what kind of plant are you? Sorry, just being funny. Funny ironic.
