Hi everyone, I'm a developer for the LNST project. We aim to automate network testing on Linux, and a big part of this problem is the network configuration of all the test machines. For the past couple of weeks I've been working on making LNST be able to use NM for the configuration instead of the traditional way of using iptools.
In this email I would like to summarize some of the problems I've encountered. These might turn out to be bug reports, suggestions or just my own mistakes. I would like your comments on these. For communication with NM I'm using dbus so all of these topics are based on what I can do through dbus. * One of the more important issues is the removal of software devices like bonding or bridge. Their creation is done automatically when activating a connection defining them, however at the moment I don't see a way to remove these devices through NM. Automatic removal of these devices is probably not the right answer but there are already specific dbus interfaces for every type of device. I think it would be nice if some of these could provide a "RemoveDevice" or a similar method. My reason for this is that I want to cleanup the test machines after testing, and this includes removing created devices. * When creating a connection for a bond device I also create connections for every slave I will be using, I wanted to use the 'secondaries' field in the master connection object to activate them all at the same time, however this didn't work. The individual connection objects were valid, since I could still use them "manually", I think the problem is that when activating a wired connection (which these bond slaves are) you need to specify a devices it should bind to, even if the connection object contains a restriction on mac-address, and you can't do that when adding a connection object to the 'secondaries' field. So this point contains two problems that might be one- if the connection object contains a restriction on mac address why can't it automatically find a target device when activating the connection. And if this is not intended shouldn't the secondaries list be a list of tuples containing connections and their target devices? * When a managed devices is somehow changed by something else than NM, NM reacts by making the device unavailable and not managing it anymore (state UNAVAILABLE). This is an OK behavior but I noticed that even after that I am unable to configure bonding devices through their /sys interface, until I shutdown NM. This is not something I'm planning on doing but it's probably a minor bug that I've noticed while experimenting. * A related problem is that, as far as I see it, there is no way to tell NM to explicitly take control over a managed device, that was made unavailable by changing something. The way I do this at the moment is by running 'ip link set ethX down' and 'ip link set ethX up' which is not very pretty... What I would like is a "reset" method in the 'org.freedesktop.NetworkManager.Device' interface that would return the device to a clean managed state. The Disconnect method doesn't work here because the interface doesn't have an active connection, and activating a connection doesn't work because the devices is not available. For me this happens quite often because I use virtual machines as my test machines, and I add new devices dynamically when the test requires them. These are automatically managed by NM but they are in an unavailable state so I have to set them down and up to be able to use them. * There is a minor bug when creating a bond connection and specifying bond options you can only use string values of the options, and not their numeric equivalents. * It is impossible to create a connection with both ipv4 and ipv6 settings set to disabled when the connection is not a slave. When both settings are disabled NM will autmatically set ipv4 method to 'auto'. This is is probably not very usefull but I've come across it when creating a bridge device. Creating a bridge without ip configuration is I think a reasonable use case, but with ipv4 set to automatic the connection activation will hang on recieving an ip address from a DHCP server that might not be there. No ip configuration could also be usable for other connection types, for example to test only L2 connectivity. Also a side question why is it that for ipv4 it is 'method': 'disabled' and for ipv6 it's 'method': 'ignore'? * "Unplugging the cable" will automatically deactivate a connection. Here I think could be a use case for testing where I intentionally unplug a cable for some time to monitor what happens after that, and later reconnect the cable. It would be usefull if I would have the option of not deactivating the connection so the devices remain configured- and I won't have to reactivate the connection later. I realize this is a corner case, but I see a potential use case and I want to hear your opinions on this. _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
