You are making a very poor assumption about which parts of the "Ethernet" interface are missing after a high voltage event.
You may still have (enough of) the MAC to be enumerated on the (PCI/PCIe/...) bus. If this occurs, then no renumbering will take place, since, as far as BIOS/boot firmware/OS can 'tell', the device still exists (can be enumerated), even if the PHY(s) are non-responsive. This is different than removing a PCI/PCIe card from a system. In this case, the device is no longer on the bus, and will not be enumerated for the OS to probe/attach/open/... > Does a disappearing reX driver interface renumber the ueX interfaces? On FreeBSD? no. On a linux system? LIkely. Let's say you had one re(4) and two em(4) devices. Let's assume for now you have: em0: WAN em1: LAN re0: OPT1 Case 0: em0 gets fried in such a way that it doesn't enumerate on the bus. We are left with: em1: LAN re0: OPT1 What should pfSense do in this instance? Case 1: em1 gets fried in such a way that it doesn't enumerate on the bus. We are left with: em0: WAN re0: OPT1 What should pfSense do in this instance? Case 2: re0 gets fried in such a way that it doesn't enumerate on the bus. We are left with: em0: WAN em1: LAN What should pfSense do in this instance? Case 3: pfSense is operating in a dual-WAN mode em0: WAN0 em1: WAN1 re0: LAN em0 gets fried in such a way that it doesn't enumerate on the bus. We are left with: em1: WAN1 re0: LAN What should pfSense do in this instance? Case 4: pfSense is operating in a dual-WAN mode em0: WAN0 em1: WAN1 re0: LAN em1 gets fried in such a way that it doesn't enumerate on the bus. We are left with: em0: WAN0 re0: LAN What should pfSense do in this instance? Case 5: pfSense is operating in a dual-WAN mode em0: WAN0 em1: WAN1 re0: LAN re0 gets fried in such a way that it doesn't enumerate on the bus. We are left with: em0: WAN0 em1: WAN1 Now let's say you have a 2440, with 4 igb(4) interfaces igb0: WAN0 igb1: WAN1 igb2: LAN igb3: OPT1 Case 6: igb0 gets fried in such a way that it doesn't enumerate on the bus. We are left with: igb1: WAN1 igb2: LAN igb3: OPT1 What should pfSense do in this instance? Case 7: igb1 gets fried in such a way that it doesn't enumerate on the bus. We are left with: igb0: WAN0 igb2: LAN igb3: OPT1 What should pfSense do in this instance? Case 8: igb2 gets fried in such a way that it doesn't enumerate on the bus. We are left with: igb0: WAN0 igb1: WAN1 igb3: OPT1 Case 9: igb3 gets fried in such a way that it doesn't enumerate on the bus. We are left with: igb0: WAN0 igb1: WAN1 igb2: LAN What should pfSense do in this instance? Case 10: igb0 and igb1 get knocked off the bus What should pfSense do in this instance? Case 11: igb1 and igb2 get knocked off the bus What should pfSense do in this instance? Case 12: igb2 and igb3 get knocked off the bus What should pfSense do in this instance? Case 13: igb3 and igb0 get knocked off the bus What should pfSense do in this instance? Case 14: igb0 and igb2 get knocked off the bus What should pfSense do in this instance? Case 15: igb1 and igb3 get knocked off the bus What should pfSense do in this instance? Case 16: igb0, igb1 and igb2 get knocked off the bus What should pfSense do in this instance? Case 17: igb0, igb1 and igb3 get knocked off the bus What should pfSense do in this instance? Case 18: igb1, igb2 and igb3 get knocked off the bus What should pfSense do in this instance? Now, having described the desired behavior for pfSense in each case, generalize an algorithm for up to 8 interfaces of the same device type, 8 different device types, or a mix of device types, that behaves correctly in each case. Pseudo-code will do for now. I look forward to your response. JIm On Thu, Oct 13, 2016 at 8:41 PM, Volker Kuhlmann <hid...@paradise.net.nz> wrote: > On Fri 14 Oct 2016 11:25:12 NZDT +1300, Walter Parker wrote: > > > Problem is that all of the current OS do this sort of renumbering (I'd > have > > to check, but I think it could be a hardware/driver issue). IIRC Linux > > systems have had this sort of problem in even greater measure than the > > BSDs. The plug and play nature of USB has caused issues for most systems > > (drive letter changes on Windows, device name changes on Linux, even BSD > > has started doing this). The brain dead here is problem that extends to > the > > PC industry as a whole. > > Totally with you there on PC industry intelligence! > > > PFSense is subject bad decisions that were made > > decades ago by other companies without enough vision. The automapping > ideas > > in hardware were not properly thought out and software didn't think it > > though either. > > Sure, pfsense can do little about dumb OS things, and swapping > interfaces randomly is a major security problem. But pfsense could still > do much better. Does a disappearing USB interface renumber Ethernet > interfaces? Does a disappearing reX driver interface renumber the ueX > interfaces? I didn't think so, so it should be possible to remove those > that will/could be renumbered and run with the rest, without getting > surprises other than missing interfaces or failing to boot. > > Volker > > -- > Volker Kuhlmann is list0570 with the domain in header. > http://volker.top.geek.nz/ Please do not CC list postings to me. > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold > _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
