Re: Happy Birthday, Theo
Happy birthday Theo On 19 May 2014 16:59, ÐÑÑÑÑ ÐÑÑомин art.is...@yandex.ru wrote: On Mon, May 19, 2014 at 12:03:37PM +0200, Marcus MERIGHI wrote: Happy Birthday, Theo. Thanks for doing your thing. Others: please remember to donate/buy. My warmest congratulations too!
Re: Happy Birthday, Theo
Happy birthday Theo :) Regards, Sepahrad On Mon, May 19, 2014 at 2:33 PM, Marcus MERIGHI mcmer-open...@tor.at wrote: Happy Birthday, Theo. Thanks for doing your thing. Others: please remember to donate/buy. Bye, Marcus -- Best Regards, Sepahrad Salour
Re: smtpd stops immediately after starting in -current
On Mon, May 19, 2014, at 09:06 PM, Allan Streib wrote: Yes, there is a core file. Also, confirmed that the problem is not appearing in snapshot OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 09:40:42 MDT 2014 Allan
Re: bind port broken
Stéphane Guedon stephane at 22decembre.eu writes: I don't know if I am doing things ok, but the Bind9 port seems broken (in a fresh 5.5 install). Thanks if someone fix it. Is there a particular reason you're not just using the packages provided? I see no advantage to building it yourself. # pkg_add isc-bind
Re: Happy Birthday, Theo
On 05/19/2014 01:03 PM, Marcus MERIGHI wrote: Happy Birthday, Theo. Thanks for doing your thing. Others: please remember to donate/buy. Bye, Marcus Happy Birthday. May the Force be with you. Thank you and warmest regards.
Re: uaudio useless?
On 2014-05-19, Mike Larkin mlar...@azathoth.net wrote: FWIW, I have 3 different uaudio dongles and they all work fine. It depends on the layout of your USB bus, see usbdevs -v. On older systems with USB2, full speed devices will be attached directly to a full speed root hub and the audio dongle will work. Here's an example from a Thinkpad X40: --- Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 addr 2: full speed, power 20 mA, config 1, USB Audio DAC(0x2704), Burr-Brown from TI(0x08bb), rev 1.00 port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 powered port 2 powered --- On systems with newer Intel chipsets that support USB3, full speed devices will be attached to a high speed rate-matching hub and the audio dongle will not work. I first noticed this on the Thinkpad X230 but mostly forgot about it. Here's an example from a PowerEdge T20: --- Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x8008), Intel(0x8087), rev 0.04 port 1 addr 3: low speed, power 100 mA, config 1, product 0x1203(0x1203), Holtek(0x04d9), rev 2.70 port 2 addr 4: low speed, power 100 mA, config 1, TEMPer sensor(0x660c), Ten X Technology, Inc.(0x1130), rev 1.50 port 3 addr 5: full speed, power 20 mA, config 1, USB Audio DAC(0x2704), Burr-Brown from TI(0x08bb), rev 1.00 port 4 powered port 5 powered port 6 powered port 2 powered port 3 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x8000), Intel(0x8087), rev 0.04 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered port 2 powered port 3 powered --- Yes, I tried all ten USB ports on that machine. They're all routed to one of the rate-matching hubs. A potential workaround would be to plug a USB2 expansion card into the box, depending on what the bus layout will be there. I might try that, but at the moment the single PCI slot is already occupied. There should also be high speed USB audio devices, and possibly asynchronous ones, but this kind of information is difficult to discern from the packaging or the manual leaflets. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Boot panic on MP amd64 with 5.5, snapshot kernels
On Tue, May 20, 2014 at 09:51:50AM -0400, John D. Verne wrote: On Mon, May 19, 2014 at 11:19:23AM -0700, Mike Larkin wrote: On Mon, May 19, 2014 at 01:42:49PM -0400, John D. Verne wrote: On Sun, May 18, 2014 at 03:04:30PM -0400, John D. Verne wrote: I just got a new amd64 box to run OpenBSD on, but it is panicking on boot when I try to run the 5.5 kernel on it. The panic is unknown MPS interrupt trigger 2 somewhere in the acpi code. bsd.rd, bsd and bsd.mp all panic in the same places, as does bsd.rd from the latest amd64 snapshot. NetBSD 6.1.4 manages to enumerate all the ACPI stuff when I use their boot image. So there's that. As an aside, I was surprised at how different the src/sys tree is from OpenBSD. But I'm going to try and see how they handle the Intel ACPICA 20110623 device, which seems to be the thing that is not working right. Get a dump of the AML using FreeBSD then. Can't really help otherwise. Ok, thanks for the tip. I managed to get FreeBSD 11-current to boot, and I've run acpidump -td to get the attached output. I hope this is what you wanted. If not, I have the FreeBSD liveCD running on the OpenBSD snapshot install on this hardware. I am at your disposal. I've also booted the OpenBSD snapshot from May 19 by disabling the acpi0 device via UKC, and then tweaked the kernel in the same manner FreeBSD does, which allows the boot process to not panic with acpi enabled. So, copying what Linux and FreeBSD does naively fixes things. I'll leave the rest up to the experts. However, then I ran into another panic related to lapic. During the FreeBSD-current back-and-forth, I ended up disabling half the serial ports on this motherboard via the BIOS. It looks like the three back panel serial ports are acceptable, but the three on-board serial ports cause a panic. FreeBSD hangs when enumerating those, and OpenBSD panics. I'll raise this as a seperate issue, but for now I've disabled them. Admittedly, this is a weird board, so those ports are both highly configurable and probably presented to (what looks like) the ISA bus in an odd manner. Perhaps an email of such a tremendous size is unlikely to get to the list. I'll try attaching the acpidump output. [demime 1.01d removed an attachment of type application/x-gunzip]
Re: Intel HD Graphics 4000, only one monitor detected
Hi Jonathan, On Tue May 20 2014 20:56, Jonathan Gray wrote: On Tue, May 20, 2014 at 10:05:07AM +0200, mar...@familjenbergkvist.net wrote: Synopsis: Intel HD Graphics 4000, only one monitor detected Category: Environment: System : OpenBSD 5.5 Details : OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 09:40:42 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: I have two identical monitors connected to my Intel HD Graphics 4000 on DisplayPort and HDMI respectively. Usually there was no problem detecting them both and split my desktop across both monitors. But somewhere between OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb 3 07:57:32 MST 2014 and OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb 7 11:45:09 MST 2014 something happened. The monitor on HDMI is mirroring the DisplayPort and it is not detected properly by xrand. After doing xrandr --auto the monitor on HDMI turns black and is not detected at all by xrand. That is around the timeframe of the xf86-video-intel update to 2.99.909 from 2.20.19. Currently we have 2.99.910. I don't see any likely commits in the kernel around that timeframe. 2.99.911 has since been released http://lists.freedesktop.org/archives/xorg/2014-March/056491.html When I get a chance I'll test it here and send you a patch to see if that changes anything. I'd be happy to provide feedback as well! ;-) Norman
Re: Boot panic on MP amd64 with 5.5, snapshot kernels
On Tue, May 20, 2014 at 12:26:04PM -0400, John D. Verne wrote: On Tue, May 20, 2014 at 09:51:50AM -0400, John D. Verne wrote: On Mon, May 19, 2014 at 11:19:23AM -0700, Mike Larkin wrote: On Mon, May 19, 2014 at 01:42:49PM -0400, John D. Verne wrote: On Sun, May 18, 2014 at 03:04:30PM -0400, John D. Verne wrote: I just got a new amd64 box to run OpenBSD on, but it is panicking on boot when I try to run the 5.5 kernel on it. The panic is unknown MPS interrupt trigger 2 somewhere in the acpi code. bsd.rd, bsd and bsd.mp all panic in the same places, as does bsd.rd from the latest amd64 snapshot. NetBSD 6.1.4 manages to enumerate all the ACPI stuff when I use their boot image. So there's that. As an aside, I was surprised at how different the src/sys tree is from OpenBSD. But I'm going to try and see how they handle the Intel ACPICA 20110623 device, which seems to be the thing that is not working right. Get a dump of the AML using FreeBSD then. Can't really help otherwise. Ok, thanks for the tip. I managed to get FreeBSD 11-current to boot, and I've run acpidump -td to get the attached output. I hope this is what you wanted. If not, I have the FreeBSD liveCD running on the OpenBSD snapshot install on this hardware. I am at your disposal. I've also booted the OpenBSD snapshot from May 19 by disabling the acpi0 device via UKC, and then tweaked the kernel in the same manner FreeBSD does, which allows the boot process to not panic with acpi enabled. So, copying what Linux and FreeBSD does naively fixes things. I'll leave the rest up to the experts. However, then I ran into another panic related to lapic. During the FreeBSD-current back-and-forth, I ended up disabling half the serial ports on this motherboard via the BIOS. It looks like the three back panel serial ports are acceptable, but the three on-board serial ports cause a panic. FreeBSD hangs when enumerating those, and OpenBSD panics. I'll raise this as a seperate issue, but for now I've disabled them. Admittedly, this is a weird board, so those ports are both highly configurable and probably presented to (what looks like) the ISA bus in an odd manner. Perhaps an email of such a tremendous size is unlikely to get to the list. I'll try attaching the acpidump output. Perhaps MIME attachments are rejected. Here's a URL: http://www.clevermonkey.org/OpenBSD/ACPI_ASRock_IMB-150.txt.gz Sorry for the noise. -- John D. Verne j...@clevermonkey.org
sed(1) man page issue
i have noticed that the sed man page has some strange clippings. the attached patch fixes it for me, but i dont know what was the intended effect. before: [1addr]a\ text Write text to standard output immediately before each attempt to read a line of input, whether by executing the `N' function or by beginning a new cycle. after: [1addr]a text Write text to standard output immediately before each attempt to read a line of input, whether by executing the `N' function or by beginning a new cycle. --- sed.1.orig Tue May 20 15:25:58 2014 +++ sed.1 Tue May 20 15:30:16 2014 @@ -283,9 +283,7 @@ .Em function-list only when the pattern space is selected. .Pp -.It [1addr] Ns Em a Ns \e -.It Em text -.Pp +.It [1addr] Ns Em a Em text Write .Em text to standard output immediately before each attempt to read a line of input, @@ -299,9 +297,7 @@ function with the specified label. If the label is not specified, branch to the end of the script. .Pp -.It [2addr] Ns Em c Ns \e -.It Em text -.Pp +.It [2addr] Ns Em c Em text Delete the pattern space. With 0 or 1 address or at the end of a 2-address range, .Em text @@ -330,9 +326,7 @@ Append a newline character followed by the contents of the pattern space to the hold space. .Pp -.It [1addr] Ns Em i Ns \e -.It Em text -.Pp +.It [1addr] Ns Em i Em text Write .Em text to the standard output. -f -- friends, romans, and countrymen, lend me your ears.
Re: sed(1) man page issue
On Tue, May 20, 2014 at 06:44:14PM +0200, frantisek holop wrote: i have noticed that the sed man page has some strange clippings. the attached patch fixes it for me, but i dont know what was the intended effect. before: [1addr]a\ text Write text to standard output immediately before each attempt to read a line of input, whether by executing the `N' function or by beginning a new cycle. after: [1addr]a text Write text to standard output immediately before each attempt to read a line of input, whether by executing the `N' function or by beginning a new cycle. it's meant to look like that, though i'm not 100% sure that it can only take that format. you can look online for some example uses. however the man page way of using two list items to show this is a bit nasty. they should probably be rewritten. jmc --- sed.1.origTue May 20 15:25:58 2014 +++ sed.1 Tue May 20 15:30:16 2014 @@ -283,9 +283,7 @@ .Em function-list only when the pattern space is selected. .Pp -.It [1addr] Ns Em a Ns \e -.It Em text -.Pp +.It [1addr] Ns Em a Em text Write .Em text to standard output immediately before each attempt to read a line of input, @@ -299,9 +297,7 @@ function with the specified label. If the label is not specified, branch to the end of the script. .Pp -.It [2addr] Ns Em c Ns \e -.It Em text -.Pp +.It [2addr] Ns Em c Em text Delete the pattern space. With 0 or 1 address or at the end of a 2-address range, .Em text @@ -330,9 +326,7 @@ Append a newline character followed by the contents of the pattern space to the hold space. .Pp -.It [1addr] Ns Em i Ns \e -.It Em text -.Pp +.It [1addr] Ns Em i Em text Write .Em text to the standard output. -f -- friends, romans, and countrymen, lend me your ears.
Re: sed(1) man page issue
hmm, on Tue, May 20, 2014 at 06:46:30PM +0100, Jason McIntyre said that it's meant to look like that, though i'm not 100% sure that it can only take that format. you can look online for some example uses. oh. sorry for the noise then :] -f -- if you have to travel on a titanic, why not go first class?
Re: iked connecting with sophos (pluto)
ping? On 05/08/14 14:07, Martijn van Duren wrote: Hello misc, I'm currently trying to set up an ipsec connection from my laptop to the vpn at my work. I'm new to ipsec, so my apologies if I missed something obvious. When setting up the connection I do see my requests go to the server, but I never get a reply. My colleagues use an ipsec connection from the same network, so it should not be a network issue. I have pf on my laptop disabled for this test. Below are the system settings as used, both on the vpn-server as on my machine. I would like to know if someone could tell me what I'm doing wrong or whether this is a bug. server: - system: Sophos UTM 9 - daemon: Pluto (strongSwan 4.4.1git20100610 THREADS VENDORID CISCO_QUIRKS) - ip: aa.bb.cc.dd - config (the required information as far as I can see): Compression off, not using strict policy. IKE Settings: AES 256 / SHA1 / Group 2: MODP 1024 Lifetime: 36000 seconds IPsec Settings: AES 256 / SHA1 / Group 2: MODP 1024 Lifetime: 36000 seconds VPN ID: vpn01.company.tld client: - system: see dmesg below - network: In a NAT network, with public ip ee.ff.gg.hh - config: - initial: ikev2 company active esp \ from any to any \ peer vpn01.company.tld \ ikesa auth hmac-sha1 prf hmac-sha1 group modp1024 \ childsa auth hmac-sha1 enc aes-256 group modp1024 \ dstid vpn01.company.tld \ lifetime 36000 \ eap mschap-v2 - 2nd (more basic? config): ikev2 active esp from any to any peer vpn01.company.tld When starting the iked it sends its IKE_SA_INIT, but I never get a reply: ca_privkey_serialize: type RSA_KEY length 1192 ca_pubkey_serialize: type RSA_KEY length 270 ca_reload: local cert type RSA_KEY ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0 /etc/iked.conf: loaded 1 configuration rules config_getocsp: ocsp_url none config_getpolicy: received policy ikev2 policy1 active esp inet from any to any local any peer aa.bb.cc.dd ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1,hmac-md5 auth hmac-sha2-256,hmac-sha1,hmac-md5 group modp2048-256,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 lifetime 10800 bytes 536870912 rsa config_getpfkey: received pfkey fd 4 config_getcompile: compilation done config_getsocket: received socket fd 11 config_getsocket: received socket fd 12 config_getsocket: received socket fd 14 config_getsocket: received socket fd 20 ikev2_init_ike_sa: initiating policy1 ikev2_policy2id: srcid FQDN/loki.my.domain length 18 ikev2_add_proposals: length 132 ikev2_next_payload: length 136 nextpayload KE ikev2_next_payload: length 264 nextpayload NONCE ikev2_next_payload: length 36 nextpayload NOTIFY ikev2_nat_detection: local source 0x20ca1a29b41bb241 0x 0.0.0.0:500 ikev2_next_payload: length 28 nextpayload NOTIFY ikev2_nat_detection: local destination 0x20ca1a29b41bb241 0x 87.233.176.10:500 ikev2_next_payload: length 28 nextpayload NONE ikev2_pld_parse: header ispi 0x20ca1a29b41bb241 rspi 0x nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 520 response 0 ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 136 ikev2_pld_sa: more 0 reserved 0 length 132 proposal #1 protoid IKE spisize 0 xforms 14 spi 0 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_MD5 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_MD5_96 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048_256 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_1536 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024 ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 264 ikev2_pld_ke: dh group MODP_2048_256 reserved 0 ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 36 ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28 ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 28 ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP ikev2_msg_send:
Re: bind port broken
Le mardi 20 mai 2014, 12:41:35 Stuart Henderson a écrit : Stéphane Guedon stephane at 22decembre.eu writes: I don't know if I am doing things ok, but the Bind9 port seems broken (in a fresh 5.5 install). Thanks if someone fix it. Is there a particular reason you're not just using the packages provided? I see no advantage to building it yourself. # pkg_add isc-bind yeah, actually it seems to have solved the trick⦠But at the same I have fixed some others⦠All in all, I improved my setup ! Thanks ! [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
