Anonymous | Login | 2024-12-22 00:34 MST |
Main | My View | View Issues | Change Log | Roadmap | Repositories |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001145 | ClearOS | app-network - Network Settings | public | 2013-05-16 15:11 | 2018-10-24 17:58 | ||||
Reporter | user2 | ||||||||
Assigned To | user2 | ||||||||
Priority | normal | Severity | feature | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | 7.5.0 Updates | Fixed in Version | 7.5.0 Updates | ||||||
Summary | 0001145: Add "none" to the connection type list for network interfaces | ||||||||
Description | With the introduction of VLAN interfaces, there is a use case for enabling network interfaces without IP addresses. From the forums: Add "Connection Type" of "none" to list - ie: This would allow the ability to have an interface configured, but specify that it should NOT have an IP address. While there are probably many reasons for doing this, the most common one would be for when VLANs are configured, and one does not wish to use the base interface (ie: ethX) untagged. ie: I might wish to specify each VLAN on eth0 as tagged (ie: eth0.1, eth0.2, etc) without having eth0 itself to have an IP. This can be done by having "BOOTPROTO=none" and NOT specifying an IPADDRESS=line (and NETMASK, etc) at all. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0001312) dcclayton (reporter) 2014-11-11 03:45 |
Would it be sensible to consider the option of 'disabled' as well - meaning that settings can be configured, but are rendered inactive. if so, there would also be the need for an 'enable' toggle. |
(0001313) user2 2014-11-11 08:50 |
There's an "onboot" configuration option available in the underlying engine. There's also the option of taking down or bringing up a network interface on-demand, but the network will pop back up on the next reboot. In theory, we could combine these two behaviors to provide a way to enable/disable an interface. Hmmm. |
Issue History | |||
Date Modified | Username | Field | Change |
2013-05-16 15:11 | user2 | New Issue | |
2013-05-16 15:11 | user2 | Status | new => confirmed |
2013-05-16 18:02 | user2 | Target Version | 6.4.0 Updates => 6.5.0 Beta 1 |
2013-08-20 13:18 | user2 | Target Version | 6.5.0 Beta 1 => 6.5.0 Beta 2 |
2013-10-07 13:51 | user2 | Target Version | 6.5.0 Beta 2 => 6.5.0 Beta 3 |
2013-10-17 12:23 | user2 | Target Version | 6.5.0 Beta 3 => 7.0.0 Alpha 2 |
2014-08-20 16:14 | user2 | Target Version | 7.0.0 Alpha 2 => 7.1.0 Beta 2 |
2014-11-11 03:45 | dcclayton | Note Added: 0001312 | |
2014-11-11 08:50 | user2 | Note Added: 0001313 | |
2015-01-29 13:18 | user2 | Target Version | 7.1.0 Beta 2 => |
2018-10-03 07:45 | user2 | Target Version | => 7.5.0 Updates |
2018-10-10 09:57 | user2 | Status | confirmed => resolved |
2018-10-10 09:57 | user2 | Fixed in Version | => 7.5.0 Updates |
2018-10-10 09:57 | user2 | Resolution | open => fixed |
2018-10-10 09:57 | user2 | Assigned To | => user2 |
2018-10-24 17:58 | user2 | Status | resolved => closed |