be a learning experience.
On Tue, 20 Oct 2020, Theo de Raadt wrote:
Stuart Longland wrote:
On 21/10/20 9:55 am, Lee Nelson wrote:
Alternatively use a single nic with vlans, and break out to separate
ports on a managed switch.
Yes, that could work too, but this is one side of a pfsync/carp
redundant
On Tue, 20 Oct 2020, Stuart Henderson wrote:
On 2020-10-20, Lee Nelson wrote:
The only real solution here, aside from using better hardware, seems to be
to use adapters with different drivers. That is the approach I'm trying
next.
Alternatively use a single nic with vlans, and break out
On Tue, 20 Oct 2020, Aaron Mason wrote:
On Tue, Oct 20, 2020 at 12:29 PM Lee Nelson wrote:
On Mon, 19 Oct 2020, Allan Streib wrote:
Lee Nelson writes:
I had considered some late-running script that would query the MAC's of
each NIC and then configure them accordingly or rewrite
On Mon, 19 Oct 2020, Allan Streib wrote:
Lee Nelson writes:
I had considered some late-running script that would query the MAC's of
each NIC and then configure them accordingly or rewrite the hostname.*
files and call netstart on them, but that just seems sloppy and
unreliable.
What
On Mon, 19 Oct 2020, Theo de Raadt wrote:
Lee Nelson wrote:
If I have multiple USB Ethernet adapters of identical make and model,
how does OpenBSD distinguish them over time.
In the order their drivers reach "interface attach" code. There are
multiple reasons the drivers c
If I have multiple USB Ethernet adapters of identical make and model, how
does OpenBSD distinguish them over time. In other words if there's a
reboot or the adapters get unplugged and moved around and plugged back in,
is there a way to make sure that the adapters associated with axen0 and
I have twice seen kernel panics in the same situation. It drops to "ddb>"
but the system is unresponsive. Unfortunately, other than taking a picture
of the screen with my cellphone, I do not have any further information from
the system. On both occasions, I was issuing "ifconfig bridge42" without
This has surely been asked before, but searching turned up nothing.
Is there a recommended way to resume an interrupted system build? I run on
very old and slow machines. I haven't completed a full system build yet,
but on my main system (Intel Celeron single core 2GB RAM from 2003) 8 hours
Since Mitchell's last email, this appeared from CVS in the place where
the patch was supposed to be applied:
CLR(m0->m_flags, M_BCAST|M_MCAST);
I skipped the patch and compiled the kernel with the source as I found
it from CVS. With this new kernel everything works as I expected. arp
broadcast
I'm running a snapshot from March 31. It did fix a problem with
split-horizon, but the arp/broadcast problem still exists.
On Mon, Apr 1, 2019, 19:42 Adrian Close wrote:
> Hi guys,
>
> Le 02/04/2019 13:18, Lee Nelson a écrit :
> > This sounds very similar to the problem I
This sounds very similar to the problem I mentioned over the last couple of
days in an email with the subject "Trouble forwarding between mpw's in
bridge (6.4)".
Our environments are very different, but I think the underlying problem may
be the same. In short, arp inside of a bridge works as it
11 matches
Mail list logo
