Hi, Thanks for your reply!
> I'll be in Brno tomorrow (July 18), btw. Sorry, I read the email a bit too late... > > 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... I found the dbus interfaces a bit easier to learn and use, and it provided me with all that I need, but i might look into libnm-glib later. > > * 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 Great! I think I saw this bz once in the past couple of weeks but since the last comment was 4 months ago I forgot about it. Removing the device after disconnecting the connection looks nice. > Ah, I know what you mean but... In future, NetworkManager will present > existing configurations through dbus so you can use the disconnect API. I don't know what you mean by that, I can already deactivate active connections through dbus, and there is a Disconnect method on every device recognized by NM. Is there going to be something more? I can also access connection objects and active connection objects... > > * 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. I create several connection objects- one bond master and several bond slaves. I want to activate them all at once by activating the master connection. It's not something I need, I currently activate the master first and then slaves one by one, but I saw that there is a possibility to specify 'secondaries' in a connection object and I thought that it would be nice and convenient to use that instead. But it didn't work when I tried it so I'm wondering if I'm using it wrong, if it's broken or if it's intended for a completely different use. > > * 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. I will look into it a bit more and try to provide a more detailed description later. > > * 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? Reproducer: 1. have a disconnected device eth1, managed by NM- state 30 2. ip link set down eth1 # NM now says that the state of the device is 20 3. try activating a connection- NM says this: 'GDBus.Error:org.freedesktop.NetworkManager.UnmanagedDevice: Device not managed by NetworkManager or unavailable' I tried this on a Fedora 19 machines with NM version 0.9.8.2-4 The only available method on the device is the Disconnect() method and that doesn't work because there is no active connection on this device. Therefore the only way to get the device back to being managed by NM is to run 'ip link set up eth1' I realize that making NM not manage the device in this way predicts that I will probably want to manage it directly and that this is not a normal use case. However I think that it would be nice if NM could have the ability to manage the device again if some method is explicitly called. > > 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. The behaviour of newly created devices might be a bug in LNST, but I still think it's an interesting suggestion. > > * 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. I don't see why not, bonding documentation contains both numeric values and string values, they are both accepted when manually configuring bond devices, so why shouldn't NM accept them? -Ondrej _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
