> From: "Ondrej Lichtner" <[email protected]> > > Hi everyone,
Hi, I'll be in Brno tomorrow (July 18), btw. > 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. I think libnm-glib might be a slightly better idea... > * 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. They should be removed when the respective connection is disconnected. https://bugzilla.gnome.org/show_bug.cgi?id=695705 > 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. Disconnect should be good enough. > My reason for this is that I want to cleanup the test machines after > testing, and this includes removing created devices. Ah, I know what you mean but... In future, NetworkManager will present existing configurations through dbus so you can use the disconnect API. > * 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? I'm not sure what you're trying to achieve. > * 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. I guess this needs a bit more details. > * 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... Can't you just activate a connection on the device? > 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. Sounds reasonable but... > 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. In future, a device will be either clean or will have a running connection. > 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. Yep, that sounds pretty much wrong. > * 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. Not sure whether this is a bug at all. > * 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. I can't find a bug number for this right now... > No ip configuration could also be usable for other connection types, > for example to test only L2 connectivity. +1 > Also a side question why is it that for ipv4 it is 'method': > 'disabled' and for ipv6 it's 'method': 'ignore'? The defaults are more or less arbitrary. > * "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. AFAIK with NM git master you can only switch the behavior globally. Cheers, Pavel _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
