Re: IP4Config and routes

[Dan Williams <dcbw redhat com>]

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