> From: Stefan Sperling
> Sent: Friday, December 1, 2017 10:35 AM
>
> Problems with ehci(4) on AMD SB700 are known.
> For instance, athn(4) USB devices don't work on such ports.
Interesting; that's a similar device to the LTE network modem I'm working
with.
> Could you try adding missing
> From: justina colmena
> Sent: Tuesday, May 22, 2018 9:08 PM
>
> Are they being started in the wrong order at boot time?
The LDAP server in use is not running on the local openBSD system. It might not
be available due to an underlying network issue or some other problem that
temporarily
So I recently converted my opensmtpd server to use ldap as the backend
for user authentication. It seems it's a bit untolerant to ldap issues?
If the ldap server isn't available when opensmtpd is started, it says it
started:
# /etc/rc.d/smtpd start
smtpd(ok)
But it isn't there:
# ps -aux |
> From: Gilles Chehade
> Sent: Wednesday, May 23, 2018 1:20 PM
>
> That's bad but could easily be fixed if you want to help us
Definitely; I'll pull the latest github head down and see if that fixes the
LDAP connection recovery after startup issue, and then I can try any
suggestions to make it
> From: Gilles Chehade
> Sent: Wednesday, May 23, 2018 1:20 PM
>
> That's bad but could easily be fixed if you want to help us
So I dropped in the latest table-ldap from git, and it still failed
authentications after an LDAP server outage. It looks like the check is only
in the table_ldap_check
On Sat, May 26, 2018 at 08:16:28AM +0200, Gilles Chehade wrote:
> please do so we have more people able to test
Done, thanks.
What are your thoughts design-wise on dealing with ldap not being
available at startup? Should layer 7 issues (ldap auth failed, etc) be
handled differently than
Thanks for the info. I don't want to move any interfaces to a
non-default routing domain, I just want to be able to run a process with
a different default route. I can make that work, via the route -T 10
exec you mention after setting a default route in that domain.
But I can't seem to get
On Wed, Jan 17, 2018 at 12:56:04PM +0100, Christopher Zimmermann wrote:
> I have the same problem and have tried to hunt the bug, but failed so
> far. Have you already identified the quirks linux and freebsd use to
> fix this problem?
No :(, I worked on it for a while but kernel hacking isn't my
On Thu, Dec 21, 2017 at 12:52:33PM -0700, Chris Bennett wrote:
> > > IP: 104.217.196.248/29
> > > Gateway: 104.217.196.249
> > > Netmask: 255.255.255.248
> > >
> >
> > What is your network interface?
> >
>
> I have two, em0 and em1
>
> em0:
> inet 104.217.196.248 255.255.255.248
>
> And I
I just upgraded to OpenBSD 6.4, and I'm trying to figure out how to do
this with the new syntax:
accept from local for any relay via smtp://smtp.domain.com as "@domain.com"
This would rewrite the outbound message to masquerade as being from the
TLD rather than a specific machine. Right now I've
On Wed, Oct 31, 2018 at 08:07:09PM -0400, TronDD wrote:
> Mail-from in the action options, I believe.
Ah, yes; that seems to work, thanks. The previous implementation was
documented as:
If the as parameter is specified, smtpd(8) will rewrite
the sender advertised in the SMTP session. address
I recently updated a couple servers that were running OpenBSD 6.3 with bind
9.11.3 to OpenBSD 6.4 and bind 9.11.4pl2. Since then, I'm been getting a large
number of "error sending response: would block" log messages:
Nov 15 11:03:58 lisa named[79587]: client @0x6f2f02bc440 10.128.30.77#65198
I'm trying to set a longer timeout on a udp state, and for some reason it
seems to be disappearing before the expiration 8-/.
There are 3 rules involved:
pass in quick on vlan110 proto udp from any to port = 9430 tag VOIP_UDP keep
state (udp.multiple 360)
pass out quick on $ext_if proto udp
On 5/17/2020 8:40 PM, Strahil Nikolov wrote:
> What is your conf having as a timeout ?
Both of the rules explicitly override the default timeout with a six
minute rule level timeout:
pass in quick on vlan110 proto udp from any to port = 9430 tag
VOIP_UDP keep state (udp.multiple 360)
I'm running OpenBSD 6.6 operating as an inter-VLAN and border router
using pf. Recently I wanted to use a nondefault state timeout for some
UDP traffic traversing from my voip subnet to a provider off site.
Within pf, there are three rules involved. The first is for traffic
coming from the
On 6/5/2020 11:15 PM, obs...@loopw.com wrote:
1) “egress” can be used to reference the external nic in a rule,
instead of having a specific IP. Egress is defined as the nic with
the default route. pass in quick log on egress inet proto tcp to
(egress) port 22
Ah, I think I seen that in the
I've had a pair of redundant firewalls using pfsync for years. I've
noticed in the past that whenever I rebooted the secondary firewall, the
carp interfaces on the primary would flip to backup and then back to
master as the secondary one rebooted. I never really noticed any issues
with it, so
On 6/9/2020 1:42 PM, Markus Wernig wrote:
Neither jumbo frames nor multicast will prevent group demotion when the
other side of a crosslink cable goes physically down. Only not having
the sync interface in the carp group will.
True. But I think he was just discussing general best practices,
Where is it documented that in order for pfsync to properly synchronize
rule specific state timeouts that the rule sets on the systems being
synchronized must be *exactly* the same?
I have a pair of redundant firewalls synchronizing state, and recently
added a couple rules that increase the
On 6/7/2020 5:21 PM, Markus Wernig wrote:
I don't see that behaviour on my carp pair. Are you using a cross-link
cable between the two firewalls? (You shouldn't, in my experience.)
Yes, I am using a direct link between the two physical firewalls. It
seems to be the configuration recommended
On 6/8/2020 6:29 AM, Philipp Buehler wrote:
did you follow some "howto" and set net.inet.carp.preempt=1?
Well, if you consider the official openBSD documentation a "how-to",
then yes :).
In the example in https://www.openbsd.org/faq/pf/carp.html under the
section "Combining CARP and
On 6/9/2020 7:36 AM, Stuart Henderson wrote:
IME the best setup for pfsync between 2 machines is to use a dedicated
cross-connect (preferably configured for jumbo frames). Obviously that's
not possible with >2 machines though.
Hmm, I had never considered using jumbo frames. It looks like
I've been trying to diagnose a mysterious issue where a UDP state
disappears before it's supposed to expire. I finally tracked it down to
pfsync. On the primary server, the state entries look like:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:02:21, expires
I just updated one of my servers running 6.7 to 6.8, and am having a
problem with openldap. I have the intermediate cert and root CA in a
file referenced by the openldap config:
TLSCACertificateFile/etc/openldap/cabundle.crt
Under 6.7 with the openldap port from that version, this results in
On 11/16/2020 6:52 AM, Stuart Henderson wrote:
...actually I have now added a workaround to the databases/openldap port
in 6.8-stable to disable TLS 1.3, so either rebuild or wait for -stable
packages and it should fix things.
Cool, I was actually already building from source in order to
On 11/16/2020 2:30 AM, Stuart Henderson wrote:
Yes OpenLDAP is broken with TLS 1.3 server-side unless you have that
commit (or build LibreSSL with TLS 1.3 server support disabled). As far
as I can tell there's no method to disable TLS 1.3 via config.
Hmm, yah, you can disable old versions,
On 11/15/2020 10:18 PM, Brad Smith wrote:
I remember seeing this commit recently. Not sure if this is your problem
or not.
https://marc.info/?l=openbsd-cvs=160511882917510=2
That definitely looks like it, thanks for the pointer.
I'm trying to compile a kernel with some debugging enabled for an problem
I've having with umb, and now my problem has turning into an error
compiling the kernel :). After getting the error on my updated from 6.8 code
base, I whacked it and did a fresh checkout, but it still shows up:
-bash-5.1$
On Mon, Jun 14, 2021 at 08:07:15AM -, Stuart Henderson wrote:
> just add "#define UMB_DEBUG" to if_umb.c and send the full dmesg output.
Hmm, that's didn't work, I also needed to update umb_debug = 1 in the
code? After that, I got a little output, full dmesg included below but
the umb part
I just upgraded a box that has a cell data card in it and it no longer
seems to work :(. The card is:
umb0 at uhub0 port 3 configuration 1 interface 12 "Sierra Wireless,
Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A"
rev 2.10/0.06 addr 2
The contents of /etc/hostname.umb0
On 6/14/2021 4:54 PM, Stuart Henderson wrote:
find when the problem started .. with 6.9 userland you can probably get
away with just booting the relevant older kernel for a test for probably
most/maybe all of the way back to 6.8.
So I booted the 6.8 kernel, and everything seemed to be mostly
I'm upgrading to OpenBSD 7 and I was happy to see the new support for
/etc/bsd.re-config to allow modified kernels to be automatically
rebuilt. However, one of the changes I need to make is updating the IRQ
on com2, as my bios assigns it a non-standard value 8-/.
I can't figure out how to do
On Tue, Nov 30, 2021 at 11:13:26PM -0500, Nick Holland wrote:
> hint: snapshots that do what you need beat releases that don't.
Granted; or I could just apply that patch to the 7.0 stable source and
copy in the new config binary :). I doubt if there will be any binary patches
that would
Thanks much for the info guys; something to look forward to in 7.1 :).
On 11/30/2021 4:17 AM, Stuart Henderson wrote:
On 2021-11-30, Paul de Weerd wrote:
On Tue, Nov 30, 2021 at 08:46:34AM -, Stuart Henderson wrote:
| On 2021-11-29, Paul B. Henson wrote:
| > I'm upgrading to OpenBS
I recently migrated an OpenBSD vm running under qemu/kvm to a new server
which has an Intel 10G X550T NIC (Intel Corporation Ethernet Converged
Network Adapter X550-T2) and am passing a vf though to the vm.
Unfortunately, it appears openbsd doesn't have a driver for this
virtualized device?
The
On Wed, Mar 20, 2024 at 09:56:06PM +0100, Kirill Miazine wrote:
> Like in this thread, I guess:
>
> https://marc.info/?t=16964239631=1=2
Yes, that is likely the issue we're hitting. Seems last message is from
10/2023 and the issue wasn't resolved :(, so I guess it's a known
problem with no
On Thu, Mar 21, 2024 at 12:23:06PM +0300, Vitaliy Makkoveev wrote:
> wg(4) diff was committed to -current. Does the problem exist in upcoming
> 7.5?
Oh, I didn't know a fix had been committed, the referenced thread didn't
mention a final one. Thanks, I'll take a look.
We're using wireguard to set up VPN connections from various systems
deployed on-prem at customer sites to central openbsd boxes to route
internal traffic between the remote boxes and the internal network.
After a fresh reboot with a given configuration, everything works great.
The problem we
Is it very common for people to be running openbsd boxes under
virtualization and using an SR-IOV vf nic? I'm curious what cards people
are using.
It looks like the only available driver is iavf, for the Intel 700
cards? Are there any other drivers I missed?
We have some systems with Intel X550
On 3/20/2024 2:46 AM, Jonathan Matthew wrote:
mcx(4) supports virtual functions, mostly because they're identical to
physical functions from the driver's perspective, so all we had to do
was add the device IDs.
Ah, that wasn't readily apparent; I didn't see anything in the man page
On 3/20/2024 9:21 AM, Zack Newman wrote:
clients in rdomain(4) 0. Last week I ran ifconfig wg1 destroy, replaced
the wgkey and wgpsk for one of the three wgpeers in the second interface,
and ran sh /etc/netstart wg1. Once I did this, the server seemingly froze:
That's similar to what we see,
On 3/20/2024 1:44 AM, Kirill Miazine wrote:
actually I checked, and I do use wgpka on clients, but not on the
server -- I don't remember why I didn't...
In our case the server is on an Internet accessible address, whereas the
clients are behind a NAT firewall. We also have keepalives enabled
101 - 142 of 142 matches
Mail list logo