Cannot understand iked
Hello everybody. I hope somebody can help me with iked. I have 2 gates, both can ping each other. One has this iked.conf: ikev2 from 212.233.112.10 to 192.168.1.0/24 \ from 192.168.2.0/23 to 192.168.1.0/24 \ local 212.233.112.10 srcid 212.233.112.10 Another has: ikev2 active \ from 77.220.137.168 to 192.168.2.0/23 \ from 192.168.1.0/24 to 192.168.2.0/23 \ peer 212.233.112.10 srcid 77.220.137.168 And the problem is: local lan clients can reach remote lan, but local gate itself cannot reach. Look: $ ping -c 2 -I 192.168.2.10 192.168.1.240 PING 192.168.1.240 (192.168.1.240): 56 data bytes 64 bytes from 192.168.1.240: icmp_seq=0 ttl=63 time=2.987 ms 64 bytes from 192.168.1.240: icmp_seq=1 ttl=63 time=2.243 ms --- 192.168.1.240 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss but $ ping -c 2 192.168.1.240 PING 192.168.1.240 (192.168.1.240): 56 data bytes --- 192.168.1.240 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss Both ping commands sent from same gate. Here is ipsecctl -sa from one of gates: FLOWS: flow esp in from 192.168.1.0/24 to 212.233.112.10 peer 77.220.137.168 srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type use flow esp out from 212.233.112.10 to 192.168.1.0/24 peer 77.220.137.168 srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type require flow esp in from 192.168.1.0/24 to 192.168.2.0/23 peer 77.220.137.168 srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type use flow esp out from 192.168.2.0/23 to 192.168.1.0/24 peer 77.220.137.168 srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 212.233.112.10 to 77.220.137.168 spi 0x22dd1b34 auth hmac-sha2-256 enc aes-256 esp tunnel from 77.220.137.168 to 212.233.112.10 spi 0xd1abf711 auth hmac-sha2-256 enc aes-256
Re: owncloudclient GUI issues - core dumps when non-root
On Wed, May 04, 2016 at 06:58:32AM +0200, Otto Moerbeek wrote: > On Tue, May 03, 2016 at 09:05:36PM -0400, Nick wrote: > > > Thanks for your advice, however it makes no difference changing login.conf > > in the way you mentioned.. Still errors out and core dumps. > > Root can't get access to it now either. Here's my login.conf, I changed the: > > > > :openfiles-cur=2048:\ > > :openfiles-max=4096:\ > > > > on my staff group as well, for which I'm a member of. > > login class != group > > The question is, which login group are you in. Also, the synatx of err, login class above > login.conf is a bit tricky. Check which login class you are in with > useinfo and check you actual limits with ulimit -a, userinfo sorry, for the typos, it's early here > > -Otto > > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-* MY LOGIN.CONF: -*-*-*-*-*-*-*-*-*-*-*-*- > > # /etc/login.conf > > > > default:\ > > :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/$ > > :umask=022:\ > > :datasize-max=2048M:\ > > :datasize-cur=2048M:\ > > :maxproc-max=1024:\ > > :maxproc-cur=512:\ > > :openfiles-cur=2048:\ > > :openfiles-max=4096:\ > > :stacksize-cur=4M:\ > > :localcipher=blowfish,8:\ > > :tc=auth-defaults:\ > > :tc=auth-ftp-defaults: > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-* AS REGULAR USER: -*-*-*-*-*-*-*-*-*-*-*-*- > > $ owncloud > > > > (owncloud:29572): GLib-ERROR **: Creating pipes for GWakeup: Too many open > > files > > > > Trace/BPT trap (core dumped) > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-* AND AS ROOT: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- > > $ su > > $ owncloud > > > > (process:3224): GConf-WARNING **: Client failed to connect to the D-BUS > > daemon: > > Did not receive a reply. Possible causes include: the remote application > > did not send a reply, the message bus security policy blocked the reply, > > the reply timeout expired, or the network connection was broken. > > > > (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS > > daemon: > > Did not receive a reply. Possible causes include: the remote application > > did not send a reply, the message bus security policy blocked the reply, > > the reply timeout expired, or the network connection was broken. > > > > (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS > > daemon: > > Did not receive a reply. Possible causes include: the remote application > > did not send a reply, the message bus security policy blocked the reply, > > the reply timeout expired, or the network connection was broken. > > > > (owncloud:3224): GLib-ERROR **: Creating pipes for GWakeup: Too many open > > files > > > > Trace/BPT trap > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- > > > > I can't think what could be causing this issue, not entirely sure how to > > debug this. > > > > > > > > Original Message > > Subject: Re: owncloudclient GUI issues - core dumps when non-root > > Local Time: May 3, 2016 9:58 PM > > UTC Time: May 3, 2016 8:58 PM > > From: zel...@zeloff.org > > To: > > CC: misc@openbsd.org > > > > On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote: > > > The owncloudclient refuses to work and core dumps on non-root user > > > Works but throws out warnings on root.. although I feel a little edgy > > > running this client as root. > > > > > > Application: owncloudclient > > > System: 5.9 Stable > > > > > > ### > > > $ owncloud > > > (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many > > > open files > > > Trace/BPT trap (core dumped) > > > > You need to bump openfiles on login.conf, e.g. > > > > :openfiles-cur=2048:\ > > :openfiles-max=4096:\ > > > > see login.conf(5), and don't forget to run cap_mkdb when you're done. > > You'll also need to log out and back in for it to take effect. When in > > doubt check things with ulimit -a and ulimit -Ha > > > > > > > $ gdb owncloud owncloud.core > > > #0 0x066932b634c5 in _g_log_abort () > > > from /usr/local/lib/libglib-2.0.so.4200.2 > > > > > > # > > > > > > $ su root > > > $ owncloud > > > > > > (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS > > > daemon: > > > Did not receive a reply. Possible causes include: the remote application > > > did not send a reply, the message bus security policy blocked the reply, > > > the reply timeout expired, or the network connection was broken. > > > > > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS > > > daemon: > > > Did not receive a reply. Possible causes include: the remote application > > > did not send a reply, the message bus security policy blocked the reply, > > > the reply timeout expired, or the network connection was broken. > > > Qt: Session management error: Authentication Rejected, reason : None of > > > the authentication protocols specified are supported and host-based > > > authentication failed > > > > > > (own
Re: owncloudclient GUI issues - core dumps when non-root
On Tue, May 03, 2016 at 09:05:36PM -0400, Nick wrote: > Thanks for your advice, however it makes no difference changing login.conf in > the way you mentioned.. Still errors out and core dumps. > Root can't get access to it now either. Here's my login.conf, I changed the: > > :openfiles-cur=2048:\ > :openfiles-max=4096:\ > > on my staff group as well, for which I'm a member of. login class != group The question is, which login group are you in. Also, the synatx of login.conf is a bit tricky. Check which login class you are in with useinfo and check you actual limits with ulimit -a, -Otto > > *-*-*-*-*-*-*-*-*-*-*-*-*-* MY LOGIN.CONF: -*-*-*-*-*-*-*-*-*-*-*-*- > # /etc/login.conf > > default:\ > :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/$ > :umask=022:\ > :datasize-max=2048M:\ > :datasize-cur=2048M:\ > :maxproc-max=1024:\ > :maxproc-cur=512:\ > :openfiles-cur=2048:\ > :openfiles-max=4096:\ > :stacksize-cur=4M:\ > :localcipher=blowfish,8:\ > :tc=auth-defaults:\ > :tc=auth-ftp-defaults: > > *-*-*-*-*-*-*-*-*-*-*-*-*-* AS REGULAR USER: -*-*-*-*-*-*-*-*-*-*-*-*- > $ owncloud > > (owncloud:29572): GLib-ERROR **: Creating pipes for GWakeup: Too many open > files > > Trace/BPT trap (core dumped) > > *-*-*-*-*-*-*-*-*-*-*-*-*-* AND AS ROOT: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- > $ su > $ owncloud > > (process:3224): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > > (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > > (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > > (owncloud:3224): GLib-ERROR **: Creating pipes for GWakeup: Too many open > files > > Trace/BPT trap > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- > > I can't think what could be causing this issue, not entirely sure how to > debug this. > > > > Original Message > Subject: Re: owncloudclient GUI issues - core dumps when non-root > Local Time: May 3, 2016 9:58 PM > UTC Time: May 3, 2016 8:58 PM > From: zel...@zeloff.org > To: > CC: misc@openbsd.org > > On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote: > > The owncloudclient refuses to work and core dumps on non-root user > > Works but throws out warnings on root.. although I feel a little edgy > > running this client as root. > > > > Application: owncloudclient > > System: 5.9 Stable > > > > ### > > $ owncloud > > (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open > > files > > Trace/BPT trap (core dumped) > > You need to bump openfiles on login.conf, e.g. > > :openfiles-cur=2048:\ > :openfiles-max=4096:\ > > see login.conf(5), and don't forget to run cap_mkdb when you're done. > You'll also need to log out and back in for it to take effect. When in > doubt check things with ulimit -a and ulimit -Ha > > > > $ gdb owncloud owncloud.core > > #0 0x066932b634c5 in _g_log_abort () > > from /usr/local/lib/libglib-2.0.so.4200.2 > > > > # > > > > $ su root > > $ owncloud > > > > (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS > > daemon: > > Did not receive a reply. Possible causes include: the remote application > > did not send a reply, the message bus security policy blocked the reply, > > the reply timeout expired, or the network connection was broken. > > > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS > > daemon: > > Did not receive a reply. Possible causes include: the remote application > > did not send a reply, the message bus security policy blocked the reply, > > the reply timeout expired, or the network connection was broken. > > Qt: Session management error: Authentication Rejected, reason : None of the > > authentication protocols specified are supported and host-based > > authentication failed > > > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS > > daemon: > > Did not receive a reply. Possible causes include: the remote application > > did not send a reply, the message bus security policy blocked the reply, > > the reply timeout expired, or the network connection was broken. > > This doesn't crash /probably/ because owncloud using root's owncloud > configuration (whatever th
Re: Openbsd broke my hard drive twice! Getting frustrated
On 12/29, Gabriel Guzman wrote: > I've been seeing a similar issue on a DELL XPS 13" Developer edition I got > back in June -- ran fine with ubuntu as shipped with Dell, and then I > wiped and installed OpenBSD and now can't even access the BIOS. I figured out the issue. On my machine (DEL XPS 13) it was the "Intel Rapid Boot" option in BIOS. Disabling that resolved all my boot issues. I can now boot with MBR or GPT off the internal SSD. And, I can also access the BIOS with the internal SSD installed in the system (this was not possible before) gabe.
Re: getentropy(2) and random(4) at boot
> The random(4) device on FreeBSD will block until the generator is > seeded [0], but not after, unless kern.random.sys.seeded is changed. > > Is this the case for getentropy(2) or random(4) on OpenBSD, and if > not, would it be a good idea to make it do so? > > [0] https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4 it does not need to block, because it is *always* seeded. http://www.openbsd.org/papers/hackfest2014-arc4random/index.html
getentropy(2) and random(4) at boot
The random(4) device on FreeBSD will block until the generator is seeded [0], but not after, unless kern.random.sys.seeded is changed. Is this the case for getentropy(2) or random(4) on OpenBSD, and if not, would it be a good idea to make it do so? [0] https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4
Re: Short maximum interpreter length
On Tue, May 3, 2016 at 9:21 PM, Ted Unangst wrote: > Aioi Yuuko wrote: >> Why is MAXINTERP in only 128? I can think of a few: >> >> 1. It's been that way a while and nobody's complained >> 2. If someone's shebangs are longer than that, they're probably doing >> whatever they're doing horribly, horribly wrong >> 3. Historical compatibility >> >> Is it one of those? If not, is it something else? > > Why does it need to be more? So we can run /usr/bin/5CBC4234CA9D027019381215FAFB31E6482D4B252A36E1EBD5FCFAD12F9E10B85C4C2C917E3DBE6C765CED9719F4F449C47AC9263513458BBEA76B617339B75A scripts.
Re: Short maximum interpreter length
Aioi Yuuko wrote: > Why is MAXINTERP in only 128? I can think of a few: > > 1. It's been that way a while and nobody's complained > 2. If someone's shebangs are longer than that, they're probably doing > whatever they're doing horribly, horribly wrong > 3. Historical compatibility > > Is it one of those? If not, is it something else? Why does it need to be more?
Re: owncloudclient GUI issues - core dumps when non-root
Thanks for your advice, however it makes no difference changing login.conf in the way you mentioned.. Still errors out and core dumps. Root can't get access to it now either. Here's my login.conf, I changed the: :openfiles-cur=2048:\ :openfiles-max=4096:\ on my staff group as well, for which I'm a member of. *-*-*-*-*-*-*-*-*-*-*-*-*-* MY LOGIN.CONF: -*-*-*-*-*-*-*-*-*-*-*-*- # /etc/login.conf default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/$ :umask=022:\ :datasize-max=2048M:\ :datasize-cur=2048M:\ :maxproc-max=1024:\ :maxproc-cur=512:\ :openfiles-cur=2048:\ :openfiles-max=4096:\ :stacksize-cur=4M:\ :localcipher=blowfish,8:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: *-*-*-*-*-*-*-*-*-*-*-*-*-* AS REGULAR USER: -*-*-*-*-*-*-*-*-*-*-*-*- $ owncloud (owncloud:29572): GLib-ERROR **: Creating pipes for GWakeup: Too many open files Trace/BPT trap (core dumped) *-*-*-*-*-*-*-*-*-*-*-*-*-* AND AS ROOT: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- $ su $ owncloud (process:3224): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (owncloud:3224): GLib-ERROR **: Creating pipes for GWakeup: Too many open files Trace/BPT trap *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- I can't think what could be causing this issue, not entirely sure how to debug this. Original Message Subject: Re: owncloudclient GUI issues - core dumps when non-root Local Time: May 3, 2016 9:58 PM UTC Time: May 3, 2016 8:58 PM From: zel...@zeloff.org To: CC: misc@openbsd.org On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote: > The owncloudclient refuses to work and core dumps on non-root user > Works but throws out warnings on root.. although I feel a little edgy running > this client as root. > > Application: owncloudclient > System: 5.9 Stable > > ### > $ owncloud > (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open > files > Trace/BPT trap (core dumped) You need to bump openfiles on login.conf, e.g. :openfiles-cur=2048:\ :openfiles-max=4096:\ see login.conf(5), and don't forget to run cap_mkdb when you're done. You'll also need to log out and back in for it to take effect. When in doubt check things with ulimit -a and ulimit -Ha > $ gdb owncloud owncloud.core > #0 0x066932b634c5 in _g_log_abort () > from /usr/local/lib/libglib-2.0.so.4200.2 > > # > > $ su root > $ owncloud > > (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > Qt: Session management error: Authentication Rejected, reason : None of the > authentication protocols specified are supported and host-based > authentication failed > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. This doesn't crash /probably/ because owncloud using root's owncloud configuration (whatever that is), i.e., it's not monitoring the same folder as when it is run by you. > > -*-*-* > > Thanks > --
Short maximum interpreter length
Why is MAXINTERP in only 128? I can think of a few: 1. It's been that way a while and nobody's complained 2. If someone's shebangs are longer than that, they're probably doing whatever they're doing horribly, horribly wrong 3. Historical compatibility Is it one of those? If not, is it something else?
Re: FW: Re: watchdog suport for new hardware
On Tue, May 03, 2016 at 03:32:34PM -0500, Chase Davis wrote: > Mike, > > We took your suggestion and re-wrote the driver to model sdhc_acpi. I > have attached the new code. However, the match function never returns > a 1. We put temporary print statements in the match routine. It is > being called several times during the kernel boot process, but it > never finds a device with HID SEL0002. Do you have any suggestions for > why it would show up in the DSDT tables when we do an acpidump, but > that the match routine never finds it? > > This is a snippet from the dmesg boot log > > Attempting to match SEL: result (0) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > Attempting to match SEL: result (0) > Attempting to match SEL: result (0) > Attempting to match SEL: result (0) > Attempting to match SEL: result (0) > acpihpet0 at acpi0: 14318179 Hz > Attempting to match SEL: result (0) > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > int > sel_acpi_match(struct device *parent, void *match, void *aux) > { > struct acpi_attach_args *aaa = aux; > struct cfdata *cf = match; > printf("Attempting to match SEL: "); > int res = acpi_matchhids(aaa, sel_hids, cf->cf_driver->cd_name); > printf("result (%d)\n", res); > return res; > } > > Thanks, > Chase I think this diff is missing some parts. Like GENERIC? Also, you need a NULL after your last HID or matchhids will walk all through memory until it hits a NULL. -ml > /*$OpenBSD: sel.c,v 1.0 2016/04/01 05:00:00 jsg Exp $ */ > /* > * Copyright (c) 2016 PREMIER System Integrators > * > * Permission to use, copy, modify, and distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > * > * Schweitzer Engineering Laboratories: SEL-3355 Embedded controller > */ > > #include > #include > #include > #include > #include > #include > > #include > > #include > #include > #include > #include > #include > > #include > > struct sel_host; > > struct sel_softc { > /* sc_dev must be the first item in the struct */ > struct device sc_dev; > struct sel_host **sc_host; > }; > > struct sel_acpi_softc { > struct sel_softcsc; > struct acpi_softc *sc_acpi; > struct aml_node *sc_node; > > /* device access through bus space */ > bus_space_tag_t sc_iot; > bus_space_handle_t sc_ioh; > bus_addr_t sc_addr; > bus_size_t sc_size; > > struct sel_host *sc_host; > }; > > int sel_wait(bus_space_tag_t, bus_space_handle_t, bool); > > /* Autoconfiguration glue */ > int sel_acpi_match(struct device *, void *, void *); > void sel_acpi_attach(struct device *, struct device *, void *); > int sel_print(void *, const char *); > int sel_wd_cb(void *, int); > > /* functions to interact with the controller */ > void sel_write_wdog(bus_space_tag_t, bus_space_handle_t, int); > u_int8_t sel_read_wdog(bus_space_tag_t, bus_space_handle_t); > u_int8_t sel_read_status(bus_space_tag_t, bus_space_handle_t); > void sel_abort(bus_space_tag_t, bus_space_handle_t); > u_int32_t sel_read_boardid(bus_space_tag_t, bus_space_handle_t); > u_int32_t sel_read_mcversion(bus_space_tag_t, bus_space_handle_t); > u_int16_t sel_read_pciboardid(bus_space_tag_t, bus_space_handle_t); > u_int8_t sel_read_ledctl0(bus_space_tag_t, bus_space_handle_t); > void sel_write_ledctl0(bus_space_tag_t, bus_space_handle_t, u_int8_t); > u_int8_t sel_read_ledctl1(bus_space_tag_t, bus_space_handle_t); > void sel_write_ledctl1(bus_space_tag_t, bus_space_handle_t, u_int8_t); > u_int8_t sel_read_miscctl0(bus_space_tag_t, bus_space_handle_t); > u_int8_t sel_read_miscctl1(bus_space_tag_t, bus_space_handle_t); > void sel_read_modelno(bus_space_tag_t, bus_space_handle_t, char*); > void sel_read_serialno(bus_space_tag_t, bus_space_handle_t, char*); > void sel_read_configid(bus_space_tag_t, bus_space_handle_t, char*); > > /* macros to extract bits from the status register */ > #define EC_STATUS_IBF(status) (((status) >> 0x1) & 0x1) > #define EC_STATUS_OBF(status) (((status) & 0x1)) > #define EC_STATUS_BUSY(status)(((status) >> 0x4) & 0x1) > #define EC_STATUS_STATE(status) (((status) >> 0x6) & 0x3) > > struct cfattach sel_acpi_ca = { > sizeof(struct sel_acpi_softc), sel_acpi_match, sel_acpi_attach > }; > > struct
Re: owncloudclient GUI issues - core dumps when non-root
On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote: > The owncloudclient refuses to work and core dumps on non-root user > Works but throws out warnings on root.. although I feel a little edgy running > this client as root. > > Application: owncloudclient > System: 5.9 Stable > > ### > $ owncloud > (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open > files > Trace/BPT trap (core dumped) You need to bump openfiles on login.conf, e.g. :openfiles-cur=2048:\ :openfiles-max=4096:\ see login.conf(5), and don't forget to run cap_mkdb when you're done. You'll also need to log out and back in for it to take effect. When in doubt check things with ulimit -a and ulimit -Ha > $ gdb owncloud owncloud.core > #0 0x066932b634c5 in _g_log_abort () > from /usr/local/lib/libglib-2.0.so.4200.2 > > # > > $ su root > $ owncloud > > (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > Qt: Session management error: Authentication Rejected, reason : None of the > authentication protocols specified are supported and host-based > authentication failed > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS > daemon: > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. This doesn't crash /probably/ because owncloud using root's owncloud configuration (whatever that is), i.e., it's not monitoring the same folder as when it is run by you. > > -*-*-* > > Thanks > --
Re: FW: Re: watchdog suport for new hardware
Mike, We took your suggestion and re-wrote the driver to model sdhc_acpi. I have attached the new code. However, the match function never returns a 1. We put temporary print statements in the match routine. It is being called several times during the kernel boot process, but it never finds a device with HID SEL0002. Do you have any suggestions for why it would show up in the DSDT tables when we do an acpidump, but that the match routine never finds it? This is a snippet from the dmesg boot log Attempting to match SEL: result (0) acpitimer0 at acpi0: 3579545 Hz, 24 bits Attempting to match SEL: result (0) Attempting to match SEL: result (0) Attempting to match SEL: result (0) Attempting to match SEL: result (0) acpihpet0 at acpi0: 14318179 Hz Attempting to match SEL: result (0) acpimadt0 at acpi0 addr 0xfee0: PC-AT compat int sel_acpi_match(struct device *parent, void *match, void *aux) { struct acpi_attach_args *aaa = aux; struct cfdata *cf = match; printf("Attempting to match SEL: "); int res = acpi_matchhids(aaa, sel_hids, cf->cf_driver->cd_name); printf("result (%d)\n", res); return res; } Thanks, Chase [demime 1.01d removed an attachment of type text/x-csrc which had a name of sel_acpi.c] [demime 1.01d removed an attachment of type text/x-chdr which had a name of selreg.h]
owncloudclient GUI issues - core dumps when non-root
The owncloudclient refuses to work and core dumps on non-root user Works but throws out warnings on root.. although I feel a little edgy running this client as root. Application: owncloudclient System: 5.9 Stable ### $ owncloud (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open files Trace/BPT trap (core dumped) $ gdb owncloud owncloud.core #0 0x066932b634c5 in _g_log_abort () from /usr/local/lib/libglib-2.0.so.4200.2 # $ su root $ owncloud (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. -*-*-* Thanks
owncloud forgetting stored user and admin passwords. 5.9-Stable
I have been having these issues with owncloud on 5.9 Stable where I will go to log in and says password is wrong, I have two set ups - one in the cloud and one at home, both are randomly doing this. My partner had to change password 8 times last night before it would actually work on next log back in login. Anyone else been having similar issues?
Re: Will mmap and the read buffer cache be unified, anyone working with it?
A separate question about combining mmap access and file IO in the current absence of a unified buffer cache: If I have a readonly mmap and do fwrite to it, could I use fsync (or msync or any other call) right after the fwrite, as a tool to guarantee that the memory mapping interface is up to date? Also between the fwrite and that call, the possible data inconsistency would be limited to the particular bytes written right? On 2015-11-12 15:45, Stuart Henderson wrote:
Re: mfs vs tmpfs: advantages and disadvantages
On Tue, 03 May 2016 02:53:36 -0600 Theo de Raadt wrote: > mfs is reliable. > tmpfs has bugs, and as a result of those bugs, it has fewer and fewer > users. > Or, maybe there are fewer problem reports because fewer people use > it, because those who tried to use it ran into problems and walked > away from it? Thanks Theo, that explains a lot. The future doesn't look too good for tmpfs in this case. > Absolutely no way, that makes no sense. Understood; I wasn't going to write anything until I was sure anyway.
Re: mfs vs tmpfs: advantages and disadvantages
I actually wrote a patch to that a while back, and it was not accepted. Looking back, I am not disappointed that it was rejected, and it forced me to find another solution: shell scripts, included below. However, in light of what Theo said, I'm possibly going to move back to mfs; even if I haven't had any issues with tmpfs yet, I feel the need to be somewhat proactive. Whilst not exactly Michelangelo's finest work of art, it's probably better than the original set of patches I submitted. I use the following in /etc/fstab: swap /var/log tmpfs.sh rw,nodev,noexec,nosuid,-s=64M,-P=/M/var/log Stored in /sbin/mount_tmpfs.sh: #!/bin/sh while getopts :g:m:n:o:P:s:u: OPT; do if [ "$OPT" == 'P' ]; then TEMPLATE=$OPTARG else MCPARAM="$MCPARAM -$OPT $OPTARG" fi done shift `expr $OPTIND - 1` /sbin/mount_tmpfs $MCPARAM $* if [ "$TEMPLATE" != "" ]; then shift `expr $# - 1` (cd "$TEMPLATE"; /bin/pax -rw -pe . "$1") fi On Tue, 3 May 2016 04:57:54 -0400 Jiri B wrote: > On Tue, May 03, 2016 at 05:08:06PM +1000, bytevolc...@safe-mail.net > wrote: > > With tmpfs being in the tree for the last 2+ years (since OpenBSD > > 5.5), I would like to ask, besides the "-P" option in mount_mfs, > > what is the advantage of using mfs over tmpfs? > > tmpfs on Bitrig does support snapshots, which can be used as an > alternative to mpf's "-P". If you are interested check it out. > > j.
rwhod in 5.9 ?
Building 5.9 machines to replace 5.5 ones. Looking in /usr/src on the 5.9 machines, I do not see the code for rwhod. Has this been removed, and if so, why? We use this on all of our mahcines. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: mfs vs tmpfs: advantages and disadvantages
On Tue, May 03, 2016 at 05:08:06PM +1000, bytevolc...@safe-mail.net wrote: > With tmpfs being in the tree for the last 2+ years (since OpenBSD 5.5), > I would like to ask, besides the "-P" option in mount_mfs, what is the > advantage of using mfs over tmpfs? tmpfs on Bitrig does support snapshots, which can be used as an alternative to mpf's "-P". If you are interested check it out. j.
Re: mfs vs tmpfs: advantages and disadvantages
> With tmpfs being in the tree for the last 2+ years (since OpenBSD 5.5), > I would like to ask, besides the "-P" option in mount_mfs, what is the > advantage of using mfs over tmpfs? mfs is reliable. > It seems tmpfs has the following advantages: > > - Can grow or shrink; shrinks when files are erased. > - Can impose definite limits on number of inodes/files (then again, >this happens in mfs too). > - Dedicated memory structures used, rather than just plonking an >entire disk FS onto it. tmpfs has bugs, and as a result of those bugs, it has fewer and fewer users. > I have seen discussions here: > http://marc.info/?l=openbsd-tech&m=139935771507987&w=2 > > There is a claim that tmpfs is not as stable on that thread, but that > was back in 2014 when this was still new. Or, maybe there are fewer problem reports because fewer people use it, because those who tried to use it ran into problems and walked away from it? > I am willing to write a patch (or series of patches) to remove mfs > support if it is deemed to be unused/unnecessary; unfortunately I only > have access to an old amd64 machine for testing. Absolutely no way, that makes no sense.
mfs vs tmpfs: advantages and disadvantages
Hello, With tmpfs being in the tree for the last 2+ years (since OpenBSD 5.5), I would like to ask, besides the "-P" option in mount_mfs, what is the advantage of using mfs over tmpfs? It seems tmpfs has the following advantages: - Can grow or shrink; shrinks when files are erased. - Can impose definite limits on number of inodes/files (then again, this happens in mfs too). - Dedicated memory structures used, rather than just plonking an entire disk FS onto it. I have seen discussions here: http://marc.info/?l=openbsd-tech&m=139935771507987&w=2 There is a claim that tmpfs is not as stable on that thread, but that was back in 2014 when this was still new. I am willing to write a patch (or series of patches) to remove mfs support if it is deemed to be unused/unnecessary; unfortunately I only have access to an old amd64 machine for testing. Thoughts?
Re: Laptop not waking from suspend on opening lid
On 03 May 2016, Anthony Campbell wrote: > On 02 May 2016, Mike Larkin wrote: > > On Sun, May 01, 2016 at 04:08:28PM +0100, Anthony Campbell wrote: > > > This is on a Thinkpad Z61m running amd64. Suspend on lid closure has > > > worked without problems for many months with numerous snapshots. After > > > upgrading on 30 April the machine no longer wakes on lid opening. The > > > sleep symbol below the screen blinks repeatedly but nothing else > > > happens. > > > > > > If I suspend it with Fn+F4 the same thing happens; it is impossible to > > > wake the machine. > > > > > > Another Thinkpad running i386 is not affected. > > > > > > > When did it last work? Eg, when before "30 April"? > > > > -ml > > > > Yes, it was fine with pretty regular snapsot upgrades until 30 April. > The problem began after that upgrade. A further upgrade on 1 May did not > restore things. > I forgot to say that the same problem, also beginning on 30 April, was discussed on openbsd-bugs@. The suggestion there was that it was only occurring on one laptop, but clearly that isn't the case since I have it too. See http://marc.info/?l=openbsd-bugs&m=145979568820455&w=2. Anthony -- Anthony Campbellhttp://www.acampbell.uk