Bug 1474295 - default netmask of IP in nmtui
default netmask of IP in nmtui
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.3
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Thomas Haller
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-24 06:33 EDT by yangfei
Modified: 2017-12-13 08:27 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description yangfei 2017-07-24 06:33:41 EDT
Description of problem:

Setting IP address by nmtui, the 255.255.255.255 netmask by default, I think this is not make sense.

Version-Release number of selected component (if applicable):


How reproducible:

# nmtui

into a tui interface and set ip address 

Steps to Reproduce:
1. # nmtui
2. set ip address 
3. the /32 netmask by default

Actual results:


Expected results:

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

Additional info:
Comment 2 Beniamino Galvani 2017-08-03 15:00:52 EDT
(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.
Comment 3 Thomas Haller 2017-09-04 08:40:22 EDT
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
Comment 4 Beniamino Galvani 2017-09-05 07:57:46 EDT
(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.
Comment 5 Thomas Haller 2017-09-05 08:50:50 EDT
(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?
Comment 6 Thomas Haller 2017-09-05 13:13:29 EDT
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.
Comment 11 Thomas Haller 2017-12-11 15:22:00 EST
> >   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
Comment 12 Vladimir Benes 2017-12-11 15:28:41 EST
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.
Comment 13 Vladimir Benes 2017-12-13 07:29:41 EST
working well now. 4 test cases added.

Note You need to log in before you can comment on or make changes to this bug.