| 2022-04-21 06:48:22 |
Ernst Sjöstrand |
bug |
|
|
added bug |
| 2022-04-21 06:48:50 |
Ernst Sjöstrand |
bug watch added |
|
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/63 |
|
| 2022-04-21 06:48:50 |
Ernst Sjöstrand |
bug task added |
|
network-manager-openconnect |
|
| 2022-05-03 00:45:35 |
Launchpad Janitor |
network-manager-openconnect (Ubuntu): status |
New |
Confirmed |
|
| 2022-05-03 00:47:19 |
pd5rm |
bug |
|
|
added subscriber pd5rm |
| 2022-05-03 06:30:24 |
dwmw2 |
bug task added |
|
openconnect (Ubuntu) |
|
| 2022-05-20 16:07:23 |
Bug Watch Updater |
network-manager-openconnect: status |
Unknown |
Fix Released |
|
| 2022-05-27 11:53:09 |
Launchpad Janitor |
openconnect (Ubuntu): status |
New |
Confirmed |
|
| 2022-05-30 12:53:12 |
Elfranne |
bug |
|
|
added subscriber Elfranne |
| 2022-06-09 08:54:24 |
Ernst Sjöstrand |
description |
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options." |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit. |
|
| 2022-06-09 08:57:38 |
Ernst Sjöstrand |
attachment added |
|
openconnect_8.20-1_8.20-1ubuntu1.diff.gz https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1969734/+attachment/5595818/+files/openconnect_8.20-1_8.20-1ubuntu1.diff.gz |
|
| 2022-06-09 09:10:29 |
Ernst Sjöstrand |
attachment added |
|
openconnect_8.20-1_8.20-1ubuntu1.diff.gz https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1969734/+attachment/5595819/+files/openconnect_8.20-1_8.20-1ubuntu1.diff.gz |
|
| 2022-06-09 09:37:39 |
Ernst Sjöstrand |
attachment removed |
openconnect_8.20-1_8.20-1ubuntu1.diff.gz https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1969734/+attachment/5595818/+files/openconnect_8.20-1_8.20-1ubuntu1.diff.gz |
|
|
| 2022-06-09 09:38:23 |
Ernst Sjöstrand |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit. |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 1.2.6:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit. |
|
| 2022-06-09 09:45:57 |
Ernst Sjöstrand |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 1.2.6:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit. |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
* Users with a common GlobalProtect serverside configuration will not be able
to connect.
* This is caused by an backwards incompatible change in openconnect between
openconnect and network-manager-openconnect
* The debdiff fixes it by reverting the backwards incompatible change.
[Test Plan]
* You need a GlobalProtect server to test it, so perhaps we can collect reports
from affected users.
* This follows upstreams fixes only.
[Where problems could occur]
* WIP
[Other Info]
* WIP |
|
| 2022-06-09 09:48:25 |
Ernst Sjöstrand |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
* Users with a common GlobalProtect serverside configuration will not be able
to connect.
* This is caused by an backwards incompatible change in openconnect between
openconnect and network-manager-openconnect
* The debdiff fixes it by reverting the backwards incompatible change.
[Test Plan]
* You need a GlobalProtect server to test it, so perhaps we can collect reports
from affected users.
* This follows upstreams fixes only.
[Where problems could occur]
* WIP
[Other Info]
* WIP |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
* Users with a common GlobalProtect serverside configuration will not be able
to connect.
* This is caused by an backwards incompatible change in openconnect between
openconnect and network-manager-openconnect
* The debdiff fixes it by reverting the backwards incompatible change.
[Test Plan]
* You need a GlobalProtect server to test it, so perhaps we can collect reports
from affected users.
* This follows upstreams fixes only.
[Where problems could occur]
* WIP
[Other Info]
* There is no Debian release with this combination of versions so we
can't import the fix from there.
* WIP |
|
| 2022-06-09 10:50:30 |
Ernst Sjöstrand |
openconnect (Ubuntu): status |
Confirmed |
In Progress |
|
| 2022-06-10 08:10:11 |
Ernst Sjöstrand |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2022-06-21 22:31:55 |
Reuben Castelino |
bug |
|
|
added subscriber Reuben Castelino |
| 2022-07-12 04:05:50 |
Ernst Sjöstrand |
bug |
|
|
added subscriber MOTU |
| 2022-07-25 10:23:59 |
Juha Vainikka |
bug |
|
|
added subscriber Juha Vainikka |
| 2022-08-01 15:07:43 |
Luís Infante da Câmara |
attachment added |
|
openconnect_8.20-1_8.20-1ubuntu1.debdiff https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1969734/+attachment/5606291/+files/openconnect_8.20-1_8.20-1ubuntu1.debdiff |
|
| 2022-08-01 15:37:56 |
Luís Infante da Câmara |
openconnect (Ubuntu): status |
In Progress |
New |
|
| 2022-08-01 15:40:27 |
Luís Infante da Câmara |
network-manager-openconnect (Ubuntu): status |
Confirmed |
Invalid |
|
| 2022-08-01 15:40:39 |
Luís Infante da Câmara |
network-manager-openconnect (Ubuntu): status |
Invalid |
Confirmed |
|
| 2022-08-01 15:47:43 |
Steve Langasek |
network-manager-openconnect (Ubuntu): importance |
Undecided |
High |
|
| 2022-08-01 15:49:35 |
Luís Infante da Câmara |
bug |
|
|
added subscriber Luís Cunha dos Reis Infante da Câmara |
| 2022-08-02 08:08:49 |
Łukasz Zemczak |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-08-02 08:08:49 |
Łukasz Zemczak |
bug task added |
|
openconnect (Ubuntu Jammy) |
|
| 2022-08-02 08:08:49 |
Łukasz Zemczak |
bug task added |
|
network-manager-openconnect (Ubuntu Jammy) |
|
| 2022-08-02 08:09:40 |
Łukasz Zemczak |
openconnect (Ubuntu): status |
New |
Fix Released |
|
| 2022-08-02 08:09:43 |
Łukasz Zemczak |
openconnect (Ubuntu Jammy): status |
New |
Incomplete |
|
| 2022-08-05 21:01:29 |
Luís Infante da Câmara |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
* Users with a common GlobalProtect serverside configuration will not be able
to connect.
* This is caused by an backwards incompatible change in openconnect between
openconnect and network-manager-openconnect
* The debdiff fixes it by reverting the backwards incompatible change.
[Test Plan]
* You need a GlobalProtect server to test it, so perhaps we can collect reports
from affected users.
* This follows upstreams fixes only.
[Where problems could occur]
* WIP
[Other Info]
* There is no Debian release with this combination of versions so we
can't import the fix from there.
* WIP |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
* This is caused by an backwards incompatible change in openconnect between
openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
* The debdiff fixes it by reverting the backwards incompatible change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
|
| 2022-08-05 21:01:54 |
Luís Infante da Câmara |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
* This is caused by an backwards incompatible change in openconnect between
openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
* The debdiff fixes it by reverting the backwards incompatible change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
This is caused by an backwards incompatible change in openconnect between openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
The debdiff fixes it by reverting this change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
|
| 2022-08-05 21:41:01 |
Brian Murray |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2022-08-06 09:01:03 |
Luís Infante da Câmara |
openconnect (Ubuntu Jammy): status |
Incomplete |
Confirmed |
|
| 2022-08-09 12:51:34 |
Luís Infante da Câmara |
openconnect (Ubuntu Jammy): status |
Confirmed |
In Progress |
|
| 2022-08-09 12:51:37 |
Luís Infante da Câmara |
network-manager-openconnect (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2022-08-12 06:32:58 |
Ernst Sjöstrand |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=2094338 |
|
| 2022-08-12 06:32:58 |
Ernst Sjöstrand |
bug task added |
|
fedora |
|
| 2022-08-19 23:28:29 |
Steve Langasek |
openconnect (Ubuntu Jammy): status |
In Progress |
Incomplete |
|
| 2022-08-26 09:05:14 |
Gundy |
bug |
|
|
added subscriber Gundy |
| 2023-03-22 21:51:57 |
Lucas Campa |
bug |
|
|
added subscriber Lucas Campa |
| 2023-05-12 08:01:42 |
Ubay Dorta Guerra |
bug |
|
|
added subscriber Ubay Dorta Guerra |
| 2023-05-31 11:39:30 |
Bug Watch Updater |
fedora: status |
Unknown |
Won't Fix |
|
| 2023-05-31 11:39:30 |
Bug Watch Updater |
fedora: importance |
Unknown |
High |
|
| 2023-05-31 12:18:20 |
Ubuntu Foundations Team Bug Bot |
tags |
jammy |
jammy patch |
|
| 2023-05-31 12:18:26 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors |
| 2023-06-05 17:18:29 |
Steve Langasek |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2023-09-01 11:31:58 |
Luís Infante da Câmara |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
This is caused by an backwards incompatible change in openconnect between openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
The debdiff fixes it by reverting this change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
This is caused by an backwards incompatible change in openconnect between openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
The debdiff fixes it by reverting this change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change. However, this is extremely unlikely as the feature was introduced in the Ubuntu archive on 21 February 2022, that is only 3 days before Debian Import Freeze for Ubuntu 22.04 (24 February 2022).
It is also possible that third-party software (outside of the Ubuntu archive) depends on the feature. However, the feature only affects GlobalProtect VPNs with the common server-side configuration mentioned above, where NetworkManager-openconnect is unusable due to the feature, and was reverted shortly thereafter in release 9.01, released on 29 April. Therefore, it is unlikely that such software is using the feature, even if the software in question is a workaround for this bug.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
|
| 2023-09-01 11:32:02 |
Luís Infante da Câmara |
openconnect (Ubuntu Jammy): status |
Incomplete |
Confirmed |
|
| 2023-09-01 18:33:04 |
Luís Infante da Câmara |
network-manager-openconnect (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2023-09-01 18:33:55 |
Luís Infante da Câmara |
bug |
|
|
added subscriber Ubuntu Sponsors |
| 2023-09-05 14:23:49 |
Lukas Märdian |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2023-09-05 15:43:06 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Lukas Märdian |
| 2023-09-07 13:45:44 |
Robie Basak |
openconnect (Ubuntu Jammy): status |
Confirmed |
Incomplete |
|
| 2023-09-08 09:23:05 |
Luís Infante da Câmara |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
This is caused by an backwards incompatible change in openconnect between openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
The debdiff fixes it by reverting this change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change. However, this is extremely unlikely as the feature was introduced in the Ubuntu archive on 21 February 2022, that is only 3 days before Debian Import Freeze for Ubuntu 22.04 (24 February 2022).
It is also possible that third-party software (outside of the Ubuntu archive) depends on the feature. However, the feature only affects GlobalProtect VPNs with the common server-side configuration mentioned above, where NetworkManager-openconnect is unusable due to the feature, and was reverted shortly thereafter in release 9.01, released on 29 April. Therefore, it is unlikely that such software is using the feature, even if the software in question is a workaround for this bug.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
This is caused by an backwards incompatible change in openconnect between openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
The debdiff fixes it by reverting this change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change. However, this is extremely unlikely as the feature was introduced in the Ubuntu archive on 21 February 2022, that is only 3 days before Debian Import Freeze for Ubuntu 22.04 (24 February 2022).
It is also possible that third-party software (outside of the Ubuntu archive) depends on the feature. However, the feature only affects GlobalProtect VPNs with the common server-side configuration mentioned above, where NetworkManager-openconnect is unusable due to the feature, and was reverted shortly thereafter in release 9.01, released on 29 April. Therefore, it is unlikely that such software is using the feature, even if the software in question is a workaround for this bug.
It is also possible that users have configured their systems in a way that depends on this feature. However, this is extremely unlikely.
Several users have commented on this bug that they can connect to GlobalProtect VPNs with this common server-side configuration using openconnect directly or connman, and they are not relying on the feature. The only way that I see that a workaround could use the feature is to detect if the feature is present, to check if the workaround is needed.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
|
| 2023-09-08 09:23:13 |
Luís Infante da Câmara |
openconnect (Ubuntu Jammy): status |
Incomplete |
Confirmed |
|
| 2023-09-08 09:33:21 |
Luís Infante da Câmara |
description |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
This is caused by an backwards incompatible change in openconnect between openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
The debdiff fixes it by reverting this change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change. However, this is extremely unlikely as the feature was introduced in the Ubuntu archive on 21 February 2022, that is only 3 days before Debian Import Freeze for Ubuntu 22.04 (24 February 2022).
It is also possible that third-party software (outside of the Ubuntu archive) depends on the feature. However, the feature only affects GlobalProtect VPNs with the common server-side configuration mentioned above, where NetworkManager-openconnect is unusable due to the feature, and was reverted shortly thereafter in release 9.01, released on 29 April. Therefore, it is unlikely that such software is using the feature, even if the software in question is a workaround for this bug.
It is also possible that users have configured their systems in a way that depends on this feature. However, this is extremely unlikely.
Several users have commented on this bug that they can connect to GlobalProtect VPNs with this common server-side configuration using openconnect directly or connman, and they are not relying on the feature. The only way that I see that a workaround could use the feature is to detect if the feature is present, to check if the workaround is needed.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
This bug only affects the specific combination of network-manager-openconnect and openconnect that ended up in Jammy.
openconnect 8.20 breaks compatibility with NetworkManager-openconnect 8.20:
"As of openconnect 8.20, INTERNAL_IPx_NETMASK can be set to 0.0.0.0 and
/0 and this causes network manager to fail with a bad IP configuration.
This happens because 0.0.0.0/0 is set as a split route, but rewritten to
be used as netmask instead.
If we detect this we force a /32 or /128 (IPv6) netmask prefix and avoid
setting the CONFIG_NEVER_DEFAULT options."
This commit was reverted because the upstream devs intention is to always be backwards compatible. Later the feature was implemented again in another way.
So the best way forward for Jammy is to revert the openconnect commit.
Working on making an SRU from this...
[Impact]
Users with a common GlobalProtect serverside configuration will not be able to connect.
This is caused by an backwards incompatible change in openconnect between openconnect and network-manager-openconnect, that adds the ability for NetworkManager to override the server-provided configuration for split VPN.
The debdiff fixes it by reverting this change.
[Test Plan]
A GlobalProtect server is needed to test it, so perhaps we can collect reports from affected users.
This follows upstream fixes only.
[Where problems could occur]
Other packages in the Ubuntu archive can depend on the feature, potentially causing regressions, or have other regressions due to the change. However, this is extremely unlikely as the feature was introduced in the Ubuntu archive on 21 February 2022, that is only 3 days before Debian Import Freeze for Ubuntu 22.04 (24 February 2022).
It is also possible that third-party software (outside of the Ubuntu archive) depends on the feature. However, the feature only affects GlobalProtect VPNs with the common server-side configuration mentioned above, where NetworkManager-openconnect is unusable due to the feature, and was reverted shortly thereafter in release 9.01, released on 29 April. Therefore, it is unlikely that such software is using the feature, even if the software in question is a workaround for this bug.
It is also possible that users have configured their systems in a way that depends on this feature. However, this is extremely unlikely.
Several users have commented on this bug that they can connect to GlobalProtect VPNs with this common server-side configuration using openconnect directly, and they are not relying on the feature. The only way that I see that a workaround could use the feature is to detect if the feature is present, to check if the workaround is needed.
[Other Info]
There is no Debian release with this combination of versions so we can't import the fix from there. |
|
