Together with this change, we should also change the IP address list format
to something sane.

The current (rather insane) way:

addresses1=192.168.2.200;24;192.168.2.1;

(and this is for just one address)

An example of a sane way (without gateway):

address=192.168.2.200/24

or

addresses=192.168.2.200/24

An example of a sane multi-address format:

address=192.168.2.200/24,192.168.3.3/24

This should of course be also reflected by nmcli.

The last semicolon in the current format was not necessary.

Another note... This should be documented.

(In reply to comment #2)
> The last semicolon in the current format was not necessary.

It's standard keyfile syntax; list-valued properties have a semicolon after each element, including the last one. (Yes, this is dumb, but there's more than a decade of precedent now.)

So:

  addresses=192.168.2.200/24;192.168.3.3/24;

I actually just ran into this yesterday too.  Yes, we should fix it up so you can use /X for the prefix.

But we also have to make sure to keep backwards compat when reading files, and there's already some backwards compat for a yet-older format.  So we'll have to slot in some code that looks for "/" in the string and handles as the new format I guess.

But for IPv4, it did makes some sense to bind the addresses to gateways.  You'll never really have a gateway that's out of your subnet, and since an address is tied to a specific subnet, you can stick the gateway in there too.  For example, unless you've got a really weird routing configuration, given an address of 192.168.1.10, you'll never have a 10.x.x.x gateway.  You'll have a gateway in 192.168.1.x since that's the same broadcast domain.

Yeah, not entirely correct, but it's good enough.

It's not clear how we'd handle the gateway if you decoupled it from the addresses for IPv4.  Another GtkEntry box doesn't work, because that doesn't have any relationship with the addresses.  And that would allow you to specify a gateway of 10.x.x.x when that gateway wasn't in one of the subnets defined by the addresses.

Plus, if you delete an address for 192.168.1.x you want to delete any 192.168.1.x gateway as well.  So it also helps from a sychronization standpoint.

Yes, technically if the device has IP addresses on multiple subnets, you can have multiple gateways and that should work just fine.  SO with IPv4 it's more about ensuring that the gateway and the subnet are tied together, which almost always they are.

But yes, for IPv6 it's completely different.  And putting the gateway there was a mistake.

> I actually just ran into this yesterday too.  Yes, we should fix it up so you
> can use /X for the prefix.

This is a quick sketch (read support only, which is enough for manual configuration).

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=pavlix/next&id=35f2d2abf3241406fd9ffbb0b603d06e8dd0e10e

> But for IPv4, it did makes some sense to bind the addresses to gateways. 

Not unless you want to use different default gateways for different IP addresses, which doesn't work anyway.

> You'll never really have a gateway that's out of your subnet, and since an
> address is tied to a specific subnet, you can stick the gateway in there too.

You're right that on IPv4 the (one) gateway should belong to a subnet of one
of the addresses. That's the only sanity check that should be made.

> Yeah, not entirely correct, but it's good enough.

Agreed. But I'd prefer to have IPv4 and IPv6 configuration as close as
possible.

> It's not clear how we'd handle the gateway if you decoupled it from the
> addresses for IPv4.

In the GUI?

> Another GtkEntry box

This is the best solution.

> doesn't work, because that doesn't
> have any relationship with the addresses.  And that would allow you to specify
> a gateway of 10.x.x.x when that gateway wasn't in one of the subnets defined by
> the addresses.

You would need to do the sanity check described above.

> Plus, if you delete an address for 192.168.1.x you want to delete any
> 192.168.1.x gateway as well.

Sure. With the same sanity check.

> So it also helps from a sychronization
> standpoint.

It helps. But what if someone actually fills in multiple gateways with multiple
addresses?

> Yes, technically if the device has IP addresses on multiple subnets, you can
> have multiple gateways and that should work just fine.

But it doesn't. At least not on Linux, which is the only platform supported
by NetworkManager.

And even if it did, on some hypothetical platform, the multiple gateways would
only be good for load-balancing scenarios. But even then they would not be used
specifically for the individual subnets but rather individually (you could e.g.
have two loadbalancing gateways on one subnet with one IP).

The relation between (multiple) IP addresses and (their) gateways doesn't work.

> But yes, for IPv6 it's completely different. And putting the gateway there
> was a mistake.

Actually, the only difference is in the possibility of using link-local
addresses for gateways. But this is usually done only for method=auto. For
method=manual, IPv4 and IPv6 are mostly equivalent (unless you really type
link-local addresses manually).

This now works in 'pavlix/next':

  [ipv4]
  method=manual
  addresses1=192.168.56.1/24
  addresses2=192.168.57.1/24
  [ipv6]
  method=manual
  addresses1=2001:db8:a:b::3/64
  addresses2=2001:db8:c:d::3/64

NM bugzilla reorganization. Sorry for the bug spam.

I tend to think the rest of the work should be done as part of bug 682946.

*** This bug has been marked as a duplicate of bug 682946 ***