Hi folks,
according to the upgrade guide I added "-soii" to hostname.re1.
It seems to work as expected, but it is not documented in
hostname.if(5).
Would you mind to add this option to the man page?
Except for changing the link local IPv6 addresses the upgrade
to 6.3 worked very well. No surpris
On 04/03/18 14:41, Florian Obser wrote:
> On Tue, Apr 03, 2018 at 01:17:06PM +0200, Harald Dunkel wrote:
>>
>> Except for changing the link local IPv6 addresses the upgrade
>
> Hmm? But you added -soii? So the link local v6 address should not have
> changed?
>
Inde
On 04/07/18 15:27, Jason McIntyre wrote:
>
> hi.
>
> sorry i'm a bit late to the party. did everything get cleared up? soii
> is documented in ifconfig(8), as expected, and linked to from
> hostname.if(5). it is not needed to be explicitly documented in
> hostname.if(5). hope that's all clear.
>
Hi folks,
hopefully its allowed to repost this message here:
One gateway running 6.3 ran into the debugger last night. Last words:
login: kernel: protection fault trap, code=0
Stopped at export_sa+0x5c: movl0(%rcx),%ecx
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
export_s
Thanx for the patch, but I wonder how I can create a syspatch from
it? If I patch, build and install stable from source, then my hosts
are cut off from the syspatch scheme. That would be highly painful.
Every helpful comment is highly appreciated.
Harri
On 5/16/18 1:07 PM, Stuart Henderson wrote:
You can't create a syspatch from it.
I am talking about a *private* syspatch. Something that I can
revert later to gain access to the official syspatches again.
That should be possible.
If you can get it tested as a patch on a self-built -stable k
On 5/16/18 10:20 AM, Martin Pieuchot wrote:
That means that the TDB has already been freed. This is possible
because the timeout sleeps on the NET_LOCK(). Diff below should prevent
that by introducing a tdb_reaper() function like we do in other parts of
the stack.
I have booted the patched
Hi folks,
On 5/16/18 3:32 PM, Harald Dunkel wrote:
On 5/16/18 10:20 AM, Martin Pieuchot wrote:
That means that the TDB has already been freed. This is possible
because the timeout sleeps on the NET_LOCK(). Diff below should prevent
that by introducing a tdb_reaper() function like we do in
Hi folks,
On 5/16/18 1:07 PM, Stuart Henderson wrote:
If you can get it tested as a patch on a self-built -stable kernel
and we can get it committed then there's a *chance* it might be
errata worthy in which case you could go back to syspatches instead.
The patched kernel is running for a we
On 5/25/18 3:20 PM, Alexander Bluhm wrote:
> On Tue, May 22, 2018 at 07:32:29AM +0200, Harald Dunkel wrote:
>> Do you think this is worth a syspatch?
>
> You are asking this question for three times. The answer is no.
>
Twice, IIRC. My apologies. Thanx for your answer. I am
Hi folks,
On 5/16/18 10:20 AM, Martin Pieuchot wrote:
On 16/05/18(Wed) 08:06, Harald Dunkel wrote:
Hi folks,
Thanks for the report.
hopefully its allowed to repost this message here:
One gateway running 6.3 ran into the debugger last night. Last words:
login: kernel: protection fault
On 6/26/18 10:56 AM, Harald Dunkel wrote:
Hi folks,
Is it possible that this problem was introduced by syspatch 008_ipsecout ?
AFAICS my hosts without 008_ipsecout did not die, so I take the
silence as a "yes".
Regards
Harri
Hi folks,
I am using IPv6-only on em0, dual stack on em1 and em2. The
corresponding carp interfaces carp{0..2} are all dual stack.
Platform is OpenBSD 6.3 plus the most recent syspatches.
Problem:
It seems that net.inet.carp.preempt=1 is not working. If I
reboot the regular master, then the dedi
Hi Stuart,
On 6/29/18 11:23 AM, Stuart Henderson wrote:
>
> Suggestions: include "ifconfig -A" and "ifconfig -g carp" output from both
> machines, also bump up net.inet.carp.log and see if that gives any clues.
>
Found it:
I have a fail-save packet filter file, which is loaded before the
"larg
Hi Martin and all others involved,
On 5/16/18 10:20 AM, Martin Pieuchot wrote:
On 16/05/18(Wed) 08:06, Harald Dunkel wrote:
Hi folks,
Thanks for the report.
I highly appreciate the syspatch. Thanx very much
Regards
Harri
Hi folks,
since 6.2 systpatch complains
# syspatch
syspatch: invalid URL configured in /etc/installurl
# cat /etc/installurl
On Thu, 12 Oct 2017 10:36:13 +0100
Stuart Henderson wrote:
>
> Remove the trailing slash.
>
Thanx, this was the trick.
Harri
>
> Remove the trailing slash.
>
You run into the same problem, if you use copy and paste
from the mirrors page
https://www.openbsd.org/ftp.html
This is error-prone. For 6.1 it worked better. I would
recommend to fix the code, and to keep the mirrors page as
it is.
Regards
Harri
Hi folks,
I have to keep the flags of dnsmasq and openvpn in sync on
several hosts, even though some hosts are just a hot standby,
not running the service per default.
Problem: The "flags" in rcctl is overloaded (probably for
historical reasons): If flags is set to "NO", then the service
is n
On Wed, 18 Oct 2017 10:25:52 +0200
Harald Dunkel wrote:
> Hi folks,
>
> I have to keep the flags of dnsmasq and openvpn in sync on
> several hosts, even though some hosts are just a hot standby,
> not running the service per default.
>
> Problem: The "flags" i
Hi Sebastian,
On 11/15/17 12:22 PM, Sebastian Benoit wrote:
> Harald Dunkel(harald.dun...@aixigo.de) on 2017.11.14 07:48:01 +0100:
>>
>> Do you think the request to distinguish between the "usual" command
>> line flags and the information whether a service shoul
Hi Stuart,
On 11/20/17 10:43 AM, Stuart Henderson wrote:
>
> There is a difference in the mechanism between daemons from packages
> (where it would be _possible_ to enable/disable independent of storing
> flags) and daemons from base (where it is not, unless changes are made
> to rc.conf - and I
>Synopsis: spoofed icmp6 echo reply for link local address
>Category: system
>Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1 (GENERIC.MP) #7: Mon Jun 12 20:41:01 CEST 2017
rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/am
PS: I need a ping to the link-local address for monitoring
(because it doesn't change). It would be very nice if somebody
could look into this.
Thanx very much
Harri
On 06/24/17 11:57, Stuart Henderson wrote:
>
> Since you have a 6.0 system handy, are you able to apply
> https://github.com/openbsd/src/commit/3e4bd4b41d124df8849a234977327b543297783e.patch
> to the kernel to see if this is what introduces the breakage?
>
No, it doesn't:
# tcpdump -i em0 -env
On 06/24/17 15:08, Stuart Henderson wrote:
>
> Hmm.. Are you able to go through some date-based checkouts of sys/netinet6
> between say mid-august and mid-november to try to find when it got introduced?
>
I can try, but wouldn't it be easier to boot the snapshot
kernels of this time? Are they st
Hi Stuart,
On 06/24/17 15:08, Stuart Henderson wrote:
>
> Hmm.. Are you able to go through some date-based checkouts of sys/netinet6
> between say mid-august and mid-november to try to find when it got introduced?
>
That was a lot of work.
Seems that the problem was introduced by
270aa588bf83
On 06/26/17 16:17, Alexander Bluhm wrote:
>
> I have commited the fix. Thanks for identifying the breakage.
>
> bluhm
>
Your welcome.
Will it be included in stable as well?
Regards
Harri
Hi folks,
after applying the most recent syspatches for 7.1 there was a system
panic at reboot time. See below.
Regards
Harriddb{0}> trace
db_enter() at db_enter+0x10
panic(81f1c877) at panic+0xbf
__assert(81f8df95,81fa63b7,469,81f7a1f2) at __assert+0x
25
vgonel(
Hi folks,
would it be possible to improve wireguard logging in OpenBSD?
A message like
Receiving handshake initiation from peer 17
in /var/log/messages of 2 weeks ago isn't really helpful. Peer
17 might have become peer 8 over time, for example.
For forensic measures in case of an inci
Hi Stuart,
On 2023-08-11 11:39:24, Stuart Henderson wrote:
On 2023/08/11 08:47, Harald Dunkel wrote:
For forensic measures in case of an incident it is crucial to
have the peers public key. This string is constant over time
(unless it is not rotated for security). The first 16 or 10
chars
Hi folks,
using the current dovecot-2.3.19.1p0v0 I had to increase the limits for
dovecot's filehandles from 1024/2048 to 4096/8192. Without this change
Thunderbird (running on Linux or MacOS) was horrible unresponsive.
Question is, why were the limits decreased in /etc/login.conf.d/dovecot
Hi folks,
I would highly appreciate a syspatch. I've got 7 openbsd gateways (all
headless systems, 7.2) in production. Buildung a custom kernel would
disconnect these hosts from further syspatches, AFAIK.
Thank you very much for your good work, anyway.
Harri
On 2022-11-22 09:01:22, Alexandr
Hi folks,
I highly appreciate your fix. Installed it on all my gateways
last night.
Regards
Harri
>Synopsis: 7.3 regression: high network latency every 12 seconds on all
>interfaces
>Category: network
>Environment:
System : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT
2023
dera...@amd64.openbsd.org:/
On 5/7/21 5:34 AM, Antonino Sidoti wrote:
Hello,
This is fresh install, no upgrade. After installing firmware updates the system
gets a DDB prompt.
Metoo, but for an upgrade from 6.8 to 6.9. See attachment for a sample
session. I have to power cycle the host to make the host boot again.
Thi
Hi folks,
On 5/17/21 9:04 AM, Harald Dunkel wrote:
On 5/7/21 5:34 AM, Antonino Sidoti wrote:
Hello,
This is fresh install, no upgrade. After installing firmware updates the system
gets a DDB prompt.
Metoo, but for an upgrade from 6.8 to 6.9. See attachment for a sample
session. I have to
Hi folks,
according to a thread on misc the rdr-to example in pf.conf(5)
is not correct. It should be
pass in on $int_if proto { tcp, udp } from any to any port 80 \
rdr-to 127.0.0.1 port 80
pass in on $int_if proto { tcp, udp } from any to $server port 80
pass in on $int_if proto { tcp, udp
38 matches
Mail list logo
