On 06/04/17 19:09, Kevin Chadwick wrote:
fxp0,1,2 are in order of pci slot. I assume usbs are the same after
boot so anyone who unplugs and plugs devices and doesn't check the
outcome on critical hardware deserves what they get. Also having
critical hardware that can be physically damaged is als
On Fri, 2 Jun 2017 08:25:57 -0400
> Linux's (and Windows and Solaris and ...) attempts to "fix" this
> problem is one of the reasons I'd consider Linux (and Windows
> and ...) crappy. A complicated solution that creates far more
> problems than it ever solves, and usually at the worst times possi
On 06/01/17 20:50, Tinker wrote:
> On 2017-06-02 00:45, Joe Gidi wrote:
>> Good news! You can have this already.
>
> Yay!
>
>> Go run Linux.
>
> Em -
>
> Nay!
>
> No yay. Hope to see a solid solution to this problem on a non-crappy OS
> soon.
>
Linux's (and Windows and Solaris and ...) atte
Oh. Yeah if there's no performance penalty on such a solution then
great. Could someone confirm that?
So this works for cabled ethernet, where NIC promiscuous mode due to the
bridge won't hurt.
Also it wouldn't work for wireless interfaces. Also to be robust it
presumes that NIC unplug impl
I don't know the bridge code in OpenBSD as well as I know it in Linux -
basic bridges don't add any appreciable overhead on that platform until you
start mucking around with bridge specific things.
It just means you maintain an arp table distinct from each sub-interface.
tl;dr - it's not going to
In the kernel however that implies an internal indirection/one or more
additional rounds copying of all traffic and passing around, right, so
even it works quite well, it's not optimal right?
Anyhow sure that is an effective workaround if needed.
On 2017-06-02 02:20, Joel Wirāmu Pauling wrote:
On 2017-06-02 00:45, Joe Gidi wrote:
Good news! You can have this already.
Yay!
Go run Linux.
Em -
Nay!
No yay. Hope to see a solid solution to this problem on a non-crappy OS
soon.
Good news! You can have this already. Go run Linux.
On June 1, 2017 8:42:45 PM EDT, Tinker wrote:
>Ah - having an interface name naming scheme that, instead of just being
>
>a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical
>slot where the device is connected, e.g. CDCE + USB
Ah - having an interface name naming scheme that, instead of just being
a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical
slot where the device is connected, e.g. CDCE + USB root-hub: 0 + slot:
17 + address: 4 = "cdceur0s17a4", would do the job too.
On 2017-06-02 00:24, Tin
Hi,
What I meant was, it's fairly easy for interface numbers (e.g. NIC A as
CDCE0 and NIC B as CDCE1) to become exchanged.
With lots of unluck, there could be mechanical stress on USB ports so
that they would rearrange spontaneously so NIC B would become CDCE0 and
NIC A would become CDCE1.
On 2017 May 29 (Mon) at 02:13:57 + (+), Tinker wrote:
:Hi misc@,
:
:For pluggable devices such as USB NIC:s, is there any way to make OpenBSD
:bind a particular device based on its MAC or USB serial number or the like
:variable, to a particular interface or device filename?
:
:E.g. MAC X is
On 05/28/17 22:13, Tinker wrote:
> Hi misc@,
>
> For pluggable devices such as USB NIC:s, is there any way to make
> OpenBSD bind a particular device based on its MAC or USB serial number
> or the like variable, to a particular interface or device filename?
no but ...
...
> (For storage devices
Hi misc@,
For pluggable devices such as USB NIC:s, is there any way to make
OpenBSD bind a particular device based on its MAC or USB serial number
or the like variable, to a particular interface or device filename?
E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external USB
hardd
13 matches
Mail list logo