1474295 – default netmask of IP in nmtui

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1474295 - default netmask of IP in nmtui

Summary: default netmask of IP in nmtui

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	NetworkManager
Sub Component:
Version:	7.3
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Thomas Haller
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2017-07-24 10:33 UTC by yangfei
Modified:	2018-04-10 13:28 UTC (History)
CC List:	8 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2018-04-10 13:27:23 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2018:0778	0	None	None	None	2018-04-10 13:28:55 UTC

Description yangfei 2017-07-24 10:33:41 UTC

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 19:00:52 UTC

(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 12:40:22 UTC

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 11:57:46 UTC

(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 12:50:50 UTC

(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 17:13:29 UTC

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 20:22:00 UTC

> >   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 20:28:41 UTC

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 12:29:41 UTC

working well now. 4 test cases added.

Comment 16 errata-xmlrpc 2018-04-10 13:27:23 UTC

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

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