[pve-devel] [PATCH common 1/2] fix #2831: never set bridge_fd to 0 with STP on

[pve-devel] [PATCH common 1/2] fix #2831: never set bridge_fd to 0 with STP on

[Fabian Grünbichler]

it's an invalid combination that causes the network reload/setup to
fail. unfortunately, this is not caught by ifupdown2 itself, but only
rejected by the kernel with ERANGE over netlink.

Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
---

Notes:
    these range checks are there in the kernel since 2011..

 src/PVE/INotify.pm | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 8cf4b44..4f682be 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -1061,13 +1061,12 @@ sub __read_etc_network_interfaces {
 	} elsif ($iface =~ m/^vmbr\d+$/) {
 	    if (!$d->{ovs_type}) {
 		$d->{type} = 'bridge';
-
-		if (!defined ($d->{bridge_fd})) {
-		    $d->{bridge_fd} = 0;
-		}
 		if (!defined ($d->{bridge_stp})) {
 		    $d->{bridge_stp} = 'off';
 		}
+		if (!defined($d->{bridge_fd}) && $d->{bridge_stp} eq 'off') {
+		    $d->{bridge_fd} = 0;
+		}
 	    } elsif ($d->{ovs_type} eq 'OVSBridge') {
 		$d->{type} = $d->{ovs_type};
 	    }
@@ -1259,11 +1258,16 @@ sub __interface_to_string {
 	$done->{bridge_ports} = 1;
 
 	my $v = defined($d->{bridge_stp}) ? $d->{bridge_stp} : 'off';
+	my $no_stp = $v eq 'off';
+
 	$raw .= "\tbridge-stp $v\n";
 	$done->{bridge_stp} = 1;
 
 	$v = defined($d->{bridge_fd}) ? $d->{bridge_fd} : 0;
-	$raw .= "\tbridge-fd $v\n";
+	# 0 is only allowed when STP is disabled
+	if ($v || $no_stp) {
+	    $raw .= "\tbridge-fd $v\n";
+	}
 	$done->{bridge_fd} = 1;
 
 	if( defined($d->{bridge_vlan_aware})) {
-- 
2.30.2

[pve-devel] [PATCH common 2/2] interfaces: improve bridge_fd handling

[Fabian Grünbichler]

and ignore values with a warning that are outside of the kernels
expected range.

Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
---
 src/PVE/INotify.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 4f682be..ad45cd2 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -1265,8 +1265,10 @@ sub __interface_to_string {
 
 	$v = defined($d->{bridge_fd}) ? $d->{bridge_fd} : 0;
 	# 0 is only allowed when STP is disabled
-	if ($v || $no_stp) {
+	if ($no_stp || ($v >= 2 && $v <= 30)) {
 	    $raw .= "\tbridge-fd $v\n";
+	} else {
+	    warn "'$iface': not setting 'bridge_fd' to value '$v' outside of allowed range 2-30\n";
 	}
 	$done->{bridge_fd} = 1;
 
-- 
2.30.2

[pve-devel] applied: [PATCH common 1/2] fix #2831: never set bridge_fd to 0 with STP on

[Thomas Lamprecht]

On 16.07.21 09:40, Fabian Grünbichler wrote:
> it's an invalid combination that causes the network reload/setup to
> fail. unfortunately, this is not caught by ifupdown2 itself, but only
> rejected by the kernel with ERANGE over netlink.
> 
> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> ---
> 
> Notes:
>     these range checks are there in the kernel since 2011..
> 
>  src/PVE/INotify.pm | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
>

applied, thanks!

Re: [pve-devel] [PATCH common 2/2] interfaces: improve bridge_fd handling

[Thomas Lamprecht]

On 16.07.21 09:40, Fabian Grünbichler wrote:
> and ignore values with a warning that are outside of the kernels
> expected range.
> 
> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> ---
>  src/PVE/INotify.pm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

applied, but ..

> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
> index 4f682be..ad45cd2 100644
> --- a/src/PVE/INotify.pm
> +++ b/src/PVE/INotify.pm
> @@ -1265,8 +1265,10 @@ sub __interface_to_string {
>  
>  	$v = defined($d->{bridge_fd}) ? $d->{bridge_fd} : 0;
>  	# 0 is only allowed when STP is disabled
> -	if ($v || $no_stp) {
> +	if ($no_stp || ($v >= 2 && $v <= 30)) {
>  	    $raw .= "\tbridge-fd $v\n";
> +	} else {
> +	    warn "'$iface': not setting 'bridge_fd' to value '$v' outside of allowed range 2-30\n";

this warns now also for the case when the user did not configured it at all
but *we* fell back to `0`.

I made two followups, one cleanup in general (independent of the changes in
this series) and one for above.

>  	}
>  	$done->{bridge_fd} = 1;
>  
>