NetworkManager issueshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues2024-03-28T08:21:08Zhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1505Feature Wish: NCP-Secure-Entry-Client VPN-Plugin2024-03-28T08:21:08ZHilkopterBobFeature Wish: NCP-Secure-Entry-Client VPN-Plugin## Description of the feature
A Network-Manager Plugin that supports the NCP-Secure-Entry-Client.
## Description of the use cases
The company I work for uses the NCP Secure Entry Client for Windows as a VPN solution. However, this sof...## Description of the feature
A Network-Manager Plugin that supports the NCP-Secure-Entry-Client.
## Description of the use cases
The company I work for uses the NCP Secure Entry Client for Windows as a VPN solution. However, this software is not only closed-source proprietary but also costs around $1000 USD per year per user. Currently, I work as a sysadmin from a Linux workstation and want to implement Linux step by step into our ecosystem. This process, however, is significantly hindered by the fact that I do not have the ability to access the company network externally via VPN.
## References and other resources
[NCP-Download](https://www.ncp-e.com/de/service/download-vpn-client)https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1504please add support for '-s' script field for openconnect2024-03-26T19:12:54ZAmit Shahplease add support for '-s' script field for openconnect## Description of the feature
I'd like to pass a custom script to openconnect. Mainly to use vpn-slice for split tunneling. This requires paying the script and parameters to openconnect's '-s' parameter.
I currently use this by directly...## Description of the feature
I'd like to pass a custom script to openconnect. Mainly to use vpn-slice for split tunneling. This requires paying the script and parameters to openconnect's '-s' parameter.
I currently use this by directly invoking openconnect from the command line, but wasn't to use it via NM (GUI) instead.
## Description of the use cases
Enabling split tunneling like described in
https://github.com/dlenski/vpn-slice?tab=readme-ov-file#usage
## References and other resourceshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1503IP address leaks when switching VPN connection2024-03-26T13:59:59ZSteve SmithIP address leaks when switching VPN connectionFedora 39 Workstation.
Lenovo Yoga 7 16ARP8
I’ve used a VPN for many years, just moved to Fedora from Mac and I’m using the built in VPN functionality in the top right 'Quicksettings' drop down.
I downloaded some Wireguard config files ...Fedora 39 Workstation.
Lenovo Yoga 7 16ARP8
I’ve used a VPN for many years, just moved to Fedora from Mac and I’m using the built in VPN functionality in the top right 'Quicksettings' drop down.
I downloaded some Wireguard config files from my VPN provider, and set them up in Network settings. I have 6 or 7 currently. I have two problems:
1. Constant notifications of “Failed to activate network connection”, whilst there is no issue at all, I'm connected just fine. These come and go constantly, quite annoying. There’s definitely no actual problem with internet connectivity during this time so it seems like some kind of bug due to VPN use, doesn’t happen when I am not on VPN.
2. More problematic is the fact I can’t switch my VPN connection without exposing my real IP. This is a big enough concern that I will be forced to install a VPN app, which means paying again for a different VPN as my current one doesn’t have a great app. When I click the top right drop down, let’s say it’s connected to “Chicago”, if I want to switch to say “Washington”, I have two options:
a) Click “VPN” which turns it off, then click right arrow to choose a connection to switch on
b) Click the right arrow (this is what I do), and move the Chicago switch to off, which closes the dialogue, so i have to then quickly click to bring it down again, click the right arrow again, and choose “Washington”.
In the time this takes to do, my real IP is exposed (I have confirmed this). I am quite surprised by this, I was advised that Wireguard protocol and Network Manager is a very good and 'secure' combination, but with IP leaks that rules it out for me unless it could be fixed or, ideally, a 'kill switch' option added.
I am not a programmer so I have no abilities to make a manual kill switch as I know some people could do quite easily. I just need to know my IP doesn't leak when changing connection (as I have to change connection regularly for my work).
Thankshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1502A core dump occurs during the execution of a nmcli command2024-03-23T12:44:50ZbanjiuqingshanA core dump occurs during the execution of a nmcli commandThis is an occasional problem. The nmcli command is executed twice every minute, and a core dump is triggered every two to three weeks.The corresponding version is glib2-2.72.2 and NetworkManager-1.32.12. The core file output is as follo...This is an occasional problem. The nmcli command is executed twice every minute, and a core dump is triggered every two to three weeks.The corresponding version is glib2-2.72.2 and NetworkManager-1.32.12. The core file output is as follows:
![image](/uploads/041d5152c5c3c65287a20d9a3488e260/image.png)https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1501Bridge connections do not connect automatically2024-03-21T16:12:42ZAleksey CovaceviceBridge connections do not connect automaticallyI have a bridge connection with a number of routes, to which some local containers connect. There are no slave connections configured directly on the connection profile, just the bridge itself.
At boot, the bridge connection is "activat...I have a bridge connection with a number of routes, to which some local containers connect. There are no slave connections configured directly on the connection profile, just the bridge itself.
At boot, the bridge connection is "activated" (according to `nmcli`), however the routes are not set up. I need to manually run `nmcli conn up my-bridge` to bring the routes up.
I wonder if this is a bug or misconfiguration on my side; `connection.autoconnect=yes` is set.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1500NetworkManager 1.46.0 does not report 6 GHz capabilities even though my devic...2024-03-22T10:34:21ZMatthijs Velsinkmvelsink@gnome.orgNetworkManager 1.46.0 does not report 6 GHz capabilities even though my device has## Summary
I'm trying to help https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2072 along, and I have hardware with 6 GHz capabilities (AMD RZ616).
`iw list` reports working 6 GHz frequencies:
```
Frequencies:
* 595...## Summary
I'm trying to help https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2072 along, and I have hardware with 6 GHz capabilities (AMD RZ616).
`iw list` reports working 6 GHz frequencies:
```
Frequencies:
* 5955 MHz [1] (23.0 dBm)
* 5975 MHz [5] (23.0 dBm)
* 5995 MHz [9] (23.0 dBm)
* 6015 MHz [13] (23.0 dBm)
* 6035 MHz [17] (23.0 dBm)
...
```
But NetworkManager does not, as `nmcli -f wifi-properties dev show wlp1s0` reports
```
WIFI-PROPERTIES.WEP: yes
WIFI-PROPERTIES.WPA: yes
WIFI-PROPERTIES.WPA2: yes
WIFI-PROPERTIES.TKIP: yes
WIFI-PROPERTIES.CCMP: yes
WIFI-PROPERTIES.AP: yes
WIFI-PROPERTIES.ADHOC: no
WIFI-PROPERTIES.2GHZ: yes
WIFI-PROPERTIES.5GHZ: yes
WIFI-PROPERTIES.6GHZ: no
WIFI-PROPERTIES.MESH: no
WIFI-PROPERTIES.IBSS-RSN: no
```
Looking at !1739, I don't quite understand why this would not work. It's almost as if the entire 6 GHz band is skipped in `nl80211_wiphy_info_handler()`?
## Version affected
1.46.0 from Fedora Rawhide
## Relevant logs
* Full output from `iw list`\
[iw_list_output.txt](/uploads/c59bd531909282bf86e99be05b09025b/iw_list_output.txt)
* Full output from `nmcli -f general,wifi-properties dev show wlp1s0`\
[nmcli_output.txt](/uploads/718595ab36fa3e25cb56ec916f2a5558/nmcli_output.txt)Beniamino GalvaniBeniamino Galvanihttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1499NetworkManager ignores mDNS settings for VPN connection2024-03-12T16:04:50ZAleksey CovaceviceNetworkManager ignores mDNS settings for VPN connectionWhen using systemd-resolved and NetworkManager, the latter apparently completely ignores `connection.mdns` for a `type=vpn` connection:
```
[connection]
type=vpn
mdns=0
```
After activating the connection, `resolvectl mdns` will show:
...When using systemd-resolved and NetworkManager, the latter apparently completely ignores `connection.mdns` for a `type=vpn` connection:
```
[connection]
type=vpn
mdns=0
```
After activating the connection, `resolvectl mdns` will show:
```
Global: yes
Link 300 (tun0): yes
```
This happens even if `connection.mdns=0` is set on `NetworkManager.conf`.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1498wlan0 gets stuck in pending state when bringing up AP mode connection with IW...2024-03-08T23:17:18ZJames Hilliardwlan0 gets stuck in pending state when bringing up AP mode connection with IWD backend## Summary
NetworkManager appears to get stuck in a pending state when configuring a wlan0 as an access point when using the IWD backend, the access point is visible and clients can connect but routes/iptables/dnsmasq settings don't app...## Summary
NetworkManager appears to get stuck in a pending state when configuring a wlan0 as an access point when using the IWD backend, the access point is visible and clients can connect but routes/iptables/dnsmasq settings don't appear to get applied so clients have no internet access.
## Version affected
`1.46.0` on [buildroot](https://buildroot.org/) with iwd version `2.16`
## Steps to reproduce
Create a connection with a config like this and try to bring up the connection with NetworkManager configured to use the IWD backend:
```
[connection]
id=connid
uuid=01adc9e6-dbcd-46e6-bb2e-8e5032a8d99b
type=wifi
interface-name=wlan0
[wifi]
mode=ap
ssid=APSSID
[wifi-security]
key-mgmt=wpa-psk
psk=wifipassword
[ipv4]
method=shared
[ipv6]
method=ignore
```
## Actual result
wlan0 should be fully enabled/connected when connection is enabled
## Expected result
wlan0 is stuck in a pending/connecting state when connection is enabled
## Relevant logs
```c
<debug> [1709938743.1640] device[e4bcd76bde98e8a1] (wlan0): Activation: (wifi) Called Start('APSSID').
<debug> [1709938743.1641] device[e4bcd76bde98e8a1] (wlan0): Activation: (wifi) IWD Device.Mode set successfully
<debug> [1709938743.1644] device[e4bcd76bde98e8a1] (wlan0): remove_pending_action (1): 'recheck-available'
<trace> [1709938743.2594] platform: (wlan0) emit signal ip4-address-changed added: 192.168.45.129/28 brd 0.0.0.0 lft forever pref forever lifetime 1235-0[4294967295,4294967295] dev 5 flags permanent src kernel
<debug> [1709938743.2595] platform: (wlan0) signal: address 4 added: 192.168.45.129/28 brd 0.0.0.0 lft forever pref forever lifetime 1235-0[4294967295,4294967295] dev 5 flags permanent src kernel
<trace> [1709938743.2598] platform: (wlan0) emit signal ip4-route-changed added: type local table 255 192.168.45.129/32 dev 5 metric 0 mss 0 rt-src rt-kernel scope host pref-src 192.168.45.129
<debug> [1709938743.2599] platform: (wlan0) signal: route 4 added: type local table 255 192.168.45.129/32 dev 5 metric 0 mss 0 rt-src rt-kernel scope host pref-src 192.168.45.129
<trace> [1709938743.2602] platform: (wlan0) emit signal ip4-route-changed added: type unicast 192.168.45.128/28 dev 5 metric 0 mss 0 rt-src rt-kernel rtm_flags linkdown scope link pref-src 192.168.45.129
<debug> [1709938743.2602] platform: (wlan0) signal: route 4 added: type unicast 192.168.45.128/28 dev 5 metric 0 mss 0 rt-src rt-kernel rtm_flags linkdown scope link pref-src 192.168.45.129
<trace> [1709938743.2609] platform: (wlan0) emit signal link-changed changed: 5: wlan0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 wifi? init addrgenmode none addr BC:25:F0:1D:6A:03 permaddr BC:25:F0:1D:6A:03 brd FF:FF:FF:FF:FF:FF driver rtl8821ae tx-queue-len 1000 gso-max-size 65536 gso-max-segs 65535 gro-max-size 65536 rx:443,42144 tx:563,224232
<debug> [1709938743.2610] platform: (wlan0) signal: link changed: 5: wlan0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 wifi? init addrgenmode none addr BC:25:F0:1D:6A:03 permaddr BC:25:F0:1D:6A:03 brd FF:FF:FF:FF:FF:FF driver rtl8821ae tx-queue-len 1000 gso-max-size 65536 gso-max-segs 65535 gro-max-size 65536 rx:443,42144 tx:563,224232
<debug> [1709938743.2611] device[e4bcd76bde98e8a1] (wlan0): queued link change for ifindex 5
<info> [1709938743.2657] device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Started 'APSSID'.
<debug> [1709938743.2658] device[e4bcd76bde98e8a1] (wlan0): activation-stage: schedule activate_stage3_ip_config
<debug> [1709938743.2659] device[e4bcd76bde98e8a1] (wlan0): activation-stage: invoke activate_stage3_ip_config
<debug> [1709938743.2660] device[e4bcd76bde98e8a1] (wlan0): activation-stage: synchronously invoke activate_stage3_ip_config
<debug> [1709938743.2661] device[e4bcd76bde98e8a1] (wlan0): ip4: required-timeout: disabled
<debug> [1709938743.2661] device[e4bcd76bde98e8a1] (wlan0): ip6: required-timeout: disabled
<debug> [1709938743.2662] active-connection[c8d123b3d4d3f96d]: set state-flags layer2-ready (was none)
<info> [1709938743.2664] device (wlan0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
<debug> [1709938743.2699] device[e4bcd76bde98e8a1] (wlan0): add_pending_action (2): 'in-state-change'
<debug> [1709938743.2704] device[e4bcd76bde98e8a1] (wlan0): remove_pending_action (1): 'in-state-change'
<info> [1709938743.2709] device (wlan0): IWD AP/AdHoc state is now Started
<trace> [1709938743.2710] device[e4bcd76bde98e8a1] (wlan0): ip4: check-state: state pending => pending, is_failed=0, is_pending=0, is_started=0 temp_na=0, may-fail-4=1, may-fail-6=1;;;
<trace> [1709938743.2710] device[e4bcd76bde98e8a1] (wlan0): ip: check-state: (combined) state pending => pending
<trace> [1709938743.2711] device[e4bcd76bde98e8a1] (wlan0): ip6: check-state: state pending => pending, is_failed=0, is_pending=0, is_started=0 temp_na=0, may-fail-4=1, may-fail-6=1;;;
<trace> [1709938743.2711] device[e4bcd76bde98e8a1] (wlan0): ip: check-state: (combined) state pending => pending
```
```
# nmcli device status
DEVICE TYPE STATE CONNECTION
eno1 ethernet connected Wired connection 1
wlan0 wifi connecting (getting IP configuration) connid
lo loopback connected (externally) lo
```
```
# iwctl device list
Devices
--------------------------------------------------------------------------------
Name Address Powered Adapter Mode
--------------------------------------------------------------------------------
wlan0 bc:25:f0:1d:6a:03 on phy0 ap
```https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1497NetworkManager IPv6 connections don't update Hop Limit from Router Advertisem...2024-03-14T07:46:30ZBen PattonNetworkManager IPv6 connections don't update Hop Limit from Router Advertisements## Summary
Interfaces managed through NM don't update their value used for the Hop Limit field in outgoing IPv6 packets when their CurHopLimit value is updated by a Router Advertisement. This goes against Hop Limit processing behavior d...## Summary
Interfaces managed through NM don't update their value used for the Hop Limit field in outgoing IPv6 packets when their CurHopLimit value is updated by a Router Advertisement. This goes against Hop Limit processing behavior described in [RFC 4861, section 6.3.4](https://datatracker.ietf.org/doc/html/rfc4861#section-6.3.4).
## Version affected
NetworkManager version: 1.44.0-3.el9
Kernel version: 5.14.0-362.13.1
OS: Red Hat 9.3
## Steps to reproduce
1. Activate a new NetworkManager connection (ipv6.method set to auto)
2. Interface is on-link with a router sending IPv6 Router Advertisements
3. Configure the router to advertise a CurHopLimit for some arbitrary value other than 64 or 0 (I used 100)
4. After the NM managed interface receives the RA with an updated CurHopLimit value, ping it from another router or host on-link
5. Check the HopLimit value in the IPv6 header for the NM managed interface's outgoing echo reply.
## Actual result
NM connections don't use updated HopLimit values in the IPv6 header of its outgoing packets when an RA includes a non-default (usually 64) or unspecified (0) value for CurHopLimit.
## Expected result
NM managed interface should process the CurHopLimit in received RAs and update the HopLimit value in its own IPv6 headers in subsequent traffic.
## Relevant logs
journalctl -u NetworkManager output collected while following above steps:
[nm_curhoplimit.log](/uploads/fbda78f836ec8a34766f744276ee3ac2/nm_curhoplimit.log)
Packet capture showing HopLimit and CurHopLimit values from NM node and from the on-link router:
[nm_CurHopLimit.pcapng](/uploads/a920799dbd23adb4504bc073ddfc94b2/nm_CurHopLimit.pcapng)https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1496ipv4.dad-timeout does not work on IB devices2024-03-11T05:56:10ZRohit Nairipv4.dad-timeout does not work on IB devices## Summary
When we set the ipv4.dad-timeout value for IB devices to a value greater than 0, IP is not assigned to the IB devices.
If the ipv4.dad-timeout is disabled, the IP assignment works as expected.
## Version affected
nmcli tool,...## Summary
When we set the ipv4.dad-timeout value for IB devices to a value greater than 0, IP is not assigned to the IB devices.
If the ipv4.dad-timeout is disabled, the IP assignment works as expected.
## Version affected
nmcli tool, version 1.40.16-4.0.1.el8_8
## Steps to reproduce
Set ipv4.dad-timeout for Infiniband (IB) devices to a value greater than 0 and reboot the node.
## Actual result
```
9: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UP group default qlen 256
link/infiniband 80:00:02:09:fe:80:00:00:00:00:00:00:00:10:e0:00:01:86:b7:22 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet6 fe80::210:e000:186:b722/64 scope link
valid_lft forever preferred_lft forever
```
## Expected result
```
8: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UP group default qlen 256
link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:10:e0:00:01:86:b7:21 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet 192.168.0.17/24 brd 192.168.0.255 scope global noprefixroute ib0
valid_lft forever preferred_lft forever
inet6 fe80::210:e000:186:b721/64 scope link
valid_lft forever preferred_lft forever
```
## Relevant logs
```
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6198] device[9d29d4a89f2a95a0] (ib1): add_pending_action (2): 'queued-state-change-disconnected'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6198] device[9d29d4a89f2a95a0] (ib1): queue-state[disconnected, reason:carrier-changed, id:113]: queue state change
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6198] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (1): 'carrier-wait'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6201] manager: (ib1): assume: cannot generate connection: device has no existing configuration
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6220] device[9d29d4a89f2a95a0] (ib1): queue-state[disconnected, reason:carrier-changed, id:113]: change state
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6220] device (ib1): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6220] device[9d29d4a89f2a95a0] (ib1): add_pending_action (2): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6220] device[9d29d4a89f2a95a0] (ib1): ip6: addrgenmode6: set none (already set)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6221] device[9d29d4a89f2a95a0] (ib1): ip6: addrgenmode6: toggle disable_ipv6 sysctl after disabling addr-gen-mode
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6221] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/disable_ipv6' to '1' (current value is '0')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6222] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/disable_ipv6' to '0' (current value is '1')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6222] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/disable_ipv6' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6223] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/accept_ra' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6223] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/use_tempaddr' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6224] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/forwarding' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6226] policy: re-enabling autoconnect for all connections on ib1
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6226] device[9d29d4a89f2a95a0] (ib1): add_pending_action (3): 'autoactivate'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6226] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (2): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6226] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (1): 'queued-state-change-disconnected'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6276] policy: auto-activating connection 'System ib1' (b470a14e-bad0-45f6-ee4a-e90be1b4f0a8)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6276] active-connection[0x559863ef11c0]: set device "ib1" [0x559863ea23e0]
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6276] device[9d29d4a89f2a95a0] (ib1): add_pending_action (2): 'activation-2'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6278] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (1): 'autoactivate'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6282] device[9d29d4a89f2a95a0] (ib1): unmanaged: flags set to [!sleeping,!by-type,!platform-init,!user-explicit,!user-settings=0x0/0x79/managed], set-managed [user-explicit=0x20], reason user-requested)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6283] device (ib1): Activation: starting connection 'System ib1' (b470a14e-bad0-45f6-ee4a-e90be1b4f0a8)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6284] device[9d29d4a89f2a95a0] (ib1): activation-stage: schedule activate_stage1_device_prepare
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6354] device[9d29d4a89f2a95a0] (ib1): activation-stage: invoke activate_stage1_device_prepare
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6354] device[9d29d4a89f2a95a0] (ib1): ip4: set state pending (was none, reason: stage1)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6355] device[9d29d4a89f2a95a0] (ib1): ip6: set state pending (was none, reason: stage1)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6355] device (ib1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6355] device[9d29d4a89f2a95a0] (ib1): add_pending_action (2): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6358] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (1): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6359] device[9d29d4a89f2a95a0] (ib1): taking down device 9
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6395] platform: (ib1) signal: link changed: 9: ib1 <DOWN;broadcast,multicast> mtu 2044 arp 32 infiniband/ipoib init addrgenmode none addr 80:00:02:09:FE:80:00:00:00:00:00:00:00:10:E0:00:01:86:B7:22 brd 00:FF:FF:FF:FF:12:40:1B:FF:FF:00:00:00:00:00:00:FF:FF:FF:FF driver mlx4_core rx:0,0 tx:0,0
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6395] device[9d29d4a89f2a95a0] (ib1): queued link change for ifindex 9
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6397] platform-linux: sysctl: setting 'net:/sys/class/net/ib1/mode' to 'connected' (current value is 'datagram')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6397] device[9d29d4a89f2a95a0] (ib1): bringing up device 9
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6403] platform: (ib1) signal: link changed: 9: ib1 <DOWN;broadcast,multicast> mtu 2044 arp 32 infiniband/ipoib init addrgenmode none addr 80:00:02:09:FE:80:00:00:00:00:00:00:00:10:E0:00:01:86:B7:22 brd 00:FF:FF:FF:FF:12:40:1B:FF:FF:00:00:00:00:00:00:FF:FF:FF:FF driver mlx4_core rx:0,0 tx:0,0
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6404] platform: (ib1) signal: link changed: 9: ib1 <DOWN;broadcast,multicast> mtu 65520 arp 32 infiniband/ipoib init addrgenmode none addr 80:00:02:09:FE:80:00:00:00:00:00:00:00:10:E0:00:01:86:B7:22 brd 00:FF:FF:FF:FF:12:40:1B:FF:FF:00:00:00:00:00:00:FF:FF:FF:FF driver mlx4_core rx:0,0 tx:0,0
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6404] platform: (ib1) signal: link changed: 9: ib1 <UP;broadcast,multicast,up,running> mtu 65520 arp 32 infiniband/ipoib init addrgenmode none addr 80:00:02:09:FE:80:00:00:00:00:00:00:00:10:E0:00:01:86:B7:22 brd 00:FF:FF:FF:FF:12:40:1B:FF:FF:00:00:00:00:00:00:FF:FF:FF:FF driver mlx4_core rx:0,0 tx:0,0
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6405] device[9d29d4a89f2a95a0] (ib1): add_pending_action (2): 'carrier-wait'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6405] device[9d29d4a89f2a95a0] (ib1): carrier: link disconnected (deferring action for 6000 milliseconds) (id=150)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6406] device[9d29d4a89f2a95a0] (ib1): activation-stage: synchronously invoke activate_stage2_device_config
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6406] device (ib1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6406] device[9d29d4a89f2a95a0] (ib1): add_pending_action (3): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6408] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (2): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6409] device[9d29d4a89f2a95a0] (ib1): bringing up device 9
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6410] device[9d29d4a89f2a95a0] (ib1): activation-stage: synchronously invoke activate_stage3_ip_config
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6410] firewalld: [a92dd9437708524d,change*:"ib1"]: firewall zone change ib1:default (not running, simulate success)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6419] platform: (ib1) signal: link changed: 9: ib1 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 65520 arp 32 infiniband/ipoib init addrgenmode none addr 80:00:02:09:FE:80:00:00:00:00:00:00:00:10:E0:00:01:86:B7:22 brd 00:FF:FF:FF:FF:12:40:1B:FF:FF:00:00:00:00:00:00:FF:FF:FF:FF driver mlx4_core rx:0,0 tx:0,0
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6435] device (ib1): carrier: link connected
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6436] device[9d29d4a89f2a95a0] (ib1): carrier: link disconnected (canceling deferred action) (id=150)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6436] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (1): 'carrier-wait'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6436] firewalld: [a92dd9437708524d,change*:"ib1"]: complete: fake success
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6436] device[9d29d4a89f2a95a0] (ib1): activation-stage: synchronously invoke activate_stage3_ip_config
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6436] device[9d29d4a89f2a95a0] (ib1): ip4: required-timeout: disabled
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6436] device[9d29d4a89f2a95a0] (ib1): ip6: required-timeout: disabled
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6437] device (ib1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6437] device[9d29d4a89f2a95a0] (ib1): add_pending_action (2): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6438] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (1): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6439] device[9d29d4a89f2a95a0] (ib1): ip:manual4: set state pending
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6439] device[9d29d4a89f2a95a0] (ib1): ip:manual6: set state pending
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6439] device[9d29d4a89f2a95a0] (ib1): ip6: addrgenmode6: set eui64
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6440] platform: (ib1) signal: link changed: 9: ib1 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 65520 arp 32 infiniband/ipoib init addrgenmode eui64 addr 80:00:02:09:FE:80:00:00:00:00:00:00:00:10:E0:00:01:86:B7:22 brd 00:FF:FF:FF:FF:12:40:1B:FF:FF:00:00:00:00:00:00:FF:FF:FF:FF driver mlx4_core rx:0,0 tx:0,0
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6440] device[9d29d4a89f2a95a0] (ib1): queued link change for ifindex 9
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6441] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/disable_ipv6' to '1' (current value is '0')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6442] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/disable_ipv6' to '0' (current value is '1')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6443] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/accept_ra' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6443] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/forwarding' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6444] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/hop_limit' to '64' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6444] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/use_tempaddr' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6448] platform: (ib1) signal: route 6 added: type unicast fe80::/64 dev 9 metric 256 mss 0 rt-src rt-kernel
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6459] device[9d29d4a89f2a95a0] (ib1): ip:manual6: set state done
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6462] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/ib1/use_tempaddr' to '0' (current value is identical)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6462] device[9d29d4a89f2a95a0] (ib1): ip:manual4: set state done
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6462] device[9d29d4a89f2a95a0] (ib1): ip4: set state done (was pending, reason: check-ip-state)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6463] device[9d29d4a89f2a95a0] (ib1): ip: set (combined) state done (was none, reason: check-ip-state)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <info> [1709886505.6463] device (ib1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6463] device[9d29d4a89f2a95a0] (ib1): add_pending_action (2): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6464] dispatcher: (3) (ib1) dispatching action 'pre-up' (with callback)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6467] device[9d29d4a89f2a95a0] (ib1): remove_pending_action (1): 'in-state-change'
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6467] device[9d29d4a89f2a95a0] (ib1): ip6: set state done (was pending, reason: check-ip-state)
Mar 8 01:28:25 slcs17adm01 nm-dispatcher[21251]: req:3 'pre-up' [ib1]: environment: CONNECTION_DBUS_PATH=/org/freedesktop/NetworkManager/Settings/1
Mar 8 01:28:25 slcs17adm01 nm-dispatcher[21251]: req:3 'pre-up' [ib1], "/usr/lib/NetworkManager/dispatcher.d/pre-up.d/10-ifcfg-rh-routes.sh": run script (no-wait)
Mar 8 01:28:25 slcs17adm01 NetworkManager[21099]: <debug> [1709886505.6658] platform: (ib1) signal: route 4 added: type unicast table 181 192.168.0.0/24 dev 9 metric 0 mss 0 rt-src rt-boot scope link
Mar 8 01:28:25 slcs17adm01 nm-dispatcher[21251]: req:3 'pre-up' [ib1], "/usr/lib/NetworkManager/dispatcher.d/pre-up.d/10-ifcfg-rh-routes.sh": complete
Mar 8 01:28:25 slcs17adm01 nm-dispatcher[21251]: req:3 'pre-up' [ib1], "/etc/NetworkManager/dispatcher.d/pre-up.d/17-exadata-roce-up": run script
```
(Please see the DEBUGGING section of "[man NetworkManager](https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/NetworkManager.html)" and attach any relevant log)https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1495Possibility to change the "Automatically connect" setting for the IPv6 protocol2024-03-08T12:40:48ZОлег ТимшинPossibility to change the "Automatically connect" setting for the IPv6 protocol## Description of the feature
"connection.autoconnect" separately 4 IPv6 protocol
## Description of the use cases
I don't see a key in the documentation that would turn off/on the "Automatically connect" parameter specifically for IPv6.
...## Description of the feature
"connection.autoconnect" separately 4 IPv6 protocol
## Description of the use cases
I don't see a key in the documentation that would turn off/on the "Automatically connect" parameter specifically for IPv6.
There is "connection.autoconnect" for the whole port, but I couldn't apply it to IPv6 protocol separately.
## References and other resourceshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1494Unable to ping a new already working domain until reboot2024-03-05T14:47:02Zphp4fanUnable to ping a new already working domain until reboot## Summary
On a server that I manage, which already had a working website with domain `example.com` (obviously that's not the actual domain), I configured a subdomain `newsubdomain.example.com` (that's not the real subdomain name either...## Summary
On a server that I manage, which already had a working website with domain `example.com` (obviously that's not the actual domain), I configured a subdomain `newsubdomain.example.com` (that's not the real subdomain name either) within the same domain. Meaning that I added the `A` and `AA` DNS records and created a separate virtual host. This subdomain happened to be hosted on a different server, but I'm pretty sure that's irrelevant.
After I set everything up, I checked the following:
- the new subdomain records had propagated to the entire world according to https://www.whatsmydns.net/
- I checked at https://dns.google/query that the new subdomain was visible by Google's DNS
- the webs servers for both the original domain (which had already been working before) and the new subdomain were both working (which is also confirmed by the following two points)
- I asked a coworker to access http://newsubdomain.example.com from their computer from my same country and it was accessible
- I checked from a third unrelated host that I could `wget http://newsubdomain.example.com`
So, on my Manjaro local computer, I tried opening http://newsubdomain.example.coom in Google Chrome, and it failed with `ERR_NAME_NOT_RESOLVED`; so I also tried to ping the subdomain from a terminal and it also failed.
I changed my network configuration to use Google's DNSs `8.8.8.8`, disconnected and reconnected to the network; retried and it kept failing.
So I rebooted, and sure enough, it could access the domain.
It's very likely (I'm almost sure) that I had also tried and (expectedly) failed to access the subdomain before I set it up. So maybe the failure response from some DNS had been cached somehow. I certainly had accessed the root domain before.
## Version affected
1.44.2-3 on Manjaro Linux
## Steps to reproduce
see Summary
Should be something like this:
- try to ping a subdomain that isn't reachable, whose root domain is reachable
- also ping the root domain for good measure
- set up the server so that the subdomain is reachable
- make sure the DNS information has propagated, that the subdomain is indeed reachable
- make sure your local network is set up to use a DNS server that does know about the subdomain
- disconnect and reconnect physically to the local network
- try again to ping the subdomain
## Actual result
- the subdomain is still unreachable until reboot
## Expected result
- the subdomain should be reachable without needing a reboot.
Note: I create new domains all the time almost on a daily basis, and never had this issue. MAYBE this is specific to the situation where a subdomain becomes reachable, which belongs to a root domain that was already previously reachable. But I'm just speculating.
## Relevant logs
(Please see the DEBUGGING section of "[man NetworkManager](https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/NetworkManager.html)" and attach any relevant log)
"By default, NetworkManager logs are not verbose and thus not very helpful for investigating a problem in detail"
Well then I'm afraid it's too late for thathttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1493Network Manager connectivity mechanism only calls dispatcher script on state ...2024-03-05T10:02:44ZRobert KrakoraNetwork Manager connectivity mechanism only calls dispatcher script on state change (i.e. LIMITED->FULL)## Summary
Set up the Network Manager configuration file to enable periodic connectivity checking which entails giving it an endpoint from which to do an HTTP GET on a file containing specific text and set the periodicity. From logs, i...## Summary
Set up the Network Manager configuration file to enable periodic connectivity checking which entails giving it an endpoint from which to do an HTTP GET on a file containing specific text and set the periodicity. From logs, it looks like an HTTP GET is directed out each interface and if none can reach the endpoint then the connection state is set to LIMITED...else it is set to FULL. Set up a dispatcher script to act on connectivity state like below if it is not "FULL". Set NetworkManager logging to TRACE and the periodic connectivity checking is occurring at the proper cadence. However, the dispatcher script only seems to get called on a connectivity change and not at the period of the connectivity check mechanism. Be nice if there was a connectivity check action which occurred at the period of the connectivity check mechanism so further efforts could be taken to recover a connection if it had not yet recovered since the last connectivity action returning with a connectivity state of LIMITED.
https://developer-old.gnome.org/NetworkManager/stable/NetworkManager.html
**#!/usr/bin/env bash
interface=$1
event=$2
if [[ $interface != "" ]]
then
echo "$interface received $event" | systemd-cat -p info -t modem-event-handler
else
echo "received $event, state $CONNECTIVITY_STATE" | systemd-cat -p info -t modem-event-handler
fi
if [[ $interface == "" ]] && [[ $event == "connectivity-change" ]] && [[ $CONNECTIVITY_STATE != "FULL" ]]
then
echo "Restart modem connection" | systemd-cat -p info -t modem-event-handler
mmcli -m any --command='AT+QPOWD=0'
fi**
## Version affected
imx8mq-pe100a:~$ nmcli --version
nmcli tool, version 1.36.2
imx8mq-pe100a:~$
## Steps to reproduce
## Actual result
## Expected result
## Relevant logs
(Please see the DEBUGGING section of "[man NetworkManager](https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/NetworkManager.html)" and attach any relevant log)https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1492Cannot add a wireguard profile to connection.secondaries, NM throw the error:...2024-03-04T14:35:31Zsam uelCannot add a wireguard profile to connection.secondaries, NM throw the error: "is not a VPN connection profile"Hello,
## Summary
I wanted to make sure a Wireguard profile was started only after the 'wlan0' had connectivity:
```
$ nmcli connection show
NAME UUID TYPE DEVICE
FUNG-1395 ...Hello,
## Summary
I wanted to make sure a Wireguard profile was started only after the 'wlan0' had connectivity:
```
$ nmcli connection show
NAME UUID TYPE DEVICE
FUNG-1395 447d6d94-75a7-4201-af17-77142956f6ef wifi wlan0
luc-Wireguard-VPN e1c83fba-ee67-4587-bfcb-807755776e32 wireguard sltuniv0
```
I've read that's what the 'connection.secondaries' setting is for, but:
```
$ nmcli connection modify FUNG-1395 connection.secondaries e1c83fba-ee67-4587-bfcb-807755776e32
Error: failed to modify connection.secondaries: 'e1c83fba-ee67-4587-bfcb-807755776e32' is not a VPN connection profile.
```
I've asked on the Mailing list[1] and been told it should be supported
[1] [https://lists.freedesktop.org/archives/networkmanager/2024-March/000253.html](https://lists.freedesktop.org/archives/networkmanager/2024-March/000253.html)
## Version affected
```
$ nmcli --version
nmcli tool, version 1.44.2
```
## Steps to reproduce
Try to add a wireguard profile to connection.secondaries
## Actual result
As NM refuses to do it, the Wireguard profile cannot be started automatically after an other profile.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1490Initial EPS Bearer Settings - Additional Settings2024-03-07T06:48:19ZJosef OuanoInitial EPS Bearer Settings - Additional Settings## Description of the feature
Regarding the initial eps bearer settings, currently as I understand both of these settings are available:
- NM_SETTING_INITIAL_EPS_BEARER_APN
- NM_SETTING_INITIAL_EPS_BEARER_CONFIGURE
Currently there are o...## Description of the feature
Regarding the initial eps bearer settings, currently as I understand both of these settings are available:
- NM_SETTING_INITIAL_EPS_BEARER_APN
- NM_SETTING_INITIAL_EPS_BEARER_CONFIGURE
Currently there are other 5G networks there that can only be enabled by setting these credentials.
- apn
- ip-type
- allowed-authorization
- user
- password
Ideally these should be added in addition to the already implemented initial eps bearer settings.\
These would also be integrated with APN setting on Gnome for Ubuntu which currently lacks the feature.
## Description of the use cases
Network Manager already implements **NM_SETTING_INITIAL_EPS_BEARER_APN** and **NM_SETTING_INITIAL_EPS_BEARER_CONFIGURE**.\
Ideally, **ip-type, allowed-authorization, username** and **password** could be added.\
Even through nmcli, the only settings available are these: **gsm.initial-eps-bearer-apn, gsm.initial-eps-bearer-configure**
which is insufficient for this purpose.
Currently using ModemManager CLI (mmcli), you can set additional authorization settings using this command:\
`mmcli -m 0 --3gpp-set-initial-eps-bearer-settings=apn='<apn_name>',ip-type='<ip_type>',allowed-auth='<auth_type>',user='<user_name>',password='<password>'`
So using a CLI approach through mmcli is not ideal, since gnome community would probably not accept it as a solution.
The target implementation of this is to give linux OS, specifically Ubuntu, the same capability to set initial eps bearer settings through `InternetAttach/Attach` feature that is found in Windows, specifically through modification of APN settings in Gnome settings.\
Also,currently APN settings in Gnome settings are set through NetworkManager.
For an example on which network uses these additional settings aside APN to be set through initial eps bearer setting, one network is AU 5G network in Japan.
## References and other resources
**Network manager initial eps bearer settings**\
https://discourse.gnome.org/t/initial-eps-bearer-apn-format/17491\
https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nm-settings-dbus.html
**nmcli**\
https://www.networkmanager.dev/docs/api/latest/nm-settings-nmcli.html
**mmcli**\
https://github.com/linux-mobile-broadband/ModemManager/blob/main/cli/mmcli-modem-3gpp.c\
https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg07148.html
**InternetAttach/Attach Feature**\
https://wiki.ubuntu.com/Networking#apn-mobile\
https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1435360\
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/mb-lte-attach-operations
**Gnome Settings current wwan setting**\
https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/main/panels/wwan/cc-wwan-data.c?ref_type=heads\
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2948https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1489Fail to connect with WPA3-Personal (SAE) and IWD backend2024-03-01T03:32:05ZIan DallFail to connect with WPA3-Personal (SAE) and IWD backend## Summary
A wifi client configured with WPA3Personal (only) and IWD backend fails to connect.
* Downgrading to WPA/WPA2/WPA3Personal works (making no other changes).
* Also, with WPA3Personal (only), the network will connect successful...## Summary
A wifi client configured with WPA3Personal (only) and IWD backend fails to connect.
* Downgrading to WPA/WPA2/WPA3Personal works (making no other changes).
* Also, with WPA3Personal (only), the network will connect successfully using `iwctrl station wlan0 connect <SSID>` and `iwctl station wlan0 show` has state "connected" and security "WPA3-Personal + FT" , so the configuration is correct and has been correctly copied to `/var/lib/iwd/<SSID>.psk`.
* The connection configuration also appears correct according to nmcli (802-11-wireless-security.key-mgmt: sae).
## Version affected
Client:
arch-linux
nmcli tool, version 1.46.0-2
iwd 2.14-1
Access point Openwrt 22.03.01
## Steps to reproduce
Access point configured with WPA2/WPA3 PSK, SAE (COMP)
Create connection using nm-applet with WiFi security WPA3Personal
Start connection with `nmcli con up <SSID>`
## Actual result
Connection fails with "Connection activation failed: No reason given"
## Expected result
Successful connection
## Relevant logs
The SSID in question is "Sparkgap79" and the activation is attempted at 11:30:29
[nm.log](/uploads/061ce80f471249b0ca34dfc6edd1ea9b/nm.log)
There is nothing in the IWD log at that time and as best I can tell, NetworkManager has no communication with iwd at that time.
[iwd.log](/uploads/9521f458814a9d2cbbb4bd0a644892d6/iwd.log)https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1488Add data-ciphers-fallback as VPN option in NetworkManager2024-03-05T10:15:04ZAldo SierraAdd data-ciphers-fallback as VPN option in NetworkManager## Add data-ciphers-fallback as an option for the VPN settings in NetworkManager
In the openvpn cofig files, theres an option name data-ciphers-fallback and sometimes is necesary to use it in order to connect to a vpn using openvpn clien...## Add data-ciphers-fallback as an option for the VPN settings in NetworkManager
In the openvpn cofig files, theres an option name data-ciphers-fallback and sometimes is necesary to use it in order to connect to a vpn using openvpn client.
```console
nmcli> set vpn.data-ciphers-fallback 'AES-128-GCM'
Error: invalid property: 'data-ciphers-fallback' not among [service-type, user-name, data, secrets, persistent, timeout]
```
Also if manually add it to the nmconnection file of the vpn, it doesn work.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1487Network information revealed to local user2024-03-15T08:04:22Zcomp isNetwork information revealed to local user## Summary
When a local user opens the Network manager app version 1.3 any local user to the machine can change or view the WIFI password
## Version affected
Network manager app 1.3
## Steps to reproduce
Open edit connection and you ...## Summary
When a local user opens the Network manager app version 1.3 any local user to the machine can change or view the WIFI password
## Version affected
Network manager app 1.3
## Steps to reproduce
Open edit connection and you will see WFI information without an administrator password being provided.
## Actual result
Allows access to the WIFI password without administrator password
## Expected result
Expect an administrator password to be provided before the WIFI information can be provided.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1486Additional DNS servers are now prepended?2024-02-25T18:16:51ZSergio CallegariAdditional DNS servers are now prepended?Not using any caching resolver, but having Network Manager in charge of just writing the name of the DNS servers in the `/etc/resolf.conf` file I am discovering that the order in which the servers are written in this file is changed.
I a...Not using any caching resolver, but having Network Manager in charge of just writing the name of the DNS servers in the `/etc/resolf.conf` file I am discovering that the order in which the servers are written in this file is changed.
I am sure that until recently Network Manager was writing *first* the DNS servers received via DHCP and then the "additional DNS servers" specified with the connection editor. Now it does the opposite: it writes the additional DNS servers on top.
Is this change documented somewhere? Is the new behavior the expected one? IMHO (but I am not a native speaker) "additional" seems to be more consistent with "appending" than "prepending". Unfortunately, even if the server order should probably not matter, in many practical cases it does. In my setup, the DHCP server sets a default DNS server with some local overrides. Being able to locally set some additional servers is useful to preserve some ability to do work if the local DNS is down. In a regular setup the first server gets tried first, so in this setup you want the DHCP server first.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1485No IPv4 after updating to 1.46.02024-02-27T07:07:52ZIyan MendezNo IPv4 after updating to 1.46.0## Summary
After updating to NetworkManager 1.46.0, I don't get an IPv4 via DHCP on my wired connection. Downgrading to 1.44.2 fixes the issue for me. Wireless connections are not affected.
## Version affected
Arch Linux running Netwo...## Summary
After updating to NetworkManager 1.46.0, I don't get an IPv4 via DHCP on my wired connection. Downgrading to 1.44.2 fixes the issue for me. Wireless connections are not affected.
## Version affected
Arch Linux running NetworkManager [1.46.0-1 from ~~[extra-testing]~~[extra]](https://archlinux.org/packages/extra/x86_64/networkmanager/).
## Steps to reproduce
1. Create wired connection (I used the KDe Plasma applet with all default options)
2. Connect
## Actual result
PC gets an IPv6 but no IPv4. I cannot connect to local devices with IPv4 only.
## Expected result
PC gets both IPV6 and IPv4 as before updating.
## Relevant logs
Here I attach logs with `level=TRACE` and the rate limits disabled on journald.
[nn_1.44.2.txt](/uploads/2029518d838fdc7bd06df8321e808c60/nn_1.44.2.txt)
[nn_1.46.txt](/uploads/3716b6bae889423bf9a2f9f26ff11040/nn_1.46.txt)