Good news! You can have this already. Go run Linux. On June 1, 2017 8:42:45 PM EDT, Tinker <ti...@openmailbox.org> 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 root-hub: 0 + slot: > >17 + address: 4 = "cdceur0s17a4", would do the job too. > >On 2017-06-02 00:24, Tinker wrote: >> 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. >> >> Or more probable, an ignorant user would intentionally replug his >> devices but the change of order of interfaces would be unintentional >> to him, and then when he ifconfig/dhclient:s his interfaces, very bad >> things could happen. >> >> This is not a big deal, but it does add one more thing to think >about, >> and in extreme corner cases it could be a security problem - God >> forbid you'd have a public network on CDCE0 and a private network on >> CDCE1 and then a little mistake causes everyone's medical records >etc. >> to be leaked on the Internet. >> >> >> The same would apply to USB serial ports (UART:s) and probably some >> other hardware - >> >> I was talking to someone who was worried that it (unintended device >> ordering) could happen even to PCI devices though I guess that's >> overkill. >> >> His solution is to enforce device names by using different hardware, >> though that kind of illustrates the problem rather than resolve it, >> doesn't it. >> >> >> OpenBSD leaves IP configuration as manual work to the user so OpenBSD >> itself won't mess it up for you, so this is not a per-se OpenBSD >> problem. >> >> But maybe OpenBSD could help people do it right. Interface number >> hard-binding to a particular device descriptor (MAC/USB serial etc.) >> would solve it. >> >> Interface name aliasing would work too (hardbound to descriptor). >> >> >> Anyhow I just wanted to bring up the potential problem. >> >> (Also Peter - this is not specifically a PF problem, however, how >> would you use egress as part of the solution?) >> >> Thanks, >> Tinker >> >> On 2017-05-30 07:04, Peter Hessler wrote: >>> On 2017 May 29 (Mon) at 02:13:57 +0000 (+0000), 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 prebooked as cdce0, and MAC Y as cdce1 , and external > >>> USB >>> :harddrive with serial number Z as /dev/sd0 and the one with serial >>> number A >>> :as /dev/sd1 (and plugging in other devices would automatically). >>> : >>> :(For storage devices there's the DUID-based mounting already >though, >>> so I >>> :guess those are a non-issue.) >>> : >>> :Some things in the OS are specified per interface/device name, e.g. > >>> PF rules >>> :(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 >..", >>> "match >>> :out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having >the >>> :interface numbers garbled on replug may be an unnecessary reason to > >>> reboot? >>> : >>> :Would be happy to learn any best practice here, thanks, >>> :Tinker >>> : >>> >>> match out on egress from 192.168.0.0/16 to any nat-to (egress) >>> ^^^^^^ ^^^^^^^^ >>> >>> the interface group "egress" is added to the interface a default >route >>> uses. Wrapping that with (), will ensure that interface is updated >>> when >>> the default routes uses a different interface.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
