Re: [PATCH] Re: IP4Config and routes
On Tuesday 08 of June 2010 23:08:01 Dan Williams wrote:
> On Tue, 2010-06-08 at 13:43 +0200, Jirka Klimes wrote:
> > On Saturday 05 of June 2010 04:58:36 Dan Williams wrote:
> > > On Wed, 2010-06-02 at 09:51 +0200, Simon Schampijer wrote:
> > > > On 12/18/2009 03:14 PM, Daniel Drake wrote:
> > > > > On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote:
> > > > >> What would you expect the routing table to look like in your case?
> > > > >> I suppose we could do a default route for link-local. Not sure
> > > > >> if that will confuse apps that expect a default route to mean an
> > > > >> internet connection though.
> > > > >
> > > > > I would expect the subnet route, as NM is creating already:
> > > > > dest=169.254.0.0
> > > > > gateway=0.0.0.0
> > > > > genmask=255.255.0.0
> > > > >
> > > > > I would also like the routing table to either include a default
route:
> > > > > dest=0.0.0
> > > > > gateway=0.0.0.0
> > > > > genmask=0.0.0.0
> > > > >
> > > > > or a multicast one:
> > > > > dest=224.0.0.0
> > > > > gateway=0.0.0.0
> > > > > genmask=240.0.0.0
> > > > >
> > > > > The routing table that NM is setting up now is reasonable, in my
> > > > > opinion, but there should be some way of customizing the behaviour
> > > > > in the settings object.
> > > > >
> > > > > Daniel
> > > >
> > > > Hi,
> > > >
> > > > what is the status on this one? Was there a conclusion on whether NM
> > > > should set a default route for link local?
> > >
> > > Creating a multicast route by default on link-local IPv4 connections
> > > seems reasonable. Want to do a patch for that? I'd say just add the
> > > desired route in aipd_get_ip4_config() in src/nm-device.c to the
> > > returned NMIP4Config object and then lets make sure the code that adds
> > > routes works correctly there.
> >
> > The patch adds a multicast route as suggested by Dan.
> >
> > destination=224.0.0.0
> > netmask=240.0.0.0
> >
> > Daniel, does it work for your case?
>
> Patch looks good; lets push it into master, NM_0_8_1, and
> NETWORKMANAGER_0_7 branches. And something else I found today, the
> Fedora network scripts add a 169.254 route by default for IPv4
> connections even if they aren't LL-only. Not sure why or if that's
> something we want to or why it was added to the Fedora initscripts in
> the first place, but might be worth finding out.
Committed to the three branches.
Regarding 169.254.0.0 route, I've searched a bit. It is part of initscripts
quite a long time now (from RedHat 9.0).
/etc/sysconfig/network-scripts/ifup-eth:
# Add Zeroconf route.
if [ -z "${NOZEROCONF}" -a "${ISALIAS}" = "no" -a "${REALDEVICE}" != "lo" ];
then
ip route add 169.254.0.0/16 dev ${REALDEVICE} metric $((1000 + $(cat
/sys/class/net/${REALDEVICE}/ifindex))) scope link
fi
http://linux.dbw.org/notes/static-routes.txt - last section.
I think that it was added as a response to Windows Automatic Private IP
Addressing(APIPA) feature when implementing zeroconf.
However, I don't know if Windows adds the route for all connections like
initscripts does. I could try to find that.
I'm not sure if the route could cause problems, probably not. But having it
just for LL-only connection looks cleaner.
There was a bug for creating it even for loopback, now
corrected:https://bugzilla.redhat.com/show_bug.cgi?id=203591#c8
Switching off the zeroconf route:
http://kbase.redhat.com/faq/docs/DOC-8628
Jirka
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: IP4Config and routes
On Tue, 2010-06-08 at 14:08 -0700, Dan Williams wrote: > Patch looks good; lets push it into master, NM_0_8_1, and > NETWORKMANAGER_0_7 branches. And something else I found today, the > Fedora network scripts add a 169.254 route by default for IPv4 > connections even if they aren't LL-only. Not sure why or if that's > something we want to or why it was added to the Fedora initscripts in > the first place, but might be worth finding out. Funny I asked the same thing awhile ago: https://bugzilla.redhat.com/show_bug.cgi?id=455186 On a different note, could your review the concept of creating multi-hop gateways that I filed at: https://bugzilla.redhat.com/show_bug.cgi?id=171763 Think there might be some interest in having multiple gateways active with NM, is there? If so, would the above ifcfg layout be OK once the rh-plugin has the support? Sorry, I didn't take that idea farther then, too many packages to patch(NM being one of them), and I don't have the connections to get all the packages that touch the main routing table patched. On a side note, shorewall has been able to support multiple gateways for a while, with two distinct ways of configuring the routing tables, one using the "main" and the other using the "default" routing tables for the gateways, note the USE_DEFAULT_RT part, have a look at: http://www.shorewall.net/MultiISP.html What's your take on the use of the routing tables? just some thoughts, Jerry ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: IP4Config and routes
On Tue, 2010-06-08 at 13:43 +0200, Jirka Klimes wrote: > On Saturday 05 of June 2010 04:58:36 Dan Williams wrote: > > On Wed, 2010-06-02 at 09:51 +0200, Simon Schampijer wrote: > > > On 12/18/2009 03:14 PM, Daniel Drake wrote: > > > > On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote: > > > >> What would you expect the routing table to look like in your case? I > > > >> suppose we could do a default route for link-local. Not sure if that > > > >> will confuse apps that expect a default route to mean an internet > > > >> connection though. > > > > > > > > I would expect the subnet route, as NM is creating already: > > > > dest=169.254.0.0 > > > > gateway=0.0.0.0 > > > > genmask=255.255.0.0 > > > > > > > > I would also like the routing table to either include a default route: > > > > dest=0.0.0 > > > > gateway=0.0.0.0 > > > > genmask=0.0.0.0 > > > > > > > > or a multicast one: > > > > dest=224.0.0.0 > > > > gateway=0.0.0.0 > > > > genmask=240.0.0.0 > > > > > > > > The routing table that NM is setting up now is reasonable, in my > > > > opinion, but there should be some way of customizing the behaviour in > > > > the settings object. > > > > > > > > Daniel > > > > > > Hi, > > > > > > what is the status on this one? Was there a conclusion on whether NM > > > should set a default route for link local? > > > > Creating a multicast route by default on link-local IPv4 connections > > seems reasonable. Want to do a patch for that? I'd say just add the > > desired route in aipd_get_ip4_config() in src/nm-device.c to the > > returned NMIP4Config object and then lets make sure the code that adds > > routes works correctly there. > > > > The patch adds a multicast route as suggested by Dan. > > destination=224.0.0.0 > netmask=240.0.0.0 > > Daniel, does it work for your case? Patch looks good; lets push it into master, NM_0_8_1, and NETWORKMANAGER_0_7 branches. And something else I found today, the Fedora network scripts add a 169.254 route by default for IPv4 connections even if they aren't LL-only. Not sure why or if that's something we want to or why it was added to the Fedora initscripts in the first place, but might be worth finding out. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: IP4Config and routes
On 06/08/2010 01:43 PM, Jirka Klimes wrote: On Saturday 05 of June 2010 04:58:36 Dan Williams wrote: On Wed, 2010-06-02 at 09:51 +0200, Simon Schampijer wrote: On 12/18/2009 03:14 PM, Daniel Drake wrote: On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote: What would you expect the routing table to look like in your case? I suppose we could do a default route for link-local. Not sure if that will confuse apps that expect a default route to mean an internet connection though. I would expect the subnet route, as NM is creating already: dest=169.254.0.0 gateway=0.0.0.0 genmask=255.255.0.0 I would also like the routing table to either include a default route: dest=0.0.0 gateway=0.0.0.0 genmask=0.0.0.0 or a multicast one: dest=224.0.0.0 gateway=0.0.0.0 genmask=240.0.0.0 The routing table that NM is setting up now is reasonable, in my opinion, but there should be some way of customizing the behaviour in the settings object. Daniel Hi, what is the status on this one? Was there a conclusion on whether NM should set a default route for link local? Creating a multicast route by default on link-local IPv4 connections seems reasonable. Want to do a patch for that? I'd say just add the desired route in aipd_get_ip4_config() in src/nm-device.c to the returned NMIP4Config object and then lets make sure the code that adds routes works correctly there. The patch adds a multicast route as suggested by Dan. destination=224.0.0.0 netmask=240.0.0.0 Daniel, does it work for your case? Jirka Hi Jirka, thanks for doing the patch. I am at a conference at the moment, so testing has to wait until next week. Thanks very much, Simon ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Re: IP4Config and routes
On Saturday 05 of June 2010 04:58:36 Dan Williams wrote: > On Wed, 2010-06-02 at 09:51 +0200, Simon Schampijer wrote: > > On 12/18/2009 03:14 PM, Daniel Drake wrote: > > > On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote: > > >> What would you expect the routing table to look like in your case? I > > >> suppose we could do a default route for link-local. Not sure if that > > >> will confuse apps that expect a default route to mean an internet > > >> connection though. > > > > > > I would expect the subnet route, as NM is creating already: > > > dest=169.254.0.0 > > > gateway=0.0.0.0 > > > genmask=255.255.0.0 > > > > > > I would also like the routing table to either include a default route: > > > dest=0.0.0 > > > gateway=0.0.0.0 > > > genmask=0.0.0.0 > > > > > > or a multicast one: > > > dest=224.0.0.0 > > > gateway=0.0.0.0 > > > genmask=240.0.0.0 > > > > > > The routing table that NM is setting up now is reasonable, in my > > > opinion, but there should be some way of customizing the behaviour in > > > the settings object. > > > > > > Daniel > > > > Hi, > > > > what is the status on this one? Was there a conclusion on whether NM > > should set a default route for link local? > > Creating a multicast route by default on link-local IPv4 connections > seems reasonable. Want to do a patch for that? I'd say just add the > desired route in aipd_get_ip4_config() in src/nm-device.c to the > returned NMIP4Config object and then lets make sure the code that adds > routes works correctly there. > The patch adds a multicast route as suggested by Dan. destination=224.0.0.0 netmask=240.0.0.0 Daniel, does it work for your case? Jirka diff --git a/src/nm-device.c b/src/nm-device.c index fcd3120..ba26dec 100644 --- a/src/nm-device.c +++ b/src/nm-device.c @@ -1019,6 +1019,7 @@ aipd_get_ip4_config (NMDevice *self, NMDeviceStateReason *reason) NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self); NMIP4Config *config = NULL; NMIP4Address *addr; + NMIP4Route *route; g_return_val_if_fail (priv->aipd_addr > 0, NULL); @@ -1033,6 +1034,14 @@ aipd_get_ip4_config (NMDevice *self, NMDeviceStateReason *reason) nm_ip4_address_set_prefix (addr, 16); nm_ip4_config_take_address (config, addr); + /* Add a multicast route for link-local connections: destination= 224.0.0.0, netmask=240.0.0.0 */ + route = nm_ip4_route_new (); + nm_ip4_route_set_dest (route, (guint32) htonl (0xE000L)); + nm_ip4_route_set_prefix (route, 4); + nm_ip4_route_set_next_hop (route, (guint32) 0); + nm_ip4_route_set_metric (route, 0); + nm_ip4_config_take_route (config, route); + return config; } ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2010-06-02 at 09:51 +0200, Simon Schampijer wrote: > On 12/18/2009 03:14 PM, Daniel Drake wrote: > > On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote: > >> What would you expect the routing table to look like in your case? I > >> suppose we could do a default route for link-local. Not sure if that > >> will confuse apps that expect a default route to mean an internet > >> connection though. > > > > I would expect the subnet route, as NM is creating already: > > dest=169.254.0.0 > > gateway=0.0.0.0 > > genmask=255.255.0.0 > > > > I would also like the routing table to either include a default route: > > dest=0.0.0 > > gateway=0.0.0.0 > > genmask=0.0.0.0 > > > > or a multicast one: > > dest=224.0.0.0 > > gateway=0.0.0.0 > > genmask=240.0.0.0 > > > > The routing table that NM is setting up now is reasonable, in my > > opinion, but there should be some way of customizing the behaviour in > > the settings object. > > > > Daniel > > Hi, > > what is the status on this one? Was there a conclusion on whether NM > should set a default route for link local? Creating a multicast route by default on link-local IPv4 connections seems reasonable. Want to do a patch for that? I'd say just add the desired route in aipd_get_ip4_config() in src/nm-device.c to the returned NMIP4Config object and then lets make sure the code that adds routes works correctly there. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On 12/18/2009 03:14 PM, Daniel Drake wrote: On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote: What would you expect the routing table to look like in your case? I suppose we could do a default route for link-local. Not sure if that will confuse apps that expect a default route to mean an internet connection though. I would expect the subnet route, as NM is creating already: dest=169.254.0.0 gateway=0.0.0.0 genmask=255.255.0.0 I would also like the routing table to either include a default route: dest=0.0.0 gateway=0.0.0.0 genmask=0.0.0.0 or a multicast one: dest=224.0.0.0 gateway=0.0.0.0 genmask=240.0.0.0 The routing table that NM is setting up now is reasonable, in my opinion, but there should be some way of customizing the behaviour in the settings object. Daniel Hi, what is the status on this one? Was there a conclusion on whether NM should set a default route for link local? Thanks, Simon ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote: > What would you expect the routing table to look like in your case? I > suppose we could do a default route for link-local. Not sure if that > will confuse apps that expect a default route to mean an internet > connection though. I would expect the subnet route, as NM is creating already: dest=169.254.0.0 gateway=0.0.0.0 genmask=255.255.0.0 I would also like the routing table to either include a default route: dest=0.0.0 gateway=0.0.0.0 genmask=0.0.0.0 or a multicast one: dest=224.0.0.0 gateway=0.0.0.0 genmask=240.0.0.0 The routing table that NM is setting up now is reasonable, in my opinion, but there should be some way of customizing the behaviour in the settings object. Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
Dan Williams a écrit : > What would you expect the routing table to look like in your case? I > suppose we could do a default route for link-local. Not sure if that > will confuse apps that expect a default route to mean an internet > connection though. Such apps are damned to be confused anyway, think for instance of a private network. So not worth considering. Correctly designed apps just try to connect whenever they see a chance, and report the connection failure if any. Anything more clever is doomed to fail in some of the zillions possible network configurations out there. Note that I am *not* talking about NetworkManager here, but about network apps. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Thu, 2009-12-17 at 16:33 +, Daniel Drake wrote: > On Wed, 2009-12-16 at 17:22 -0800, Dan Williams wrote: > > 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? > > There is no default route created for link-local connections. And if > there were, I suspect this isn't always what you want, e.g. see > https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/99489 > > However, if the default route was created, I'd be happy and our bug > would go away. There would be no need to create a multicast route. (I > was just taking that approach as thats what happens when Sugar/NM-0.6 > creates a simple mesh connection on XO-1 -- there is no default route, > but there is a multicast route) > > You can reproduce this easily - just use nm-applet to create a > link-local adhoc wireless connection, run "route -n", and observe a lack > of default route. > > I've found the piece of code that causes the routes property to be > ignored for link-local connections, it's in > real_act_stage4_get_ip4_config() > > We either need to rework that code to allow certain types of routes, or > get that default route created like you say. What do you think? What would you expect the routing table to look like in your case? I suppose we could do a default route for link-local. Not sure if that will confuse apps that expect a default route to mean an internet connection though. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2009-12-16 at 17:22 -0800, Dan Williams wrote: > 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? There is no default route created for link-local connections. And if there were, I suspect this isn't always what you want, e.g. see https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/99489 However, if the default route was created, I'd be happy and our bug would go away. There would be no need to create a multicast route. (I was just taking that approach as thats what happens when Sugar/NM-0.6 creates a simple mesh connection on XO-1 -- there is no default route, but there is a multicast route) You can reproduce this easily - just use nm-applet to create a link-local adhoc wireless connection, run "route -n", and observe a lack of default route. I've found the piece of code that causes the routes property to be ignored for link-local connections, it's in real_act_stage4_get_ip4_config() We either need to rework that code to allow certain types of routes, or get that default route created like you say. What do you think? Thanks, Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2009-12-16 at 20:10 +, 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
Re: IP4Config and routes
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. > 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. 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. Thanks for your help, as always! Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2009-12-16 at 18:23 +, Daniel Drake wrote: > On Wed, 2009-12-16 at 17:53 +, Daniel Drake wrote: > > Thanks! Very comprehensive. > > > > Is this part correct? > > > > "Routes cannot be used with the 'shared' or 'link-local' methods as > > there is no upstream network." > > > > We're using link-local. Might explain my troubles, but in this case we > > need a route even though we aren't dealing with an upstream network. > > Well, if it is correct, we aren't even hitting the bit of the code where > it is enforced. (or at least I haven't spotted it) 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/... > I have traced the code and I am finding : > > - nm_setting_new_from_hash() is being called > - it is calling parse_one_setting() > - which then calls nm_setting_new_from_hash() > - the hash table has 2 properties inside(method,routes) > - one_property_cb() is called on both those properties and is successful > at adding them to the list > - back in nm_setting_new_from_hash(), g_object_newv() is called with the > property list (method and routes) > - a NMSettingIP4Config is constructed, and these properties are set: > 6(ignore auto routes), 7(ignore auto dns), 10(never default), 1(method) > > Why is set_property not called for the routes property? > Is it because routes is a _nm_param_spec_specialized? (I'm not exactly > sure what the difference is between this and the regular glib param > specs) 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. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2009-12-16 at 17:53 +, Daniel Drake wrote: > Thanks! Very comprehensive. > > Is this part correct? > > "Routes cannot be used with the 'shared' or 'link-local' methods as > there is no upstream network." > > We're using link-local. Might explain my troubles, but in this case we > need a route even though we aren't dealing with an upstream network. Well, if it is correct, we aren't even hitting the bit of the code where it is enforced. (or at least I haven't spotted it) I have traced the code and I am finding : - nm_setting_new_from_hash() is being called - it is calling parse_one_setting() - which then calls nm_setting_new_from_hash() - the hash table has 2 properties inside(method,routes) - one_property_cb() is called on both those properties and is successful at adding them to the list - back in nm_setting_new_from_hash(), g_object_newv() is called with the property list (method and routes) - a NMSettingIP4Config is constructed, and these properties are set: 6(ignore auto routes), 7(ignore auto dns), 10(never default), 1(method) Why is set_property not called for the routes property? Is it because routes is a _nm_param_spec_specialized? (I'm not exactly sure what the difference is between this and the regular glib param specs) Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2009-12-16 at 09:49 -0800, Dan Williams wrote: > http://live.gnome.org/NetworkManager > > which leads you to: > > http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html > Thanks! Very comprehensive. Is this part correct? "Routes cannot be used with the 'shared' or 'link-local' methods as there is no upstream network." We're using link-local. Might explain my troubles, but in this case we need a route even though we aren't dealing with an upstream network. Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2009-12-16 at 12:40 +, Daniel Drake wrote: > Hi, > > Ad-hoc networking is broken in Sugar because no route is created for > multicast packets - this means the collaboration features do not work. > > I can see that I can specify routes in the IP4Config object (hence we > could modify Sugar to fix this) but the only documentation I can find > is: > > Routes - aau - (read) > Tuples of IPv4 route/prefix/next-hop/metric. http://live.gnome.org/NetworkManager which leads you to: http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html "Array of IPv4 route structures. Each IPv4 route structure is composed of 4 32-bit values; the first being the destination IPv4 network or address (network byte order), the second the destination network or address prefix (1 - 32), the third being the next-hop (network byte order) if any, and the fourth being the route metric. For the 'auto' method, given IP routes are appended to those returned by automatic configuration. Routes cannot be used with the 'shared' or 'link-local' methods as there is no upstream network." If I need to expand on that, please let me know and I'll update the docs. > I'm not too knowledgeable about routing tables and the language I speak > is the one that "route -n" returns, basically I want a route of: > destination=224.0.0.0 > gateway=0.0.0.0 > genmask=240.0.0.0 > flags=U > metric=0 > > I guess next-hop is gateway, and metric is metric, but I'm a bit stuck > on "route" and "prefix" route == destination prefix = "Genmask" from /sbin/route but as a CIDR prefix, not a subnet mask > Can anyone help me convert those values into ones that NM understands, > or point me at some existing code which uses this functionality? Lot of the internal NM code does this; internally NM uses GSList *nm_utils_ip4_routes_from_gvalue (const GValue *value); void nm_utils_ip4_routes_to_gvalue (GSList *list, GValue *value); to get translate the 'routes' key into something it can use. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP4Config and routes
On Wed, 2009-12-16 at 12:40 +, Daniel Drake wrote:
> Hi,
>
> Ad-hoc networking is broken in Sugar because no route is created for
> multicast packets - this means the collaboration features do not work.
>
> I can see that I can specify routes in the IP4Config object
I started guessing at some numbers and actually, I can't seem to get
this working at all.
With my latest guess, here is the object being returned by
NMSettingsConnection.GetSettings() on the user settings service:
{'802-11-wireless': {'band': 'bg', 'ssid': dbus.ByteArray("asfdsfg's
network"), 'mode': 'adhoc'}, 'connection': {'autoconnect': False,
'type': '802-11-wireless', 'id': "Auto asfdsfg's network", 'uuid':
'28cbb90800f37c775511a1eab45a834b53cb32a1'}, 'ipv4': {'routes': [[224,
4, 0, 0]], 'method': 'link-local'}}
There is no resulting entry in the routing table (checked by running
'route -n')
Even if I use an invalid value (such as a string) for routes, NM doesn't
complain, as if it is ignoring my routes key altogether. Am I missing
something obvious?
Thanks,
Daniel
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
IP4Config and routes
Hi, Ad-hoc networking is broken in Sugar because no route is created for multicast packets - this means the collaboration features do not work. I can see that I can specify routes in the IP4Config object (hence we could modify Sugar to fix this) but the only documentation I can find is: Routes - aau - (read) Tuples of IPv4 route/prefix/next-hop/metric. I'm not too knowledgeable about routing tables and the language I speak is the one that "route -n" returns, basically I want a route of: destination=224.0.0.0 gateway=0.0.0.0 genmask=240.0.0.0 flags=U metric=0 I guess next-hop is gateway, and metric is metric, but I'm a bit stuck on "route" and "prefix" Can anyone help me convert those values into ones that NM understands, or point me at some existing code which uses this functionality? Thanks, Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
