Diagnostics > factory defaults does not work as expected



  • The factory defaults menu item says the following:

    _  Reset to factory defaults
        LAN IP address will be reset to 192.168.1.1
        System will be configured as a DHCP server on the default LAN interface
        Reboot after changes are installed
        WAN interface will be set to obtain an address automatically from a DHCP server
        webConfigurator admin username will be reset to 'admin'
        webConfigurator admin password will be reset to 'pfsense'_

    This is not what happens when performing a factory default on my APU box. I had to break out the serial cable and connect it in order to communicate with the box. It was sitting at the initial install screen for configuration of the interfaces.

    Why doesn't it reset to defaults like it says in the menu?



  • Well, it did what it said, but it also 'forgot' about "what NIC is doing what".

    What really happened is : a default  /conf.default.config.xml is put in place.
    This config.xml presumes "em0" and "em1" interfaces. If yours are different, then pfSense stops so you can chose yours.
    So, yes it resets to default but the impact is somewhat bigger as what's being mentioned upfront.



  • It would be nice to handle this automagically for the known common devices - Alix, APU, SG-series…
    e.g. https://github.com/pfsense/pfsense/pull/1602
    I have not seen any progress on this, but it would be very good to have for 2.3



  • How about dropping this stupid BSD-style interface naming and using something more universal, like eth0, eth1, eth2 and so on.
    Just take the interfaces and enumerate them by the MAC address number increasing. So the lowest MAC address would always be eth0, and up.
    Installing a new interface may cause of course the need to re-assign, as it is now. But it would save a lot of headaches in other aspects.

    Various Linux flavorus have implemented UDEV, which is a bit more complex, it assigns the names by MAC address at system installation, but when adding a new interface it doesn't mess up, it follows enumeration upwards.


  • Banned

    @robi:

    Various Linux flavorus have implemented UDEV, which is a bit more complex, it assigns the names by MAC address at system installation, but when adding a new interface it doesn't mess up, it follows enumeration upwards.

    Actually, that's no longer valid with systemd.  ::) >:(



  • Yes I had to survive that too, I know what you're talking about. Have no clue why they had to change something which was fundamentally working flawlessly for 2 decades.
    I'm not asking to implement UDEV or systemd here, this was just a side note.

    Simply enumerate interfaces by the MAC address, name them ethX regardless of the brand/driver.



  • According to https://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5 renaming an interface is easy:

    It is also possible to rename an interface by doing:
    ifconfig_ed0_name="net0"

    So we need a small script which would check for existence of rc.conf.local at boot, if it's not there, enumerate all the existing interfaces by MAC address, generate a rc.conf.local with the renames as above and reboot to apply changes.



  • @robi:

    According to https://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5 renaming an interface is easy:

    It is also possible to rename an interface by doing:
    ifconfig_ed0_name="net0"

    So we need a small script which would check for existence of rc.conf.local at boot, if it's not there, enumerate all the existing interfaces by MAC address, generate a rc.conf.local with the renames as above and reboot to apply changes.

    Kind of defeats the purpose of a factory reset if you're loading a custom config file.



  • @phil.davis:

    It would be nice to handle this automagically for the known common devices - Alix, APU, SG-series…
    e.g. https://github.com/pfsense/pfsense/pull/1602
    I have not seen any progress on this, but it would be very good to have for 2.3

    Yes that's definitely something I want to get merged for 2.3.

    @robi:

    According to https://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5 renaming an interface is easy:

    It is also possible to rename an interface by doing:
    ifconfig_ed0_name="net0"

    So we need a small script which would check for existence of rc.conf.local at boot, if it's not there, enumerate all the existing interfaces by MAC address, generate a rc.conf.local with the renames as above and reboot to apply changes.

    No, that wouldn't work at all (no FreeBSD init scripts). There are a million possible edge case bugs in doing something like that. Similar attempts have been made in the past that never got to an acceptable state because there were too many possible failure modes. It is something worth reconsidering in v3.0 though.



  • Well, it could be then some pfSense-specific layer between the OS and pfSense, which could always translate interface names to ethX. I would imagine something like a function enumerating the interfaces by name and assigning some pfSense-internal name to them, and another function resolving that name from the MAC address back to the OS-level naming each time the config is generated.
    Shouldn't be too difficult.



  • Actually, the fact that the interfaces have to be re-assigned at the console whenever the hardware changes is quite annoying, specially when vlans are involved.
    This is because the same config is being copied over to different sets of hardware (with the same number of NICs, but different drivers are being used, such as igb and em) and re-assignment is needed to be done each time.

    Following the ideas in this topic, I decided to create my own rc.local.conf file containing this:

    ifconfig em0 name eth0
    ifconfig em1 name eth1
    ifconfig em2 name eth2
    ifconfig em3 name eth3
    ifconfig igb0 name eth0
    ifconfig igb1 name eth1
    ifconfig igb2 name eth2
    ifconfig igb3 name eth3
    

    And from now on use only ethX in pfSense config file.
    The code above looks stupid because half of the commands will fail on one hardware, and the other half on the other. But, at least, in the end, I will have consistent ethX interface names on both, and I don't have to keep re-assigning all the interfaces and VLANs each time I change hardware. It also saves me from fiddling around by editing the config xml by hand.

    I tried the above with the shellcmd package, unfortunately the "earlyshellcmd" option doesn't happen early enough. At boot, interface mismatch test is ran before the  earlyshellcmds, so this would result in the need to re-assign with the old names at boot etc…
    A quick fix would be to run earlyshellcmds before interface assignment test happens at startup.



  • @robi:

    A quick fix would be to run earlyshellcmds before interface assignment test happens at startup.

    Pull request submitted.



  • I just print a screen shot of the interfaces with their MAC addresses and tape it to the router. And improvement opportunity would be to print it out with a P-Touch and tape it to the box.


  • Rebel Alliance Developer Netgate

    Renaming the interfaces like that doesn't actually solve any problems, as you still have to map them from the current names to a new name. If adding or removing an interface changes the mappings, then you have just made it much harder to figure out what goes where and it still didn't solve your actual problem.

    Any scheme you come up with to map the names would be more complicated than simply making WAN/LAN assumptions based on the actual interfaces. Which still can have issues.

    I like the BSD style, myself.



  • OK. I really don't see your point when a device has all the nics from the same manufacturers, using the same driver. You'd get names from em0 to em4 for example for onboard nics. Adding a new Intel nic can be very well also an em, you can't really tell in advance what to expect, because I've had interesting experiences seeing original em3 and em4 being shifted to em4 and em5, and the new card became em3. That's something one can't really prepare for in advance, it's pretty much like a gamble.

    My environment became quite advanced now, I admit that. But here's the scenario:

    • several hardware configurations, with the same number of nics, but different types
    • all run Nano from CF cards
    • the NanoBSD image is the same on all of them, but highly customized with varoius BSD packages
    • the upgrade deployment process acts like this:
        - convert the vanilla pfSense fresh NanoBSD image to a virtual disk
        - apply all the OS-level customizations needed in a virtual machine running the NanoBSD image, having the same number of virtual nics, simulating part of the real network in the virtual environment
        - restore the config, let the pfSense official upgrade/package reinstall run as it should
        - test thoroughly the resulted appliance
        - duplicate slice
        - export the virtual disk back to raw image
        - copy with dd the new image to spare CF cards
        - halt each physical device, just replace the CF card and boot it

    The method above has several advantages:

    • the most secure upgrade scenario, assuring that in case of failure on specific hardware, restoring previous state requires nothing more than a halt, CF card exchange and boot (this excluding slice swapping problems, config.xml modifications, etc.)
    • a whole lot faster since you don't have to do all the package re-installatios and customizations several times, just once, properly tested
    • absolutely minimum service downtime, since it only takes a few seconds more than a reboot, and chances to fail are minimized because we are past the upgrade procedure

    Now the only real issue is that on virtual hardware the nics are seen as "em", on some hardware they appear as "em" and "igb", and on some others they appear as "re" and "rl".
    Renaming universally all the interfaces to ethX at boot saves me from dragging a console at each rack and do manual re-assigning. Plus reassignment is a real pain when you have lots of vlans.

    Having a unique consistent naming, calculated from MAC addresses ascending numbering would be the best imho. MAC addresses don't change, usually they are printed by the manufacturer at least on a paper given with the motherboard if not already sticked on the box. Users could simply look at the addresses and knew in advance which will become what in pfSense. Addition of an interface with a MAC address known in advance would help preparing the engineer in what changes are expected at boot. There would be no need to figure out anything.

    Putting a sticker with the MAC in a visible place is also a best practice. When installing a new hardware, look a MAC addresses first and assign the interfaces in the MAC address order. That's a perfect way to keep things clean.


  • Rebel Alliance Developer Netgate

    That doesn't solve the insert/delete shifting, though, and it's still a made-up mapping that can have the same problems as using driver-specific names. The only problem it solves for others (e.g. not you) is that it makes a boot with mismatched interfaces work better in that specific scenario, but there are other better ways around that.

    If it made assumptions using the current drivers based on MAC addresses it would accomplish the same "goal" but without the remapping of names to some other arbitrary meaningless string. Plus remapping names would add support headaches (for us) since we'd have to track down the actual drivers used in each NIC rather than spotting them easily.

    Hardware isn't always arranged how you want with MACs (See the 4860 and 8860 NIC layout for an example, far left port is igb1, not igb0). Picking any automated scheme will help some and break others, but at least keeping the default driver names keeps us close to FreeBSD and allows us to set things up like we want.

    Automated assignment from a completely default config I could get behind. If a NIC disappears it should (ideally) not start from scratch and auto-assign things as it could cause severe breakage on a network.



  • OK, I understand your views now.

    I'll still keep the renaming in my specific environment for now, as it makes my life a whole lot easier.