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

    USB NICs, dynamic BSD device names and interface assignment?

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    6 Posts 3 Posters 3.0k 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.
    • rcfaR
      rcfa
      last edited by

      I noticed that USB ethernet interfaces get their device names assigned in a somewhat unpredictable way, mostly by the order by which they are plugged-in, but I’m not sure if device name assignment is predictable during boot, if the USB interfaces remain plugged into the same USB port before and after restart.

      Certainly moving the interface to another USB port may result the interface names changing.

      So, what does pfSense do? Recognize the proper NIC by looking at the associated MAC address, or could it happen that I have randomly the DMZ and LAN segments swapped, if upon a reboot the corresponding USB ethernet NICs are recognized in a different sequence and have their device names swapped?

      Of course, I could do lots of testing, but that won’t prove what’s (supposed to) happen(ing). Does anyone here know what the code actually looks at when making the relevant assignments for a NIC to its corresponding role?

      1 Reply Last reply Reply Quote 0
      • G
        gnhb
        last edited by

        Right now, it just looks at the interface name (vr0, fe0, etc.) as assigned by FreeBSD for physical interfaces.

        Some OS's solve this problem by tying the name to the physical USB port, but I'm not sure what FreeBSD does.

        GB

        1 Reply Last reply Reply Quote 0
        • rcfaR
          rcfa
          last edited by

          @gnhb:

          Right now, it just looks at the interface name (vr0, fe0, etc.) as assigned by FreeBSD for physical interfaces.

          Some OS's solve this problem by tying the name to the physical USB port, but I'm not sure what FreeBSD does.

          Thanks for the answer. That's a potential pitfall that I need to investigate further.
          It might be useful to enhance pfSense to optionally assign interface roles based on MAC address rather than device name.

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

            It's not going to change if you plug it into a different USB port. The only way it could shift is if you add a second card with the same driver.

            1 Reply Last reply Reply Quote 0
            • rcfaR
              rcfa
              last edited by

              @cmb:

              It's not going to change if you plug it into a different USB port. The only way it could shift is if you add a second card with the same driver.

              Uhm, yeah. Sorry I wasn't clear. I'm trying to use a low-power netbook (one built-in ethernet) with two USB ethernet interfaces. So e.g. built-in -> WAN, USB1 -> LAN, USB2 -> DMZ
              But if I can't be 100% sure that a specific physical port is always going to be the LAN because at boot time the system may discover one or the other USB interface first…

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

                @rcfa:

                But if I can't be 100% sure that a specific physical port is always going to be the LAN because at boot time the system may discover one or the other USB interface first…

                Shouldn't, though I stay away from USB networking at all costs so I'm not sure, but it should be like PCI/PCI-e/PCI-X, where it'll never change from what it is (unless you rearrange the cards in that case), the detection isn't some random process.

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