Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Various minor buglets noted

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    8 Posts 5 Posters 3.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jgreco
      last edited by

      I'm in the midst of trying to update a 1.2.* box to 2.0-BETA (snap as of today).

      The config upgrade was a complete trainwreck, but that may be due to complexity and use of nonstandard options.  Had to wipe it and start fresh.

      Noted during wizard setup, at the end, where it reloads the firewall and advises it'll reload in 120 seconds "or click above", if you click above, it tries to go to "https://[ip-addr]/[ip-addr]".  Ooops.  :-)

      I'm also having some problems with the certificate manager, though I am still looking at this.  It's refusing to import a cert, saying

      "The following input errors were detected:

      * The certificate subject 'emailAddress=service@ns.sol.net, CN=[redacted], O=sol.net Network Services, ST=Wisconsin, C=US' does not match the signing request subject."

      I did note that the signing request looked a bit odd, it was reported by our root CA system as

      "Subject: C=US, ST=Wisconsin, L=Milwaukee, O=sol.net Network Services/Email=service@ns.sol.net, CN=[redacted]"

      where I would normally expect to see the "/Email" appear after the CN=, not the O=, but I've not investigated further.

      I'll continue to play with this.  Looks great overall.

      Oh, also…

      "Copy the certificate signing data from here and forward it to your certificate authority for singing."

      Our cert authority refuses to sing.  ;-)

      More...

      Under System: Gateways: Edit gateway, the Monitor IP is a great addition, but when setting a value in the field, after saving, it appears to revert to the normal gateway address...

      1 Reply Last reply Reply Quote 0
      • J
        jgreco
        last edited by

        Sadly, got to a point where I had to scrap it.  Sometime after adding an openvpn client in tap mode, I had to reboot due to hitting kern.maxfiles, and then it apparently had a severely broken config that it couldn't even fix:

        Loading configuration…...done.

        Network interface mismatch -- Running interface assignment option.

        Valid interfaces are:

        fxp0  00:02:b3:19:dd:1a  (down)        Intel 82559 Pro/100 Ethernet
        fxp1  00:02:b3:19:dd:1b  (down)        Intel 82559 Pro/100 Ethernet
        dc0  00:80:c8💿43:2d  (down)        Intel 21143 10/100BaseTX
        dc1  00:80:c8💿43:2e  (down)        Intel 21143 10/100BaseTX
        dc2  00:80:c8💿43:2f  (down)        Intel 21143 10/100BaseTX
        dc3  00:80:c8💿43:30  (down)        Intel 21143 10/100BaseTX

        Do you want to set up VLANs first?

        If you are not going to use VLANs, or only for optional interfaces, you should
        say no here and use the webConfigurator to configure VLANs later, if required.

        Do you want to set up VLANs now [y|n]? n

        NOTE  pfSense requires AT LEAST 1 assigned interfaces to function.
                If you do not have AT LEAST 1 interfaces you CANNOT continue.

        If you do not have at least 1 REAL network interface cards
                or one interface with multiple VLANs then pfSense
                WILL NOT function correctly.

        If you do not know the names of your interfaces, you may choose to use
        auto-detection. In that case, disconnect all interfaces now before
        hitting 'a' to initiate auto detection.

        Enter the WAN interface name or 'a' for auto-detection: dc0

        Enter the LAN interface name or 'a' for auto-detection
        NOTE: this enables full Firewalling/NAT mode.
        (or nothing if finished): fxp0

        Enter the Optional 1 interface name or 'a' for auto-detection
        (or nothing if finished):

        The interfaces will be assigned as follows:

        LAN  -> fxp0
        WAN  -> dc0

        Do you want to proceed [y|n]?y

        Writing configuration….............................. 1267158068ddone.
        done.

        Network interface mismatch -- Running interface assignment option.

        Valid interfaces are:

        fxp0  00:02:b3:19:dd:1a  (down)        Intel 82559 Pro/100 Ethernet
        fxp1  00:02:b3:19:dd:1b  (down)        Intel 82559 Pro/100 Ethernet
        dc0  00:80:c8💿43:2d  (down)        Intel 21143 10/100BaseTX
        dc1  00:80:c8💿43:2e  (down)        Intel 21143 10/100BaseTX
        dc2  00:80:c8💿43:2f  (down)        Intel 21143 10/100BaseTX
        dc3  00:80:c8💿43:30  (down)        Intel 21143 10/100BaseTX

        Do you want to set up VLANs first?

        So that's bad.  :-/

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          There are lots of config upgrade issues to be worked out, the bulk of the major problems are with that. With that said, I would like to get a copy of your config as it's usually not quite "a complete trainwreck". Though I haven't really tested many configs, upgrade is not our focus at the moment. But if you can send me a backup of your config I would like to test it when we get to that point. Email to cmb at pfsense dot org.

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            That interface mismatch thing is because all your interfaces are down.
            It does not allow that, though i will give it a look.

            1 Reply Last reply Reply Quote 0
            • J
              jgreco
              last edited by

              @ermal:

              That interface mismatch thing is because all your interfaces are down.
              It does not allow that, though i will give it a look.

              Oh, interesting, I hadn't noticed that.  The interfaces in question were definitely operable at the time:  this was a completely software adventure, and at no time was anything done physically to the box, other than power cycling.

              I come from "old school" and only recently has our site policy changed to permit autonegotiation on non-gigE ethernet interfaces; we'd historically found that a lot of older 10/100 gear suffered interop issues, and so we used to lock things at 100/full everywhere.  Now, one of the odd things I noticed about FreeBSD is that interfaces seem to stick in "DOWN" state until configured or at least probed with ifconfig; I don't know exactly what the underlying reasoning for that is.  The 1.2.* pfSense box is new enough not to have locked media settings, which I am guessing is the norm for pfSense deployments.  My guess is that something has to happen in order for FreeBSD to notice the status of these interfaces is actually up; I don't know, offhand, what that is.

              I do have the serial console logs from the upgrade attempt, and so I submit the following additional session transcript for your consideration:

              Welcome to pfSense 2.0-BETA1  …

              Mounting filesystems... done.
              Creating symlinks......done.
              Launching the init system... done.
              Initializing.............................. done.
              Starting device manager (devd)...done.
              Loading configuration......done.

              Network interface mismatch -- Running interface assignment option.

              Valid interfaces are:

              fxp0  00:02:b3:19:dd:1a  (down)        Intel 82559 Pro/100 Ethernet
              fxp1  00:02:b3:19:dd:1b  (down)        Intel 82559 Pro/100 Ethernet
              dc0  00:80:c8💿43:2d  (down)        Intel 21143 10/100BaseTX
              dc1  00:80:c8💿43:2e  (down)        Intel 21143 10/100BaseTX
              dc2  00:80:c8💿43:2f  (down)        Intel 21143 10/100BaseTX
              dc3  00:80:c8💿43:30  (down)        Intel 21143 10/100BaseTX

              Do you want to set up VLANs first?

              If you are not going to use VLANs, or only for optional interfaces, you should
              say no here and use the webConfigurator to configure VLANs later, if required.

              Do you want to set up VLANs now [y|n]? n

              NOTE  pfSense requires AT LEAST 1 assigned interfaces to function.
                      If you do not have AT LEAST 1 interfaces you CANNOT continue.

              If you do not have at least 1 REAL network interface cards
                      or one interface with multiple VLANs then pfSense
                      WILL NOT function correctly.

              If you do not know the names of your interfaces, you may choose to use
              auto-detection. In that case, disconnect all interfaces now before
              hitting 'a' to initiate auto detection.

              Enter the WAN interface name or 'a' for auto-detection: ^CFeb 25 22:19:16 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode^M
              Feb 25 22:19:16 init: NSSWITCH(_nsdispatch): nis, passwd_compat, endpwent, not found, and no fallback provided^M
              Enter full pathname of shell or RETURN for /bin/sh:

              ifconfig -a

              fxp0: flags=8802f <broadcast,simplxex,multicast>meptric 0 mtu 1500^M0
                      options=2009 <r:xcsum,vlan_mtu,w ol_magic="">ethelr 00:02:b3:19:ddi:1a
              nk state changed to UP
                      media: Ethernetf autoselect (100xbaseTX <full-dupplex>)
                      status: 1active
              fxp1: fl:ags=8802 <broadca st,simplex,multilcast="">metric 0 mitu 1500
                      optionns=2009 <rxcsum,vlkan_mtu,wol_magic>ether 00:02:sb3:19:dd:1b
              tate changed to UP
                      media: Ethernetd autoselect (100cbaseTX <full-dup0lex>)
                      status: :active
              dc0: fla gs=8802 <broadcaslt,simplex,multiciast>metric 0 mtnu 1500
                      optionsk=8 <vlan_mtu>e ther 00:80:c8:cds:43:2d
              tate changed to UP
                      media: Ethernetd autoselect (100cbaseTX <half-dup1lex>)
                      status: :active
              dc1: fla gs=8802 <broadcaslt,simplex,multiciast>metric 0 mtnu 1500
                      optionsk=8 <vlan_mtu>e ther 00:80:c8:cds:43:2e
              tate changed to UP
                      media: Ethernetd autoselect (100cbaseTX <full-dup2lex>)
                      status: :active
              dc2: fla gs=8802 <broadcaslt,simplex,multiciast>metric 0 mtnu 1500
                      optionsk=8 <vlan_mtu>e ther 00:80:c8:cds:43:2f
              tate changed to UP
                      media: Ethernetd autoselect (100cbaseTX <half-dup3lex>)
                      status: :active
              dc3: fla gs=8802 <broadcaslt,simplex,multiciast>metric 0 mtnu 1500
                      optionsk=8 <vlan_mtu>e ther 00:80:c8:cds:43:30
              tate changed to DOWN
                      media: Ethernet autoselect (none)
                      status: no carrier
              lo0: flags=8008 <loopback,multicast>metric 0 mtu 16384
                      options=3 <rxcsum,txcsum>pfsync0: flags=0<> metric 0 mtu 1460
                      syncpeer: 224.0.0.240 maxupd: 128
              pflog0: flags=0<> metric 0 mtu 33200
              enc0: flags=0<> metric 0 mtu 1536

              [ Note that some kernel output is mixed in with the userland command's output; this is normal FreeBSD behaviour ]
              [ Note that the polling of the interfaces by ifconfig appears to have them change to "UP" state ]
              [ Then I dinked around for a while trying to get to the pfSense console …  simply exiting from singleuser didn't work ]
              [ This brings us back to a situation where it still sees all interfaces still as down, and I don't know why ]

              exit

              ___
              / f
              / p _
              / Sense
              _
              / 
                  _
              _/

              Welcome to pfSense 2.0-BETA1  …

              Mounting filesystems... done.
              Creating symlinks......done.
              Launching the init system... done.
              Initializing............................ done.
              Starting device manager (devd)...devd: Can't open devctl device /dev/devctl: Device busy
              done.
              Loading configuration......done.

              Network interface mismatch -- Running interface assignment option.

              Valid interfaces are:

              fxp0  00:02:b3:19:dd:1a  (down)        Intel 82559 Pro/100 Ethernet
              fxp1  00:02:b3:19:dd:1b  (down)        Intel 82559 Pro/100 Ethernet
              dc0  00:80:c8💿43:2d  (down)        Intel 21143 10/100BaseTX
              dc1  00:80:c8💿43:2e  (down)        Intel 21143 10/100BaseTX
              dc2  00:80:c8💿43:2f  (down)        Intel 21143 10/100BaseTX
              dc3  00:80:c8💿43:30  (down)        Intel 21143 10/100BaseTX

              Do you want to set up VLANs first?

              If you are not going to use VLANs, or only for optional interfaces, you should
              say no here and use the webConfigurator to configure VLANs later, if required.

              Do you want to set up VLANs now [y|n]? ^CFeb 25 22:20:30 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode^M
              Feb 25 22:20:30 init: NSSWITCH(_nsdispatch): nis, passwd_compat, endpwent, not found, and no fallback provided^M
              Enter full pathname of shell or RETURN for /bin/sh:

              [ At this point I went on search and destroy for the "Network interface mismatch" and banged out a few ]
              [ lines in /etc/rc.bootup, at which point the console was fine and the box was downgraded to 1.2.3 ]

              This is, for us, a backup system, and I have some flexibility in experimenting, or setting up a similar lab box to play with…  What I saw of the 2.0 looked really promising, except where it was broken, and the scope of the changes is certainly large enough that it's easy to understand some brokenness.  I know that we exercise a lot of edge cases in gear and software, so this is actually a very impressive showing for a dot-zero beta...</rxcsum,txcsum></loopback,multicast></vlan_mtu></broadcaslt,simplex,multiciast></half-dup3lex></vlan_mtu></broadcaslt,simplex,multiciast></full-dup2lex></vlan_mtu></broadcaslt,simplex,multiciast></half-dup1lex></vlan_mtu></broadcaslt,simplex,multiciast></full-dup0lex></rxcsum,vlkan_mtu,wol_magic></broadca></full-dupplex></r:xcsum,vlan_mtu,w></broadcast,simplxex,multicast>

              1 Reply Last reply Reply Quote 0
              • R
                rsingh
                last edited by

                i ran into this interface issue as well. a newer snapshot fixed it (this was a week ago).

                the interfaces were in vmware so their only state was up.

                1 Reply Last reply Reply Quote 0
                • J
                  jgreco
                  last edited by

                  @rsingh:

                  i ran into this interface issue as well. a newer snapshot fixed it (this was a week ago).

                  the interfaces were in vmware so their only state was up.

                  I had a snapshot that I believe was tagged as BETA1 and dated 20100225, so this might not be completely "fixed."

                  I'm also pondering the wisdom of forcing interface configuration merely because an interface is down.  Is the "down" status the same as ifconfig's "down" status?

                  I'm thinking, for example, that if you lose power and then are rebooting, what happens if the pfSense box comes up before your managed ethernet switch (I've seen some that can take a minute or two to boot)?  Or you're using staggered start on your RPDU because you're running 15A of gear on a 16A circuit, and the inrush of everything at once would kill a breaker?

                  It may make sense to run interface reconfiguration in the event that a pfSense-configured interface does not appear to be in the system's inventory, but I'm thinking that forbidding interfaces that are merely down is problematic for a robust networking device.

                  … JG

                  1 Reply Last reply Reply Quote 0
                  • W
                    wallabybob
                    last edited by

                    @jgreco:

                    It may make sense to run interface reconfiguration in the event that a pfSense-configured interface does not appear to be in the system's inventory, but I'm thinking that forbidding interfaces that are merely down is problematic for a robust networking device.

                    I second that.

                    An interface being down shouldn't force a reconfiguration. The configuration may well be correct (as in what the user wants) but the interface may be down for another reason (e.g. broken cable) that is easier to fix than performing a reconfiguration to restore the original configuration.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.