On Fri 14 Oct 2016 16:41:22 NZDT +1300, Jim Thompson wrote: > > Does a disappearing reX driver interface renumber the ueX interfaces? > > On FreeBSD? no. On a linux system? LIkely.
I am unsure whether that is still so for Linux, there seem to have been changes there but I haven't looked at it as it's been inconsequential to me. But pfsense runs on freebsd so linux behaviour has no relevance here. > 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? Run! No change of interface assignments to ports. Ignore missing interfaces. The way you are presenting this anyway. > 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? Run with re0:OPT1 only. Ignore missing interfaces. > 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? Run. No change of interface assignments to ports. Ignore missing interfaces. > 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? Run with re0:LAN only. Ignore missing interfaces. > 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? Run with re0:LAN only. Ignore missing interfaces. > 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 Run with em0: WAN0, em1: WAN1 only. Ignore missing interfaces. > Now let's say you have a 2440, with 4 igb(4) interfaces > > igb0: WAN0 > igb1: WAN1 > igb2: LAN > igb3: OPT1 All interfaces are igbX. No interfaces left that don't get shuffled around. Stop. All your remaining cases are the same. > 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 had already given it in my previous email. It doesn't give improvement in all cases, but in those which are safe. You'll need to store user-chosen mappings of interfaces to ports. That's already done. The current situation sucks. A user of a router appliance is not primarily interested in as to why it sucks. But Espen Johansen gave the solution: Don't touch primary OS-port names or their braindead implementation. Create aliases based on MAC address. Access port exclusively through alias name. Fix pfsense(!!) to keep rules assigned to no interface accessible from the BUI, so the user can manually re-assign them in bulk, instead of enforcing a click-me-stupid orgy or XML file hacking. Aliases to emX, reX, igbX etc names are a matter of today's intelligence in OS implementation. No more excuses for decades old decisions. :-) 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
