On Wed, 2009-12-16 at 20:10 +0000, Daniel Drake wrote: > On Wed, 2009-12-16 at 11:59 -0800, Dan Williams wrote: > > Yes, it's correct in these cases because for shared, NM is handling the > > network and there's no routing out of it since the network is NAT-ed to > > the main connection. In link-local it's not relevant since the > > link-local is by definition /not routable/... > > But just because there is no upstream router doesn't mean that access to > the routing table should be excluded. The user may want to add a default > route out on that interface. Or, in our case, we want to pass all > multicast traffic to the interface.
The default route is controlled internally by NM; it should never be part of the connection settings. Does your multicast routing need to be different than the default route? > > I'm more inclined to think that the bits aren't getting passed by to NM > > correctly; are you sure you're passing the item with a dbus signature of > > 'aau'? The code that actually unpacks the routes property is > > nm_utils_ip4_routes_from_gvalue() in nm-utils.c. Trace into > > nm-setting-ip4-config.c's set_property() call and see if the PROP_ROUTES > > case is run. > > set_property() was never called but I figured it out: I have to use > dbus.Array() in Python. Yeah, you have to cast sometimes in Python if dbus-python can't figure it out. The properties may need to be casted since it's not possible for introspection to discover the expected dict property value types. > I'm now using: > > ip4_config['routes'] = dbus.Array([(224,4,0,0)], signature='au') > > set_property() is now being called for routes, but the routing table is > not being modified. I'll continue investigating tomorrow. Ok, let me know. Dan _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list