Bug 1474295

(In reply to yangfei from comment #0)
> Description of problem:
>
> Setting IP address by nmtui, the 255.255.255.255 netmask by default, I think
> this is not make sense.

> I expect the netmask according to the IP subnet to add, for example,
> 192.168.0.0/24 the default netmask is 255.255.255.0, and 172.16.0.0/16, the
> default netmask is 255.255.0.0

I don't think that choosing the prefix of the classful network
associated with the address makes much sense today. If the user
forgets to add a prefix, the interface should get the /32 prefix; the
tool should not make up a prefix which possibly is not the same the
user wants.

Note that in this regard nmtui has the same behavior of other modern
tools for configuring networking, as tools in the iproute2 suite.

I think we should improve this.

At least for IPv4, it's really common that 192.168.0.0 shall mean /24. Anyway, it's only a default behavior, the user can still edit it explicitly. But I agree that this default makes sense (more often then not).

Please review: th/tui-route-input-rh1474295

(In reply to Thomas Haller from comment #3)
> I think we should improve this.
> 
> At least for IPv4, it's really common that 192.168.0.0 shall mean /24.
> Anyway, it's only a default behavior, the user can still edit it explicitly.
> But I agree that this default makes sense (more often then not).
> 
> Please review: th/tui-route-input-rh1474295

Maybe I'm too used to iproute2, but I find confusing that tools try to guess what users want to do.

Ok, for addresses this could make sense because it's unlikely that somebody wants to configure a /32 (which is still possible using the explicit syntax).

But when a route to 192.168.1.1 is entered, I think nmtui should not convert it to 192.168.1.1/24.

(In reply to Beniamino Galvani from comment #4)
> (In reply to Thomas Haller from comment #3)
> > I think we should improve this.
> > 
> > At least for IPv4, it's really common that 192.168.0.0 shall mean /24.
> > Anyway, it's only a default behavior, the user can still edit it explicitly.
> > But I agree that this default makes sense (more often then not).
> > 
> > Please review: th/tui-route-input-rh1474295
> 
> Maybe I'm too used to iproute2, but I find confusing that tools try to guess
> what users want to do.
> 
> Ok, for addresses this could make sense because it's unlikely that somebody
> wants to configure a /32 (which is still possible using the explicit syntax).
> 
> But when a route to 192.168.1.1 is entered, I think nmtui should not convert
> it to 192.168.1.1/24.

True, if the host-part is no-zero, it uses /32. Fixed.


It would be better if the cursor leaves the entry to normalize the field (and immediately show the completed prefix). However, at a quick glance, I am unable to add such a functionality. It would be more effort.


ACK to the branch as-is?

Ok, reworked the branch again and merged as:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=08d7bf5988173f8569b17c646eb1a5c5d9d9340c


Now the prefix length is guessed both for the addresses and routes destination.

Also, various other UI glitches were fixed.

> >   addr:   192.168.0.1   -> 192.168.0.1/32
> I cannot see this, I can see 192.168.0.1/24, are you sure it should be 32?
>
> >   route:  192.168.0.1   -> 192.168.0.1/24

ah right. Of course, for addresses, you may set the host-part != 0, and the plen is still autodetected != 32.

for routes, if the host part is not zero, then it always detects /32.

So:

  addr:   192.168.0.1   -> 192.168.0.1/24
  route:  192.168.0.1   -> 192.168.0.1/32

ok and now I have route:
192.168.0.3 192.168.0.2 256

and it ends with 192.168.0.3/32 not as you wrote:
>   route:  192.168.0.1   -> 192.168.0.1/24

just checking if it's OK.

working well now. 4 test cases added.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0778