Request for testing: new rc.inet1

Nobby6 · 03-04-2021, 01:49 AM

Quote:

Originally Posted by Nobby6

#

scrap this, wrong thread

tadgy · 03-04-2021, 05:37 AM

Quote:

Originally Posted by Nobby6

So the latest official network scripts differ eh?
The conf file does not include ipaliases

You can still use the IPALIASES[x]="" option if you so wish, but it's mostly deprecated now the IPADDRS[x]="" option takes a list of addresses which are applied to the interface.

Just set IPADDRS[x]="" to whatever primary and alias addresses (space delimited) and it'll work fine.

Quote:

Originally Posted by Nobby6

I've worked around it but I gotta say the new man page needs to be re written with clearer examples - especial if its no longer 100% fully backward compatible

The scripts are 100% backwards compatible - that was one of the major aims of them, so that people's rc.inet1.conf files can be used without modification.

The rc.inet1.conf man page is littered with examples; I'm not sure why there is an issue with it?

tadgy · 03-04-2021, 05:42 AM

Quote:

Originally Posted by Nobby6

Stopping the network interfaces...
Starting the network interfaces...
Error: inet6 prefix is expected rather than "2001:xxxx:xxxx:xxxx:2/64".

the ipv6 address entry is as per man page

# IPv6 config options for eth0:
IP6ADDRS[0]="2001:xxxx:xxxx:xxxx:2/64"
#

I've been unable to replicate your issue here.

Please can you give more details as to your network set up and when this error occurs?
Does it appear after any manual tinkering with the network interfaces?

davjohn · 03-04-2021, 01:57 PM

About my previous patches, I'm not sure anymore if this is good idea

Maybe it's better to leave inet1 script as is and who needs can customize IPv6 addresses with sysctl settings.
But I still think privacy extension or stable private addresses should be default.

And IPv6 SLAAC should be handled before IPv4 DHCP, otherwise it takes 5 minutes to get IPv6 address.
At least for me, can anyone else confirm this?

tux_dude · 03-06-2021, 11:27 AM

I am unable to pull IPV6 address with the new rc.inet1 script with USE_SLAAC[0]="yes". If I roll back to the older script, SLAAC address are automatically assigned (which is the default). What's the best place start troubleshooting. Nothing meaningful is shown in message or syslog.

tadgy · 03-06-2021, 01:19 PM

Quote:

Originally Posted by tux_dude

I am unable to pull IPV6 address with the new rc.inet1 script with USE_SLAAC[0]="yes". If I roll back to the older script, SLAAC address are automatically assigned (which is the default). What's the best place start troubleshooting. Nothing meaningful is shown in message or syslog.

My first suggestion would be to add the SLAAC_TIMEOUT[0]="" option to your rc.inet1.conf, and set it to a value greater than 15 (which is the default) to try and see if it's just a slow router announcement causing problems.

Let me know if that solves the problems

davjohn · 03-06-2021, 01:27 PM

Quote:

Originally Posted by tux_dude

I am unable to pull IPV6 address with the new rc.inet1 script with USE_SLAAC[0]="yes". If I roll back to the older script, SLAAC address are automatically assigned (which is the default). What's the best place start troubleshooting. Nothing meaningful is shown in message or syslog.

Could you try patch bellow?
I have similar problem, eventually, IP is assigned but it takes about 5 minutes.

Code:

--- rc.inet1.orig       2021-02-28 22:01:59.000000000 +0100
+++ rc.inet1    2021-03-06 08:00:03.081951586 +0100
@@ -323,6 +323,35 @@
       debug_log "/sbin/ip address flush dev ${1}"
       /sbin/ip address flush dev ${1}
       IF_UP=0
+      if [ -e /proc/sys/net/ipv6 ] && [ "${USE_DHCP6[$i]}" != "yes" ] && [ "${USE_SLAAC[$i]}" = "yes" ]; then # configure via SLAAC
+        info_log "${1}: enabling SLAAC"
+        # Enable accepting of RA packets, unless explicitly configured not to:
+        if [ "${USE_RA[$i]}" = "no" ]; then
+          debug_log "${1}: ignoring IPv6 RA"
+          echo "0" >/proc/sys/net/ipv6/conf/${1}/accept_ra
+        else
+          debug_log "${1}: accepting IPv6 RA"
+          echo "1" >/proc/sys/net/ipv6/conf/${1}/accept_ra
+        fi
+        # Enable auto configuration of interfaces:
+        echo "1" >/proc/sys/net/ipv6/conf/${1}/autoconf
+        # Bring the interface up:
+        debug_log "/sbin/ip link set dev ${1} up"
+        /sbin/ip link set dev ${1} up
+        echo "${1}: waiting for router announcement"
+        for ((j = ${SLAAC_TIMEOUT[$i]:=15} * 2; j--;)); do # by default, wait a max of 15 seconds for the interface to configure
+          /sbin/ip -6 address show dynamic dev ${1} 2>/dev/null | grep -Ewq 'inet6' && { IF_UP=1; break; }
+          sleep 0.5
+        done
+        if ((IF_UP != 1)); then
+          echo "${1}: timed out"
+          info_log "${1}: failed to auto configure after ${SLAAC_TIMEOUT[$i]} seconds"
+          debug_log "/sbin/ip address flush dev ${1}"
+          /sbin/ip address flush dev ${1}
+          debug_log "/sbin/ip link set dev ${1} down"
+          /sbin/ip link set dev ${1} down
+        fi
+      fi
       # Slackware historically favours dynamic configuration over fixed IP to configure interfaces, so keep that tradition:
       if [ "${USE_DHCP[$i]}" = "yes" ] || { [ -e /proc/sys/net/ipv6 ] && [ "${USE_DHCP6[$i]}" = "yes" ]; }; then # use dhcpcd
         info_log "${1}: starting dhcpcd"
@@ -365,35 +394,6 @@
           debug_log "/sbin/ip address flush dev ${1}"
           /sbin/ip address flush dev ${1}
           debug_log "/sbin/ip link set dev ${1} down"
-          /sbin/ip link set dev ${1} down
-        fi
-      fi
-      if [ -e /proc/sys/net/ipv6 ] && [ "${USE_DHCP6[$i]}" != "yes" ] && [ "${USE_SLAAC[$i]}" = "yes" ]; then # configure via SLAAC
-        info_log "${1}: enabling SLAAC"
-        # Enable accepting of RA packets, unless explicitly configured not to:
-        if [ "${USE_RA[$i]}" = "no" ]; then
-          debug_log "${1}: ignoring IPv6 RA"
-          echo "0" >/proc/sys/net/ipv6/conf/${1}/accept_ra
-        else
-          debug_log "${1}: accepting IPv6 RA"
-          echo "1" >/proc/sys/net/ipv6/conf/${1}/accept_ra
-        fi
-        # Enable auto configuration of interfaces:
-        echo "1" >/proc/sys/net/ipv6/conf/${1}/autoconf
-        # Bring the interface up:
-        debug_log "/sbin/ip link set dev ${1} up"
-        /sbin/ip link set dev ${1} up
-        echo "${1}: waiting for router announcement"
-        for ((j = ${SLAAC_TIMEOUT[$i]:=15} * 2; j--;)); do # by default, wait a max of 15 seconds for the interface to configure
-          /sbin/ip -6 address show dynamic dev ${1} 2>/dev/null | grep -Ewq 'inet6' && { IF_UP=1; break; }
-          sleep 0.5
-        done
-        if ((IF_UP != 1)); then
-          echo "${1}: timed out"
-          info_log "${1}: failed to auto configure after ${SLAAC_TIMEOUT[$i]} seconds"
-          debug_log "/sbin/ip address flush dev ${1}"
-          /sbin/ip address flush dev ${1}
-          debug_log "/sbin/ip link set dev ${1} down"
           /sbin/ip link set dev ${1} down
         fi
       fi

tadgy · 03-06-2021, 06:02 PM

Quote:

Originally Posted by davjohn

Could you try patch bellow?
I have similar problem, eventually, IP is assigned but it takes about 5 minutes.

Code:

--- rc.inet1.orig       2021-02-28 22:01:59.000000000 +0100
+++ rc.inet1    2021-03-06 08:00:03.081951586 +0100
@@ -323,6 +323,35 @@
       debug_log "/sbin/ip address flush dev ${1}"
       /sbin/ip address flush dev ${1}
       IF_UP=0
+      if [ -e /proc/sys/net/ipv6 ] && [ "${USE_DHCP6[$i]}" != "yes" ] && [ "${USE_SLAAC[$i]}" = "yes" ]; then # configure via SLAAC
+        info_log "${1}: enabling SLAAC"
+        # Enable accepting of RA packets, unless explicitly configured not to:
+        if [ "${USE_RA[$i]}" = "no" ]; then
+          debug_log "${1}: ignoring IPv6 RA"
+          echo "0" >/proc/sys/net/ipv6/conf/${1}/accept_ra
+        else
+          debug_log "${1}: accepting IPv6 RA"
+          echo "1" >/proc/sys/net/ipv6/conf/${1}/accept_ra
+        fi
+        # Enable auto configuration of interfaces:
+        echo "1" >/proc/sys/net/ipv6/conf/${1}/autoconf
+        # Bring the interface up:
+        debug_log "/sbin/ip link set dev ${1} up"
+        /sbin/ip link set dev ${1} up
+        echo "${1}: waiting for router announcement"
+        for ((j = ${SLAAC_TIMEOUT[$i]:=15} * 2; j--;)); do # by default, wait a max of 15 seconds for the interface to configure
+          /sbin/ip -6 address show dynamic dev ${1} 2>/dev/null | grep -Ewq 'inet6' && { IF_UP=1; break; }
+          sleep 0.5
+        done
+        if ((IF_UP != 1)); then
+          echo "${1}: timed out"
+          info_log "${1}: failed to auto configure after ${SLAAC_TIMEOUT[$i]} seconds"
+          debug_log "/sbin/ip address flush dev ${1}"
+          /sbin/ip address flush dev ${1}
+          debug_log "/sbin/ip link set dev ${1} down"
+          /sbin/ip link set dev ${1} down
+        fi
+      fi
       # Slackware historically favours dynamic configuration over fixed IP to configure interfaces, so keep that tradition:
       if [ "${USE_DHCP[$i]}" = "yes" ] || { [ -e /proc/sys/net/ipv6 ] && [ "${USE_DHCP6[$i]}" = "yes" ]; }; then # use dhcpcd
         info_log "${1}: starting dhcpcd"
@@ -365,35 +394,6 @@
           debug_log "/sbin/ip address flush dev ${1}"
           /sbin/ip address flush dev ${1}
           debug_log "/sbin/ip link set dev ${1} down"
-          /sbin/ip link set dev ${1} down
-        fi
-      fi
-      if [ -e /proc/sys/net/ipv6 ] && [ "${USE_DHCP6[$i]}" != "yes" ] && [ "${USE_SLAAC[$i]}" = "yes" ]; then # configure via SLAAC
-        info_log "${1}: enabling SLAAC"
-        # Enable accepting of RA packets, unless explicitly configured not to:
-        if [ "${USE_RA[$i]}" = "no" ]; then
-          debug_log "${1}: ignoring IPv6 RA"
-          echo "0" >/proc/sys/net/ipv6/conf/${1}/accept_ra
-        else
-          debug_log "${1}: accepting IPv6 RA"
-          echo "1" >/proc/sys/net/ipv6/conf/${1}/accept_ra
-        fi
-        # Enable auto configuration of interfaces:
-        echo "1" >/proc/sys/net/ipv6/conf/${1}/autoconf
-        # Bring the interface up:
-        debug_log "/sbin/ip link set dev ${1} up"
-        /sbin/ip link set dev ${1} up
-        echo "${1}: waiting for router announcement"
-        for ((j = ${SLAAC_TIMEOUT[$i]:=15} * 2; j--;)); do # by default, wait a max of 15 seconds for the interface to configure
-          /sbin/ip -6 address show dynamic dev ${1} 2>/dev/null | grep -Ewq 'inet6' && { IF_UP=1; break; }
-          sleep 0.5
-        done
-        if ((IF_UP != 1)); then
-          echo "${1}: timed out"
-          info_log "${1}: failed to auto configure after ${SLAAC_TIMEOUT[$i]} seconds"
-          debug_log "/sbin/ip address flush dev ${1}"
-          /sbin/ip address flush dev ${1}
-          debug_log "/sbin/ip link set dev ${1} down"
           /sbin/ip link set dev ${1} down
         fi
       fi

I've not forgotten your patches!

I'm going to take a look at them tomorrow in more detail. I can't see the moving of SLAAC being a problem, but just have to mull it over to be sure!

Cheers

tadgy · 03-06-2021, 06:55 PM

Quote:

Originally Posted by davjohn

Code:

<snip>
+        # Enable auto configuration of interfaces:
+        echo "1" >/proc/sys/net/ipv6/conf/${1}/autoconf
+        if [ "${SLAAC_MODE[$i]}" = "eui64" ]; then
+          echo "0" > /proc/sys/net/ipv6/conf/${1}/addr_gen_mode
+        else
+          if [ -n "${IP6SECRET[$i]}" ]; then
+            echo "${IP6SECRET[$i]}" > /proc/sys/net/ipv6/conf/${1}/stable_secret
+            echo "2" > /proc/sys/net/ipv6/conf/${1}/addr_gen_mode
+          else
+            echo "3" > /proc/sys/net/ipv6/conf/${1}/addr_gen_mode
+          fi
+        fi
+        if [ "${USE_PRIVACYEXT[$i]}" = "yes" ]; then
+          echo "2" > /proc/sys/net/ipv6/conf/${1}/use_tempaddr
+        fi

Shouldn't the setting of the secret come before activation of the auto configuration? Same for the setting on privacy extensions?

To me, it makes sense to do those before bringing up the interface with SLAAC - have you tried it that way around? Can you give it a go and let me know?

davjohn · 03-07-2021, 02:02 AM

Quote:

Originally Posted by tadgy

Shouldn't the setting of the secret come before activation of the auto configuration? Same for the setting on privacy extensions?

To me, it makes sense to do those before bringing up the interface with SLAAC - have you tried it that way around? Can you give it a go and let me know?

Yes, activation of auto configuration should be last. Not sure how it ended this way

tadgy · 03-07-2021, 10:55 AM

Quote:

Originally Posted by davjohn

Yes, activation of auto configuration should be last. Not sure how it ended this way

Excellent.

What name and email address do you want added to the log?
Feel free to email me if you prefer not to have it splurged all over the internet! darren (at) slackware (dot) uk

davjohn · 03-07-2021, 12:10 PM

Quote:

Originally Posted by tadgy

Excellent.

What name and email address do you want added to the log?
Feel free to email me if you prefer not to have it splurged all over the internet! darren (at) slackware (dot) uk

You can just use my forum username, if that's ok?

There are some more issues with SLAAC, if bridge is configured.
Because forwarding is enabled for bridge interface, and if forwarding is enabled, Router Advertisements is not accepted, even if accept_ra is 1, it needs to be 2.
So SLAAC doesn't work.
Maybe set accept_ra to 2, if USE_RA[] is set to "yes"?

But, I don't understand how it worked before, it seems something changes if accept_ra and/or autoconf is manually set.

Second is the same problem (if SLAAC is handled after DHCP, interface is already up) that it takes 5 min to get IP (at least for me), because br_open() brings interface (bridge) up.

I don't know how important is this, how many people use bridge in this way. Except me

tadgy · 03-07-2021, 01:21 PM

Quote:

Originally Posted by davjohn

You can just use my forum username, if that's ok?

Not a problem

Quote:

Originally Posted by davjohn

There are some more issues with SLAAC, if bridge is configured.
Because forwarding is enabled for bridge interface, and if forwarding is enabled, Router Advertisements is not accepted, even if accept_ra is 1, it needs to be 2.
So SLAAC doesn't work.
Maybe set accept_ra to 2, if USE_RA[] is set to "yes"?

But, I don't understand how it worked before, it seems something changes if accept_ra and/or autoconf is manually set.

Can you paste your rc.inet1.conf for me (just the relevant bits..)?
Do you mean SLAAC doesn't work on the bridge interface itself, or on one of the interfaces at the other end of the bridge?

Quote:

Originally Posted by davjohn

Second is the same problem (if SLAAC is handled after DHCP, interface is already up) that it takes 5 min to get IP (at least for me), because br_open() brings interface (bridge) up.

Is this fixed by your previous patch to move SLAAC to before DHCP? If so, that's already been addressed as I've added that patch

Quote:

Originally Posted by davjohn

I don't know how important is this, how many people use bridge in this way. Except me

The more issues/bugs we find now, the more stable it'll be come release.

davjohn · 03-07-2021, 01:54 PM

Quote:

Originally Posted by tadgy

Not a problem

Can you paste your rc.inet1.conf for me (just the relevant bits..)?
Do you mean SLAAC doesn't work on the bridge interface itself, or on one of the interfaces at the other end of the bridge?

Code:

IFNAME[1]="br0"
BRNICS[1]="eth0 tap0 tap10 tap11"
IPADDR[1]=""
HWADDR[1]="f4:52:...."
NETMASK[1]=""
IPALIASES[1]=""
USE_DHCP[1]="yes"
DHCP_HOSTNAME[1]=""
MTU[1]="9000"
USE_SLAAC[1]="yes"
IP6SECRET[1]="xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx"
USE_PRIVACYEXT[1]="yes"

Yes SLAAC for bridge interface doesn't work.
As I understand problem is because forwarding is enabled and kernel documentation for accept_ra:

Quote:

Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled.

Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled.

So RA is not accepted if forwarding is enabled, but it's always enabled for bridge interface?
If I change rc.inet1 to set 2 instead of 1: echo "2" >/proc/sys/net/ipv6/conf/${1}/accept_ra
Then it works.

Quote:

Is this fixed by your previous patch to move SLAAC to before DHCP? If so, that's already been addressed as I've added that patch

Yes it's fixed, but not for bridge

Problem is that interface is already up (br_open() brings it up), before SLAAC is enabled (same situation as it's already up by DHCP).
if I comment "/sbin/ip link set dev ${IFNAME[$1]} up", in br_open() then it works.
This shouldn't matter, because if_up() brings it up anyway (or down if it can't get IP).
The only problem I see with this is that some people create bridge without assigning IP in this case interface is then down. So this is probably not a solution.

tadgy · 03-07-2021, 02:18 PM

Quote:

Originally Posted by davjohn

Yes SLAAC for bridge interface doesn't work.
As I understand problem is because forwarding is enabled and kernel documentation for accept_ra:
...
So RA is not accepted if forwarding is enabled, but it's always enabled for bridge interface?
If I change rc.inet1 to set 2 instead of 1: echo "2" >/proc/sys/net/ipv6/conf/${1}/accept_ra
Then it works.

My only concern regarding making it '2' by default is whether this affects the ability of interfaces at the end of the bridge from getting IP addresses via SLAAC. Do any of your interfaces at the end of the bridge have any trouble getting their addresses?

Sorry for the questions but I don't currently have SLAAC enabled on my router to test

Quote:

Originally Posted by davjohn

Yes it's fixed, but not for bridge

Problem is that interface is already up (br_open() brings it up), before SLAAC is enabled (same situation as it's already up by DHCP).
if I comment "/sbin/ip link set dev ${IFNAME[$1]} up", in br_open() then it works.
This shouldn't matter, because if_up() brings it up anyway (or down if it can't get IP).
The only problem I see with this is that some people create bridge without assigning IP in this case interface is then down. So this is probably not a solution.

This is exactly the argument I was going to make as I read your reply.

I've got an idea though - how about we check whether IPADDRS/IP6ADDRS/IPADDR is set for that interface, and if so not bring up the bridge at that point because it'll be done later?
That way, if someone doesn't want the bridge itself to have an IP, it'll still be put into the up state.

Edit: Thinking about it more, we'd have to check for /every/ way an IP address could be set... so it would be IPADDRS/IP6ADDRS/IPADDR/DHCP/DHCP6/SLAAC ...