LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-02-2020, 03:50 PM   #46
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,530

Rep: Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856

Quote:
Originally Posted by tadgy View Post
Hey - thanks for the follow up

I'm still of the opinion that if the admin wants to use something like wireguard, which modifies the routing tables when it starts, it's either up to that application or the admin to return the system to the state it found it in.

Having rc.inet1 clear user defined tables still seems like interference with things beyond rc.inet1's remit - we can't support every possible configuration that may get set up on the system; rc.inet1 can only support things it sets up itself.

Cheers
I appreciate your optimism and positive thinking Well, this wireguard thingy is trying to gain traction & achieve popularity. You can find articles all over the place about it and the kernel devs already accepted the module code for the 5.5/5.6 kernel series. So it will maybe become the main VPN solution. That's why I took the effort to update this thread. And it's not necessary about supporting every possible configuration, but properly flushing the existing crap and start clean (rc.inet1 down/restart).
https://en.wikipedia.org/wiki/Wireguard

I'm not sure I'll ever use wireguard myself, not very happy with the crypto employed (again that Bernstein stuff all over the place) and wondering why AES is not used, especially now when all the modern CPUs provide HW acceleration. In this respect, wireguard, while trying to be more efficient, looks like a poor man's VPN solution (of course Google & co are happy to employ alternative, resources "cheaper" crypto, they have a lot of encrypted traffic to handle and it's finally users data, not theirs ).
Speaking of security, as with sex, I prefer to stick to the motto: better safe than sorry.
 
1 members found this post helpful.
Old 02-19-2020, 09:30 PM   #47
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 86

Original Poster
Rep: Reputation: 91
Robby has put out a new package with the latest (small) changes in the git tree. It's available from:
http://slackware.com/~rworkman/netwo...arch-1_rlw.txz

The only changes since the last package are syntax changes to stop shellcheck being grumpy, and some examples added to the .conf file.

Unless people come up with some bugs or issues, this should be the version that goes off to Pat (hopefully) shortly

Please do test the new package if you have the ability!
 
Old 05-22-2020, 10:05 AM   #48
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,705

Rep: Reputation: Disabled
I've looked briefly at rc.inet1 and the sample rc.inet1.conf, and I have some questions/comments.
  1. Do we still need a MAXNICS parameter? Surely rc.inet1 should be able to figure out the number of configured interfaces on the fly? (And now that 802.1Q and 802.1ad are a thing, the comment about sending an image of any box with more than 6 NICs hasn't really aged well.)

  2. The DHCP timeout in rc.inet1 has been changed from 30 seconds to 15. Surely this will fail on any host connected to a switch running the original Spanning-Tree protocol using the default Forward Delay?

  3. From what I can see, rc.inet1 treats IPv6 SLAAC and DHCP6 as mutually exclusive, when in fact they are not. SLAAC is usually combined with stateless DHCP to obtain parameters such as DNS servers, time servers and so on.

  4. An IPALIASES variable has been introduced in rc.inet1.conf, but the concept of having a "primary address" and then a number of "aliases" has long since been abandoned. Why not have an IPADDRS variable with space-delimited addresses in CIDR format (just like IP6ADDRS), and have rc.inet1 add the address specified by $IPADDR for backwards compatibility?

  5. rc.inet1 attempts to handle relatively advanced setups like LAGs (teaming/bonding) and VLAN subinterfaces, but it seems to assume that an IP address should always be directly assigned to such interfaces. If you're running a hypervisor, both these interface types are usually added to bridges. In fact, a bridge with a VLAN interface member that references a LAG is not at all uncommon.

    How about handling complex interfaces types like LAGs (which have a considerable number of configuration settings) in a similar fashion to virtual L3 interfaces, and have rc.inet1 create them before any IP configuration is performed?

Last edited by Ser Olmy; 05-22-2020 at 10:06 AM.
 
2 members found this post helpful.
Old 05-22-2020, 02:27 PM   #49
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 86

Original Poster
Rep: Reputation: 91
Quote:
Originally Posted by Ser Olmy View Post
Do we still need a MAXNICS parameter? Surely rc.inet1 should be able to figure out the number of configured interfaces on the fly? (And now that 802.1Q and 802.1ad are a thing, the comment about sending an image of any box with more than 6 NICs hasn't really aged well.)
The MAXNICS setting is required as there is no (easy) way to determine the highest indices used of a group of arrays in bash, and there is no way to know whether there are 'holes' in the array assignments - bash arrays do not have to be assigned consecutively, so there may be jump between, the first interface defined as index 1, and the second at index 6.

The MAXNICS parameter is just an ugly solution to these, and other, problems. Robby and I agreed that this was the least ugly solution for the moment.

The comment is a throwback to the original rc.inet1, and since it's in code that most end users will never look at, it's not going to hurt

Quote:
Originally Posted by Ser Olmy View Post
The DHCP timeout in rc.inet1 has been changed from 30 seconds to 15. Surely this will fail on any host connected to a switch running the original Spanning-Tree protocol using the default Forward Delay?
I can't speak to STP as I'm not a networking expert, but doesn't it relate to switch->switch configurations, not switch->host?

The timeout was reduced to stop people moaning about slow boot times when their DHCP server did not respond quickly enough. For the most part, this default timeout is going to be appropriate for the vast majority of end users. It can always be increased with the DHCP_TIMEOUT parameter for the interface if a longer timeout is required. It's a trade off, and I think we've found the mid-ground.

Quote:
Originally Posted by Ser Olmy View Post
From what I can see, rc.inet1 treats IPv6 SLAAC and DHCP6 as mutually exclusive, when in fact they are not. SLAAC is usually combined with stateless DHCP to obtain parameters such as DNS servers, time servers and so on.
You are correct in that SLAAC and DHCP6 are very intermixed, and indeed dhcpcd can configure interfaces with SLAAC if the DHCP call fails. However, if you are using a pure SLAAC network, there is no need to burden the boot process with a DHCP timeout wait when SLAAC can be auto-configured by the kernel directly.

If people are unaware if their network uses SLAAC or DHCP6, they should configure with DHCP6, and let dhcpcd handle SLAAC configuration if it needs to.

Quote:
Originally Posted by Ser Olmy View Post
An IPALIASES variable has been introduced in rc.inet1.conf, but the concept of having a "primary address" and then a number of "aliases" has long since been abandoned. Why not have an IPADDRS variable with space-delimited addresses in CIDR format (just like IP6ADDRS), and have rc.inet1 add the address specified by $IPADDR for backwards compatibility?
The IPALIASES parameter was NOT introduced in this version of the rc.inet1 script - this is a throwback to the original versions of rc.inet1 and retained for backwards compatibility. This means that rc.inet1.conf files from previous versions of rc.inet1 can be used without modification in the new rc.inet1 - this was an important requirement.

Quote:
Originally Posted by Ser Olmy View Post
rc.inet1 attempts to handle relatively advanced setups like LAGs (teaming/bonding) and VLAN subinterfaces, but it seems to assume that an IP address should always be directly assigned to such interfaces. If you're running a hypervisor, both these interface types are usually added to bridges. In fact, a bridge with a VLAN interface member that references a LAG is not at all uncommon.
You do not need to assign IP addresses to interfaces to have them configured - you can omit the IPADDR/IP6ADDRS parameters and rc.inet1 will still do the correct thing with bringing up interfaces.

Thanks for the input
 
1 members found this post helpful.
Old 05-22-2020, 10:04 PM   #50
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,705

Rep: Reputation: Disabled
Quote:
Originally Posted by tadgy View Post
The MAXNICS setting is required as there is no (easy) way to determine the highest indices used of a group of arrays in bash, and there is no way to know whether there are 'holes' in the array assignments
How about:
Code:
#!/bin/bash

IPADDRS[0]="192.168.16.1/24 10.10.128.97/28"
IPADDRS[1]="10.0.0.1/24"
IPADDRS[1970]="1.2.3.4/8"

for index in ${!IPADDRS[@]}; do
  # call relevant subroutines
done
The only real issue is that at least one specific variable must be set for all relevant interfaces for this to work. Well, we could just mash together the indices of several variables (if an interface doesn't have an IP address, it must have some other parameter set or rc.inet1 might as well skip it) and loop through the results filtered through sort and uniq.
Quote:
Originally Posted by tadgy View Post
I can't speak to STP as I'm not a networking expert, but doesn't it relate to switch->switch configurations, not switch->host?
A switch cannot know in advance whether a device that just activated its interface is a host or another switch. Unless the switch has been manually configured with a lower Forward Delay or the specific port has been configured as a "portfast"/"edge" port, there will be a 30 second delay before the port starts forwarding traffic.

There are still quite a few switches out there that runs the original 802.1D spanning-tree protocol, but I guess users with such switches could be expected to manually set the DHCP_TIMEOUT parameter.
Quote:
Originally Posted by tadgy View Post
You are correct in that SLAAC and DHCP6 are very intermixed, and indeed dhcpcd can configure interfaces with SLAAC if the DHCP call fails. However, if you are using a pure SLAAC network, there is no need to burden the boot process with a DHCP timeout wait when SLAAC can be auto-configured by the kernel directly.
If a client uses just SLAAC on an IPv6-only network, it won't be able to access a DNS server. There really should be a way to specify SLAAC + stateless DHCP.

In fact, there is no need to treat static address configuration and DHCP as mutually exclusive for either IPv4 or IPv6.
Quote:
Originally Posted by tadgy View Post
The IPALIASES parameter was NOT introduced in this version of the rc.inet1 script - this is a throwback to the original versions of rc.inet1 and retained for backwards compatibility.
My mistake.

In that case, I'd like to nominate IPADDR and IPALIASES for deprecation, which means we change netconfig and add some text in rc.inet1.conf to inform users of this fact, while we also keep supporting both parameters in rc.inet1 indefinitely.

It's the Slackware way, and it's really the only way.
 
Old 05-23-2020, 12:08 AM   #51
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 86

Original Poster
Rep: Reputation: 91
Quote:
Originally Posted by Ser Olmy View Post
How about:
Code:
#!/bin/bash

IPADDRS[0]="192.168.16.1/24 10.10.128.97/28"
IPADDRS[1]="10.0.0.1/24"
IPADDRS[1970]="1.2.3.4/8"

for index in ${!IPADDRS[@]}; do
  # call relevant subroutines
done
The only real issue is that at least one specific variable must be set for all relevant interfaces for this to work. Well, we could just mash together the indices of several variables (if an interface doesn't have an IP address, it must have some other parameter set or rc.inet1 might as well skip it) and loop through the results filtered through sort and uniq.
The problem, as you say, is the "mashing up" of all the variables in order to get the indices actually being used - it's VERY hacky. You'd have to put virtually every parameter into the mash up in order to make sure you do get the index of every parameter that may be set - especially since, as I pointed out previously, there doesn't have to be an IP address defined for an interface to be configured. You'd end up having to mash up IPADDR, IP6ADDRS, BRNICS, BONDNICS, etc etc.

I'm happy to have the discussion with Robby, but I can't see him going for this as a solution, when you can just set MAXNICS to a higher value if you know you're going to configure more interfaces (and it's doubtful the vast majority of Slackware users would use >6 interface configurations).

Quote:
Originally Posted by Ser Olmy View Post
If a client uses just SLAAC on an IPv6-only network, it won't be able to access a DNS server. There really should be a way to specify SLAAC + stateless DHCP.
netconfig still prompts you for a DNS server when you select to configure with SLAAC, so you'd be expected to configure your network with known values just as you would for a statically defined one. SLAAC is only used for the automatic provisioning of IP addresses - DHCP6 is used for the automatic configuration of all network parameters.

Assuming that setting the network set up type to DHCP6 doesn't get you SLAAC + stateless DHCP (I really don't know, it wasn't part of my testing), we are in the unfortunate position of being unable to code for every network configuration out there. The most common network configurations with IPv6 are a) SLAAC+RA+static DNS, b) DHCP6 automatic configuration and c) full IPv6 static configuration.

Quote:
Originally Posted by Ser Olmy View Post
In that case, I'd like to nominate IPADDR and IPALIASES for deprecation, which means we change netconfig and add some text in rc.inet1.conf to inform users of this fact, while we also keep supporting both parameters in rc.inet1 indefinitely.
This is certainly something that is possible, but not my call
The deprecation of backwards compatible configuration would have to be made by Robby or Pat. I certainly see your rationale, and do somewhat agree with it - I can bring it up in a discussion with Robby and see what he thinks.

Cheers.
 
Old 05-25-2020, 03:04 PM   #52
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 86

Original Poster
Rep: Reputation: 91
Quote:
Originally Posted by tadgy View Post
TI'm happy to have the discussion with Robby, but I can't see him going for this as a solution, when you can just set MAXNICS to a higher value if you know you're going to configure more interfaces (and it's doubtful the vast majority of Slackware users would use >6 interface configurations).
I've had a chat with Robby and we've agreed that, while MAXNICS is a hack and we don't like it, any other solution would be even more messy.

Most people will never need to touch MAXNICS as they are never likely to use that number of interfaces on the 'usual' Slackware host. Nevertheless, MAXNICS is commented in rc.inet1.conf as to when it should be used, and I (rightly or wrongly) credit the average Slackware administrator with the ability to figure out when to use it

Quote:
Originally Posted by tadgy View Post
The deprecation of backwards compatible configuration would have to be made by Robby or Pat. I certainly see your rationale, and do somewhat agree with it - I can bring it up in a discussion with Robby and see what he thinks.
Robby and I feel that trying to get this kind of change into Slackware 15 along with all the proposed changes to rc.inet1 for bonding and ipv6, etc. will be a step too far for Pat to accept.

Cheers
 
  


Reply

Tags
bond, ipv6, networking, rc.inet1, slackware, testing, vlan


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] slackware current, typo in new rc.inet1, also is gtk3 now required for firefox? pataphysician Slackware 23 05-24-2017 01:48 AM
Modifications to rc.inet1, rc.inet1.conf and rc.wireless hba Slackware 1 12-07-2014 03:57 AM
Error for wireless request "Set Nickname" (8B1C) -- /etc/rc.d/rc.inet1.conf hellbillyJoker Linux - Networking 1 04-06-2010 07:24 PM
rc.inet1 doesn't give me a new DHCP IP jsmith6 Slackware 3 03-10-2008 04:38 PM
rc.inet1 and rc.inet1.conf edafe Slackware 0 02-16-2005 09:51 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:16 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration