Please add NetworkManager option not to auto-enable new network devices

[Steve Atwell]

This is a feature request.

It would be nice if Network Manager could be configured such that it won't automatically attempt to use new network devices attached to the system.

Here's the reasoning. My team manages a large fleet of enterprise desktops. We've had a number of cases where a user plugs a USB NIC into their computer, and Network Manager helpfully configures the new network interface and runs dhclient on it. And if the DHCP response is answered, you get a new default route, new resolv.conf, etc. In a couple cases this was caused by plugging in an Android phone that had USB tethering turned on, and I think we even had one case where plugging in a USB GPS did this. None of the cases involved the user actually intending to use the device as a network interface.

We could blacklist the usbnet module, but there are legitimate cases where we want to allow USB networking. It would be so much better if we could get Network Manager not to use these new devices that have shown up until the user configures them.

[Mathieu Trudel-Lapierre (cyphermox)]

This is a feature request I've already discussed shortly with Etienne Goyer.

Setting as Wishlist/Confirmed since I can acknowledge the issue, except there is a lack of easy ways to fix this.

Thinking back however, I'm certain there is a way of at least patching NM so that the default wired connections usually created automatically would not be, which will allow you to have new devices not automatically build connections and activate, but still allow creating them manually when needed. Since patching this is possible then it should be relatively simple to also make that optional and dependant on a gconf/dconf key (which would default to the current behavior).

[Mathieu Trudel-Lapierre (cyphermox)]

Looking at the code quickly, maybe emptying nm_settings_device_added() (in src/settings/nm-settings.c:1425) is sufficient to block this functionality.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mathieu Trudel-Lapierre (cyphermox)]

Why is this targetted to 13.04 beta 1? Should I get that the priority for this has changed?

What are the specific use cases that changed the importance for this bug?

Perhaps it would be possible to special-case USB net devices and avoid them autoconnecting, forcing a user to click on a connection to enable it, but I'll need to look at the code with more attention to figure this one out.

[Adam Stokes (adam-stokes)]

IIRC this was discussed on IRC and because of the driving force behind this particular feature request we would like to see this in the raring release and possibly backported into Precise/Quantal. It would be appreciated if this feature request would stay on your radar during the Raring development cycle.

Thank you!
Adam

[Marius B. Kotsbak (mariusko)]

For the Android case, in the newest version, it requires manually enabling thethering so that use case for this option should have disappeared. At least it should not be set as default, as it creates extra steps for those using the phone as described.

[Dan Williams (dcbw)]

For the original request about a fleet of machines, the facility to disable this is already there:

1) set no-auto-default=* in /etc/NetworkManager/NetworkManager.conf
2) preconfigure a wired connection for the existing wired interface, locked on MAC address

future versions of NetworkManager will allow you to lock on interface name, but be aware that the interface won't always be 'eth0' so some amount of machine-specific configuration will always be required here.

If #1 and #2 are done, then no other device will get the automatic DHCP connection.

In the case of all other USB ethernet devices (including android devices) there's simply no way to distinguish between an Android device and an actual usb-ethernet device with an RJ-45 connector on the end. You can either go about tagging every single Android device into a blacklist for this.

Or we could start a whitelist of usb-ethernet kernel drivers or something. That would include asix, rndis, catc, etc. Half of drivers/net/usb/ is a candidate for whitelisting.

The big question: are there any/many usb-ethernet dongles that use plain cdc-ether ?

[TJ (tj)]

I'm seeing this on a fleet of laptops which all have Fast Ethernet, 802.11a/g/n and GSM HSPA interfaces.

If the WLAN is active and configured as the default route when the GSM HSPA WWAN is activated the default route is changed to be the WWAN.

I wonder if NM could accept a user-specified (or automatically assigned) metric for each interface without requiring a static route to be specified?

If the user then chooses to disconnect from an existing network or the connection drops through being out of range the next most senior link would be selected. The manual configuration I use for default routes is:

$ ip route ls
default via 10.254.251.1 dev eth0 proto static metric 1
default via 10.254.251.1 dev wlan0 proto static metric 9
default via 10.50.163.2 dev wwan0 proto static metric 19
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
10.50.163.0/26 dev wwan0 proto kernel scope link src 10.50.163.32 metric 7
10.254.1.0/24 dev virbr0 proto kernel scope link src 10.254.1.1
10.254.251.0/24 dev eth0 proto kernel scope link src 10.254.251.50 metric 1
10.254.251.0/24 dev wlan0 proto kernel scope link src 10.254.251.60 metric 9

Notice how the metric assigned by NM to wwan0's link (7) is more senior than wlan0 (9). I think that could do with changing as a default so that 802.11a/g takes preference behind wired Ethernet.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release