Re: DNS over IPSec weirdness
First of all, I have no real clue. It sound weird. But maybe I can help you at least with that one: Am Donnerstag, den 11.12.2014, 16:13 + schrieb Zé Loff: However, if I try to do something like ping -c 1 www_lan.foo.bar (or e.g. ssh) I can see the packets with the DNS request pass through enc0 on the tunnel (and on the physical interface too) but nothing traffic shows up on enc0 on the other endpoint (I do believe they show up on the physical interface on that end, but my tcpdump foo isn't good enough to be sure). You can get the IPsec SA SPIs and keys with the ipsecctl -k -sa command. Feed them into tcpdump with -E espalg:espkey (please read the man page, before you do so). Wireshark may also decrypt your stream via the ESP protocol settings. -dd -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: Music On Console (MOC)
On 12/12/14 19:48, Ted Unangst wrote: On Fri, Dec 12, 2014 at 15:00, Richard Toohey wrote: (3) can help with the POSIX questions. The maintainer has asked the same question on a MOC forum: http://moc.daper.net/node/1369 I have no idea what posix features they want, so it's a tough question. Thanks for all the replies - very much appreciated. I think I should try a different tack - I'm not a MOC user nor a developer and I don't understand the POSIX issues. If anyone using OpenBSD and MOC wants to ensure that future versions work on OpenBSD, then now is a good time to help out. And best to contact the MOC developers directly: http://moc.daper.net/node/269. Thanks, Richard.
Re: problems compiling i386 from source (patching)
li...@ggp2.com wrote: I applied the newest unbound patch to several amd64 machines without trouble, and have had issues on several of my i386 boxes. The initial error was probably the same as below, but led me to believe I may have had some kind of kernel or system frankenbox behavior. I used cvs to pull all the latest sources (cvs -q up -rOPENBSD_5_6 -Pd is what I ran, so it should be the latest patch branch code), compiled/installed/rebooted to the new kernel, then ran through the steps for a make build. make build bombed out on nsd with a similar error. in unbound, running make -f Makefile.bsd-wrapper obj works fine, but make -f Makefile.bsd-wrapper produces the error (which I believe is what I initially saw): ... checking for ctime_r... yes checking if make supports $ with implicit rule in scope... yes configure: Stripping extension flags... configure: creating ./config.status Bad system call (core dumped) config.status: creating Makefile Bad system call (core dumped) config.status: error: could not create Makefile *** Error 1 in /usr/src/usr.sbin/unbound (Makefile.bsd-wrapper:65 '/usr/src/usr.sbin/unbound/obj/config.status') I ran into this as well, and found a similar problem on the net. Unfortunately I didn't preserve the link but read on for a possible solution. If your machine is upgraded all the time you may have /usr/bin/nawk getting in the way, which should have been removed during the 5.5-5.6 upgrade. (section 2. Files to delete and move) It seems I did at least the nsd part of this section, so I just (re)ran the first set of rm-s, which includes /usr/bin/nawk, and the problem was gone.
Xorg fails PIII agp
hi guys moving from openbsd 5.4 to 5.6 with a fresh install I've found Xorg refuse to work. I leave a Xorg and dmesg file with 5.4 and 5.6. In the case of 5.4 xorg just works out of the box. I really don't know what is missing. thnks !! [demime 1.01d removed an attachment of type application/octet-stream which had a name of LogXorg5.6] [demime 1.01d removed an attachment of type application/octet-stream which had a name of dmesg54] [demime 1.01d removed an attachment of type application/octet-stream which had a name of Xorg54Log] [demime 1.01d removed an attachment of type application/octet-stream which had a name of dmesg5.6]
Re: Xorg fails PIII agp
On Fri, 12 Dec 2014 07:03:56 -0430 elvis fuentes freebsdd...@gmail.com wrote: [demime 1.01d removed an attachment of type application/octet-stream which had a name of LogXorg5.6] [demime 1.01d removed an attachment of type application/octet-stream which had a name of dmesg54] [demime 1.01d removed an attachment of type application/octet-stream which had a name of Xorg54Log] [demime 1.01d removed an attachment of type application/octet-stream which had a name of dmesg5.6] Your attachment is removed by list manager. Copy paste inline within your email...
Re: OpenBSD 5.6 - amd64 on Lenovo G480
On 12 December 2014 at 03:50, Leonardo Santagostini lsantagost...@gmail.com wrote: Hello @misc, This mail is regarding about issues that im facing after doing a fresh install of 5.6 RELEASE and snapshot on my latptop The point is that after installing sucessfully i am trying to start X but screen goes black. The only way i have to go to console is pressing CTRL+ALT+F1 after lid close, suspend and resume. Just wanting to know what is the best way i can help you regarding this. i know sending: 1) dmesg 2) x.org.log Is ok, but i have no idea what else could help. So, please, just let me know what else is needed, so i can do my homework. (Also i tried snapshot from 12/08 but an libc version problem appears when x starts) Regards, Leonardo Santagostini http://ar.linkedin.com/in/santagostini Hello Leonardo, have you done fw_update -v ? Hard to say if it's needed since you didn't include the dmesg. -- Regards, Ville Valkonen
Re: CPU power consumption on thinkpad x201 on openbsd current
On Wed, Jun 04, 2014 at 11:08:42PM +0200, Johan Svensson wrote: I'm trying to migrate from Linux to Openbsd on my laptop (thinkpad x201). The first problem that i came across was that the Cpu fanspeed was running constantly at 3500RPM. After the acpithinkpad.c patch from jcs (and i modified to make it work on the openbsd-current(link: http://exclude.se/patch/jcs_mod_by_js.diff) Another thing that i noticed is that the battery lifetime is really bad. In Linux i get around ~5,5 hours. In OpenBSD i get around 2 hours. when i ran : sysctl hw.sensors | grep -i consumption. the output of the cpu was 6W. in Linux it's around 1,5W. with: apmd -C and apmd -L it's the same. dmesg: http://exclude.se/openbsd/dmesg.txt Is there anyway to fix this? Regards Johan Svensson I've done some testing on an x201i and it seems the intel_powerclamp driver (Package Level C-state Idle Injection for Intel CPUs) is responsible for the difference in battery life. If that Linux driver is blacklisted battery life drops to about the same levels as on OpenBSD.
Re: AMD64 packages
On 2014-12-12, ian kremlin i...@kremlin.cc wrote: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects is grab a fresh source tree and compile them manually. for example, libc: cd /usr/src/lib/libc edit 'shlib_version' to have the appropriate major/minor versions This is bad advice. There is a reason why we bump library versions! What you could do if you can't wait for new packages and don't have the correct version of the library, is to identify the date/time when the library was updated and e.g. cvs up -D 2014/12/05 (i.e. before the update) to fetch a copy of the source code for the library at the version you need, and build that.
Re: AMD64 packages
Hi Ian, ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects Definitely not the easiest way. Waiting for the next snapshot is definitely much easier and safer for the average user. is grab a fresh source tree and compile them manually. for example, libc: There are dragons. Sometimes, you need to do make includes in the right directory first. Then again, that tends to reinstall *many* headers, not just those you care about right now, so be sure you don't install some that hurt you. Also, make depend can sometimes be necessary, and you certainly should never forget about make obj. When there is a flag day, very special steps may be required before doing anything else or somewhere in the middle. If you screw up, chances are you can't even do a clean shutdown any longer and are in for fsck(8) and manually reinstalling working libraries in single user mode before you can fully boot again. If this scares anybody, i'm not surprised; updating libraries is not a playground for newbies. cd /usr/src/lib/libc edit 'shlib_version' to have the appropriate major/minor versions (pkg_add(1) will tell you which ones it wants. That, actually, is *terrible* advice and almost guarantees a fiasco. If you edit shlib_version manually, you build a library containing code *incompatible* with what it's supposed to contain, so the end result will be that programs using that library will, at run time, * crash, * produce obviously wrong results, * and/or silently produce results that are wrong in non-obvious ways. Some programs, by mere luck, may also work, if you are lucky, but it's hard to predict in advance which ones will and which ones wont. To update a library, update all related source code - ideally, the whole source tree unless you know precisely what you are doing - to one consistent state, than compile from that state *without* manually screwing with shlib_version. That's the whole point of library versioning! make make install The command make install in lib/libc is among the more dangerous commands you might type, and if something is wrong, recovery is often more difficult than recovery from less scary errors. the bsd.port.mk(5) build system is well thought out No objection here... and allows for straightforward, helpful maneuvers like this ... but i really wouldn't give it that twist. Nothing about what you said is straightforward or helpful. It sounds more like somewhere between foolhardy and suicidal. pkg_check(8) is also an invaluable tool in helping deal with package issues. also, use the right $PKG_PATH! That's good advice again, for sure. Yours, Ingo
Re: AMD64 packages
ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects Definitely not the easiest way. Waiting for the next snapshot is definitely much easier and safer for the average user. is grab a fresh source tree and compile them manually. for example, libc: There are dragons. No, Ingo, stop right there. What he is trying to do is create a frankenstein. People who do this will run into problems. Then they'll submit a bug report. It ends badly.
Re: AMD64 packages
On Dec 12, 2014 1:06 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects Definitely not the easiest way. Waiting for the next snapshot is definitely much easier and safer for the average user. is grab a fresh source tree and compile them manually. for example, libc: There are dragons. No, Ingo, stop right there. What he is trying to do is create a frankenstein. People who do this will run into problems. Then they'll submit a bug report. It ends badly. I never dreamed that asking a simple question of about how long it might be before I could fix what I screwed up would end causing all of this. Whenever new packages are available, I'll fix what I broke and try to not do it again. Stan
Re: AMD64 packages
On Fri, Dec 12, 2014 at 2:02 PM, Ingo Schwarze schwa...@usta.de wrote: There are dragons. ingo, theo: sorry to post toxic advice, and thanks for the knowledge. i did not realize how shlib_version worked. i must have gotten lucky with my build but i should go back and fix it properly now ian
