Re: Simultaneous use of link-local + DHCP for IPv4
Hi, On Wed, 2022-11-02 at 11:39 +0100, Christian Eggers wrote: > According to Wikipedia [1], IPv6 hosts are required to always > configure a > link-local address, even if a global address is available. As far as > I > know, NM allows only one type of address (link-local / DHCP / manual) > for an > IPv4 connection (although multiple addresses may be configured in > manual mode). > > Would it be useful (or is it already possible), to allow parallel use > of > link-local + dhcp/manual for IPv4? > > Background: On our (embedded) product, we currently implement only > IPv4 (nobody > asked for IPv6 support yet). The user is responsible for choosing the > address > selection method according to his needs in order to communicate with > our device. > > In future versions, we would like to add peer-to-peer communication > between > our devices which shall work independently of a proper IP address > configured > by the user. So if the device is configured for DHCP (factory > default), > discovery and communication between our devices shall work also for > such cases, > where no DHCP server is present. > > We try to avoid the "Microsoft" approach where link-local is used as > a fallback > if no DHCP server is responding. This would increase startup time and > doesn't > perform well if the DHCP server is connected later (due to the mobile > nature of > our equipment). > > regards, > Christian > > > [1] > https://en.wikipedia.org/wiki/Zero-configuration_networking#Address_selection Since 1.40, you can configure `ipv4.link-local` property. Try that. One problem is that if you use DHCP + link-local, then the "activated" state will not be reached before we get an DHCP and link-local address. And the timeout for link-local addresses is rather high. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Announcement: this mailing list will be retired by the end of Oct 2022
On Wed, 2022-10-26 at 23:16 +0200, Andrea Veri wrote: Hi Andrea, It is done: https://mail.gnome.org/archives/networkmanager-list/2022-November/msg0.html I think the old list can be shut down. What will happen when sending an email to the old list? Will a bounce message be sent back? Can it link to the new place? > We can provide you the subscribers list if the decision you want to > pursue is subscribing existing list members on the new hosting > platform. the list admin can see the subscribers at https://mail.gnome.org/mailman/roster/networkmanager-list That was all that's needed. Invitations are sent. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager GNOME mailing list migrated to new "networkmana...@list.freedesktop.org"
Hi everybody, This mailing list at networkmanager-list@gnome.org is about to shut down ([1]). [1] https://mail.gnome.org/archives/networkmanager-list/2022-October/msg6.html The new mailing list for NetworkManager is at networkmana...@list.freedesktop.org ([2]). [2] https://lists.freedesktop.org/mailman/listinfo/networkmanager Thanks GNOME for the past 18 years of service. Thanks freedesktop for giving us a new place. If you prefer, there is also a tag in GNOME's discourse ([3]). Or try one of the other ways to get in touch ([4]). [3] https://discourse.gnome.org/tag/networkmanager [4] https://networkmanager.dev/community/ All the subscribers of the old list will receive an invite for the new list shortly. Hope to see you there. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Announcement: this mailing list will be retired by the end of Oct 2022
On Thu, 2022-10-27 at 11:49 +0200, Andrea Veri wrote: > > The migration to Discourse has been in the discussion for years [1], > further actions were also communicated in August/September [2] and > [3]. Either way thanks for your feedback, we'll try to improve the > process next time anything like this happens. Indeed. Once being aware of the discussions, they are easy to find. Apparently that many people were still surprised. At least, I was. > List archives are mainly composed of HTML files, I don't foresee any > particular reason on why the history of 20+ years of mails stored in > a mail archive would be shut down in the future, please don't worry > about that. Thanks, thats good to know. Your wording at ([1]) > That’s correct, all the lists listed in there will be turned into > RO mode, list archives will remain around for the time being. made me unsure. [1] https://discourse.gnome.org/t/common-questions-re-mailman-to-discourse/11841 Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Announcement: this mailing list will be retired by the end of Oct 2022
On Wed, 2022-10-26 at 23:15 +0200, Andrea Veri wrote: > On Wed, Oct 26, 2022 at 9:10 PM Martin wrote: > > > You actually go to https://discourse.gnome.org/tag/networkmanager, > right top corner where the ring bell is, then click on the > notification preference you want there :) yes, that's nice. I susbscribed. IMO it doesn't conflict to both have discussions on discourse and having a mailman mailing list. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Announcement: this mailing list will be retired by the end of Oct 2022
On Wed, 2022-10-26 at 23:16 +0200, Andrea Veri wrote: > On Wed, Oct 26, 2022 at 9:29 PM Thomas Haller > wrote: > > Hi, > > > > I think that "we" (the NetworkManager community) will try to get a > > mailman mailing list on freedesktop.org. There is already > > modemmanager-de...@lists.freedesktop.org, so this seems a good fit. > > Our > > git is also on gitlab.freedesktop.org. > > > > > That's unfortunate to hear, would you mind elaborating more on what > made you decide not to migrate to Discourse? Just personal preference (of myself and others). While I wish that mailman would have some improvements, overall it's suitable for our needs. It served us well. I probably just don't know what I am missing out, but I still don't see it. NetworkManager historically is both a GNOME and a freedesktop project (we use gitlab.freedesktop.org, while applet and VPN plugins are on gitlab.gnome.org). Having a freedesktop mailing list would fit the project too. If it weren't for that, I wouldn't know where else to migrate and would stronger consider discourse. On a side note, it's not a big problem... But I don't understand the urgency of sending an announcment and shutting the list down (basically) immediately afterwards. A longer grace period would have been better. I was ignorant of these plans. That ignorance is my fault, but a simple email to the list would have helped. > > > It's also unclear whether we should try to automatically subscribe > > the > > current list subscribers to the new place. I think we should do > > that. > > > > Opinions? > > > > > We can provide you the subscribers list if the decision you want to > pursue is subscribing existing list members on the new hosting > platform. that would be great. Thank you. I probably will come back to you about this. As GNOME plans to leave the archive up as read-only, that's sufficient. But I am worried that on a few years that will be shut down and the history lost. If that ever happens, we should try to archive the history somewhere. Would it be possible to get a dump of the entire archive? Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Announcement: this mailing list will be retired by the end of Oct 2022
Hi, I think that "we" (the NetworkManager community) will try to get a mailman mailing list on freedesktop.org. There is already modemmanager-de...@lists.freedesktop.org, so this seems a good fit. Our git is also on gitlab.freedesktop.org. It's also unclear whether we should try to automatically subscribe the current list subscribers to the new place. I think we should do that. Opinions? A big "Thank You" to the GNOME community for having our list there for so long, 18 years. The service is (was) very appreciated. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DNS over TLS connection setting providers
hi Petr, On Sat, 2022-10-15 at 21:41 +0200, Petr Menšík via networkmanager-list wrote: > Hi! > > I were traveling on a new train recently with working public wifi. > Because I use dns=dnsmasq on my laptop, I thought about new > connection.dns-over-tls setting I have discovered. > > I maintain also package stubby, which might be a great fit into > providing the service. Because dns over tls requires not only IP > address > of dns server, but also its name obtained with secure enough way. But > I > have not seen a way to specify it. DoT currently anyway only has an effect with systemd-resolved. But being unable to specify the server name is a missing feature: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/528 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1434 > But I thought, what if I wanted just > primary forwarder to be directed to a service providing DNS over TLS, > such as stubby? It configures forwarders, their names and certificate > pins. dnsmasq might still provide ability to configure different > domains > going to different server on connected LANs. But if NetworkManager > had > option to send forwarder 127.0.0.83 when DNS over TLS setting is on, > it > could provide per connection ability to use DNS over TLS over > untrusted > networks, but use plain UDP queries on trusted networks. > > To work, it would require: > > - manual configuration of stubby service to listen on alternative > address 127.0.0.83, not on default localhost > - Network Manager should start stubby.service after connection > requiring > dns over tls is activated. It might be possible to auto-start it by > some > systemd feature, but I think it won't know when it is no longer > necessary this way. > - Network Manager would replace DNS obtained from DHCP with stubby's > address only on connections setting dnsovertls=yes. > - Network Manager should stop stubby.service after all connections > requiring it are disconnected. > > I think it would require two new configuration options in > NetworkManager.conf: > > dnsovertls_ip=127.0.0.83 # whatever IP to use when it is activated > dnsovertls_service=stubby # what service to start and stop on > connection > activation > > While I think here about dnsmasq and stubby combination, it might > work > also with different provider. I think dnscrypt might be possible > example, altough I have never used it. in /run/ there are two files: /run/NetworkManager/no-stub-resolv.conf /run/NetworkManager/resolv.conf no-stub-resolf.conf contains the actual name servers (that NM would configure also in dnsmasq/systemd-resolved). When using a `[main].dns` plugin (dnsmasq/systemd-resolved), then "resolv.conf" usually just contains 127.0.0.1/127.0.0.53. -- granted, in a common setup with systemd-resolved, /etc/resolv.conf is a symlink, and NetworkManager wouldn't actually write that file (due to `[main].rc-manager=symlink` setting). But it still writes the internal /run/NetworkManager/resolv.conf. Anyway, there is precedence to writing localhost to resolv.conf. Except, it's not configurable much: - `[main].rc-manager` determines whether /etc/resolv.conf is written (but not *what* is written). - whether you have a DNS plugins, determines whether the nameservers in resolv.conf are redirected to localhost. > > What do you think about that? Sounds compliated :) > Is even NM able to start or stop services? NM would be able to start services via systemd. NM currently never directly talks to systemd, and we were always reluctant to add a feature that has such a dependency. Instead, NeworkManager uses D-Bus activation (with wpa_supplicant, systemd- resolved), requires the service already running (bluez, ModemManager) or spawns it themselves (teamd, dnsmaq). (Spawning processes ourselves is highly problematic and should be avoided). > Should it even attempt to control some? Are there some alternatives, > except using systemd-resolved only? I understand it manages its own > configuration per interface. I think other implementations do not > allow > that. Would it make sense to simplify per-connection setting of > secured > DNS also in UI? How woud you simplify the UI? The UI just mirrors the main configuration concept of NetworkManager: that you have connection profiles with configuration, which you activate/deactivate. With NetworkManager, if you don't think about "connection profiles", it's not clear how such an API could look (or a UI). > > Is there any plan to configure per-connection configuration of SNI > names > for TLS services? I think, the SNI should be "attached" to the configuration where the DNS server lies. Above MR extends the `ipv4.dns`, `ipv6.dns` properties, which however only works for manual, per-profile DNS settings. If you get the DNS server from DHCP, etc, then above MR cannot set the SNI. > Like dns.google for 8.8.8.8? I am not sure most user > needs it configured per
[meetup] Next Monthly NetworkManager Online Meetup (2022.09.14)
Hi, Tomorrow will be our montly online NetworkManager meetup. Everybody is welcome!! Bring a topic :) Details: https://mail.gnome.org/archives/networkmanager-list/2022-June/msg00011.html https://networkmanager.dev/community/meetup/ Sorry for the late announcement. I almost forgot about it :) Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Programmatically manage no-auto-default.state file?
On Wed, 2022-08-10 at 18:44 +0300, Andrei Borzenkov wrote: > On 10.08.2022 13:09, Thomas Haller wrote: > > On Wed, 2022-08-10 at 09:01 +0300, Andrei Borzenkov via > > networkmanager- > > list wrote: > > > When automatic connection is deleted/modified, interface is added > > > to > > > /var/lib/NetworkManager/no-auto-default.state. Is there any > > > device > > > property to show "no-auto-default" state? Is there any command/D- > > > Bus > > > API > > > to remove interface from this list? > > > > > > there is no such API. > > > > I guess you can delete the file, or modify it with "sed". That gets > > complicated, because NetworkManager only loads the file ones and > > writes > > it anew at unpredictable times. To get it right, you'd have to stop > > NM, > > modify the file, start NM. > > > > Btw, `sudo NetworkManager --print-config` prints the content of the > > no- > > auto-default.state flag. Note that as NetworkManager loads the file > > only once and remembers it, the running NetworkManager may not have > > cached what --print-config shows. > > > > OK, thanks. I overlooked this option. > > > > > Why do you want that? > > > > Mostly to reset NetworkManager state to clean default. Usually it is > frowned upon direct editing of internal state files and this file is > certainly internal state. That's a good choice to avoid internal state. In practice, the files in /var/lib/NetworkManager are reasonably simple. So if you edit them with the current understanding of how it is structured, also when upgrading to a newer NetworkManager version it must still work. That is, because when upgrading to a new NetworkManager version, NetworkManager must cope with the current form of those files anyway and it cannot break behavior in a bad way anyway. So while this is not stable API, we must reasonably stick to the behavior in the future. The bigger problem is that NetworkManager reads and writes those files at unpredicatable times. The only really correct way to handle it is by first stopping NetworkManager, the modifying the files, then (re)starting NetworkManager. > > If you say that editing it is OK it is fine for me. > To forget the state as if it were a reboot, delete /run/NetworkManager. To forget the state as if it were a factory reset, delete /var/lib/NetworkManager and /etc/NetworkManager. Graned, your distro might install some files in /etc/NetworkManager. Possibly it should avoid that. But it means you might want to take care before wiping /etc/NeworkManager. NetworkManager itself is fine to start without empty /etc/NetworkManager. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Programmatically manage no-auto-default.state file?
On Wed, 2022-08-10 at 09:01 +0300, Andrei Borzenkov via networkmanager- list wrote: > When automatic connection is deleted/modified, interface is added to > /var/lib/NetworkManager/no-auto-default.state. Is there any device > property to show "no-auto-default" state? Is there any command/D-Bus > API > to remove interface from this list? there is no such API. I guess you can delete the file, or modify it with "sed". That gets complicated, because NetworkManager only loads the file ones and writes it anew at unpredictable times. To get it right, you'd have to stop NM, modify the file, start NM. Btw, `sudo NetworkManager --print-config` prints the content of the no- auto-default.state flag. Note that as NetworkManager loads the file only once and remembers it, the running NetworkManager may not have cached what --print-config shows. Why do you want that? "no-auto-default" flag prevents the creation of the "Wired connection 1" profiles. The "Wired connection 1" profile gets generated for ethernet (depending on "no-auto-default" setting), so that you could boot a unconfigured machine, and it would connect automatically. E.g. if you boot a new VM, that it connects using DHCP. The device ends up in /var/lib/NetworkManager/no-auto-default.state because the user manually deleted or modified the generated "Wired connection 1". If the user did so already, then they are already "on the machine" and messed with it. At this point, if the user wants a profile, they can just create one and don't need to rely on "Wired connection 1". There is no other magic to "Wired connection 1". Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[meetup] Next Monthly NetworkManager Online Meetup (2022.08.10)
Hi everybody, Tomorrow will be our montly online NetworkManager meetup. Everybody is welcome!! Bring a topic :) Details: https://mail.gnome.org/archives/networkmanager-list/2022-June/msg00011.html https://networkmanager.dev/community/meetup/ Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Does NetworkManager support WiFi 6 IEEE 802.11ax USB wireless adapters?
On Sun, 2022-07-24 at 22:05 +0800, Turritopsis Dohrnii Teo En Ming via networkmanager-list wrote: > Subject: Does NetworkManager support WiFi 6 IEEE 802.11ax USB > wireless adapters? > > Good day from Singapore, > > Does NetworkManager support WiFi 6 IEEE 802.11ax USB wireless > adapters? Hi, I actually don't know. Would would be required for that? I think you cannot select 6 GHz bands. The lower layers are basically all handled by wpa_supplicant. Where would NetworkManager need to care? Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Changing IP on bridge without disconnecting VMs
On Wed, 2022-07-13 at 08:49 -0500, Dan Williams via networkmanager-list wrote: > On Wed, 2022-07-13 at 07:57 -0500, Chris Adams via networkmanager- > list > wrote: > > I have my primary ethernet interface configured in a bridge in NM, > > so > > that I can run VMs and have them on the local network directly. I > > needed to change the IP of the host system, but when I ran "nmcli > > con > > up > > br0", NM removed the VM virtual NICs from the bridge. > > > > Is there a way to do this differently so that wouldn't happen? > > It's > > not > > a common thing of course, but something I have needed to do before. > > I think this two step process might work for you: > > 1) update the connection to remove the old IP and add the new one, > with > something like: > > nmcli con mod +ipv4.addresses > nmcli con mod -ipv4.addresses > > 2) nmcli dev reapply What Dan says is correct. Just to add, there is also `nmcli device modify "$IFNAME" ipv4.addresses `, which does something similar, but without modifying the persistent profile. An that case, the change is ephemeral. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[meetup] Next Monthly NetworkManager Online Meetup (2022.07.13)
Hi everybody, as announced, tomorrow will be our montly online meetup. Everybody is welcome!! :) Details: https://mail.gnome.org/archives/networkmanager-list/2022-June/msg00011.html https://networkmanager.dev/community/meetup/ hope to see you. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Autoconnect backoff
On Wed, 2022-07-06 at 15:14 +0200, Sven Schwermer via networkmanager- list wrote: > Hi, > > I have a device with cellular modem running a Linux-based OS with > ModemManager/NetworkManager used for the connectivity management. > Occasionally, the cellular connection breaks and it takes several > connection attempts until the connection can be established again. > Currently, we have autoconnect-retries=0 for our cellular connection > so > there are infinite retries. This, however, can cause significant > system > load if the ModemManager connect (dbus) calls fail immediately which > occasionally happens. > > As far as I understand, NetworkManager will attempt a new > autoconnection > attempt right away after the previous attempt failed. The only way of > slowing this down is to set autoconnect-retries=1 which will cause > NetworkManager to wait for 5 minutes between attempts. This wait > duration seems to be fixed. > > Is there a way to make NetworkManager perform a backoff (e.g. linear > or > exponential) between connection attempts? Are there any other ways to > guarantee that the cellular modem is "always connected" without > having > NetworkManager to loop like crazy when a (re-)connection attempt > fails? > > Thanks and best regards, > Sven Hi what you say is correct. No, this is how it works. After autoconnect-retries, autoconnect gets blocked for 5 minutes. That is not configurable. Patch or suggestion for improvements welcome, however, it's not clear to me how to extend this so that it makes sense. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling periodic scans
On Fri, 2022-07-01 at 02:12 +0300, Slava Monich wrote: > > What I had in mind was a scenario when the device running network > manager has more than one Wi-Fi interface, and those are not > connected > (but have to be ready to be connected at any time). Passive scans > produce lots of D-Bus traffic, which creates serious load (I mean it, > really serious load) on the device. And yet, periodic scans on all > those > interfaces produce more or less the same list of networks, needlessly > wasting precious system resources. Hi, you mean, active scans, right? NM doesn't do passive scans (though it should). It's not clear that both devices will see the same scan result. E.g. one radio might be worse, or maybe one of them is 2.4GHz only... it seems non-trivial to select a device to use for scanning. Also, if there is a good algorithm for solving this problem reliably, then maybe this should be done by NetworkManager, because another serivce find it hard to understand all the subtleties for selecting a device for scanning. Also, I guess after one device finds an SSID, it would connect and you'd re-enable scanning on the other device? Imainge you have a profile for $SSID that is tied to "connection.interface-name=wlan0". When then scanning is only enabled on wlan1, then even if wlan1 finds $SSID, then you would need logic that recognizes that now scanning on wlan0 needs to be turned on. But of course, there is no guarantee that wlan0 will find $SSID, so you need logic to disable it again. Seems all non-trivial. Maybe, if the scanning is too resource intensive, then maybe we should -- after X minutes of scanning without success -- ratelimit the scanning and only scan 1 every 5 minutes. Or maybe, we could switch to passive scans for 4 out of 5 minutes... Btw, you can also just set the device as unmanaged. After all, if you are not going to scan, nothing interesting will happen on that device. For unmanaged devices we don't scan. There is a D-Bus API (and it does not survive reboot). Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[meetup] Announcing monthly online meetup for NetworkManager
Hi, In the past, we used to meet at Devconf.cz and also had virtual meetups in the past 2 years. There was always the idea floating around, that we could meet regularly and online. Now, such a meetup is scheduled. It will be every second Wednesday of the month. See https://networkmanager.dev/community/meetup/ It will be via google meet. There is no agenda. We will talk about whatever comes up and what *you* bring. It will not be recorded (unless, during a meetup we all agree to record it). The week before the meeing, I will send a short reminder on the list. Hope to see you :) Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Where does NetworkManager keep DHCP client lease data?
On Fri, 2022-06-24 at 17:39 -0700, Jim Garrison via networkmanager-list
wrote:
> When using dhclient, the current lease info, including expiration
> time, is in /var/lib/dhclient/dhclient.leases, and contains
> something similar to
>
> lease {
> interface "enp3s0";
> fixed-address [redacted];
> option subnet-mask 255.255.254.0;
> option dhcp-lease-time 3523;
> option routers [redacted];
> option dhcp-message-type 5;
> option dhcp-server-identifier 96.113.84.141;
> option domain-name-servers 127.0.0.1,75.75.75.75,75.75.76.76;
> option domain-search "[redacted]";
> option dhcp-renewal-time 2016;
> option broadcast-address 255.255.255.255;
> option dhcp-rebinding-time 3073;
> option domain-name "hsd1.or.comcast.net.";
> renew 3 2022/06/22 23:59:57;
> rebind 4 2022/06/23 00:23:15;
> expire 4 2022/06/23 00:30:45;
> }
>
> However, my system (Centos 8 Stream) uses NetworkManager which, based
> on
> my research, uses its own internal DHCP client. Looking in
> /var/lib/NetworkManager I see
>
> $ sudo ls -1 /var/lib/NetworkManager/
> internal-79cbd87e-9d65-4aa4-8768-88b460fd372c-enp3s0.lease
> internal-79cbd87e-9d65-4aa4-8768-88b460fd372c-ens1.lease
> internal-bdaf2eb0-de2e-4573-a415-214629c7b757-enp3s0.lease
> NetworkManager-intern.conf
> NetworkManager.state
> secret_key
> seen-bssids
> timestamps
>
> which looks promising. However, the lease files contain only the IP
> address. For example, the first file listed above contains only
>
> # This is private data. Do not parse.
> ADDRESS=[redacted]
>
> Simple question: Where does NetworkManager keep the lease data so it
> knows when it needs to renew the lease?
Hi,
the files in /var/lib/NetworkManager are internal not public API. That
of course does not prevent you from accessing it, but use with care.
That is also the case for the dhclient lease files. These files are not
supposed to give information about the lease.
You can see the current lease information on the D-Bus API, for example
via `nmcli -f ALL device show ens1` or `nmcli -f DHCP4 device show
ens1`.
In recent NM versions, you can also find the same information in
`/run/NetworkManager/devices/$IFINDEX` (if you prefer reading files).
This *is* public API.
A lease only makes sense to NetworkManager while it's running and
connected. It just knows in memory how long the lease is valid. I don't
think that works different when you use dhclient alone (not as
NetworkManager plugin). Well, maybe you could restart dhclient, and it
would have remembered that it had a lease. NM doesn't do that. If you
re-activate the device (or reboot or restart NM), it will try to get a
new lease and start the DHCP state machine again. It only uses the
previous ADDRESS= to give a hint to the DHCP server which address it
would like to have.
If the device is currently not active, then there is no public API for
past leases. Yes, you could parse the
/var/lib/NetworkManager/*.lease to get some some of the information,
but this only contains information which NetworkManger cares about (the
`ADDRESS=`), not most of the interesting data. It's anyway not clear
what you would like to know about past leases.
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Proposal to export mdns and llmnr enabled interfaces
Hi, On Fri, 2022-06-03 at 13:55 +0200, Petr Menšík via networkmanager-list wrote: > Hi! > > I would like to propose improvement with mdns (and possible llmnr) > resolution. Current Fedora and Ubuntu contains mdns4_minimal in > /etc/nsswitch.conf. Which means any name.local gets resolved by mdns > on > every interface and always. > > But network manager has configuration for mdns resolution on each > connection. I know it targets primary systemd-resolved, but I think > it > could export those information in a simple way for mdns nss plugin. > > For example into file /run/mdns.interfaces, which would change only > on > each connection change. It would be simple text file, containing on > each > line interface name followed by a list of supported address families. As this is run-time configuration, maybe it should be the ifindex. The ifindex tends to uniquely identify an interface. Not completely, if the signed 32 number wraps or if you move interfaces between namespaces, but still. On the other hand, interfaces can be renamed. Anyway. There are problably some conflicting requirements. E.g. the file should be simple to parse, but also be expressive and extensible with future features. Making it fully general (instead of specific only to nss- mdns) makes it potentially more useful. But it also makes it harder to design future proof. > > Current defaults in distribution resolve only over IPv4. I don't see > a > reason for that, so I would enable also IPv6 resolution on any > connection, which does not set ipv6.method to disabled. As long as it > has link-local IPv6 address, mdns might work. But could be restricted > to > connections having public IPv6 address eventually. > > nss-mdns plugin has separate mdns4_minimal (resolve over IPv4 only), > mdns6_minimal (resolve over IPv6 only) and mdns_minimal (resolve over > both). If it would be modified to read /run/mdns.interfaces before > each > query, it could just use single version and provide dynamic > behaviour, > while keeping simple logic in nss plugin. > > I would like to have similar possibility also for LLMNR protocol, > which > si very similar. But does not have any nss plugin in current > distributions. I would like to make one eventually. > > I would like to have simple way to allow or restrict multicast > resolution on some networks, like public transport or conferences. > Where > I don't trust other devices, so I don't want to ask them for names. > > What would you think? > > The overhead in NM seems minimal, yet it would allow good cooperation > with the system name resolution. Similar configuration could be also > provided by different service, like systemd-networkd or any other. > > What do you think about such change? It sounds like a good idea to me. Who would define this API? What does https://github.com/lathiat/nss-mdns think about this? :) Thank you for reaching out!! Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: cloned-mac-address not working when current mac is 00:00:00:00:00:00
Hi, On Thu, 2022-06-02 at 10:42 -0700, Aaron Brice via networkmanager-list wrote: > I'm using a yocto arm build of NetworkManager 1.32.10 on an embedded > device. There is a broadcom network device attached over PCIe that > comes up with a MAC of 00:00:00:00:00:00 on network device enp1s0, > and I am trying to manage it with NetworkManager. I set cloned-mac- > address to the mac that I want to assign to it. However when I try > to bring it up I get this helpful error: > > # nmcli con up ethernet-enp1s0 > Error: Connection activation failed: No suitable device found for > this connection (device enp1s0 not available because device is not > available). > > If I set the MAC to something else with "ip link set dev enp1s0 addr > " first, then the nmcli con up succeeds and sets the mac to the > value specified in cloned-mac-address. Is there a way to get this to > work on boot with just NetworkManager? My nmconnection file: Some drivers/NICs don't support changing the MAC address at all, or only badly. Seems you can change it, but maybe after changing it, the NIC takes a very long time to get carrier (cable-plugged in) back. If that's the case, maybe configure "carrier-wait-timeout". Read `man NetworkManager.conf`. In any case, check the level=TRACE log. Read [1] for hints about logging. If you read [1] about privacy concerns and are aware, you may also email it here. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L27 Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration improvement suggestion
On Mon, 2022-05-30 at 12:49 +0200, Petr Menšík wrote:
> On 5/28/22 22:22, Thomas Haller wrote:
> > As you say, NetworkManager can run dnsmasq as DNS plugin by
> > configuring
> > `[main].dns=dnsmasq` in `man NetworkManager.conf`.
> >
> > In that mode, NetworkManager will spawn the dnsmasq process.
> > Doing that is undesirable, for several reasons.
> >
> > I agree, it would be much better, if dnsmasq could run as a
> > separate
> > service. In the best case, dnsmasq could be D-Bus activated, then
> > it
> > doesn't even have to be a systemd service (altough, on systemd
> > systems,
> > of course systemd would start the dnsmasq service).
> >
> > When would dnsmasq reload those files? Usually, we would prefer
> > that
> > everything can be configured via D-Bus. Of course, if dnsmasq by
> > default runs without D-Bus, then that wouldn't work. What would
> > those
> > configuration snippes contain beside `enable-dbus`?
> I thought it could contain dnssec for selected networks. However that
> is
> not possible to set via dbus (or alternatives). It requires restart,
> because some structures are initialized different way. Just pure
> reconfiguration by re-reading config file is not enough. It would
> require no small changes in dnsmasq to allow enabling validation
> runtime.
If we had a system wide dnsmasq instance (that NetworkManager talks
to), then I think it would be up to the admin (or the distro default)
to set dnssec.
Likewise for enable-dbus. Just as the admin has to set `dns=dnsmasq2`
in NetworkManager.conf, they would also have to make sure that D-Bus is
enabled. IMO, D-Bus is just a useful and basic IPC mechanism, it's not
a cumbersome dependency that users need to avoid. So, I'd be fine if
that dnsmasq service is shipped with "enable-dbus" on by default. And
if not, it's up to the admin to change that.
What NetworkManager provides is per-interface configuration,
nameservers, DNS searches, and maybe some nameserver specific dnssec
settings. But not the basic dnssec/enable-dbus settings. Then,
NetworkManager would not need to drop conf snippets and not restart the
service.
If you compare with wpa_supplicant.service, it also is D-Bus
activatable and has D-Bus enabled... at least on distros where users
expect to use NetworkManager with wpa_supplicant. See `systemctl cat
wpa_supplicant.service`.
> > /etc/NetworkManager/dnsmasq.d is a semidocumented thing, where
> > users
> > could hack the setup by dropping snippets. I wonder how bad it
> > would be
> > to move away from the way how we do it currently. Maybe we could
> > symlink all files there from /run. Or maybe we would need to add a
> > separate dns=dnsmasq2 plugin for the new way.
> >
> >
> > I would prefer the notion that dnsmasq is just running as a stand-
> > alone
> > service, and NetworkManager can push interface-specific DNS
> > configuration to it (basically, like with systemd-resolved) and
> > also
> > with the notion that there could be other services that configure
> > their
> > part. For example, WireGuard's wg-quick could configure the DNS
> > server
> > on the WireGuard interface (though, currently I think that would
> > call
> > /usr/sbin/resolvconf -- unless systemd-resolved is detected).
>
> There is a problem that no generic interface good for reconfiguration
> of
> running services exist. resolvconf can configure something and
> openresolv package attempts to do such thing.
/usr/sbin/resolvconf would be such a generic API. It doesn't have to be
openresolv. For example, Fedora has no openresolv package. However
there is a resolvconf compat binary which directly talks to systemd-
resolved.
NetworkManager itself can be configured to call resolvconf and talk to
systemd-resolved's native API. But NetworkManager won't ever be a
provider of an resolvconf API. That is because NetworkManager is a
service that can configure your local caching DNS service, but it does
not pretend to be that service itself. If you currently use
`dns=dnsmasq` in NetworkManager, then you'll get a split-DNS setup, but
that is not extendable/accessible to to be configured by other tools.
Which can be a very fine thing for certain uses!! But we won't extend
that. What we could do, is that dnsmasq itself becomes a central
service that NetworkManager talks to ("dns=dnsmasq2").
If dnsmasq would want to fill the space of systemd-resolved, it either
needs a resolvconf backend, or provide a general API that independent
services can cooprerate on. NetworkManager won't need to talk
resolvconf however, it can directly implement dnsmasq's native API (as
it does today). For NetworkManager this API also doesn't need to be
"very general"
Re: dnsmasq integration improvement suggestion
On Fri, 2022-05-27 at 15:30 +0200, Petr Menšík via networkmanager-list wrote: > Hi! > > I were thinking how could be Network Manager's integration with > dnsmasq > improved. > > Today it is running separate service in NetworkManager.service. I > thought about possible solution and think have found solution. > > Dnsmasq can include all files with matching pattern from a directory. > On > Fedora, it uses /etc/dnsmasq.d for normal service and > /etc/NetworkManager/dnsmasq.d for dnsmasq running from dns=dnsmasq > mode > in NM. > > What if default dnsmasq.service just included also > /run/dnsmasq.d/*.conf? That would allow starting real dnsmasq.service > from NM. But it could add additional configuration snippet into > /run/dnsmasq.d/NetworkManager.conf, for example enable-dbus. It would > then be able to also enable dnssec validation just for some > connections. > When NM would need to stop dnsmasq, it would make this file empty. > > What do you think about this integration? Would it be better than > bundling dnsmasq into NetworkManager.service? > > Cheers, > Petr > As you say, NetworkManager can run dnsmasq as DNS plugin by configuring `[main].dns=dnsmasq` in `man NetworkManager.conf`. In that mode, NetworkManager will spawn the dnsmasq process. Doing that is undesirable, for several reasons. I agree, it would be much better, if dnsmasq could run as a separate service. In the best case, dnsmasq could be D-Bus activated, then it doesn't even have to be a systemd service (altough, on systemd systems, of course systemd would start the dnsmasq service). When would dnsmasq reload those files? Usually, we would prefer that everything can be configured via D-Bus. Of course, if dnsmasq by default runs without D-Bus, then that wouldn't work. What would those configuration snippes contain beside `enable-dbus`? /etc/NetworkManager/dnsmasq.d is a semidocumented thing, where users could hack the setup by dropping snippets. I wonder how bad it would be to move away from the way how we do it currently. Maybe we could symlink all files there from /run. Or maybe we would need to add a separate dns=dnsmasq2 plugin for the new way. I would prefer the notion that dnsmasq is just running as a stand-alone service, and NetworkManager can push interface-specific DNS configuration to it (basically, like with systemd-resolved) and also with the notion that there could be other services that configure their part. For example, WireGuard's wg-quick could configure the DNS server on the WireGuard interface (though, currently I think that would call /usr/sbin/resolvconf -- unless systemd-resolved is detected). best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is RFC 6731 supported?
On Fri, 2022-05-27 at 19:33 +0200, Petr Menšík via networkmanager-list wrote: > Hi, > > I have a quick question. I think Network Manager has own DHCP client > capabilities. Can it request RDNSS domain list specified in RFC 6731? > Were there any request to support it at least partially? > > Regards, > Petr > Hi, no, it does not request the option. The requested options are also not configurable for the internal DHCP plugin (when using dhclient plugin, you could edit some file in /etc). I don't remember a request about this. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wifi access point with zero signal
On Tue, 2022-05-24 at 12:17 +, Alexandre Bard wrote: > Hello, > > I am using networkmanager 1.22.10 and sometimes see a strange > behavior: > Our AP is showing in in the list but with a RATE and SIGNAL of "0" > and > is not connectable. > > # nmcli d wifi list > IN-USE BSSID SSID MODE CHAN RATE > SIGNAL BARS SECURITY > * 7C:97:63:70:3E:F8 ROBOT_TEST_AP Infra 1 0 Mbit/s > 0 WPA2 > > # nmcli d wifi connect ROBOT_TEST_AP password > Error: No network with SSID 'ROBOT_TEST_AP' found. > > > It happens sometimes in our automated tests, I don't have more > details > yet but it is likely that after just a few seconds or a rescan, the > AP > becomes connectable. > > It looks to me like a kind of race condition where the AP is listed > but > not actually ready. > > Does someone know if this is an expected behavior or if this has been > fixed in newer versions of NetworkManager ? > > > Best regards, > Alexandre Bard Hi, I don't know, but to debug this, please read https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1011#note_1400744 The log should tell you about the wifi scan result. Unless there is a bug, this is what wpa_supplicant exposes. Compare there. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unable to determine UID of the request whan adding a connection.
On Tue, 2022-05-17 at 08:34 +, Fr�d�ric Martinsons wrote: > Thank you for your quick response. > > > NetworkManager usually will authenticate the request using > > PolicyKit. > > -- unless, you set [main].auth-polkit in `man NetworkManager.conf` > > or > > make the request as root user. > > > > You say you don't use PolicyKit, so you set `[main].auth- > > polkit=false`? > > > > I compile NM with --disable-polkit configure option but I used a > custom NetworkManager.conf with didn't have [main].auth-polkit = > false. I'll add it to be sure it is not used. That merely changes the compile time default to set `[main].auth- polkit=false` implicitly. The PolicyKit code is always build, because it has no additional dependency (just talking D-Bus). But this is fine. > > > > The UID NetworkManager gets from dbus-daemon. It's not clear why > > that > > would fail. I presume, this is dbus-daemon, not dbus-broker? > > Yes, this is dbus-daemon. ACK. > > > Are you using `hidepid` mount option for procfs? It should also > > work > > with that, but it could cause problems. > > Nope, just rw, relatime ACK. Fine. > > > Or maybe you could run it under strace? However, that might be and > > overwhelming amount of information. I'd try patching the source and > > do > > some printf debugging. > > Yes, I already patch nm-dbus-manager.c to know exactly where it fails > but since then, I didn't manage to reproduce the issue after > countless attempts. > > The fact that the completion took 4s on error case is not of any help > to pinpoint where it fails ? We get the caller info (UID and PID) via D-Bus calls GetConnectionUnixUser and GetConnectionUnixProcessID (see _get_caller_info_ensure()). Both blockingly, with a timeout of 2 seconds (which would add up to 4 seconds). Maybe dbus-daemon does not reply in time? It's ugly that these calls in NetworkManager are done blockingly, but even so, we heavily rely on basic IPC to work, and if it's not working it's not clear how to proceed there. If that's the case, I don't know a solution. Trying dbus-broker is probably too much of an invasive change? Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unable to determine UID of the request whan adding a connection.
On Tue, 2022-05-17 at 06:51 +, Fr�d�ric Martinsons via networkmanager-list wrote: > Hello, > I used NM 1.32.12 in an embedded environment, I have another daemon > which is responsible for creating and monitoring connection profiles > via libnm. I recently experienced errors I cannot understand, I > received an error "Unable to determine UID of the request" in the > completion callback of nm_client_add_connection_async. > > Looking at the code , it leads to this function > (https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/ > 1.32.12/src/core/nm-dbus-manager.c#L1580) that return NULL. NetworkManager usually will authenticate the request using PolicyKit. -- unless, you set [main].auth-polkit in `man NetworkManager.conf` or make the request as root user. You say you don't use PolicyKit, so you set `[main].auth-polkit=false`? NetworkManager needs to find out information about the calling process, which usually means that the process needs to stick around long enoug (you cannot just make the D-Bus request and quit before waiting for the response). This is especially the case with PolicyKit enabled, but it probably is also the case for other reasons. Well, it seems your client tool is waiting for the D-Bus reply, so that isn't the problem. Are you using `hidepid` mount option for procfs? It should also work with that, but it could cause problems. The UID NetworkManager gets from dbus-daemon. It's not clear why that would fail. I presume, this is dbus-daemon, not dbus-broker? I don't know what would cause it. If you don't see sufficient information with full `level=TRACE` logs (see [1]), then maybe you could build NM from source, and add additional print messages? [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L27 Or maybe you could run it under strace? However, that might be and overwhelming amount of information. I'd try patching the source and do some printf debugging. good luck, Thomas > > src/core/nm-dbus-manager.c · 1.32.12 · NetworkManager / > NetworkManager > NetworkManager — network management daemon > gitlab.freedesktop.org > > The problem is there are no error/warning logs in NM which could help > me to understand (so I guess the various g_return_val_if_fail used in > the function are not reached). The only difference I see (beside the > error of course) is the completion time between the async request and > its response in my daemon (roughly 4 seconds in case of error instead > of practically instant). > > From what I understand, it is related to authorization check but > before this error, my daemon managed to create a NMClient and perform > various getter on it. > Several things that I can add for information: > - The system does not use polkit. > - NM runs as root and the client runs as a limited user. > - The problem is pretty hard to reproduce (see this two times on > several thousand of the same sequence). > > Can you please give advice on how I can investigate more on that ? > Maybe some particular traces to activate ? > > Thank you very much in advance for all the help you can bring. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: connection to disable an interface
On Sat, 2022-05-14 at 22:43 +0300, Andrei Borzenkov wrote: > On 14.05.2022 22:24, Thomas Haller wrote: > > Hi, > > > > > > On Sat, 2022-05-14 at 07:38 +0300, Andrei Borzenkov via > > networkmanager- > > list wrote: > > > > > > > > > > > > The background is a security requirement. Unused interfaces > > > > must > > > > ideally remain disabled at the physical layer when a cable is > > > > plugged > > > > in. Ideally, the LEDs would also remain dark. > > > > > > > > > > It sounds like > > > > > > no-auto-default=* > > > > > > mostly does what you want. > > > > > > that option merely disables that NetworkManager will automatically > > generate a profile for ethernet devices, that don't have a profile > > yet. > > Such profiles are called "Wired connection 1", which is how you can > > recognize it. > > > > This does very little magic, you can manually create a profile to > > the > > same effect. In any case, NetworkManager would have already set the > > interface IFF_UP at this point -- regardless of "(no-)auto- > > default". > > > > Sure, but usual question is - what are the expected threats? Simply > having interface up does not hurt anyone (except may be audit > company). > But having automatic profile on interface allows someone to connect > PC > with DHCP server and so get known IP address to (attempt to) access > the > server. This is prevented by no-auto-default. > you are right! Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: connection to disable an interface
On Fri, 2022-05-13 at 23:23 +0200, Adrian Freihofer via networkmanager- list wrote: > Hi > > Is it somehow possible to disable an interface via NetworkManager? > > I am thinking of something like: > > nmcli connection modify con-eth0 802-3-ethernet.phy disabled > nmcli connection up con-eth0 > > which would basically have the same effect as: > > ip link set eth0 down > > > nmcli connection modify con-eth0 802-3-ethernet.phy enabled > nmcli connection up con-eth0 > > which would basically have the same effect as: > > ip link set eth0 up > > > The background is a security requirement. Unused interfaces must > ideally remain disabled at the physical layer when a cable is plugged > in. Ideally, the LEDs would also remain dark. > > If this function does not exist yet, would it be interesting for > NetworkManager? > Could the functionality be implemented with reasonable effort or > would > it be difficult to implement? > > Thank you and regards, > Adrian no, what you ask for is currently not possible. NM always likes to set the interface up, because otherwise it wouldn't get a carrier event (to know whether a cable is plugged in). Doing that causes other difficulties, like when the device is "disconnected" in NetworkManager, then NetworkManager needs to set IPv6 addr-gen-mode "none". Otherwise, kernel would already add an IPv6 address, which is more than NetworkManager wants. What would be best, if kernel would allow to enable carrier-detection on an interface, without all the other things that "IFF_UP" brings. But what you ask for is very sensible. Just not done yet, and it's also not entirely clear what do to. "ethernet.phy no" seems odd to me, because you have to activate a profile to set it down. Also, most of the other settings of the profile would be meaningless with "phy no". What you already can do, is `nmcli device set $IFNAME managed no`. I think that is the way. The only problem with this is, that NetworkManager will give up the interface and leave it to the user an a not well-defined state. What would even be the right state? If the device is currently connected, I partly think that NM should just leave everything up (including all IP addresses). The advantage of that would be, that setting a device unmanaged does not disconnect you right away. On the other hand, if the device is currently disconnected and you set it unmanaged, then I think the addr-gen-mode will stay at "none". That is confusing to the user, because IPv6 does not work without modification. Or should NM always deconfigure it? Maybe it is indeed the latter, and then NM should also set the interface down. Patch welcome, but maybe first discuss what it should do in detail :) Thank you. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: connection to disable an interface
Hi, On Sat, 2022-05-14 at 07:38 +0300, Andrei Borzenkov via networkmanager- list wrote: > > > > > > The background is a security requirement. Unused interfaces must > > ideally remain disabled at the physical layer when a cable is > > plugged > > in. Ideally, the LEDs would also remain dark. > > > > It sounds like > > no-auto-default=* > > mostly does what you want. that option merely disables that NetworkManager will automatically generate a profile for ethernet devices, that don't have a profile yet. Such profiles are called "Wired connection 1", which is how you can recognize it. This does very little magic, you can manually create a profile to the same effect. In any case, NetworkManager would have already set the interface IFF_UP at this point -- regardless of "(no-)auto-default". Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New connection appears after unplugging Ethernet
On Sun, 2022-04-24 at 22:00 +, Martin wrote: > Dears, > > when I *unplug* the Ethernet of my laptop computer, a new connection > "enp0s25" appears out of the nothing. When I plug the Ethernet in > again, > my usual connection "Wired" is automatically used, probably because > the > other connection "enp0s25" is active? > > Before unplugging: > > NAME UUID TYPE DEVICE > Wired 6... ethernet enp0s25 > > After unplugging: > > $ nmcli con > NAME UUID TYPE DEVICE > enp0s25 c... ethernet enp0s25 > Wired 6... ethernet -- > > Maybe relevant software versions (Debian testing): > > linux-image-5.16.0-6-amd64 5.16.18-1 > network-manager 1.36.4-2 > udev 250.4-1 > > How can I prevent a new Ethernet connection on *unplugging* Ethernet? > Thanks in advance! > > Cheers Hi the profile with the same name as the device, is usually generated by NetworkManager in response to an external configuration. You'd see "connected (externally)" in `nmcli device`. That usually means that some other program is configuring the device. Or it would be a bug... to investigate, check the `level=TRACE` log. Read [1] [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L27 best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is anybody using [main].dns=unbound (dnssec-trigger) plugin with NetworkManager?
Hi, On Tue, 2022-04-12 at 08:30 +0200, Thomas Haller wrote: > NetworkManager supports DNS plugins: "dnsmasq", "systemd-resolved" > and "unbound". > > "unbound" was added a long time ago ([2], [3]), but is the most > incomplete. > It only spawns "/usr/libexec/dnssec-trigger-script". It does so > blockingly, > which is problematic ([1]). > > The plugin is really a part of dnssec-trigger, but that doesn't > actually use > the NM "unbound" plugin, instead it installs a dispatcher script. > > > I think this plugin should be dropped. > > Would you care? Are you using it? Please report back, if that's the > case. > I'd be surprised of any users, but I'd like to hear. > > > [1] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/b6eb237a271c91f6ca9d74f0db8f7e80b9998d51/src/core/dns/nm-dns-unbound.c > [2] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/186e4dcf7a0ebdd7432cf3e34d426b9d58bb85bc > [3] https://bugzilla.gnome.org/show_bug.cgi?id=699810 Dropped by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/5da17c689be5e66ea2f63dea6f1846625e652998 If this causes problems for you, please reach out. Thanks. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Is anybody using [main].dns=unbound (dnssec-trigger) plugin with NetworkManager?
Hi all, NetworkManager supports DNS plugins: "dnsmasq", "systemd-resolved" and "unbound". "unbound" was added a long time ago ([2], [3]), but is the most incomplete. It only spawns "/usr/libexec/dnssec-trigger-script". It does so blockingly, which is problematic ([1]). The plugin is really a part of dnssec-trigger, but that doesn't actually use the NM "unbound" plugin, instead it installs a dispatcher script. I think this plugin should be dropped. Would you care? Are you using it? Please report back, if that's the case. I'd be surprised of any users, but I'd like to hear. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/b6eb237a271c91f6ca9d74f0db8f7e80b9998d51/src/core/dns/nm-dns-unbound.c [2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/186e4dcf7a0ebdd7432cf3e34d426b9d58bb85bc [3] https://bugzilla.gnome.org/show_bug.cgi?id=699810 Thanks!! Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Centos Stream 9: NetworkManager/conf.d/ override mtu received from dhcp
Hi, On Wed, 2022-03-30 at 22:56 +, Stephen Horton via networkmanager- list wrote: > Hello, I'm new to the list; I am working on moving an application to > Centos Stream 9 running inside an openstack cloud virtual guest. I > have created: > /etc/NetworkManager/conf.d/90-dns-none.conf: > [main] > dns=none > to prevent Network Manager from overwriting the /etc/resolv.conf with > incorrect DNS server entries from our DHCP service. This is working. > > I also need to tell Network Manager to override the MTU provided by > the DHCP service (which is telling my interfaces to use mtu=9000). I > have created: > /etc/NetworkManager/conf.d/91-mtu-none.conf: > [connection] > match-device=interface-name:eth0 > ethernet.mtu=0 this sets global defaults in NetworkManager.conf. This is documented in `man NetworkManager.conf`. While you can do this, it seems preferable to not change the default, but change the actual setting in the respective profile. nmcli connection modify "$PROFILE" ethernet.mtu 1500 OK, granted, setting "ethernet.mtu=0" is documented to have a very specific additional behavior, that is: If configured explicitly to 0, the MTU is not reconfigured during device activation unless it is required due to IPv6 constraints. Hm, the text reads as this should work. Maybe there is a bug in handling `ethernet.mtu=0` in `NetworkManager.conf`. > then: systemctl reload NetworkManager This reloads configuration from NetworkManager.conf. That has no effect on devices that are currently activated. To change the configuration of a device, activate a profile with `nmcli connection up $PROFILE`. If the device is already activated, then re-activate the profile with `nmcli connection up $PROFILE`. You can also use `nmcli device reapply $IFNAME` or `nmcli device modify $IFNAME`, which does something slightly different but is a way to change runtime configuration too. If you care about the difference, read `man nmcli`. Otherwise, just do a full re-activation with `nmcli conneciton up $PROFILE`. > I can then: nmcli device modify eth0 ethernet.mtu 1500 and it > changes the mtu to 1500 (shown in: ip address show). However, when I > reboot, it changes back to mtu 9000. `nmcli device modify` modifies the current runtime configuration. Read `man nmcli` about what it does. Usually, adjust the profile with `nmcli connection modify` and activate the desired profile with `nmcli connection up`. > > ifcfg-eth0 file still contains MTU=9000 A profile on disk gets modified by `nmcli connection modify $PROFILE` (and a few other special cases, like when a system-wide password is provided during activation). > > Can someone provide some guidance on how this should work please? > Maybe https://www.redhat.com/sysadmin/becoming-friends-networkmanager is a useful introduction? best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is gtk4 support in libnma still EXPERIMENTAL?
On Thu, 2022-03-24 at 10:47 +0100, Michael Biebl wrote: > Am 13.03.22 um 22:18 schrieb Thomas Haller: > > On Sun, 2022-03-13 at 16:01 +0100, Michael Biebl wrote: > > > > > > Am 13.03.22 um 12:46 schrieb Thomas Haller: > > > > On Sat, 2022-03-12 at 21:55 +0100, Michael Biebl wrote: > > > > > > > > ./usr/lib/x86_64-linux-gnu/girepository-1.0/NMA4-1.0.typelib > > > > > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so > > > > > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0.0.0 > > > > > ./usr/lib/x86_64-linux-gnu/pkgconfig/libnma-gtk4.pc > > > > > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0 > > > > > ./usr/share/vala/vapi/libnma-gtk4.vapi > > > > > ./usr/share/vala/vapi/libnma-gtk4.deps > > > > > ./usr/share/gir-1.0/NMA4-1.0.gir > > > > > > > > > > > > yes. I think it's fine. is there a problem? > > > > > > > > You cannot load gtk3 and gtk4 in the same application, and > > > > consequently, you cannot load libnma.so (gtk3) and libnma-gtk4 > > > > together. > > > > > > > > libnma is a GUI library based on GTK. It seems not unreasonable > > > > that > > > > the GTK version is part of the library name -- in particular, > > > > as > > > > there > > > > might come GTK5 in the future. > > > > > > > > These are really two different libraries (with very similar API > > > > and > > > > the > > > > same underlying sources). > > > > > > I see the necessity and maybe this is just bike shedding on my > > > side > > > but > > > I'd personally prefer the gtk part being dropped, so the soname > > > becomes > > > libnma-4.so.0 > > > And correspondingly libnma-4.pc (libnma4.pc would be fine as > > > well). > > > > > > Or do we have some prior art where the gtkX string is encoded in > > > the > > > library soname? > > > > > > I also find it a bit inconsistent that the gobject instrospection > > > files > > > do not have GTK string embedded. > > > > Hi, > > > > > > I tend to agree. > > > > but it might be too late for that... even if it was announced as > > experimental :) > > > > Lubomir, wdyt? > > Could we have some definitive answer if the naming is going to stay? > I have a request in Debian to enable gtk4 support in libnma but > before > doing that, I'd like to have an answer here first. hi it's gonna stay. Lubomir argued that the name is actually good. In the meantime there are now also two releases (1.8.34 and 1.8.36). At this point, it would seem a bad idea to rename -- regardless any arguments in favor. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN Killswitch and keep-connection-alive toggles or scripts
On Thu, 2022-03-24 at 23:01 +, rherr via networkmanager-list wrote: > I have Alpine Linux with the OpenVPN plugin. This works very well > importing and automatically installing my .ovpn file. I like the > settings menus and this makes the setup very easy. I haven't found a > VPN killswitch or always on (persistent) connection feature anywhere. > I also have nftables on my system. I read that nftables is the new > standard for Linux. I have done a killswitch and always on feature > using mods to a file (using "nano") and with "ufw" (firewall) on an > Ubuntu system before nftables became the standard. > > I am comfortable with working in the terminal and making mods to > files. I don't know anything about nftables. Is there a way to get > the features onto my system? Thanks for any advice. is your question how tou migrate your ufw setup to nftables? I think nfw is just on top of iptables, so in the best case it would abstract the underlying firewall system (iptables/nftables) for you. If ufw doesn't, you may need to rewrite your firewall rules. nftables also provides an iptable compatibility tool. That is, my /usr/sbin/iptable symlinks to an nftables binary. So maybe nfw doesn't need to change? Finally, there is also firewalld, which abstracts between iptables and nftables... firewalld is an alternative to ufw. anyway. I don't know. This is probably not the best place to ask for advice on nfw/nftables :) best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PSK+SAE when creating an Access Point
On Tue, 2022-03-22 at 11:52 +0100, Alfonso Sanchez-Beato via networkmanager-list wrote: > Hi there! > > I have been using NetworkManager 1.36.2 to create an Access Point, > but I am having some problems. Only devices that support WPA3 are > able to connect to the AP. Looking at the history, I see that > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/f5d78c2d289c9e4a4c247d2520c7c3e2baf537c8 > introduced a change that configures wpa_supplicant to be able to > connect to any of WPA, WPA2 or WPA3 and choose the best candidate. > However, it looks like this is breaking the hotspot case, at least > for me - when I revert the change I am able to connect again from > WPA2-only devices. > > I have seen these problems on > * An intel NUC with Intel wifi driver > * On a VM, when loading mac80211_hwsim with two radios (one for > hotspot, the other for connecting to it) > > Kernel version is 5.15.0 and wpa_supplicant is 2.10. Is this a bug or > maybe a more modern wpa_supplicant is needed? > > Thanks, > Alfonso Hi, sounds related to https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638#note_1306214 ? best Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is gtk4 support in libnma still EXPERIMENTAL?
On Sun, 2022-03-13 at 16:01 +0100, Michael Biebl wrote: > > Am 13.03.22 um 12:46 schrieb Thomas Haller: > > On Sat, 2022-03-12 at 21:55 +0100, Michael Biebl wrote: > > > > ./usr/lib/x86_64-linux-gnu/girepository-1.0/NMA4-1.0.typelib > > > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so > > > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0.0.0 > > > ./usr/lib/x86_64-linux-gnu/pkgconfig/libnma-gtk4.pc > > > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0 > > > ./usr/share/vala/vapi/libnma-gtk4.vapi > > > ./usr/share/vala/vapi/libnma-gtk4.deps > > > ./usr/share/gir-1.0/NMA4-1.0.gir > > > > > > yes. I think it's fine. is there a problem? > > > > You cannot load gtk3 and gtk4 in the same application, and > > consequently, you cannot load libnma.so (gtk3) and libnma-gtk4 > > together. > > > > libnma is a GUI library based on GTK. It seems not unreasonable > > that > > the GTK version is part of the library name -- in particular, as > > there > > might come GTK5 in the future. > > > > These are really two different libraries (with very similar API and > > the > > same underlying sources). > > I see the necessity and maybe this is just bike shedding on my side > but > I'd personally prefer the gtk part being dropped, so the soname > becomes > libnma-4.so.0 > And correspondingly libnma-4.pc (libnma4.pc would be fine as well). > > Or do we have some prior art where the gtkX string is encoded in the > library soname? > > I also find it a bit inconsistent that the gobject instrospection > files > do not have GTK string embedded. Hi, I tend to agree. but it might be too late for that... even if it was announced as experimental :) Lubomir, wdyt? best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is gtk4 support in libnma still EXPERIMENTAL?
On Sat, 2022-03-12 at 21:55 +0100, Michael Biebl wrote: > Am 12.03.22 um 21:47 schrieb Michael Biebl: > > > > Hi there, > > > > there has been a flurry of updates for nm vpn plugins adding > > support for > > GTK4. All of them require a libnma built with GTK4 support which is > > still marked experimental. > > > > I haven't seen any real follow up commits in libnma dealing with > > GTK4 > > issues, so I wonder if the EXPERIMENTAL status is still true or if > > it's > > safe to enable support for it (say in the Debian package). > > Related to that, are you really considering embedding gtk4 into the > soname and pc file name? > > > ./usr/lib/x86_64-linux-gnu/girepository-1.0/NMA4-1.0.typelib > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0.0.0 > ./usr/lib/x86_64-linux-gnu/pkgconfig/libnma-gtk4.pc > ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0 > ./usr/share/vala/vapi/libnma-gtk4.vapi > ./usr/share/vala/vapi/libnma-gtk4.deps > ./usr/share/gir-1.0/NMA4-1.0.gir yes. I think it's fine. is there a problem? You cannot load gtk3 and gtk4 in the same application, and consequently, you cannot load libnma.so (gtk3) and libnma-gtk4 together. libnma is a GUI library based on GTK. It seems not unreasonable that the GTK version is part of the library name -- in particular, as there might come GTK5 in the future. These are really two different libraries (with very similar API and the same underlying sources). best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is gtk4 support in libnma still EXPERIMENTAL?
On Sat, 2022-03-12 at 21:47 +0100, Michael Biebl wrote: > > Hi there, > > there has been a flurry of updates for nm vpn plugins adding support > for > GTK4. All of them require a libnma built with GTK4 support which is > still marked experimental. > > I haven't seen any real follow up commits in libnma dealing with GTK4 > issues, so I wonder if the EXPERIMENTAL status is still true or if > it's > safe to enable support for it (say in the Debian package). hi, it was called "experimental" in the NEWS file for "libnma-1.8.32" a few weeks ago. Otherwise, I don't see that libnma-gtk4 is marked as expirmental (is it?). In general, we don't have a strong definition what it means that something is experimental. The word was IMO used informally in the NEWS file. We don't take that as an excuse to cause unnecessary(!) harm to downstream/users by breaking API. If you have a GTK4 application that needs libnma, then you are gonna need the libnma-gtk4 version. Out of necessity, it's reasonable to start using libnma-gtk4 now. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding experimental arguments to nmcli tool
On Tue, 2022-03-08 at 22:15 +0100, Thomas Haller wrote: > of course, that's just an example to show all pieces. Above could be > written shorter as: > > nmcli connection modify $PROFILE --keyfile | \ > nmcli connection modify keyfile \ > connection.uuid $(uuidgen) \ > autoconnect no > interestingly, if you don't modify the UUID, then the profile would already exist, and the command would not add a new profile, but actually overwrite the existing one. Actually, we could in general support nmcli connection modify "$PROFILE" connection.uuid $(uuidgen) $OPTIONS as a way to add/clone a profile, and modifying it ... and determining the UUID (currently you cannot specify the UUID of a new profile via nmcli). That would be then similar to the existing nmcli connection clone $PROFILE1 $NAME2 except, that clone currently does not support $OPTIONS -- but it really should, for completeness. I am not saying that all these options should be actually implemented (especially not in step 1). But that they might make sense in the grand scheme of things. So it's useful to think about how that would be. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding experimental arguments to nmcli tool
Hi, On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via networkmanager-list wrote: > Hello everyone! > > The proposed experimental solutions are: > > 1. 'nmcli c show --keyfile $UUID' to output the profile keyfile in > stdout. > 2. 'nmcli c add ... --keyfile' to output the generated keyfile in > stdout > instead of adding it to the NetworkManager configuration so the > NetworkManager daemon is not required.. re:2.: this `nmcli c add --keyfile` does not actually add the profile in NM (via D-Bus). That's a bit odd, but ok(?). what you also need is: 3. I think in this set, it would also make sense to have a `nmcli c modify "$PROFILE" --keyfile $OPTIONS`, which reads $PROFILE from D-Bus, modifies it in-memory and prints the result to stdout. 4. none of the above commands allow to add a profile from stdin. That is necessary to tie it all together. This could be for example `nmcli connection modify keyfile $OPTIONS`. Here, "keyfile" means to read a keyfile from stdin. The result would be then added via D-Bus -- which is a bid odd, that `nmcli connection modify` creates a new profile in NM. On the other hand, it really does take a profile (from stdin), modify it, and add it somewhere. 5. finally, `nmcli connection modify keyfile --keyfile $OPTIONS` would read the profile from stdin, modify it, and output again to stdout. then you can do: nmcli connection modify $PROFILE --keyfile | \ nmcli connection modify keyfile \ connection.uuid $(uuidgen) \ autoconnect no \ --keyfile | \ nmcli connection modify keyfile of course, that's just an example to show all pieces. Above could be written shorter as: nmcli connection modify $PROFILE --keyfile | \ nmcli connection modify keyfile \ connection.uuid $(uuidgen) \ autoconnect no these are the basic operations. I don't have a strong opinion about the actual command line options (though, I find it odd that `nmcli-c- modify` adds a profile). --- also, when editing/outputting keyfile format, eventually you want to write it to a file. With above, the user could do: nmcli connection show $PROFILE --keyfile > /etc/NetworkManager/system-connections/myfile.nmconnection the problem with this is that umask is likely wrong, so you'd need to do `chmod 600` (and `nmcli connection load $FILENAME`). Maybe --keyfile could accept a filename, like nmcli connection show $PROFILE --keyfile=/etc/NetworkManager/system-connections/myfile.nmconnection so that nmcli gets the permissions right and (opt-in or opt-out) load the file in NM. Also, keyfiles can only be in 3 well-known locations: A) /var/lib/NetworkManager/system-connections/ B) /etc/NetworkManager/system-connections/ C) /run/NetworkManager/system-connections/ these are the default paths, but they depend on the $PREFIX during compilation. Also, B) can be configured in NetworkManager.conf as [keyfile].path. Anyway. With this, maybe it would make sense to have shortcuts: nmcli connection show $PROFILE --keyfile=etc:myfile.nmconnection best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding experimental arguments to nmcli tool
On Tue, 2022-03-08 at 14:57 +0100, Till Maas wrote: > Hi, > > Am Mo., 7. März 2022 um 22:38 Uhr schrieb Thomas Haller via > networkmanager-list : > > Hi, > > > > On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via > > networkmanager-list wrote: > > > > > > It has been considered to add experimental new arguments to > > > 'nmcli' > > > tool > > > related to keyfiles. These arguments will be added with a warning > > > message on documentation specifying they are experimental. The > > > main > > > idea > > > is to experiment and not commit to them for a long time. > > > > re:experimental. > > > > I don't think it's good to mark new API as experimental. Breaking > > API > > is annoying to users, and should only be done if there are very > > very > > good reasons or when no users are affected. Otherwise, the > > annoyance is > > the same regardless whether the API is marked as experimental. With > > the > > difference, that if the API was experimental, it has the notion of > > being the fault of the user using the API (which it really isn't). > > > > > Currently, the API is not delivered to users since there is no > agreement on how to do it. > For example the features that Fernando mentioned are not that complex > to code but hard to find an agreement on for the command-line flags. > Therefore, the possible annoyance of users is solved by not giving > them a choice at all, They simply cannot use the API, therefore they > will also not have to change it. By delivering something as > experimental, the users get a choice: They > can use it and accept that they might have to adapt or they can > choose not to use it and be in the same situation as if we did not > deliver the API at all. Basically, we will provide additional value > to early adopters, unblock our development (the code can be written > already) and once there is an agreement on the final API, only small > changes would be necessary if at all. Therefore, adding experimental > features seem to be an overall benefit. Let's just discuss how the feature should be done. Which is not a very controversial or hard question. I think it's not necessary to have a meta discussion about the process how we do it. And it's not necessary to introduce an "experimental" API, when we can just add the real thing. We can find agreement on the real thing, at which point it's not experimental. That in the future the choice might turn out to be suboptimal, is always the danger and not special about this. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: CSME integration - next steps, network selection
On Tue, 2022-03-08 at 08:35 +0200, Emmanuel Grumbach via networkmanager-list wrote: > I realized I am missing a piece before this. > I need to be able to get and handle nl80211 events, which means that > I > need a thread or event loop or something that listens to the nl80211 > channel and parses events. The event I need is the end of the > connection from the CSME side. This brings to the fundamental > question > of the threading model in NetworkManager. > Do we have a sort of event loop? Looks like the NetworkManager runs > on > an event loop and very few things run in a different thread, but I > couldn't really see any clear information about it. Hi, we use a glib mainloop. Read https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/ There is only one thread (except, that GDBus spawns a worker thread internally and that we might do a blocking write to sysctl on a thread, but NM itself is for the most case single threadded). In this case, you would poll on the file descriptor. So use `nm_g_unix_fd_add_source()`. best, Thomas > > Thoughts? > > Thanks :) > > Emmanuel Grumbach > egrumb...@gmail.com > > On Mon, Mar 7, 2022 at 5:00 PM Emmanuel Grumbach > wrote: > > > > Hi, > > > > Next steps about the CSME integration :) > > Now the flow I need is to do the following in case os_owner is > > false: > > List all the connections configured on wifi > > * If none match what we got from CSME - we do nothing and wait > > until CSME will remove the rfkill > > * If there is a match, we need pick that connection but > > connect > > to the same bssid as CSME was connected to > > Then we can ask for ownership > > > > I saw there is nm_setting_wireless_get_bssid which will tell us if > > the > > connection has a bssid (not sure I am correct here) and if there is > > a > > bssid, we'll connect to that same AP. Is that something I can use? > > > > Maybe I should create another connection with a specific bssid and > > "disable" all the others? not sure what's the right way to go here. > > Another thing we'll need is to limit the scan on the channel on > > which > > the AP we look for is working. We don't want to waste time to scan > > all > > the channels. The supplicant has a configuration for that. > > > > Any guidance will be appreciated :) > > > > I'll continue digging anyway. > > > > Thanks! > > > > Emmanuel Grumbach > > egrumb...@gmail.com > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding experimental arguments to nmcli tool
Hi, On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via networkmanager-list wrote: > > It has been considered to add experimental new arguments to 'nmcli' > tool > related to keyfiles. These arguments will be added with a warning > message on documentation specifying they are experimental. The main > idea > is to experiment and not commit to them for a long time. re:experimental. I don't think it's good to mark new API as experimental. Breaking API is annoying to users, and should only be done if there are very very good reasons or when no users are affected. Otherwise, the annoyance is the same regardless whether the API is marked as experimental. With the difference, that if the API was experimental, it has the notion of being the fault of the user using the API (which it really isn't). We can never be 100% sure that an API is perfectly future proof. We can just think hard and try to make the best choices now. And if something turns out not to be optimal, we treat that like we always do. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: CSME firmware / host coexistence - grab the CSME connection info params
On Sat, 2022-02-26 at 23:37 +0200, Emmanuel Grumbach via networkmanager-list wrote: > Hi, > > I'd like to get some guidance on how to continue the implementation > of the CSME firmware coexistence. > We now need to fetch the connection parameters from CSME (through the > kernel). There is a vendor command API in the kernel. This works > above the nl80211 channel. > > So should I include the header file in src/libnm-platform/wifi/nm- > wifi-utils-nl80211.c ? > OTOH, only recent kernels have this header, so what's the way to ask: > try to include this, if you don't have it, let's disable the feature? > Should I use this type of ifdef: > #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 27) > ? > Do you prefer to have a separate nm-wifi-utils-intel-vnd.c file since > it exists only as an Intel Vendor command? > Should I create a new handler in NMWifiUtilsClass for that purpose? > > Then, the nm core code could use the NMWifiUtilsClass to fetch the > data when it sees that RFKILL is asserted with the reason = > "OS_NOT_OWNER". > > Thanks :) Hi, Btw, what means "vendor" when you say "vendor command API"? It is kinda important to us, is that the feature can be used with an upstream kernel (without propritary modules -- and preferably only with upstream modules). Which header is this? Usually, we want to build a version of NetworkManager that supports most features, regardless against which kernel (headers) it was build. Because, you should be able to upgrade your kernel and get the feature automatically. It means, we would rather fail at runtime, if kernel doens't support it. That means, we either add a fork of the header in `src/linux-headers`. Alternatively, if we only require a few defines, you can copy them directly to the source file where needed. It depends on how much is needed. If this gets fetched via nl80211, then src/libnm-platform/wifi/nm- wifi-utils-nl80211.c is the right place. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Set APN protocol for mobile modem
On Fri, 2022-02-11 at 13:54 +0100, Edouard Debry via networkmanager- list wrote: > > Hello, > > I run mobian on a pinephone. > > When mobile data is turned on, the phone receives an ipv6 only > address. Trouble is that it seems to break connexion sharing. > > Some people solved this issue by setting their APN protocol back to > ipv4. However, I cannot find this option on the gnome user interface, > I can only choose the APN name. > > But I am sure I can force the APN protocol by writing it directly to > NetworkManager's configuration files. > > Could someone gear me towards the correct configuration file ? Hi, `nmcli connection` to see all profiles. `nmcli connection show "$PROFILE"` to see the details of one profile. `nmcli connection modify "$PROFILE" ...` to change a profile. but it's not clear how IPv6 "breaks connection sharing". That seems not right. Maybe better find out what is really happening. Check the resulting IP configuration with `ip addr` and `ip route` to possibly understand what is wrong. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager Community Meetup at DevConf.CZ 2022
Hi Everybody, as in the past iterations of DevConf.CZ and DevConf.US, we will again have a slot for our NetworkManager community meetup. This will be a virtual meeting on Saturday, January 29, 2022. We will just meet and discuss NetworkManager and related topics. There is no fixed agenda. If you are interested, join us! https://www.devconf.info/ https://devconfcz2022.sched.com/event/siK0/networkmanager-community-meetup-devconfcz-2022 If you have questions, you can find us on IRC (#nm on LiberaChat) or reply to this email. See you, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: System-Wide 802.1x configuration?
Hi, On Wed, 2021-12-29 at 14:20 +0100, Jonas Bygdén via networkmanager-list wrote: > Today we configure our Linux clients to use wired 802.1x on the on- > board ethernet interface in the laptops they get. If I understand you correctly, you pre-configure machines for others (like students or employees). > > Some users choose to connect their laptop to a monitor using USB-C, > and then using the ethernet interface that's built-in to the monitor. > This changes the interface/connection and hence it doesn't have the > pre-configured 802.1x, requiring a new configuration of 802.1x for > that interface as well. > > So, my question is: Is it possible to configure 802.1x for all > connections at once, globally "system wide", instead of on a "per > connection" basis? Making the 802.1x configuration work regardless of > which interface/connection is used to connect to the (wired) network? What would mean "globally system-wide"? You need configuration for configuring a network interface. That configuration is the connection profile. And since there are profiles, there is no need to have a concept for "global system-wide" configuration. Just create/predeploy such a profile yourself. a connection profile "matches" on a device based on certain properties. For example, if you have an ethernet profile that does not specify "connection.interface-name", then it would apply to any ethernet device (unless it's restricted via some other property, like "ethernet.mac- address", "match.*"). It would sound, that you want that your profile is applicable to any device. Usually, a profile can only be activated once at any given moment. You could instead configure "connection.multi-connect=multiple", to activate on multiple devices at the same time. However, that might not make sense for your usecase and is probably not a good idea (because it's confusing). best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Overriding IP4.DNS values on an interface
On Tue, 2021-12-14 at 23:53 +0100, Juan A. Rubio via networkmanager-
list wrote:
> Hello,
>
> I'm using Network Manager v1.22.16
>
> I've got an eth0 connection profile configured for DHCP ([ipv4] ->
> method=auto)
>
> When the connection profile is enabled, two DNS servers are received
> on that particular interface, e.g.:
>
> $ nmcli dev show eth0
> ...
> IP4.DNS[1]: 10.27.30.201
> IP4.DNS[2]: 10.27.30.202
> ...
>
> All good.
>
> Let's say that now I want to override the DNS server list on that
> interface and remove those two DNS servers to add my own DNS server,
> e.g. I want this scenario:
>
> $ nmcli dev show eth0
> ...
> IP4.DNS[1]: 10.27.30.203
> ...
>
> Is there a way to do this with nmcli or the DBUS apis?
>
> Thanks in advance
> Juan
Hi,
NetworkManager is all about configuring profiles ("connections") and
activating them.
Hence, you configure the corresponding profile with the DNS setting.
- See all profiles with `nmcli connection`.
- See the setting of a profile with `nmcli connection show "$PROFILE"`.
- Modify a profile with `nmcli connection modify "$PROFILE" ipv4.dns 8.8.8.8
ipv4.ignore-auto-dns yes`.
- (Re-)Activate the profile with `nmcli connection up "$PROFILE"`.
- See activated devices with `nmcli device`
See `man nm-settings` or `man nm-settings-nmcli`.
nmcli only talks to the public D-Bus API. So of course all these steps
could also be done by using the D-Bus API directly.
best,
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How do I build the networkmanager
On Thu, 2021-11-18 at 22:11 +, Rao Shoaib via networkmanager-list wrote: > Hello everyone, > > I have cloned the following repo, but can not figure out how to build > it. Can someone please provide me with the build instructions? > > Regards, > > Shoaib > > NetworkManager / NetworkManager > > NetworkManager / NetworkManager > NetworkManager — network management daemon > Hi, NetworkManager can both use autotools and meson for building. Choose the one you prefer. How to build a autotools/meson project, follows in general similar steps. e.g. ./autogen.sh ./configure $OPTIONS make sudo make install and meson build ninja -C build Search the internet for how autotools/make or meson works. Most important is to get the configure options right for your environment. In particular the `--prefix` where things get installed... See also https://wiki.gnome.org/Projects/NetworkManager/Hacking and read https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/77d7b8287c43fdc25cbea6d976d3867459bfd314/CONTRIBUTING.md#building-from-source On Fedora, you can also use these COPR repositories: https://copr.fedorainfracloud.org/coprs/networkmanager If you have questions, you may also ask on IRC (#nm on Libera.Chat). best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is there a way to use dbus api to list the connected clients?
On Tue, 2021-11-02 at 20:34 +0800, Woodrow Shen via networkmanager-list wrote: > Hi all, > > I know there are few methods to find connected clients with AP mode, > but we have the same > question as[1] to look for the possibility to dump the information > like dhcp lease. > > Can someone help me with this topic? > > Thanks, > Woodrow > > [1] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/633 Hi, that would be a useful feature, but not done (yet). best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: relocate dnsmasq --conf-dir location?
On Thu, 2021-10-28 at 07:21 -0700, mailingl...@bentleyemail.net wrote: > Our embedded device has a readonly partition for configuration and > such. /etc/ is on this readonly partition. > > We currently use keyfile path=/writable partition in order to get > system-connections off the readonly partition. Is there a way to get > the dnsmasq --conf-dir parameter to point to a different location as > well? > > Currently I see: > # ps | grep dns > 340 nobody /usr/sbin/dnsmasq --conf-file=/dev/null --no-hosts --keep- > in-foreground --bind-interfaces --except-interface=lo --clear-on-reload > --strict-order --listen-address=172.16.54.100 --dhcp- > range=172.16.54.109,172.16.54.254,60m --dhcp-lease-max=50 --dhcp- > leasefile=/var/lib/NetworkManager/dnsmasq-br0.leases --pid- > file=/var/run/nm-dnsmasq-br0.pid --conf- > dir=/etc/NetworkManager/dnsmasq-shared.d > 345 nobody /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no- > hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid > --listen-address=127.0.0.1 --cache-size=400 --clear-on-reload --conf- > file=/dev/null --proxy-dnssec --enable- > dbus=org.freedesktop.NetworkManager.dnsmasq --conf- > dir=/etc/NetworkManager/dnsmasq.d > > I have not seen where I can influence this location. Can you advise? > I'd like to be able to have something like: > > /usr/sbin/dnsmasq --conf-file=/dev/null --no-hosts --keep-in-foreground > --bind-interfaces --except-interface=lo --clear-on-reload --strict- > order --listen-address=172.16.54.100 --dhcp- > range=172.16.54.109,172.16.54.254,60m --dhcp-lease-max=50 --dhcp- > leasefile=/var/lib/NetworkManager/dnsmasq-br0.leases --pid- > file=/var/run/nm-dnsmasq-br0.pid --conf- > dir=/modifiable/NetworkManager/dnsmasq-shared.d > /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind- > interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen- > address=127.0.0.1 --cache-size=400 --clear-on-reload --conf- > file=/dev/null --proxy-dnssec --enable- > dbus=org.freedesktop.NetworkManager.dnsmasq --conf- > dir=/modifiable/NetworkManager/dnsmasq.d > > Thanks, Hi, no, that's not currently possible. You could: 1) bind-mount the directory "/modifiable/NetworkManager/dnsmasq*.d" to "/etc/NetworkManager/dnsmasq*.d" 2) you could replace /usr/sbin/dnsmasq with a wrapper script that hacks the configuration option. 3) the code does if (g_file_test(CONFDIR, G_FILE_TEST_IS_DIR)) argv[argv_idx++] = "--conf-dir=" CONFDIR; You could patch the code (welcome upstream) to also accept SYMLINKS, then you could symlink the /modifiable dir from /etc. 4) maybe this could be made configurable in NetworkManager.conf (patch maybe welcome upstream). But with 1) and 3) you would have alternatives for that. Beside, dropping files to --conf-dir entirely bypasses NetworkManager and it would be better to natively support the features that are hacked this way. 5) any other patch that works for you. 1) seems best. 3) is best otherwise, if you invest the work and can wait for a new version of NetworkManager. best, Thoma ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Why NM seems to behave differently in initrd from in real root?
On Thu, 2021-10-07 at 22:12 +0800, Coiby Xu via networkmanager-list wrote: > Hi NM developers, > > This is Coiby from the Red Hat Kernel Debug team who is responsible > for > Fedora/RHEL's kexec-tools. Currently, kexec-tools parses ifcfg-* or > .nmconnection to build up dracut cmdline parameter like ip= to set > up kdump initrd network which is tedious and error-prone. Recently, > I'm > implementing a different approach which is to set up kdump initrd > network > by copying connection profiles from real root to initrd directly. > However, > one unexpected thing is NM seems to behave differently in initrd from > in > real root and the same connection profiles copied from the real root > lead > to different result in kdump initrd. So is there a general reason why > NM > behaves differently in initrd and real root? Is it a better approach > that > kexec-tools sets up kdump initrd network by copying connection > profiles > from real root to kdump initrd? It will be appreciated if NM > developers > could provide answers or comments on these questions since you are > experts > on this type of problems. NetworkManager should behave very similar in real-root and initrd. Which probably is the point of NetworkManager in initrd in the first place: to do the same everywhere. The points you brought up, are special cases and configuration issues Or even missing features, and we can find ways to make those usecases work better. I replied to the rhbz and upstream issue, if that helps. Copying connection profiles seems like a good idea. But the real problem is that you are writing a non-interactive tool, which is confronted with some profiles on disk, and then automatically needs to do the right thing. That is not possible in all cases, and that is despite we even have an API to more conveniently parse the profile files. For example, if there are two profiles on disk that are both set to autoconnect on the same device, then a generic, non-interactive tool cannot understand which one to prefer or what even to do about that. That is regardless whether you copy profiles or whether you parse and syntesize new ones. The real solution is: the user must have configuration that works for your tool first place. > > For the details of how NM behaves differently in kdump initrd, I've > reported some of the inconsistent behaviours as bugs [1] [2]. > connection.wait-device-timeout=6000 and connection.autoconnect=false > could be used to bypass [1] and [2] respectively so the same > connections > could be brought up in initrd. replied to both. Hope that helps. Let's discuss there. > A third issue for which I haven't found a > workaround is the case of bridging network over VLAN network over > teaming > network where I create a teaming network interface which is used as > the > parent interface of a VLAN interface which is in turn a slave > interface > of network bridge. The problem is the network bridge sometimes gets > the > IP address belonging the VLAN subnet but sometimes not. Btw, the > third > issue is found on a physical machine and can't be reproduced on a VM. Hard to say. Seems like a bug? Please report is, so we can track it and discuss in detail. > > I've tested the modified kexec-tools [3] by setting up different > networks > including the aforementioned bridging network over VLAN network over > teaming network. Other tests including bridging network over physical > interface/bonding network/teaming network/VLAN network, VLAN network > over physical interface/bonding network/teaming work and etc. All > tests > have passed for VM. And except for the bridging network over VLAN > network > over teaming network, the tests have also passed for one physical > machine. That sounds promising. > But I'm not sure if they are sufficient considering there is > machine-specific issue like znet network device. Any suggestion is > welcome. there are countless of combinations. It's great you invest time in considerable amount of testing! znet seems difficult. I comment about that on [2]. > > [1] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/803 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2007563 > [3] > https://src.fedoraproject.org/fork/coiby/rpms/kexec-tools/commits/direct_nm > > best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Calling async functions of NMClient from another thread
On Sat, 2021-10-09 at 14:05 +0200, Luis Felipe via networkmanager-list wrote: > Hi all, > > it's my first post, so please apologize for any mistake. > > I have a trouble with NMClient (libnm) and threads in my C-application. > Here the scenario: > > - in the main thread, gmain-loop and NMClient are created; here > 'g_main_loop_run()' is called too > > - in a separated thread, a XML-RPC server is started. Each time a new > RPC arrives, this server creates a new thread with the proper function > > - the RPC-function calls an async NMClient-function > (nm_client_activate_connection_async), and the following errors appear: > > > (process:668): GLib-CRITICAL **: 17:53:29.664: > g_main_context_push_thread_default: assertion 'acquired_context > ' failed > > (process:668): GLib-CRITICAL **: 17:53:29.664: > g_main_context_pop_thread_default: assertion 'g_queue_peek_head > (stack) == context' failed > > > I expected that the async-functions can be called from any context, but > doesn't look like, or am I doing something wrong? > Please can somebody give me a hint for solving this issue? Thanks in > advance. > > BR, hi, First of all, NMClient is a cache of the NetworkManager data you see on the D-Bus API. Accessing that cache is not thread safe. You you need to coordinate access. This does NOT work via some mutex. Instead you need "acquire" exclusive access to the GMainContext (which is associated with the NMClient instance: nm_client_get_main_context()). That is, because as nm_client_get_main_context() gets iterated, D-Bus events and timeout events may be processed, and the NMClient instance may change at any time. So to ensure that the NMClient instance is unchanging, you need to ensure that nobody else is currently iterating the context. Technically, when accessing NMClient you don't need to acquire the GMainContext on your current thread, it would be enough that no other thread has it acquired. If another thread has it acquired, there are races because the data might change. In particular, running the context on the main thread with g_main_loop_run() means you must not access NMClient (aside g_object_ref/g_object_unref and accessing a subset of trivial functions like nm_client_get_dbus_connection() and nm_client_get_main_context() - - but not for example nm_client_get_dbus_name_owner()). Indeed, nm_client_activate_connection_async() uses GTask and does little more than calling g_dbus_connection_call()... except, before making the D-Bus call it does dbus_context = nm_g_main_context_push_thread_default_if_necessary(priv->dbus_context); (see [1]). The reason is that the D-Bus reply must first be processed on nm_client_get_main_context() so that the cache can be updated with the new data, and that the response is in order with the other D-Bus signals we process, then GTask will make that the response gets dispatched on the callers main-context. So the problem is really that nm_client_get_main_context() is already acquired on the main thread and g_main_context_push_thread_default() fails. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/06d448245b26709d6eb5c24279c352cb17df7cdf/src/libnm-client-impl/nm-client.c#L535 Instead, you need to coordinate access to the NMClient instance by passing access to the GMainContext around. You might iterate the g_main_context_default() on the main thread, and give NMClient a *different* GMainContext instance. The problem then is that you still need to take care that NMClient's context gets iterated at the right times (but also that it gets iterated *all* the time). That unfortunately seems non trivial, also because glib does not provide a function to integrate a GMainContext in another GMainContext. In libnm, we do that this way: [2]. * TL;DR: THE RIGHT SOLUTION: So the best solution might be to schedule any access via g_idle_source_new() on NMClient's GMainContext. Another theoretical solution is that you just make the D-Bus call ActivateConnection yourself, with g_dbus_connection_call(). Of course, then the response is again not in sync/ordered with respect to the events/state of NMClient, which brings other problems. And you still couldn't access NMClient directly from the other thread. Btw, before version 1.22, you could *only* use NMClient with g_main_context_default(). Try not to use such an old libnm version. [2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/06d448245b26709d6eb5c24279c352cb17df7cdf/src/libnm-glib-aux/nm-shared-utils.c#L5488 best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Link-local with fixed IP
On Fri, 2021-09-24 at 07:07 +, moonkid--- via networkmanager-list wrote: > Hello together, > > is it possible to use a fixed (static?) IP on a network interface > when > it is configured as "Link-local"? Currently not. > > Let me explain my problem first and the background (Why I want this) > after. I think it makes sense to combine IPv4 link local addressing together with manual or DHCP(v4) methods. That should be added. We are about to rework the IP handling of NetworkManager. That should make it simpler to implement that feature. > > I am on a RaspberryOS (Pi4 with two interfaces: LAN and WLAN). > Network-Manager is not installed by default so I did it via "apt". > Via nmtui I setup the "eth0" with Link-local as you can see on the > screenshot [1]. > > I tried to setup a fixed IP on "eth0" and used the dhcpd.conf for > that. > > $ cat /etc/dhcpcd.conf > interface eth0 > static ip_address=169.245.228.100 > noipv6 You mean, you are using "[main].dhcp=dhcpcd" in NetworkManager.conf? Yes, I guess this would work somewhat. But it totally bypasses NetworkManager, and hacks an IP address there. This is not how it's supposed to work and users should not be required to edit files in /etc as root. > > When I connect another PC (a Win10 Laptop) to "eth0" I can see in the > /var/log/syslog that this fixed IP is used at the first step. But > after > it another random IP is setup. At the end the IP is not overridden > but > "eth0" got two IPs. I was not aware that this is possible. I don't know. You'd have to check dhcpcd documentation what "static" means. In geneal, if you use [main].dhcp=dhcpcd", then NetworkManager execs dhcpcd to do DHCP. If you then configure dhcpcd directly, then some things will happen and that would be transparant to NetworkManager. > > 2: eth0: mtu 1500 qdisc mq state UP > group default qlen 1000 > link/ether e4:5f:01:5d:1c:b8 brd ff:ff:ff:ff:ff:ff > inet 169.254.232.113/16 brd 169.254.255.255 scope link > noprefixroute > eth0 > valid_lft forever preferred_lft forever > inet 169.245.228.100/16 brd 169.245.255.255 scope global > noprefixroute eth0 > valid_lft forever preferred_lft forever > inet6 fe80::e65f:1ff:fe5d:1cb8/64 scope link > valid_lft forever preferred_lft forever > > But from the Win10 PC the Pi is reachable (SSH) only via the second > (random) IP. What can I do to setup a fixed IP? That's unclear. If you use IPv4LL addresses, then they are in subnet 169.245.0.0/16. If your Windows PC has multiple interfaces, then I would check that 169.245.0.0/16 really gets routed the right way. When you try to reach an link local address, then you usually have to specify the interface which should be used (both with IPv4 and IPv6). > > Now let me explain some background because you will ask why I need > this. > ;) > I am not very familiar with network things and also "Link-local" is > totaly new for me. But in my understanding it is that what I need for > my > use case without setting up an DHCP Server on the PI. > My use-case is that I want to connect (via "eth0") the Pi headless(!) > to > a LAN Port of Windows 10 PC. There is no device (router, switch, ...) > between the Pi and the Win - only a LAN cable. There is absolutely > now > way to do any network configurations on the Windows machine! It is > setup > to listen on every DHCP by default. No way to change that! > > But I found out that the Windows machine takes an IP address when the > "opposite machine" (the Pi on the other end of the LAN cable) is > setup > to Link-local. This saves me from setup an DHCP server on the Pi - > which > I tried but did not succeeded. I think a DHCP server would be > overhead > because the Pi only connects to this one machine. > > Why a fixed IP? As told the Pi is headless. When I connect the Win > machine I do not know the IP of the Pi. There is no usual way to find > out the Pi's IP without doing any network scans. But I also have no > monitor on the Pi to look into its log files or network status > appletts. > Btw: I know that in most situations a Pi is reachable via > "raspberrypi.local" by default. This works here on my case. But I do > not > want to trust on that. I would sleep better when I would have the > real > IP. The "raspebbrypi.local" did not help me to get the IP behind it > because when I ping it I just get a IPv6 look-a-like address back - > no > IPv4. Even if there is a way to get the IPv4 IP behind > "raspberrypi.local" from the Windows machine it would be a workaround > because I would have to do it on every connection. I would prefer a > static/fixed always known IP. > > Btw: As you can see there is also a IPv6 address on "eth0" but I > tried > to deactivate IPv6 via "noipv6" in dhcpcd.conf; but it is ignored or > overridden. You could also run "ipv4.method=shared". Then NetworkManager will run a DHCP server and the Windows-PC can just connect. Also the IP address in NetworkManager
[RFC] drop nm-iface-helper (--configure-and-quit=yes) from NetworkManager?
Hi, Since NM 1.0, NM supports a [main] configure-and-quit=yes option in NetworkManager.conf (see also the manual page [1]). [1] https://networkmanager.dev/docs/api/1.32.10/NetworkManager.conf.html This tells NM to quit once the interfaces are configured. That works for static addresses by NM simply exiting and leaving the interface configured. To support DHCP/autoconf6, NM starts /usr/libexec/nm-iface- helper, which is an per-interface IP manager process. The idea is to avoid a "heavy daemon" while still honoring NetworkManager configuration. Which may be fine for static addressing, but once you start nm-iface-helper it's not clear why that is so much more lightweight to be worth it. IMO, the solution for "NM is too heavy" is not "disable NM and run some nm-iface-helper instead", the solution is "improve resouce consumption of NM". Sidenote: "configure-and-quit=yes" is not the same as "configure-and- quit=initrd", which has a different use and a real purpose. I think this mode does not work well and makes little sense. The biggest downsides is that you loose a lot in this mode. No more Wi-Fi, VPN, bluetooth. No more D-Bus API of NM. For this mode there are already sensible alternatives (a bash script, dhclient or systemd- networkd). I propose to drop "configure-and-quit=yes" mode. Dropping nm-iface-helper is a change in behavior, but maybe not too bad. NM would simply keep running. A user who had configure-and-quit mode working would still have a working setup (arguably, working "better"). I don't recall *any* bug reports for nm-iface-helper. I suspect nobody is using this. Is somebody using it? Would you miss it? Opinions? best Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: link-local fallback
On Mon, 2021-08-30 at 15:50 +, Michel, Matthias via networkmanager- list wrote: > Hi Thomas > > On Tue, 2021-04-27 at 19:46 +0200, Thomas Haller wrote: > > Hi, > > > > > > On Tue, 2021-04-27 at 12:04 +, Michel, Matthias via > > networkmanager- > > list wrote: > > > Hi > > > I'm using the dhcp=systemd setting in the networkmanager v1.30.2. > > > > Btw, dhcp=systemd is an (intentionally) undocumented option. > > Eventually > > it will be replaced and behave the same as dhcp=internal. > > > > In practice, for you there should be no difference between using > > dhcp=internal and dhcp=systemd. And if there is a difference, that > > is > > probably something we'd like to fix/investigate. > > > > But sure, dhcp=systemd works too. > > > > > I have a requirement to switch to a fallback link-local when the > > > dhcp > > > is not available and to return from link-local to dhcp when it is > > > back. > > > > > > What I was able to configure was the fallback to link-local. But > > > switching to dhcp automatically was not possible. > > > > > > my connections with networkmanager: > > > > > > cat br-lan.nmconnection > > > [connection] > > > id=br-lan > > > uuid=0d924e20-a7ca-4eec-9ad1-28b6d2ddb0c2 > > > autoconnect-priority=100 > > > autoconnect-retries=1 > > > interface-name=br-lan > > > llmnr=2 > > > permissions= > > > zone=lan > > > > > > [bridge] > > > stp=false > > > > > > [match] > > > kernel-command-line=!test; > > > > > > [ipv4] > > > dhcp-timeout=3 > > > dns-search= > > > may-fail=false > > > method=auto > > > route1=224.0.0.0/4,0.0.0.0,0 > > > > > > [ipv6] > > > addr-gen-mode=stable-privacy > > > dns-search= > > > method=auto > > > [proxy] > > > > > > > > > cat br-lan-ll.nmconnection > > > [connection] > > > id=br-lan-ll > > > uuid=1d924e20-a7ca-4eec-9ad1-28b6d2ddb0c2 > > > type=bridge > > > autoconnect=true > > > autoconnect-priority=50 > > > interface-name=br-lan > > > llmnr=2 > > > permissions= > > > timestamp=1617958884 > > > zone=lan > > > > > > [bridge] > > > stp=false > > > > > > [match] > > > kernel-command-line=!test; > > > > > > [ipv4] > > > dns-search= > > > method=link-local > > > route1=224.0.0.0/4,0.0.0.0,0 > > > > > > [ipv6] > > > addr-gen-mode=stable-privacy > > > dns-search= > > > method=disabled > > > > > > [proxy] > > > > > > > > > my connection with networkd: > > > > > > cat /etc/systemd/network/lan.network > > > [Match] > > > Name=enp44s0u2u1 > > > > > > [Network] > > > Bridge=br0 > > > > > > cat /etc/systemd/network/br0.netdev > > > [NetDev] > > > Name=br0 > > > Kind=bridge > > > > > > cat /etc/systemd/network/bridge.network > > > [Match] > > > Name=br0 > > > > > > [Network] > > > DHCP=ipv4 > > > LinkLocalAddressing=fallback > > > > > > [DHCPv4] > > > MaxAttempts=1 > > > > The problem is that once the LL profile activates, it will not fail > > automatically, and DHCP is never tried again. > > > > So there really needs to be one profile that enables both DHCP and > > LL, > > possibly with an option that says: only do LL while not having a > > DHCP > > lease. That requires new API. The current ipv4.method is not > > flexible > > enough for that. That needs improvement. > > > > > > > I studied the code of networkmanager and networkd. > > > > > > networkd: > > > > > > > > > https://github.com/systemd/systemd/blob/3a1e9d8083b83f611a23cc84ba69a8175e659629/src/network/networkd-dhcp4.c#L1128 > > > > > > > > > networkmanager: > > > > > > > > > https://github.com/NetworkManager/NetworkManager/blob/af360238be198257934b89d42f24431401550721/src/core/dhcp/nm-dhcp-systemd.c#L495 > > > > > > Is there a design reason why this behavior is implemented > > > differently? > > > > The reason is that it was not implemented this way
Re: nm-applet becomes unresponsive
On Thu, 2021-09-02 at 15:22 +, Sascha Zosgornik via networkmanager- list wrote: > Hello Mr. Haller, > > I am sorry to tell you but the NM-applet becomes very unresponsive > after > I changed the IP settings from "Automatic (DHCP)" towards "Automatic > (DHCP) addresses only" and "Automatic, DHCP only" on IP6. > > These glitches last from 30 seconds upwards to several minutes and > often > effect the entire desktop environment with it. I later cases towards > the > point that any interaction with application becomes impossible. > > After switching back to "Automatic" and "Automatic (DHCP) behaves the > applet normal and responsive again but you might understand that it was > hard to figure the problem and solve it while the applet refused any > interaction for several minutes. > Hi, from the description it's not clear how to solve this, or what causes it. Of course, that does not sound like correct behavior. First step, you sure you are actually using nm-applet? For example, if you'd use GNOME(3) or KDE, then you'd commonly would not use that application. I also ask, because nm-applet (unlike nm-connection-editor) has no capabilities to change the IP method. So it's not clear how your description about switching to "Automatic" ties into nm-applet. Maybe you don't mean nm-applet? If you are positive which GUI is used, then you could report an upstream issue. However, with the given information, I don't think the issue fixable either. But it might still be useful so that others can find the report, and maybe provide additional information. So, a bug report would be appreciated, but I cannot guarantee that it will lead to a resolution. nm-applet is here: https://gitlab.gnome.org/GNOME/network-manager-applet/-/issues best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[FYI] NetworkManager Community Meetup DevConf.US 2021
Hi everybody, as in the past Devconf too, we'll have an informal meetup at DevConf.US 2021, this Thursday (2 September 2021). https://devconfus2021.sched.com/event/lkgA/networkmanager-community-meetup-devconfus-2021 You are welcome to join and discuss anything related to NetworkManager. Hope to see you there. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Chrony IPv6 sources offline after resume - dispatcher script runs before IPv6 is up
On Thu, 2021-08-12 at 21:03 +0300, Andrei Borzenkov via networkmanager- list wrote: > Chrony comes with sample NetworkManager dispatcher script that offlines > NTP sources when interface goes down and onlines them when interface > comes up. Technically it runs "chronyc onoffline" which tries to > determine whether each source can be reached. This script is actually > installed by distributions (openSUSE and Ubuntu for sure). > > When system goes to suspend NetworkManager offlines interfaces that > causes chrony to offline its sources. On resume chrony is expected to > online them again. > > This works well for IPv4 sources but IPv6 sources remain offline. Like > > $ chronyc -n sources > 210 Number of sources = 8 > MS Name/IP address Stratum Poll Reach LastRx Last sample > > === > > ^? 2001:67c:1560:8003::c8 0 6 0 - +0ns[ +0ns] > +/- > 0ns > ^? 2001:67c:1560:8003::c7 0 6 0 - +0ns[ +0ns] > +/- > 0ns > ^- 91.189.89.199 2 8 377 108 -2030us[-2209us] > +/- > 53ms > ^- 91.189.94.4 2 8 377 49 -2878us[-3067us] > +/- > 60ms > ^+ 79.111.152.5 1 8 377 51 -2960us[-3149us] > +/- > 18ms > ^* 188.225.9.167 2 8 377 49 -1819us[-2008us] > +/- > 15ms > ^+ 85.21.78.91 2 8 377 116 -3053us[-3230us] > +/- > 19ms > ^+ 185.209.85.222 2 8 377 50 +6182us[+5993us] +/- > 23ms > $ > > The reason is - when ifup dispatcher script runs, IPv6 is not yet > configured. Here are route entries > > default via 192.168.1.1 dev wlan0 proto dhcp metric 20600 > 169.254.0.0/16 dev wlan0 scope link metric 1000 > 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.6 metric > 600 > ::1 dev lo proto kernel metric 256 pref medium > fe80::/64 dev wlan0 proto kernel metric 600 pref medium > > So IPv4 is up and has default route but IPv6 still only link-local > address. Couple of seconds later > > ::1 dev lo proto kernel metric 256 pref medium > 2a00:::::/64 dev wlan0 proto ra metric 600 pref medium > fe80::/64 dev wlan0 proto kernel metric 600 pref medium > default via fe80::1 dev wlan0 proto ra metric 20600 pref medium > > Is it possible to run dispatcher script after both IPv4 and IPv6 are > configured on interface? Or only IPv6 for that matter - it does not > matter if "chronyc onoffline" runs multiple times. > > Both IPv4 and IPv6 are set to auto. Hi, there are several dispatcher events, documented at [1]. [1] https://networkmanager.dev/docs/api/1.32.8/NetworkManager-dispatcher.html one of them is "dhcp6-change" change, but I guess that even should also fire when we get new IPv6 addresses from a router. Or an alternative event could be added. That probably does not happen (yet), which might be a bug. It's also not entirely trivial, because probably that the event should only be emitted after the IPv6 addresses pass DAD and are no longer tentative. Note that the "up" event gets invoked when the device is logically connected. If you configure ipv6.may-fail=no, then that includes IPv6 to be ready (but it also makes it mandatory). There is also ipv6.required-timeout, which means to wait for IPv6 this long. This allows the user to better control what "up" means, but it's not a general solution for your dispatcher script, because that should work with any configuration. best, Thomas * ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Make NetworkManager connection profiles without changing the current network configuration
On Tue, 2021-08-03 at 17:45 +0300, Andrei Borzenkov via networkmanager- list wrote: > On 03.08.2021 17:38, Thomas Haller via networkmanager-list wrote: > > > > Also, if you modify profiles via D-Bus API (which is what nmcli > > does), > > then the configuration only take effect when activating the profile > > the > > next time. I mean, the profile changes immediately, but the current > > network configuration does not. That means, even if a profile is > > currently activated, you might be able to modify it, without > > changing > > the runtime configuration of the interface yet. > > Is it possible to see profile properties currently active on a > interface? Because nmcli displays configured properties even if they > changed and device was activated with older profile definition. Currenly not. You can call on the device GetAppliedConnection(), which gives the settings as they were during the last activation (or during the last Apply call). Theoretically, you could say, if that differs from the profile, it changed. That might be useful information, in particular, that would be good to see in `nmcli device` output. > > > - if you modify a profile that is currently active, then the > > properties > > "connection.metered" and "connection.zone" take effect immediately, > > unless you specify "no-reapply" flag for Update2 ([1]). > > > > Is it possible to do it with nmcli? Not at the moment. But would also be useful! best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Make NetworkManager connection profiles without changing the current network configuration
On Tue, 2021-08-03 at 13:26 +, Matthew Starr via networkmanager-
list wrote:
> I am looking for a way to generate connection profile config files
> without applying the settings to the currently enabled network
> interfaces that are already configured. I am using NetworkManager on
> an embedded device and I want to fully generate all profile config
> files before having any of them be applied. This is to ensure the full
> update of the embedded device was successful before applying the
> changes. So basically, I am looking for a way to use nmcli to generate
> config files for connection profiles and have them written somewhere,
> but not have them take effect with the current running instance of
> NetworkManager. I don't want the network interfaces current state
> interrupted since an update application is talking to a remote update
> server telling it the update status.
>
> Here is the background of what I am currently doing. I am currently
> doing this by running NetworkManager in a chroot which uses the new
> /etc path vs the running system and the config files are written
> there. Once the install is successful, the chroot /etc path is setup
> as the new official path on reboot. The issue is that running
> NetworkManager in the chroot requires stopping the NetworkManager for
> the running system and then using nmcli the new profiles are created.
> This results in those changes taking effect immediately and stay until
> I stop NetworkManager in the chroot environment and restart
> NetworkManager in the normal runtime environment. When those changes
> take effect, I lose connection to my remote update server that is
> tracking the update status.
>
> Does this write config but don't apply functionality exist? If not are
> there any other suggestions other than writing my own NetworkManager
> profile config file generator? I want to avoid writing a config file
> generator as I know over time sometimes newer versions of
> NetworkManager change the connection profile config file format
> slightly.
Hi,
NetworkManager reads profiles from disk only during startup and during
`nmcli connection reload` and `nmcli connection load "${PATHS[@]}"`.
Unless any of these 3 things happen, you can modify the profiles on
disk at will.
Also, if you modify profiles via D-Bus API (which is what nmcli does),
then the configuration only take effect when activating the profile the
next time. I mean, the profile changes immediately, but the current
network configuration does not. That means, even if a profile is
currently activated, you might be able to modify it, without changing
the runtime configuration of the interface yet. However, it's still
tricky because:
- if you delete a profile, then a device currently activate with the
profile must go down.
- if you modify a profile, then it might start to autoactivate right
away. You can avoid that by setting the profile to not autoconnect
(`connection.autoconnect=no`), or using Update2 D-Bus API ([1]) with
"block-autoconnect" flag. You could also set the device to temporarily
block autoconnect.
- if you modify a profile that is currently active, then the properties
"connection.metered" and "connection.zone" take effect immediately,
unless you specify "no-reapply" flag for Update2 ([1]).
[1]
https://networkmanager.dev/docs/api/latest/gdbus-org.freedesktop.NetworkManager.Settings.Connection.html#gdbus-method-org-freedesktop-NetworkManager-Settings-Connection.Update2
Profiles are in keyfile format, the API for handling them is exposed in
libnm. See the example ([2]). That is relatively convenient, provided
that you also use libnm's NMConnection and NMSetting types to construct
the profile in the first place. After all, parsing a keyfile begs the
question: to what? And the answer is "NMConnection" and it's only
useful if your tool operates in terms of NMConnection.
[2]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/7a39f1f7e7ee6d3d409523957e889bd8a940d414/examples/python/gi/nm-keyfile.py
You can also generate the files yourself.It should not be too hard. You
can also use glib's GKeyFile API ([3]) which is the lower layer here.
In general, I wouldn't be too concerned that the file you write today
won't be accepted by NetworkManager tomorrow. This is NetworkManager's
native file format, so it MUST be stable. It would be a bug, if
behavior changes. Of course, if you do something unusual and behavior
changes, then we might only notice the regression after it already
happened. Avoid that, by not doing something other than nmcli does.
That is, I would anyway suggest to use nmcli to modify the profile and
check what it does, and the mimik the result. Also check `man nm-
settings` and `man nm-settings-keyfile`.
[3] https://developer-old.gnome.org/glib/stable/glib-Key-value-file-parser.html
It would be a nice feature if nmcli could directly write keyfiles to disk or
stdout
([4]). Patch welcome.
[4]
Re: Can anyone suggest an end-to-end example of how to establish wifi connection in C++
On Mon, 2021-08-02 at 09:44 -0700, Michael Uman wrote: > Hello, > > I appreciate the answer I received the other day but unfortunately I > was unable to figure out how to accomplish this. I am looking for an > example of how to establish a new wifi connection to an AP using C++. I > will be using Qt 5.14 and qtdbus to access NM But I dont know what > steps are necessary to establish the connection. I will have the AP > SSID and the password, and need to create the network connnection. Hi, NetworkManager is about having connection profiles and activating them. So, first you create a suitable profile (or, find it, if you already have one). You can crate profile with "AddConnection2" D-Bus API. That is basically what `nmcli connection add type wifi` does. You can also use "AddAndActivateConnection2". That way, you can provide an incomplete profile and an access point, and NetworkManager will complete the missing values of the profile that gets created. Then it will proceed to activate it. That is what `nmcli device wifi connect` does (if you don't have a profile yet). If you have a profile, then you can activate it by calling "ActivateConnection". Check the docs here: https://networkmanager.dev/docs/api/latest/spec.html In the simplest case, the profile already contains all secrets, and "802-11-wireless-security.psk-flags" is set to zero (see `man nm- settings` for "Secret flag types"). Otherwise, a program needs to run which can provide the secret. That's a "secret agent". How to run a secret agent was alluded by the mail by Andrei. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Lack of new OpenVPN SAML interoperability
Hi, On Sun, 2021-08-01 at 14:19 -0300, Marcus Diniz wrote: > Hello, > > First of all, I'm sorry to copy both gnome-network-list and > networkmanager-list, because I didn't know or couldn't recognize > which one would be the proper one to mention this fact. > > I've been trying to access my OpenVPN cloud account through the > 'Import profile' wizard that comes with Gnome Network. > > I simply go to Settings->Network, then on VPN panel I click on '+' > symbol, a new window appears, then I select 'Import from file...'. > Finally, after imported, when I try to connect, I receive the > following errors: How you create a profile does not matter much. What matters, is the actual settings in the profile (you see them with `nmcli connection show "$PROFILE"`) and which versions of NetworkManager, nm-openpvn and openvpn versions are used. > Aug 1 14:17:13 blackbox systemd[1]: NetworkManager- > dispatcher.service: Succeeded. > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3179] audit: op="connection-activate" uuid="29cf64b5- > 5104-4953-83e2-367bf0a140ed" > name="device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_Paulo]" > pid=2455 uid=1000 result="success" > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3261] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: Started the VPN service, PID 42217 > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3367] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: Saw the service appear; activating connection > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3699] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: VPN plugin: state changed: starting (3) > Aug 1 14:17:17 blackbox NetworkManager[1266]: > [1627838237.3705] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: VPN connection: (ConnectInteractive) reply received > Aug 1 14:17:17 blackbox nm-openvpn[42221]: OpenVPN 2.4.7 x86_64-pc- > linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] > [AEAD] built on Jul 19 2021 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: library versions: OpenSSL > 1.1.1f 31 Mar 2020, LZO 2.10 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: the current -- > script-security setting may allow this configuration to call user- > defined scripts > Aug 1 14:17:17 blackbox nm-openvpn[42221]: TCP/UDP: Preserving > recently used remote address: [AF_INET]209.14.3.201:1194 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: UDP link local: (not > bound) > Aug 1 14:17:17 blackbox nm-openvpn[42221]: UDP link remote: > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: chroot will be > delayed because of --client, --pull, or --up-delay > Aug 1 14:17:17 blackbox nm-openvpn[42221]: NOTE: UID/GID downgrade > will be delayed because of --client, --pull, or --up-delay > Aug 1 14:17:17 blackbox nm-openvpn[42221]: [br-gru-dc2- > g1.cloud.openvpn.net] Peer Connection Initiated with > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:18 blackbox nm-openvpn[42221]: AUTH: Received control > message: AUTH_FAILED,SSO Auth Failed due to lack of client support > Aug 1 14:17:18 blackbox nm-openvpn[42221]: SIGUSR1[soft,auth- > failure] received, process restarting > Aug 1 14:17:23 blackbox NetworkManager[1266]: > [1627838243.8605] vpn-connection[0x559b36c6c510,29cf64b5-5104-4953- > 83e2- > 367bf0a140ed,"device_1_mdiniz@moneytrans_eu@secunit.openvpn.com_[Sao_ > Paul: VPN plugin: requested secrets; state connect (4) > Aug 1 14:17:25 blackbox nm-openvpn[42221]: NOTE: the current -- > script-security setting may allow this configuration to call user- > defined scripts > Aug 1 14:17:25 blackbox nm-openvpn[42221]: TCP/UDP: Preserving > recently used remote address: [AF_INET]209.14.3.201:1194 > Aug 1 14:17:25 blackbox nm-openvpn[42221]: UDP link local: (not > bound) > Aug 1 14:17:25 blackbox nm-openvpn[42221]: UDP link remote: > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:25 blackbox nm-openvpn[42221]: [br-gru-dc2- > g1.cloud.openvpn.net] Peer Connection Initiated with > [AF_INET]209.14.3.201:1194 > Aug 1 14:17:26 blackbox nm-openvpn[42221]: AUTH: Received control > message: AUTH_FAILED,SSO Auth Failed due to lack of client support > Aug 1 14:17:26 blackbox nm-openvpn[42221]: SIGUSR1[soft,auth- > failure] received, process restarting > > > While using openvpn3 package it works flawlessly. NetworkManager-openvpn plugin does currently not support openvpn3 (I think, and as you probably expirience here). Is the problem here that openvpn client verions 2 cannot talk with an openvpn3 peer? > I wonder, are there any plans to add openvpn3 support for the VPNs? Things get
Re: nm-openvswitch on debian/ubuntu
On Wed, 2021-07-28 at 15:14 +0200, Sohaib E. wrote:
> I found this error in the logs : ovsdb: Could not connect: No such
> file or directory
>
> My ovsdb's unix socket is in /var/run/openvswitch. I don't think
> Network Manager is expecting another path but if it is, where do I
> change that ?
it's not configurable, it's a compile time constant.
Grep the source for "/db.sock".
But that should be correct already. Did you `systemctl start
openvswitch.sevice`?
Where is your db.sock file exactly?
best,
Thomas
>
> Thanks.
>
>
> Le mer. 28 juil. 2021 à 12:57, Thomas Haller a
> écrit :
> > Hi,
> >
> > On Wed, 2021-07-28 at 12:41 +0200, Sohaib E. wrote:
> > > Thank you for your quick answer.
> > >
> > > I have compiled NetworkManager's package myself but I still faced
> > some
> > > issues deploying an ovs bridge.
> > >
> > > Besides the NetworkManager-ovs.conf (openvswitch-switch.service
> > instead
> > > of openvswitch.service), what other settings must be modified for
> > this
> > > to work ?
> >
> >
> > I don't think anything else is missing.
> >
> > Obviously, you need to create connection profiles, read `man nm-
> > openvswitch` about that ([1]). And, you'd activate the right
> > profiles
> > (`nmcli connection up` and watch current setup with `nmcli device`
> > and
> > `nmcli connection`).
> >
> > Other than that, nothing comes to mind. As always when debugging
> > NetworkManager, enable level=TRACE logging and read the log. See
> > [2]
> > for hints about logging.
> >
> > Maybe the path to ovsdb's unix socket is different on the system?
> > That
> > is currently a compile time constant. You should see that in the
> > logs...
> >
> >
> > [1]
> > https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nm-openvswitch.html
> > [2]
> > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/2d879c1ac5d907fe184898b23693fb8148363645/contrib/fedora/rpm/NetworkManager.conf#L27
> >
> >
> > best,
> > Thomas
> >
> >
> > >
> > > Thank you for your time,
> > > Sohaib
> > >
> > > Le mer. 28 juil. 2021 à 10:39, Thomas Haller
> > > a
> > > écrit :
> > > > On Tue, 2021-07-27 at 18:39 +0200, Sohaib E. via
> > > > networkmanager-
> > list
> > > > wrote:
> > > > > Hello,
> > > > >
> > > > > I'm trying to use Network Manager to deploy ovs bridges on
> > > > > debian/ubuntu.
> > > > >
> > > > > I understand that Network Manager itself do not have such a
> > feature
> > > > > and needs an additional plugin called nm-openvswitch.
> > Nevertheless,
> > > > > this plugin is not available on debian/ubuntu and, therefore,
> > > > > I
> > was
> > > > > wondering if there was any workaround to deploy ovs bridges
> > using
> > > > > nmcli on ubuntu/debian or to install nm-openvswitch on
> > > > ubuntu/debian.
> > > >
> > > > nm-openvswitch is part of NetworkManager, but
> > > >
> > > > - it can be disabled/enabled at compile time
> > > >
> > > > - it is loaded from a shared library (dlopen), so it can be
> > packaged
> > > > separately (as done on Fedora, with NetworkManager-openvswitch
> > > > package). But it doesn't have to be packaged separately, Debian
> > tends
> > > > to put all these device plugins in the same "network-manager"
> > > > package,
> > > > while Fedora tends to split them (NetworkManager-
> > > > {wifi,team,wwan,...}).
> > > >
> > > >
> > > > Debian builds with this code disabled. You would either have to
> > > > convince the debian maintainers to package this, or build
> > > > NetworkManager yourself. In the latter case, you could just
> > rebuild
> > > > the
> > > > debian package with minor changes to the build settings.
> > > >
> > > >
> > > > best,
> > > > Thomas
> > > >
> >
> >
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-openvswitch on debian/ubuntu
Hi,
On Wed, 2021-07-28 at 12:41 +0200, Sohaib E. wrote:
> Thank you for your quick answer.
>
> I have compiled NetworkManager's package myself but I still faced some
> issues deploying an ovs bridge.
>
> Besides the NetworkManager-ovs.conf (openvswitch-switch.service instead
> of openvswitch.service), what other settings must be modified for this
> to work ?
I don't think anything else is missing.
Obviously, you need to create connection profiles, read `man nm-
openvswitch` about that ([1]). And, you'd activate the right profiles
(`nmcli connection up` and watch current setup with `nmcli device` and
`nmcli connection`).
Other than that, nothing comes to mind. As always when debugging
NetworkManager, enable level=TRACE logging and read the log. See [2]
for hints about logging.
Maybe the path to ovsdb's unix socket is different on the system? That
is currently a compile time constant. You should see that in the
logs...
[1]
https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nm-openvswitch.html
[2]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/2d879c1ac5d907fe184898b23693fb8148363645/contrib/fedora/rpm/NetworkManager.conf#L27
best,
Thomas
>
> Thank you for your time,
> Sohaib
>
> Le mer. 28 juil. 2021 à 10:39, Thomas Haller a
> écrit :
> > On Tue, 2021-07-27 at 18:39 +0200, Sohaib E. via networkmanager-list
> > wrote:
> > > Hello,
> > >
> > > I'm trying to use Network Manager to deploy ovs bridges on
> > > debian/ubuntu.
> > >
> > > I understand that Network Manager itself do not have such a feature
> > > and needs an additional plugin called nm-openvswitch. Nevertheless,
> > > this plugin is not available on debian/ubuntu and, therefore, I was
> > > wondering if there was any workaround to deploy ovs bridges using
> > > nmcli on ubuntu/debian or to install nm-openvswitch on
> > ubuntu/debian.
> >
> > nm-openvswitch is part of NetworkManager, but
> >
> > - it can be disabled/enabled at compile time
> >
> > - it is loaded from a shared library (dlopen), so it can be packaged
> > separately (as done on Fedora, with NetworkManager-openvswitch
> > package). But it doesn't have to be packaged separately, Debian tends
> > to put all these device plugins in the same "network-manager"
> > package,
> > while Fedora tends to split them (NetworkManager-
> > {wifi,team,wwan,...}).
> >
> >
> > Debian builds with this code disabled. You would either have to
> > convince the debian maintainers to package this, or build
> > NetworkManager yourself. In the latter case, you could just rebuild
> > the
> > debian package with minor changes to the build settings.
> >
> >
> > best,
> > Thomas
> >
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-openvswitch on debian/ubuntu
On Tue, 2021-07-27 at 18:39 +0200, Sohaib E. via networkmanager-list
wrote:
> Hello,
>
> I'm trying to use Network Manager to deploy ovs bridges on
> debian/ubuntu.
>
> I understand that Network Manager itself do not have such a feature
> and needs an additional plugin called nm-openvswitch. Nevertheless,
> this plugin is not available on debian/ubuntu and, therefore, I was
> wondering if there was any workaround to deploy ovs bridges using
> nmcli on ubuntu/debian or to install nm-openvswitch on ubuntu/debian.
nm-openvswitch is part of NetworkManager, but
- it can be disabled/enabled at compile time
- it is loaded from a shared library (dlopen), so it can be packaged
separately (as done on Fedora, with NetworkManager-openvswitch
package). But it doesn't have to be packaged separately, Debian tends
to put all these device plugins in the same "network-manager" package,
while Fedora tends to split them (NetworkManager-{wifi,team,wwan,...}).
Debian builds with this code disabled. You would either have to
convince the debian maintainers to package this, or build
NetworkManager yourself. In the latter case, you could just rebuild the
debian package with minor changes to the build settings.
best,
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Hostname Management
On Fri, 2021-07-23 at 17:24 +0100, Mark Corbin wrote: > Hello > > I'm trying to control a device hostname independently of > NetworkManager, > but am unable to disable NetworkManager's hostname management. I'm > using > NM version 1.28.2 > > I've added the following to the configuration file: > > [main] > hostname-mode=none that's right. This is documented in `man NetworkManager.conf`. > > When NM starts at boot I see the following messages: > > hostname: hostname: using hostnamed > hostname: hostname changed from (none) to "" that's only informational. It doesn't mean that NetworkManager actively changes the hostname of your system. > Using nmcli to set the hostname triggers a DBus call to set the static > (which fails) and transient (which succeeds) hostnames: `nmcli general hostname` sets the static hostname. That is mostly unrelated to `[main].hostname-mode`, which is about the transient hostname. This comes from a time before hostnamectl. Today there is little reason to call this. Just use hostnamectl to set the static hostname. Setting the transient hostname on the other hand still makes sense and (depending on your environment) is NetworkManager's job. This way you can get the (transient) hostname from DHCP or via reverse DNS lookup. But it doesn't seem that you want that (which is sensible. Just set a static hostname instead). > > Jul 23 16:11:03 OldHostname dbus-daemon[1368]: [system] Activating via > systemd: service name='org.freedesktop.hostname1' > unit='dbus-org.freedesktop.hostname1.service' requested by ':1.4' > (uid=0 > pid=1472 comm="/usr/sbin/NetworkManager --no-daemon ") > Jul 23 16:11:03 OldHostname audit: AUDIT1334 prog-id=35 op=LOAD > Jul 23 16:11:03 OldHostname audit: AUDIT1334 prog-id=36 op=LOAD > Jul 23 16:11:03 OldHostname kernel: audit: type=1334 > audit(1627056663.748:120): prog-id=35 op=LOAD > Jul 23 16:11:03 OldHostname kernel: audit: type=1334 > audit(1627056663.748:121): prog-id=36 op=LOAD > Jul 23 16:11:03 OldHostname dbus-daemon[1368]: [system] Successfully > activated service 'org.freedesktop.hostname1' > Jul 23 16:11:03 NewHostname systemd-hostnamed[10804]: Failed to write > static host name: Device or resource busy > Jul 23 16:11:03 NewHostname NetworkManager[1472]: > [1627056663.9942] hostname: could not set hostname: > GDBus.Error:System.Error.EBUSY: Failed to set static hostname: Device > or > resource busy > Jul 23 16:11:03 NewHostname NetworkManager[1472]: > [1627056663.9944] audit: op="hostname-save" arg="NewHostname" pid=10800 > uid=0 result="fail" reason="Saving the hostname failed." > > I was hoping that nmcli would return "set-hostname: hostname is > unmanaged" when hostname-mode set to 'none'. `nmcli general hostname` calls SetHostname on D-Bus, which ends up at this code: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/888735838382cf45530914b34d383277ff4ddbe4/src/core/nm-hostname-manager.c#L330 > I have two questions: > 1) Can I configure NM so that it doesn't make any attempts to change > either the static or transient device hostname? - NM only sets the static hostname if you call the respective API. Don't don't do that, if you don't want that. - to avoid NM setting the transient hostname, hostname-mode=none would work. Alternatively just configure a static hostname. > 2) If I change the hostname externally from NM should the NM service > be > restarted? No. NM listens to signals from systemd-hostnamed or watches /etc/hostname file. It would pick up the change automatically. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: traffic statistics by network connection
On Fri, 2021-07-23 at 11:59 -0400, David H Durgee wrote: > > Looking at the documentation for ip xfrm it appears that I should be > able to issue commands: > > ip xfrm policy list > ip xfrm state list > > When I attempt to use them from my login I get an "operation not > permitted" error, so I assume I must use sudo for them to work. > Before > I do so can someone confirm for me that these particular commands are > safe to use and will not impact system operation? yes, these commands would only query the current configuration and not change it. They are thus safe... at least, to the best of my knowledge. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: traffic statistics by network connection
On Wed, 2021-07-21 at 10:49 -0400, David H Durgee wrote: > Thomas Haller wrote: > > > On Tue, 2021-07-20 at 16:26 -0400, David H Durgee via > > networkmanager- > > list wrote: > > > > > How can I get traffic statistics by network connection? Is there > > > a > > > way > > > to retrieve this using nmcli? Is there another tool that will do > > > so? > > > > > > I have looked around and the tools I see work at the interface > > > level, > > > not at the connection level. > > > > > > I am using nmcli 1.22.18 as distributed with linux mint 20.1 x64 > > > here. > > Ui, > > > > a "connection" is a profile, that is a bunch of settings for > > configuring a network interface. Basically, see the lower-case keys > > in > > `nmcli connection show "$PROFILE". A profile has no traffic > > statstics, > > nor would it make sense. > > > > Well, that's not entirely correct and I guess it might make some > > sense > > to collect statistics associated with a profile. NM associates > > additional information to prfiles with "connection.timestamp" and > > "wifi.seen-bssids" properties and there are also the lease files > > under > > /var/lib/NetworkManager. But these are exceptions, usually a > > profile is > > just the settings that the user configured. In particular traffic > > statistics are not tracked or associated with connection profiles > > in > > NetworkManager (yet). > > > > > > > > On D-Bus, > > > > $ busctl -j call org.freedesktop.NetworkManager /org/freedesktop > > org.freedesktop.DBus.ObjectManager GetManagedObjects > > > > you see the "org.freedesktop.NetworkManager.Device.Statistics" > > interface (which is per-interface). That exposes the RX/TX bytes. > > That > > is basically the same as kernel reports via netlink API. However, > > the > > values are stale unless you RefreshRateMs to a positive value > > (which > > causes NM to periodically poll the statistics from kernel). > > > > > > There is no further magic with > > "org.freedesktop.NetworkManager.Device.Statistics". You could just > > as > > well read the information via netlink. > > > > These statistics are ad-hoc, and will be lost after reboot (or when > > the > > interface dispears). I guess you could build an interesting tool > > for > > that. I am not aware that one exists. However, the API was added by > > Ubuntu developers, and presumably the do have a use for it and a > > tool. > > > > > > best, > > Thomas > > My reason for asking about this was as a means of confirming proper > operation of a strongswan VPN. When activated this VPN does not > create > a tun interface as the VPN I was previously using did. I had hoped > to > find some way to confirm that the traffic is indeed being routed via > the VPN as opposed to going directly over the WiFi connection even > when > the VPN is active. I see. > > Perhaps I need to take another approach. How difficult would it be > for me to modify the connection to add a tun interface? I see no way > to specify this in the GUI, but inspecting the lapsed VPN connection > shows a "dev=tun" statement in the VPN section of its nmconnection > file. Would manually adding such a statement to the strongswan VPN > nmconnection file be sufficient? Are other additional statements > required that are not present by default? I am not familiar with strongswan VPN. In general, it's the responsibility of the VPN plugin to create the interface (if at all). For IPSec VPN (like libreswan, strongswan), the tunnel can also be configured without having an actual interface. They can use XFRM instead. So if strongswan does not create an interface, then that might be still correct. And possibly there is a configuration in strongswan to switch between the two modes. IDK. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: traffic statistics by network connection
On Tue, 2021-07-20 at 16:26 -0400, David H Durgee via networkmanager- list wrote: > How can I get traffic statistics by network connection? Is there a > way > to retrieve this using nmcli? Is there another tool that will do so? > > I have looked around and the tools I see work at the interface level, > not at the connection level. > > I am using nmcli 1.22.18 as distributed with linux mint 20.1 x64 > here. Ui, a "connection" is a profile, that is a bunch of settings for configuring a network interface. Basically, see the lower-case keys in `nmcli connection show "$PROFILE". A profile has no traffic statstics, nor would it make sense. Well, that's not entirely correct and I guess it might make some sense to collect statistics associated with a profile. NM associates additional information to prfiles with "connection.timestamp" and "wifi.seen-bssids" properties and there are also the lease files under /var/lib/NetworkManager. But these are exceptions, usually a profile is just the settings that the user configured. In particular traffic statistics are not tracked or associated with connection profiles in NetworkManager (yet). On D-Bus, $ busctl -j call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects you see the "org.freedesktop.NetworkManager.Device.Statistics" interface (which is per-interface). That exposes the RX/TX bytes. That is basically the same as kernel reports via netlink API. However, the values are stale unless you RefreshRateMs to a positive value (which causes NM to periodically poll the statistics from kernel). There is no further magic with "org.freedesktop.NetworkManager.Device.Statistics". You could just as well read the information via netlink. These statistics are ad-hoc, and will be lost after reboot (or when the interface dispears). I guess you could build an interesting tool for that. I am not aware that one exists. However, the API was added by Ubuntu developers, and presumably the do have a use for it and a tool. best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how to disable WiFi / wpa-supplicant so hostapd can be used ?
On Tue, 2021-07-20 at 22:04 +0100, Jason Vas Dias via networkmanager- list wrote: > If I do : > # nmcli radio wifi off > , it disassociates the PHY for the device and I have to > 'rfkill $id unblock' . > If I reenable wireless, and do > # systemctl stop wpa_supplicant > # mv /usr/sbin/wpa_supplicant /usr/sbin/wpa_supplicant.bin > after starting NM, then I can run hostapd . > I have to remember to move wpa_supplicant back after I stop > using hostapd . > Please add support for enabling either hostapd or wpa_supplicant, > not both, to NM = or is there some way of disabling running the > wpa_supplicant service only, without rfkill ? Hi, configure the device as unmanaged. Temporarily, with `nmcli device set wlan0 managed no` Permanently, there are several means (udev rules, config files). the best seems to be a file /etc/NetworkManager/conf.d/90-wlan-unmanaged.conf with [device-90-wlan-unmanaged] match-device=interface-name:wlan0 managed=0 see `man NetworkManager.conf`. If you do it that way, you can still override it at runtime with `nmcli device set wlan0 managed yes`. I think `nmcli device set wlan0 managed yes` may not sufficiently instruct wpa_supplicant to let go of the device. That means, you still might need `systemctl stop wpa_supplicant.service`. Patch welcome to properly handle the release of a device by setting it unmanaged. best, Thomas > > > On 20/07/2021, Jason Vas Dias wrote: > > > > Good day - > > > > Whenever I try to run hostapd, NM still runs wpa-supplicant, > > which periodically tries to put the WiFi interface into scanning > > mode, which messes up the hostapd session . > > > > Please is there a config file setting or applet interaction > > to disable wpa-supplicant (and maybe configure & run hostapd) ? > > > > I'd like NM to start dhclient on my Wired interface, and > > be able to bring up my L2TP VPN, but leave the Wireless > > interface entirely alone. > > > > Any way to do this in NetworkManager.conf or GUI ? > > > > Thanks in advance for any replies, > > Best Regards, > > Jason > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated
On Thu, 2021-07-15 at 10:17 +0300, Andrei Borzenkov wrote: > On Wed, Jul 14, 2021 at 5:52 PM Thomas Haller via networkmanager-list > wrote: > > > > So, yes, there should be not much to do except replace the > > interface > > name "org.freedesktop.NetworkManager*" with > > "org.freedesktop.DBus.Properties". > > > > It is probably oversimplified. Signatures are different, so any code > that handles these signals has to be modified to account for it. Also > NM signal unambiguously identifies a specific interface, while D-Bus > signal can come from any interface object implements, so additional > verification that we are dealing with the expected interface is > needed > before properties can be interpreted. I agree. You are correct!! best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated
On Wed, 2021-07-14 at 13:32 +0200, m...@mike.franken.de wrote:
> Hi,
>
> thx for your answer.
>
> On Mittwoch, 14. Juli 2021 13:19:44 CEST Thomas Haller wrote:
> [...]
> > > I use the perl module Net::DBus for this job.
> > > The following snippet shows how far I got up to date:
> > >
> > > my $busobjpath = "/org/freedesktop/DBus/Properties";
> >
> > Such an object path does not exist on NetworkManager's D-Bus API.
> >
> > Object paths start with "/org/freedesktop/NetworkManager".
> >
> > See all object with `d-feet` or `busctl tree
> > org.freedesktop.NetworkManager`.
>
> so how can I use org.freedesktop.DBus.Properties.PropertiesChanged
> then?
> What would be the correct way instead?
> Using
> my $busobjpath = "/org/freedesktop/NetworkManager/Settings";
> as before?
> This doesn't work either, though.
>
> Probably there is a fundamental misunderstanding regaring the concept
> on my
> side.
Hi,
I am not familiar with this Perl's Net::DBus, but in general:
On D-Bus, you have the well-known name
("org.freedesktop.NetworkManager") where you find NetworkManager's D-
Bus API.
There, you find many D-Bus objects, at paths that start with
"/org/freedesktop/NetworkManager". You see them with `busctl tree
org.freedesktop.NetworkManager`.
All of these objects also implement the standard D-Bus interface
"org.freedesktop.DBus.Properties" -- as documented at
https://dbus.freedesktop.org/doc/dbus-specification.html
That interface, has (among) others a signal "PropertiesChanged".
This "org.freedesktop.DBus.Properties.PropertiesChanged" signal works
very similar to the earlier "PropertiesChanged" signals from the NM
specific interfaces ( "org.freedesktop.NetworkManager*").
So, yes, there should be not much to do except replace the interface
name "org.freedesktop.NetworkManager*" with
"org.freedesktop.DBus.Properties".
you mention specifically
my $busobjpath = "/org/freedesktop/NetworkManager/Settings";
In `d-feet` you'll see that this object only has three properties. So
you'll see few PropertiesChanged signals on that object...
Does that help? Otherwise, please share a working, minimal example.
best,
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated
On Wed, 2021-07-14 at 13:10 +0200, m...@mike.franken.de wrote:
> Hi *,
>
> since NetworkManager 1.22 using the signal
> org.freedesktop.NetworkManager.
> Settings.PropertiesChanged is deprecated. One should use
> org.freedesktop.
> DBus.Properties.PropertiesChanged instead. Since NetworkManager 1.32
> this
> signal indeed is completely removed.
> I couldn't find any example on how to easily replace the code using
> the
> deprecated signal. I use PropertiesChanged to listen for connectivity
> changes,
> escpecially activation/deactivation of interfaces.
> Goal is to configure a few things, whenever connections were
> (de)activated.
>
> I use the perl module Net::DBus for this job.
> The following snippet shows how far I got up to date:
>
> my $busobjpath = "/org/freedesktop/DBus/Properties";
Such an object path does not exist on NetworkManager's D-Bus API.
Object paths start with "/org/freedesktop/NetworkManager".
See all object with `d-feet` or `busctl tree
org.freedesktop.NetworkManager`.
> my $busif = "org.freedesktop.DBus.Properties";
> my( $oBUSIF ) = $oBUSSVC->get_object( $busobjpath, $busif ) || die
> $!;
> $oBUSIF->connect_to_signal(
> "PropertiesChanged", sub {
> &{ \ }( @_ )
> } || die $!;
> }
> }
> my( $reactor ) = Net::DBus::Reactor->main();
> $reactor->run();
>
> The code seems to work, but it does not react on any changes
> regarding
> Networkmanager connections, at least onPropertiesChanged is never
> called.
> The old code was using NetworkManager's special PropertiesChanged
> signal and
> worked as expected.
>
> Any idea?
>
> Thx and bye.
> Michael.
Too bad that there was still a user of this API. We wouldn't have
dropped it yet, if we had been aware of existing users. But it's hard
to know who uses an API, unless you break it. Sorry about the breakage.
best,
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wifi mac address randomization password involved
On Tue, 2021-07-06 at 15:42 +, rherr via networkmanager-list wrote: > Attn: networkmanager-list > > I am trying to set up wifi mac address randomization to be automatic. I > have tried using NetworkManager and selecting "Random" in the space > provided in the GUI. I tried setting up a "Unit" and scripts also in > netctl and systemd. I can manually change the wifi setting in > macchanger and it works, but will not stay that way after a reboot, and > will only manually change after I "sudo macchanger -r > "my_network_interface_name"". The change in wifi always asks for a > password. The wired connection, however, is perfectly automated using > "macchanger -r "my_network_interface_name"" alone. I'm familiar with > sites like: > https://www.fosslinux.com/15186/how-to-change-or-spoof-a-mac-address-in-ubuntu-and-linux-mint.htm > https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address.html > and have followed the directions. I'm open to new ideas. There was a > recent change in Ubuntu OS for me to 20.04. Any help is appreciated. Hi, see an old blog: https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ also, read and use this file: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/f929bc9945e334ff89cee6598ecffcd749f52c93/examples/nm-conf.d/30-anon.conf best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PPP over ATM support
Hi, On Wed, 2021-06-23 at 01:13 +0200, Denis Prost via networkmanager-list wrote: > The only minor problem left is that this connection is not listed in > know if there is a way to have it appear in nm-applet GUI ? The GUI would need to explicitly support a certain type, and nm-applet (in this case) does not. The only solution for making that work is to extend the GUI or use an alternative GUI (I am not aware that one exists with ADSL support). It's unclear whether that is desirable however. Is this feature in the GUI only missing because nobody worked on it? Or is the feature intentionally missing to keep the GUI simple and understandable (albeit more limited). If it's the former, then a patch can fix it. Probably a well done patch for this would be accepted... it depends however and the UI should be discussed before fully working on a feature that later might not be accepted. The workaround is to use nmcli (or a possible alternative script/tool that suits you). best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.32.0 released
Hi everybody, On behalf of the NetworkManager community, I am happy to announce a new release of NetworkManager: 1.32.0. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/d9c0d43879e8420dda6482b05341dcfeedf7be43 Find the tarball at our usual location: https://download.gnome.org/sources/NetworkManager/1.32/ https://download.gnome.org/sources/NetworkManager/1.32/NetworkManager-1.32.0.tar.xz md5: 637d790b4c4453cf04f141ed71e95957 sha1: 1390bec433ba5d53d954a57321ddd453a621c3b7 sha256: ff6ecee04c1142304ddbd49a1794bb01b39ca52a0f8f59dc1c192331ee549e73 sha512: 71b6740900847f4efca665340bed76083a5f17037e570d2c89c016750b9ada70b09033c02ded0b9974a172051517cacf7466107783f2fbde70e9741bf0ae0ad0 To see what's new check the NEWS file: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/d9c0d43879e8420dda6482b05341dcfeedf7be43/NEWS or https://networkmanager.dev/blog/networkmanager-1-32/ Thanks to everybody who contributed to this release with patches and translations: Aaron Barany, Andrew Zaborowski, Beniamino Galvani, Bhushan Shah, Fernando Fernandez Mancera, Georg Müller, Gris Ge, Jagadeesh Kotra, Jan Palus, Javier Jardón, Jonas Dreßler, Jonas Jelten, Jonathan Lebon, Julia Dronova, Mejans, Paul Menzel, Peter van der Velde, Sibo Dong, Simon McVittie, Thomas Haller, Tony Espy, Vojtech Bubela, Wade Berrier, Wen Liang, Yuri Chornoivan, orbea, zsien. And as always special thanks to Vladimír Beneš, Filip Pokryvka, and Vitezslav Humpa for testing NetworkManager. Best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Preserve MAC address for a specific device
On Tue, 2021-06-08 at 19:03 +0700, Pedro Ribeiro wrote: > On Tue, 2021-06-08 at 12:37 +0200, Thomas Haller wrote: > > That means the effectively used > > value can first always be configured for each profile, and > > these > > default values only matter if the per-profile values > > explicitly > > indicates to use the default from NetworkManager.conf. > > Thank you, this worked perfectly. Turns out I was setting the preserve > value after the general one, not before! ah cool... Note what `man NetworkManager.conf` says about the order of these sections: The sections within one file are considered in order of appearance, with the exception that the [connection] section is always considered last. In the example above, this order is [...] [...] When having different sections in multiple files, sections from files that are read later have higher priority. So within one file the priority of the sections is top-to-bottom. Across multiple files later definitions take precedence. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Preserve MAC address for a specific device
On Tue, 2021-06-08 at 15:17 +0700, Pedro Ribeiro via networkmanager- list wrote: > Hi, > > I have the following configuration in spoof.conf in order to anonymise > MAC addresses when connecting to a network: > > [device-mac-randomization] > wifi.scan-rand-mac-address=yes > > [connection-mac-randomization] > ethernet.cloned-mac-address=stable > wifi.cloned-mac-address=stable > > However, this doesn't work with an iPhone tether ethernet device: > > Jun 8 10:53:06 testing NetworkManager[50086]: > [1623124386.8513] device (iphone): state change: disconnected -> > prepare (reason 'none', sys-iface-state: 'managed') > Jun 8 10:53:06 testing NetworkManager[50086]: > [1623124386.8520] platform-linux: do-change-link[19]: failure changing > link: failure 95 (Operation not supported) > Jun 8 10:53:06 testing NetworkManager[50086]: > [1623124386.8537] platform-linux: do-change-link[19]: failure changing > link: failure 95 (Operation not supported) > Jun 8 10:53:06 testing NetworkManager[50086]: > [1623124386.8537] device (iphone): set-hw-addr: failed to set-cloned > MAC address to fa:2b:4c:dd:47:b1 (stable) (NME_UNSPEC) > Jun 8 10:53:06 testing NetworkManager[50086]: > [1623124386.8550] device (iphone): state change: prepare -> failed > (reason 'config-failed', sys-iface-state: 'managed') > > Probably the device doesn't allow the MAC address to be changed. > Anyway, I decided to see if I could disable the MAC address > randomisation for a specific device with the following config file: > > [connection-iphone] > match-device=interface-name:iphone > ethernet.cloned-mac-address=preserve > > ... but it doesn't seem to work, NM always tries to set the ethernet > address of the device as above. > > Am I doing something wrong? Is this possible, to have a global > randomisation on but turned off for a specific device? did you afterwards reload the configuration with `killall -SIGHUP` or `systemctl reload NetworkManager`? And did you re-activate the desired profile afterwards? `man NetworkManager.conf` says about the [connection*] section: Specify default values for connections. Such default values are only consulted if the corresponding per-connection property explicitly allows for that. That means, all these properties correspond to a property of the connection profile (for example connection.mud-url). Only if the per-profile property is set to a special value that indicates to use the default, the default value from NetworkManager.conf is consulted. It depends on the property, which is the special value that indicates fallback to the default, but it usually is something like empty, unset values or special numeric values like 0 or -1. That means the effectively used value can first always be configured for each profile, and these default values only matter if the per-profile values explicitly indicates to use the default from NetworkManager.conf. all these default values can be configured per-profile. Check the per-profile value by looking at the profile with `nmcli connection show "$PROFILE"`. > to have a global > randomisation on but turned off for a specific device? And, the default values in the [connection*] section can also be per- device too. As you specified "match-device=interface-name:iphone", this section will only be relevant when activating a profile on iphone device which does not specify ethernet.cloned-mac-address already. [connection-ethernet-cloned-mac-address-iphone] match-device=interface-name:iphone ethernet.cloned-mac-address=preserve [connection-ethernet-cloned-mac-address-all] ethernet.cloned-mac-address=stable best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for Intel Active Management Technology over wireless in Linux
On Thu, 2021-05-27 at 21:40 +0300, Emmanuel Grumbach via networkmanager-list wrote: > > Disclaimer: This feature is available only on vPRO Platforms. > > Question to the NM maintainers: > Would you consider merging patches that would implement this? Definitely. The most important property for implementing a feature is that the underlying dependencies are also open soure and merged upstream. In this case, the requirement is that (upstream) kernel and (upstream) wpa_supplicant can support this feature -- or at least, there is a real possibility that it will support it in the future. That you need a special hardware is fine. It however poses a practical problem if upstream contributors cannot test/contribute to it. It basically means that those contibutors who care about this feature (and can test it) need to carry more burden than usual. > Do you see any blocker to implement this? Maybe the handling of RFKILL in NetworkManager requires some cleanup first. That would be in `src/core/nm-manager.c` and `src/core/rf-kill- manager.c`. Your description is very detailed. Thank you. It does not sound entirely trivial to me however :). NetworkManager is mostly about having connection profiles and activating them. It's not clear to me how this ATM fits with that model. Would the user still configure a connection profile? Should a connection profile be auto-generated (there are cases where wo do that, for example for bluetooth paired devices). > Any recommendation for the implementation? NetworkManager does talk relatively little nl80211 to kernel. Mostly it only configures wpa_supplicant. And most things happen when "activating" a profile in NetworkManager. I don't have concrete suggestions. Did you look at NetworkManager alraeady? Maybe we can find first "simpler" steps and break this down? best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhclient-${IFNAME}.conf stopped working after upgrade FC32 -> FC34
Hi,
First of all, as always: enable level=TRACE logging and look at the
logs and have them ready for inspection. Read [1] for hints about
logging.
[1]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/bae22a45d837e76e805f0f411b2d71748e76625e/contrib/fedora/rpm/NetworkManager.conf#L27
1) you already found the [main].dhcp setting. See `man
NetworkManager.conf`. So, this probably does not apply to you. Still:
If you configure [main].dhcp=dhclient, then NetworkManager uses
dhclient DHCP plugin. That involves reading files from /etc/dhcp and
merging them. This was, the user can hack the behavior of dhclient.
This did not change between Fedora 32 and Fedora 34.
What might have changed, is the default setting for [main].dhcp. Since
NetworkManager 1.18, the default changed from [main].dhcp=dhclient to
[main].dhcp=internal. But that did not happen in Fedora 32. So it's not
clear why this would behave different. Also, you might have had another
application that dropped a configuration snippet to
/{usr/lib,run,etc}/NetworkManager/conf.d, which is now gone? Anyway,
check that the desired right DHCP plugin is used.
2) what might have changed is how certain options get merged from
/etc/dhcp. Enable `level=TRACE` logging. See how dhclient gets spawned.
Note the configuration file that NetworkManager generated. Check what
differs or what is missing (if anything).
3)
> $ nmcli c m $UUID 'DHCP4.OPTION+=supersede domain-name-servers=(127.0.0.1)'
this does not work. The upper case optoins are not settings of the
profile. Instead these are run-time information of the device (display
only). The way to configure NetworkManager is by configuring settings
of the connection profile, that is the lower case options in nmcli
Except, bypassing that API by instructing dhclient in /etc/dhcp
directly as you did earlier.
4) I did try :
'set ipv4.dns 127.0.0.1
save persistant
'
I think you would still the the DNS settings form DHCP. Disable that
with
nmcli connection modify "$PROFILE"
ipv4.ignore-auto-dns yes ipv6.ignore-auto-dns yes
Of course, if all you want is 127.0.0.1 and this is a very static
configuration, then there is no problem with telling NetworkManager not
to configure /etc/resolv.conf. The best way is to make /etc/resolv.conf
as symlink to /etc/my-resolv.conf. That automatically tells
NetworkManager to stay away. Otherwise, configure [main].dns=unmanaged.
See the [main].dns, [main].rc-manager and [main].systemd-resolved
options in `man NetworkManager.conf`.
best,
Thomas
On Mon, 2021-05-31 at 16:17 +0100, Jason Vas Dias via networkmanager-
list wrote:
> I did try :
> 'set ipv4.dns 127.0.0.1
> save persistant
> '
> in 'nmcli c e $uuid', but this did not work either after an up / down
> -
> /etc/resolv.conf was not updated to contain only '127.0.0.1' - it did
> ALSO contain '127.0.0.1', but as a suffix, not a prefix - this is not
> what I want .
> This did used to work with my old setup on FC32, but not on FC34 .
> Is there any custom dhclient.conf file that is included in the current
> implementation anymore ?
> Thanks, Jason
>
> On 31/05/2021, Jason Vas Dias wrote:
> >
> > Good day -
> >
> > On an FC32 x86_64 box, which I just successfully upgraded to FC34 ,
> > now running NM 1.30.4-1.fc34.x86_64 :
> > I had some custom dhclient configuration files, which used to be
> > honored
> > by NM - ie. they took effect before upgrade, but not after:
> >
> > /etc/dhcp/{dhclient-ens1u2u4.conf,dhclient-wlp59s0.conf}
> >
> > which contain:
> >
> > dhclient.ens1u2u4.conf :
> >
> > interface "ens1u2u4" {
> > send dhcp-client-identifier 34:48:ed:a8:7c:be;
> > send host-name "jvdspc.jvds.net";
> > supersede domain-name-servers 127.0.0.1;
> > }
> >
> >
> > dhclient.wlp59s0.conf :
> > interface "wlp59s0" {
> > send dhcp-client-identifier 5c:80:b6:72:cb:7b;
> > send host-name "jvdspc.jvds.net";
> > supersede domain-name-servers 127.0.0.1;
> > }
> >
> >
> > There are links to these files in /etc/dhclient-
> > {ens1u2u4,wlp59s0}.conf ,
> > and
> > /etc/dhclient.{ens1u2u4,wlp59s0}.conf .
> >
> > These files used to be merged in to the effective DHCP client
> > configuration , on FC32, and all prior FC & RHEL releases I've
> > used, in:
> > /var/lib/NetworkManager/dhclient-{ens1u2u4,wlp59s0}.conf
> > , in use for each interface, which is written for each 'up'
> > transition,
> > but no longer.
> >
> > I have in /etc/NetworkManager/NetworkManager.conf:
> >
> > [main]
> > #plugins=ifcfg-rh
> > dhcp=dhclient
> >
> >
> > I want to run my own ISC BIND caching nameserver,
> > which serves some authoritative zones and some RPZ (response
> > policy) zones
> > ,
> > and also tell any Dynamic DNS configured DHCP servers what I
> > consider
> > my domain name to be.
> >
> > I already had to disable systemd-resolved service after the
> > upgrade, which
> > also
> > broke using my own nameserver.
> >
> > Please can
Re: Network Manager + ovsdb issues
Hi, On Mon, 2021-05-24 at 14:35 -0700, Abu Rasheda via networkmanager-list wrote: > Hello, > > I am seeing two issues with NM and ovsdb. Issue # 2 is more critical. > > In my configuration, I have two bridges in OVS. On one of the bridge, > the interface needs to be under Network Manager, so I have changed > commands to: > > nmcli conn add type ovs-bridge conn.interface > nmcli conn add type ovs-port conn.interface > nmcli conn add type ovs-interface slave-type ovs-port conn.interface > nmcli conn add type ethernet conn.interface these commands are not complete and not working. Could you share the full commands? also, after you created the profiles (an activate them), what gives `nmcli connection`, `nmcli device` and `ovs-vsctl show` ? > On the other bridge, I am still using, e.g. > > ovs-vsctl --timeout=5 add-br > > Also, there are a bunch of places where ovs-vsctl is used for reading, > e.g. > > ovs-vsctl list-ports > > > > The issues I am seeing are: > > (1) For Interface/ports created via nmcli, sometimes I have issue > deleting them: > > I see the config file in /etc/NetworkManager/system-connections/ovs- > slave-port1 > > nmcli c delete ovs-slave-port1 > > I get something like, this device does not exist (I have seen this > error once) This merely deletes a profile in NetworkManager. This always should succeed, and there is no reason why it can fail (except bugs). But there is not enough information provided, to understand what exactly fails. The message "device does not exist" doesn't make sense for this command. Please share the literal error messages by quoting them, not paraphrasing. Also, please always collect `level=TRACE` logs of NetworkManager. See https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/9eac9c846c6bb7b0baa77b72638aaf79df4a5ca6/contrib/fedora/rpm/NetworkManager.conf#L29 for hints about logging. > > Following is a more important issue > > (2) In some situations, commands like the following would timeout: > > ovs-vsctl --timeout=5 add-port bridge1 port1 > > If I run the above command without --timeout, this will never return. > However, if I let it timeout or ctrl-c and use ovs-vsctl show, it > shows that port1 is created. Are "bridge1" and "port1" the actual names, or is this an example? > > I ran this under strace and saw ovs-vsctl is stuck at poll call. I > have also seen > > cat ovsdb-server.log > 2021-05- > 24T14:13:11.930Z|3|reconnect|INFO|unix:/var/run/vmware/nsx- > agent/nsxagent_ovsdb.sock: connecting... > 2021-05- > 24T14:13:11.930Z|4|reconnect|INFO|unix:/var/run/vmware/nsx- > agent/nsxagent_ovsdb.sock: connection attempt failed (No such file or > directory) I am no tfamiliar with OVS, but this doesn't seem relevant. Is something else in those logs? > > It connects fine when using ovs-vsctl show > > Question: > > 1. Is it okay to use both nmcli and ovs-vsctl to create > bridges/ports/interfaces (when they are under different bridges)? yes (presumably) did you test that not using NetworkManager in parallel avoids the problem? NetworkManager talks directly to ovsdb, like ovsvs-ctl does. Deactivate all OVS profiles in NetworkManager (check `nmcli connnection` and `nmcli conneciton down "$PROFILE"`). Then also check that nothing is left over in ovsdb from NetworkManager (with `ovs-vsctl show`). Then perform the steps on the other bridge. Do they work? > > 2. Have anyone seen these errors? > I didn't. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 1.20.4 and wpa_supplicant v2.9
On Thu, 2021-05-20 at 14:07 +0200, Juan A. Rubio via networkmanager- list wrote: > Hello, > > I'm using NetworkManager version 1.20.4 on a device with a > Buildroot-based custom Linux distribution. The version of > wpa_supplicant is 2.9 and I've noticed that this version of > supplicant > has lost the -u flag > > E.g. from wpa_supplicant v2.6's help message > > " -u = enable DBus control interface " > > In previous versions, I would start supplicant with the -u option and > that would be all that was needed in order to get NM to manage it > using D-BUS. > > So I'm wondering what is the right way of starting wpa_supplicant > v2.9 > to allow control by NM? Isn't NM expected to start it via D-BUS > activation if the supplicant isn't already running? > > Thanks in advance for your help > Juan Hi, yes, NetworkManager will D-Bus activate wpa_supplicant. It also only interacts with wpa_supplicant using the D-Bus interface. You consequently need to ensure that supplicant is properly configured and can use D-Bus. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager CAN Support
Hi, On Tue, 2021-05-11 at 13:23 +, Kraxner, Josef AVL/AT via networkmanager-list wrote: > Hello, > > I have one question regarding CAN support in NetworkManager. I tried > to set up CAN within NetworkManager, but it doesn’t work. > Then I noticed that there is anyway no CAN connection type available > (nmcli connection add type can ifname can0 -> bad connection type: > can) > Did I something wrong or is CAN anyway not implemented at the moment? CAN interfaces are currently not supported (beside, the "generic" connection type, where you could create the interface outside of NetworkManager and only use the generic profile for doing IP configuration on the link -- but, I think generic profiles are little used, so there might be problems with that.) > Will you plan to integrate CAN configuration in future? No plan. Things get done exactly when somebody wishes to contribute a feature. Such a contribution would be very welcome. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: link-local fallback
Hi, On Tue, 2021-04-27 at 12:04 +, Michel, Matthias via networkmanager- list wrote: > Hi > I'm using the dhcp=systemd setting in the networkmanager v1.30.2. Btw, dhcp=systemd is an (intentionally) undocumented option. Eventually it will be replaced and behave the same as dhcp=internal. In practice, for you there should be no difference between using dhcp=internal and dhcp=systemd. And if there is a difference, that is probably something we'd like to fix/investigate. But sure, dhcp=systemd works too. > I have a requirement to switch to a fallback link-local when the dhcp > is not available and to return from link-local to dhcp when it is > back. > > What I was able to configure was the fallback to link-local. But > switching to dhcp automatically was not possible. > > my connections with networkmanager: > > cat br-lan.nmconnection > [connection] > id=br-lan > uuid=0d924e20-a7ca-4eec-9ad1-28b6d2ddb0c2 > autoconnect-priority=100 > autoconnect-retries=1 > interface-name=br-lan > llmnr=2 > permissions= > zone=lan > > [bridge] > stp=false > > [match] > kernel-command-line=!test; > > [ipv4] > dhcp-timeout=3 > dns-search= > may-fail=false > method=auto > route1=224.0.0.0/4,0.0.0.0,0 > > [ipv6] > addr-gen-mode=stable-privacy > dns-search= > method=auto > [proxy] > > > cat br-lan-ll.nmconnection > [connection] > id=br-lan-ll > uuid=1d924e20-a7ca-4eec-9ad1-28b6d2ddb0c2 > type=bridge > autoconnect=true > autoconnect-priority=50 > interface-name=br-lan > llmnr=2 > permissions= > timestamp=1617958884 > zone=lan > > [bridge] > stp=false > > [match] > kernel-command-line=!test; > > [ipv4] > dns-search= > method=link-local > route1=224.0.0.0/4,0.0.0.0,0 > > [ipv6] > addr-gen-mode=stable-privacy > dns-search= > method=disabled > > [proxy] > > > my connection with networkd: > > cat /etc/systemd/network/lan.network > [Match] > Name=enp44s0u2u1 > > [Network] > Bridge=br0 > > cat /etc/systemd/network/br0.netdev > [NetDev] > Name=br0 > Kind=bridge > > cat /etc/systemd/network/bridge.network > [Match] > Name=br0 > > [Network] > DHCP=ipv4 > LinkLocalAddressing=fallback > > [DHCPv4] > MaxAttempts=1 The problem is that once the LL profile activates, it will not fail automatically, and DHCP is never tried again. So there really needs to be one profile that enables both DHCP and LL, possibly with an option that says: only do LL while not having a DHCP lease. That requires new API. The current ipv4.method is not flexible enough for that. That needs improvement. > I studied the code of networkmanager and networkd. > > networkd: > > https://github.com/systemd/systemd/blob/3a1e9d8083b83f611a23cc84ba69a8175e659629/src/network/networkd-dhcp4.c#L1128 > > > networkmanager: > > https://github.com/NetworkManager/NetworkManager/blob/af360238be198257934b89d42f24431401550721/src/core/dhcp/nm-dhcp-systemd.c#L495 > > Is there a design reason why this behavior is implemented > differently? The reason is that it was not implemented this way (yet). currently, you cannot have LL and DHCP together. Neither always together nor LL-fallback-for-DHCP. Both of course makes sense. > > Is it mainly a configuration error on my part? No. > Would the community accept changes to get the same behavior for > networkmanager as is the case in networkd? Yes, but it might not be as straight forwards as it should be. Also, currently we are about to rework a part in NetworkManager that manages the IP configuration. That should make it simpler to do such a thing. But the work is not yet finished. In the current code, without this larger rework, I find it rather difficult to implement this feature, and also that would conflict/overlap with that work in progress. Independent of that, there is the question how the current API (that is the settings of the connection profiles) should be extended in a backward compatible and future proof way, so that such schemes are configurable. Possbily there should be new options ipv4.dhcp=disabled|required|optional ipv4.ll=disabled|enabled|fallback that basically extend "ipv4.method". Thank you for you offer to help out. We always appreciate that!! For thinking about how the connnection profiles should be, that is already a good task. About the internals (that get currently reworked), maybe hold back for a few weeks because the work would overlap. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: multiple profiles
On Mon, 2021-04-19 at 10:32 -0700, Abu Rasheda wrote:
> Thanks, for the reply!
>
> So I have to check manually? no way nmcli saying file exits and quit.
> (because it will still make a file with name ifcfg-xxx-1 if ifcfg-xxx
> exist).
Hi,
not sure why you ask so much about the filename. If you create the
profile via D-Bus API (nmcli, or any of the client tools), then the
filename is not well defined. It will be "something" suitable. If you
care about the filename, create the file yourself, with the desired
name (followed by `nmcli connection reload`).
This seems to be more about the name of the connection profile
("connection.id"). But yes, the resulting filename is based on the
profile name, with a numeric suffix ("-1") if the name already exists.
But more to your question: no, `nmcli connection add` will not fail if
a profile with the chosen "connection.id" already exits. It will print
a warning about that.
If you are an interactive user, then check yourself the existing
profiles (and their names) via `nmcli connection`.
If you write a script, then script it. E.g.
nmcli connection show id "$NAME" &>/dev/null ||nmcli connection add con-name
"$NAME" type ...
best,
Thomas
>
> On Fri, Apr 16, 2021 at 11:27 PM Thomas Haller
> wrote:
> > On Fri, 2021-04-16 at 17:57 -0700, Abu Rasheda via networkmanager-
> > list
> > wrote:
> > > E.g. running the following command multiple times
> > >
> > > nmcli conn add type ethernet
> > >
> > > will create multiple files
> > >
> > > -rw-r--r--. 1 root root 270 Apr 16 20:53 ifcfg-ethernet
> > > -rw-r--r--. 1 root root 272 Apr 16 20:54 ifcfg-ethernet-1
> > >
> > > Is it possible for nmcli to see that ifcfg-ethernet already exist
> > and
> > > not create ifcfg-ethernet-1
> > >
> > > How can I pass this message to nmcli
> > >
> > > Thanks
> >
> >
> > Hi,
> >
> >
> > The NetworkManager client tool (like nmcli, or a GUI) in general
> > does
> > not know which file name will be chosen. In the NetworkManager API
> > you
> > can see the file name (like
> >
> > - `nmcli -f all connection`
> > - `nmcli connection up filename "$FILENAME"`
> > - `nmcli connection load "$FILENAME"`
> >
> > but the client tool cannot pre-determine which file name will be
> > used
> > when adding a profile.
> >
> > If you care about the filename, create the file instead of using
> > `nmcli
> > connection add` (followed by `nmcli connection reload`)
> >
> >
> > But is your problem really the filename here? It seems, when you
> > add
> > a
> > new profile, it would be good to choose a name for it, and don't
> > let
> > nmcli automatically choose "ethernet" and "ethernet-1". Just do:
> >
> > nmcli connection add type ethernet con-name xxx
> >
> > "con-name" is an alias for "connection.id", and contrary to what
> > one
> > might reasonably expect, the "id" is not enforced to be unique:
> >
> > $ nmcli connection add type ethernet con-name xxx
> > Connection 'xxx' (7f23f5cd-90f3-4cd8-8612-cf5d0856b130)
> > successfully
> > added.
> > $ nmcli connection add type ethernet con-name xxx
> > Warning: There is another connection with the name 'xxx'. Reference
> > the connection by its uuid '8811722f-d662-48c5-9271-c8aa764d8f4a'
> > Connection 'xxx' (8811722f-d662-48c5-9271-c8aa764d8f4a)
> > successfully
> > added.
> >
> > It's a good idea to ensure yourself that the connection.id is
> > unique.
> > That means, before you add a new profile, check the existing names
> > in
> > `nmcli connection` output and choose a different name.
> >
> >
> > best,
> > Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Erroneous "mismatching interface name" error?
On Mon, 2021-04-19 at 09:59 -0400, Lars Kellogg-Stedman via networkmanager-list wrote: > I have a system (an OpenShift bare metal node running RHCOS > 47.83.202103051045-0) with NetworkManager 1.26.0. The system recently > lost its public ip address. When I logged into the system, I saw: > > # nmcli c show > NAME UUID TYPE > DEVICE > Wired connection 1 de1f2c7a-9fb9-3581-89ce-43cb3157db92 ethernet > eno1 > Wired connection 2 e2318199-ce78-35d4-91b0-b2b4a73fb6b6 ethernet > -- > Wired connection 3 e14a050c-e6c6-33f5-93ef-d1db97a39052 ethernet > -- > Wired connection 4 ae774310-1c88-3354-9d0d-82997bae23b5 ethernet > -- > > Where "Wired connection 2" is supposed to be online for device eno2. > The device is set correctly in the connection configuration: > > # nmcli c show 'Wired connection 2' > [...] > connection.interface-name: eno2 > > And the interface was in fact present, although it was showing > NO-CARRIER (which is maybe why we lost the address in the first place, > but doesn't explain the subsequent error): > > # ip addr show eno2 > 3: eno2: mtu 1500 qdisc mq > state DOWN group default qlen 1000 > link/ether 90:b1:1c:3a:15:7f brd ff:ff:ff:ff:ff:ff > > > When I tried to bring up the interface by running `nmcli c up > "Wired connection 2"`, I received the following error: > > # nmcli c up 'Wired connection 2' > Error: Connection activation failed: No suitable device found for > this > connection (device eno1 not available because profile is not > compatible with device (mismatching interface name)). > > Why was this connection trying to use eno1 instead of eno2? Because NetworkManager is looking for a suitable device, but it couldn't find any. Hence, it also wasn't smart enough, that eno2 would have been less wrong. If you had done $ nmcli connectoin up "Wired connection 2" ifname eno2 then the command would have still failed, but with a better error message (like "cable is not plugged in"). NetworkManager already tries to find the best of the unsuitable devices, patch welcome to make it smarter to understand that eno2 would have been better. Here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/34e4a3ef174005439af78278500290ce68e4bebb/src/core/nm-manager.c#L3845 > > After rebooting the system, the interface came up without a problem: > > # nmcli c show > NAME UUID TYPE > DEVICE > Wired connection 2 e2318199-ce78-35d4-91b0-b2b4a73fb6b6 ethernet > eno2 > Wired connection 1 de1f2c7a-9fb9-3581-89ce-43cb3157db92 ethernet > eno1 > Wired connection 3 e14a050c-e6c6-33f5-93ef-d1db97a39052 ethernet > -- > Wired connection 4 ae774310-1c88-3354-9d0d-82997bae23b5 ethernet > -- > signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: multiple profiles
On Fri, 2021-04-16 at 17:57 -0700, Abu Rasheda via networkmanager-list wrote: > E.g. running the following command multiple times > > nmcli conn add type ethernet > > will create multiple files > > -rw-r--r--. 1 root root 270 Apr 16 20:53 ifcfg-ethernet > -rw-r--r--. 1 root root 272 Apr 16 20:54 ifcfg-ethernet-1 > > Is it possible for nmcli to see that ifcfg-ethernet already exist and > not create ifcfg-ethernet-1 > > How can I pass this message to nmcli > > Thanks Hi, The NetworkManager client tool (like nmcli, or a GUI) in general does not know which file name will be chosen. In the NetworkManager API you can see the file name (like - `nmcli -f all connection` - `nmcli connection up filename "$FILENAME"` - `nmcli connection load "$FILENAME"` but the client tool cannot pre-determine which file name will be used when adding a profile. If you care about the filename, create the file instead of using `nmcli connection add` (followed by `nmcli connection reload`) But is your problem really the filename here? It seems, when you add a new profile, it would be good to choose a name for it, and don't let nmcli automatically choose "ethernet" and "ethernet-1". Just do: nmcli connection add type ethernet con-name xxx "con-name" is an alias for "connection.id", and contrary to what one might reasonably expect, the "id" is not enforced to be unique: $ nmcli connection add type ethernet con-name xxx Connection 'xxx' (7f23f5cd-90f3-4cd8-8612-cf5d0856b130) successfully added. $ nmcli connection add type ethernet con-name xxx Warning: There is another connection with the name 'xxx'. Reference the connection by its uuid '8811722f-d662-48c5-9271-c8aa764d8f4a' Connection 'xxx' (8811722f-d662-48c5-9271-c8aa764d8f4a) successfully added. It's a good idea to ensure yourself that the connection.id is unique. That means, before you add a new profile, check the existing names in `nmcli connection` output and choose a different name. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Output silence!
Hi,
On Fri, 2021-04-16 at 17:52 -0700, Abu Rasheda via networkmanager-list
wrote:
> When a command is executed using nmcli, on the success a line like the
> following is printed.
>
> Connection 'eth0-ethernet' (a24480cb-f5d6-40a6-a716-dba09ab53d07)
> successfully added.
>
> Is it possible to not have this line go to standard out?
> without using ">" operator. May some switch can be passed to nmcli
No. Use shell and its redirection feature. There is nothing wrong with
using shell's features to redirect and process the output. What is the
problem with that?
In general, nmcli should be usable from scripts, while also pleasing ot
the interactive, human user. That is a conflict. If you write a script,
you would not want this extra text but only get the UUID (or a
failure).
I guess, nmcli should get better here, and providing alternative
outputs that are more consumable by scripts. But the result would be
only more command line options, that all become part of the stable
API... we are slow and reluctant to change (or even extend) the output
of nmcli.
For example, if you go full measure, you could be very strict about
parsing the output and do something like:
nmcli_my_add() {
local x
x=$(LANG=C nmcli connection add "$@") || return 1
x="$(printf "%s" "$x" | sed -n 's/^Connection '.*' (\(.\+\)) successfully
aadded\.$/\1/p')"
test -n "$x" || return 1 # Something is wrong, we failed to parse the
output!!
printf "%s\n" "$x"
}
UUID="$(nmcli_my_add type ethernet ...)"
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Wifi AP without WPS Pin?
On Fri, 2021-04-09 at 10:41 +0200, Florian Klein wrote: > Hello Thomas, > > Thanks a lot for your reply. This is really helpful. > > In the meantime I found that this issue got fixed last month in > Network Manager: > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/756 Oh, I was not aware of this. > But because we do not have a way to use the latest version it would > be wonderful to find a workaround. if you rebuild NetworkManager, then it should be simple to backport this patch. But indeed, it is undesirable to maintain your own package... > I tried to disable wps in the wpa_supplicant config [1] file but this > did not work. Is this the right way to adjust it? Is this even the > wpa_supplicant config used by network manager? I thought that might work. I tried, and even with debug logging wpa_supplicant does not log that it was reading the config file and it didn't complain about bogus entries in the configuration. But it should have used the file... I don't know. I'd suggest to run wpa_supplicant with debug logging (-ddd) and check the logs, if you didn't already do that. best, Thomas > > Thanks a lot and best regards, > > Florian > > [1] Added to > /etc/wpa_supplicant/wpa_supplicant.conf > > ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev > wps_disabled=1 > update_config=1 > country=DE > > > > > On 9. Apr 2021, at 08:42, Thomas Haller wrote: > > > > On Wed, 2021-04-07 at 17:18 +0200, Florian Klein wrote: > > > Dear Network Manager Experts, > > > > > > we are opening an Access Point with network manager (on a RPI4 > > > with > > > Raspbian) and everything is working fine except that when > > > connecting > > > from Windows 10 we are asked for a pin first (probably wps pin) > > > instead > > > of getting shown directly the passphrase field to enter. This is > > > not > > > observed on Mac and Linux. > > > > > > Our wifi-ap configuration: > > > sudo nmcli c add con-name wifi-ap type wifi ssid test > > > ifname > > > wlan0 save yes autoconnect yes 802-11-wireless.mode ap 802-11- > > > wireless.band bg ipv4.method shared wifi-sec.key-mgmt wpa-psk > > > wifi- > > > sec.psk "test1234" > > > > > > > > > We already tried multiple configurations from the provided page: > > > > > > https://developer.gnome.org/NetworkManager/stable/settings-802-11-wireless-security.html > > > like: > > > - wps-method 1 > > > - proto rsn > > > - pairwise ccmp > > > > > > But nothing really helped. Would be fantastic to get your support > > > here. > > > Thanks > > > > > > Hi Florian, > > > > > > in another email you said that you are using Version 1.14.6, from > > Raspian10. That's is quite an old version and it might be > > interesting > > to try a recent version. But in practice, I don't think your > > question > > will be solved by that, so OK. > > > > NetworkManager's "wifi.mode ap" is something simple that is mainly > > aimed for simple setups. The reason is that if you run a "serious" > > access point, you might want to configure countless parameters > > related > > to Wi-Fi, but then also want more control over the DHCP and DNS > > server. > > NetworkManager does that all, but the configuration options are not > > that extended. So, consider whether NetworkManager is the right > > choice > > here. But we really want NetworkManager to be stellar also in such > > cases, so it's not that we say: "such usecase is not supported". > > But: > > "maybe it doesn't work that well yet, but we'd hope to improve on > > that > > (e.g. by adding new configuration options and fix issues in certain > > use-cases)". > > > > > > OK, more to your actual question... > > > > > > NetworkManager uses wpa_supplicant's AP mode. wpa_supplicant is the > > sibling of hostapd, and both are highly configurable. Your problem > > indeed seems to be related to WPS. I am not familiar with this, so > > I > > don't know the solution. I would think you first should understand > > how > > to configure this in wpa_supplicant (or hostapd). And then, in a > > second > > step, how to bring NetworkManager to get that right. > > > > What NetworkManager does, is relatively simple. Enable > > `level=TRACE` > > logging (see [1]), then NetworkManager will log the options that it >
Re: Network Manager Wifi AP without WPS Pin?
On Wed, 2021-04-07 at 17:18 +0200, Florian Klein wrote:
> Dear Network Manager Experts,
>
> we are opening an Access Point with network manager (on a RPI4 with
> Raspbian) and everything is working fine except that when connecting
> from Windows 10 we are asked for a pin first (probably wps pin) instead
> of getting shown directly the passphrase field to enter. This is not
> observed on Mac and Linux.
>
> Our wifi-ap configuration:
> sudo nmcli c add con-name wifi-ap type wifi ssid test ifname
> wlan0 save yes autoconnect yes 802-11-wireless.mode ap 802-11-
> wireless.band bg ipv4.method shared wifi-sec.key-mgmt wpa-psk wifi-
> sec.psk "test1234"
>
>
> We already tried multiple configurations from the provided page:
> https://developer.gnome.org/NetworkManager/stable/settings-802-11-wireless-security.html
> like:
> - wps-method 1
> - proto rsn
> - pairwise ccmp
>
> But nothing really helped. Would be fantastic to get your support here.
> Thanks
Hi Florian,
in another email you said that you are using Version 1.14.6, from
Raspian10. That's is quite an old version and it might be interesting
to try a recent version. But in practice, I don't think your question
will be solved by that, so OK.
NetworkManager's "wifi.mode ap" is something simple that is mainly
aimed for simple setups. The reason is that if you run a "serious"
access point, you might want to configure countless parameters related
to Wi-Fi, but then also want more control over the DHCP and DNS server.
NetworkManager does that all, but the configuration options are not
that extended. So, consider whether NetworkManager is the right choice
here. But we really want NetworkManager to be stellar also in such
cases, so it's not that we say: "such usecase is not supported". But:
"maybe it doesn't work that well yet, but we'd hope to improve on that
(e.g. by adding new configuration options and fix issues in certain
use-cases)".
OK, more to your actual question...
NetworkManager uses wpa_supplicant's AP mode. wpa_supplicant is the
sibling of hostapd, and both are highly configurable. Your problem
indeed seems to be related to WPS. I am not familiar with this, so I
don't know the solution. I would think you first should understand how
to configure this in wpa_supplicant (or hostapd). And then, in a second
step, how to bring NetworkManager to get that right.
What NetworkManager does, is relatively simple. Enable `level=TRACE`
logging (see [1]), then NetworkManager will log the options that it
sets in supplicant, like
Config: added 'mode' value '2'
('2' means AP mode). NetworkManager configures wpa_supplicant via the
D-Bus API.
I think there is a "wps_disabled" option in wpa_supplicant.conf. It's
not clear whether "wps_disabled" is really the right solution to your
problem. But if it is, you might be able to set that in
wpa_supplicant.conf so that it gets honored.
If it's really about wps_disabled, I guess you could also re-compile
supplicant package without WPS support. Would be at least interesting
as a try.
If that is the right solution, then maybe this should be set by
NetworkManager (but I think the flag is currenlty not configurable via
D-Bus(?)). Anyway, it would be interesting later to improve
NetworkManager to get this right.
[1]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L49
hope this gave you some ideas,
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how to create bridge on main interface?
On Tue, 2021-03-23 at 15:28 +0100, Jan Hutař via networkmanager-list
wrote:
> Hello.
>
> Hopefully this is good place to ask. If not, please suggest something
> else.
>
> For quite some time I'm trying to figure out how to create a bridge
> using main network interface (the only one which is routable to the
> host).
>
> I have tried these Ansible tasks:
>
> - name: "Get {{ public_nic }} connection name"
> shell: nmcli --terse device | grep "^{{ public_nic }}:" | cut -d
> ':' -f 4
> register: public_connection_cmd
> - name: "Extract {{ public_nic }} connection name"
> set_fact:
> public_connection: "{{
> public_connection_cmd.stdout_lines|first|trim }}"
>
> - name: "Create brpublic bridge connection"
> nmcli:
> conn_name: brpublic
> ifname: brpublic
> type: bridge
> stp: no
> state: present
>
> - name: "Put {{ public_nic }} device into brpublic"
> nmcli:
> conn_name: brpublic-slave
> ifname: "{{ public_nic }}"
> type: bridge-slave
> master: brpublic
> state: present
>
> - name: "Remove old {{ public_nic }} connection"
> nmcli:
> conn_name: "{{ public_connection }}"
> state: absent
> when: "public_connection != '' and public_connection !=
> 'brpublic-slave'"
This is the ansible module "nmcli". I am not familiar with that, it
might be fine though. FYI, there is also
https://galaxy.ansible.com/linux-system-roles/network
> but this breaks the network on the last task.
>
> I have also tried these two ways via "shell":
>
> set -xe
>
> old_connection=$( nmcli --terse device | grep "^{{ public_nic }}:"
> | cut -d ':' -f 4 )
while not a big difference, I'd do:
old_connection="$(nmcli -g DEVICE,CON-UUID device | sed -n 's/^{{ public_nic
}}://p')"
>
> nmcli con add type bridge con-name brpublic ifname brpublic
> ###nmcli con add type bridge-slave con-name brpublic-slave ifname
> "{{ public_nic }}" master brpublic
> nmcli connection modify "$old_connection" master brpublic
nmcli connection modify uuid "$old_connection" master brpublic
>
> ###if [ -n "$old_connection" -a "$old_connection" != 'brpublic-
> slave' ]; then
> ### nmcli c delete "$old_connection"
> ###fi
>
> nmcli con up brpublic
if the port profile "$old_connection" was already activated, then this
script does not change anything about that.
Your script modifies "$old_connection", but modifying a profile only
does that. If the profile is currently active, then those changes only
take effect after activating the profile again (with `nmcli connection
up uuid "$old_connection"`).
> but this fails as well (script works, but at the end according to `ip
> a` IP
> is still on the main interface, not on "brpublic").
>
> Mine end goal is to have VM on that bridge that can be accessible from
> outside network.
>
> What is the right way to do that remotely?
That sounds doable. But I'd suggest to test the script under
circumstances where you can easily recover from looking connections.
> Thank you in advance,
> Jan
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Consent, maybe?
On Fri, 2021-03-19 at 12:03 +0100, Thomas Haller via networkmanager- list wrote: > On Fri, 2021-03-19 at 06:52 -0400, Adam Sherlock via networkmanager- > list wrote: > Hi, I forgot to say: Good luck!! :) Any maybe you'd like to get inspired (or contribute) to https://github.com/cathay4t/nispor/ . best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Consent, maybe?
On Fri, 2021-03-19 at 06:52 -0400, Adam Sherlock via networkmanager- list wrote: > Hello I'm new to programming and in the process of learning Rust. I > was looking into possibly using your code as a sort of template for > writing a similar network manager in Rust. I'm not sure if this would > fall under LPGL or not so I figured I'd ask first if it does and if > so could I get consent please? > > Thank you, > > Adam Sherlock (piliener) Hi, Copyright on NetworkManager is held by many people, there is no individual who can give consent. As far as I know, all NetworkManager code is either licensed GPL-2.0- or-later or LGPL-2.1-or-later. If you use the code under terms of GPL- 2.0-or-later, then there is no problem. If you want to use the code under terms of LGPL-2.1-or-later, then you have to take care which code you are looking at. Each file has a SPDX-License-Identifier that is probably/presumably correct -- albeit it's often more strict than necessary: meaning, many files claim to be GPL-2.0-or-later when actually most/all of the code in that file would actually be LGPL-2.1- or-later. You'd only know that be investigating. Having said that, I don't know how much code you can reuse of NetworkManager in a Rust implementation. Probably many things work sufficiently different for that not to be a problem. But I don't know. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: "A 'wireless' setting is required if no AP path was given."
On Mon, 2021-03-01 at 10:54 -0500, Steve Newcomb wrote: > I have 2 hosts that experience interruptions in their > NetworkManager-managed wifi connections. > > In an attempt to force the hosts to restore their wifi connections > more promptly than they otherwise would, I have them running a cron > job called "keepWirelessAlive.py" every 3 minutes. If wifi is > running, the job does nothing. If not, it attempts to restore the > connection using nmcli: > > nmcli device connect wlp3s0 `man nmcli` says about `nmcli device connect`: Connect the device. NetworkManager will try to find a suitable connection that will be activated. It will also consider connections that are not set to auto connect. If no compatible connection exists, a new profile with default settings will be created and activated. This differentiates nmcli connection up ifname "$DEVICE" from nmcli device connect "$DEVICE" The case where nmcli finds a suitable existing profile and connects it is clear. But if the SSID for that profile is not in range, no suitable profile is found and NetworkManager is told to create a new profile. `nmcli device connect` does that by providing an incomplete profile, that NetworkManager completes. However, `nmcli device connect` does not work in that case, because you would at least need to specify the SSID. Thus, creating a profile with `nmcli device connect` does not work. Instead, it would work with `nmcli device connect wifi ssid ...`. It sounds like you don't want to use `nmcli device connect`. Use `nmcli connection up "$PROFILE"` or even `nmcli connection profile "$PROFIILE" ifname "$IFACE"`. If you really don't want to select the profile yourself, and let NetworkManager choose one, maybe you need to first ensure that the Wi- Fi scan list is up to date. That is, issue a `nmcli device wifi rescan` before `nmcli device connect`. But anyway, sometimes connecting to a Wi-Fi may fail. For example, when the SSID cannot be found. It may simply happen sometimes. Ignore the error and retry after a while. If you want to understand why any of that happens, enable level=TRACE log ([1]) in NetworkManager and debug logging for supplicant. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 Also, I would try to solve those interruptions, instead of adding a cron job like this... again, the (trace/debug) logfile is the way to go. best, Thomas > > (see below). The command works fine in tests, but when such an attempt > is made automatically by the cron job, it fails, and NetworkManager's > log > messages explain that I've failed to specify a 'wireless' setting (see > below). Alas, I can't find a 'wireless' setting anywhere in > NetworkManager's documentation, so I suspect the log message could be > clearer. > > Everything is OK: > > Mar 1 00:18:01 carp CRON[2615]: (root) CMD > (/usr/local/ch-tools3/keepWirelessAlive.py) > Mar 1 00:21:01 carp CRON[2740]: (root) CMD > (/usr/local/ch-tools3/keepWirelessAlive.py) > > But then the connection is lost: > > Mar 1 00:23:36 carp NetworkManager[657]: [1614576216.8719] > sup-iface[0x557adf36a8d0,wlp3s0]: connection disconnected (reason -4) > Mar 1 00:23:36 carp NetworkManager[657]: [1614576216.8993] > device (wlp3s0): supplicant interface state: completed -> disconnected > Mar 1 00:23:36 carp NetworkManager[657]: [1614576216.9775] > device (wlp3s0): supplicant interface state: disconnected -> scanning > Mar 1 00:23:40 carp NetworkManager[657]: [1614576220.2651] > device (wlp3s0): supplicant interface state: scanning -> authenticating > Mar 1 00:23:40 carp NetworkManager[657]: [1614576220.3809] > device (wlp3s0): supplicant interface state: authenticating -> > disconnected > Mar 1 00:23:40 carp NetworkManager[657]: [1614576220.8807] > device (wlp3s0): supplicant interface state: disconnected -> scanning > Mar 1 00:23:52 carp NetworkManager[657]: [1614576232.5545] > device (wlp3s0): link timed out. > Mar 1 00:23:52 carp NetworkManager[657]: [1614576232.5567] > device (wlp3s0): state change: activated -> failed (reason > 'ssid-not-found', sys-iface-state: 'managed') > Mar 1 00:23:52 carp NetworkManager[657]: [1614576232.5667] > manager: NetworkManager state is now DISCONNECTED > Mar 1 00:23:53 carp NetworkManager[657]: [1614576233.5961] > device (wlp3s0): Activation: failed for connection 'X' > Mar 1 00:23:53 carp NetworkManager[657]: [1614576233.5997] > device (wlp3s0): state change: failed -> disconnected (reason 'none', > sys-iface-state: 'managed') > Mar 1 00:23:53 carp dbus-daemon[655]: [system] Activating via systemd: > service name='org.freedesktop.nm_dispatcher' > unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.13' > (uid=0 pid=657 comm="/usr/sbin/NetworkManager --no-daemon ") > Mar 1 00:23:53 carp NetworkManager[657]: [1614576233.6407] > dhcp4 > (wlp3s0):
Re: "unreachable" routes
On Thu, 2021-02-18 at 12:28 +0100, Robert Vogelgesang wrote:
> Hello @all,
>
> currently I'm trying to update an old server running CentOS 6, which
> doesn't use NetworkManager, to a system with Networkmanager 1.26.0.
> I'm strugging to find the correct syntax to define "unreachable"
> routes.
>
> In CentOS 6 this could be done by creating a file, e. g.
> /etc/sysconfig/network-scripts/route-eth0, with the content:
>
> unreachable 192.0.2.0/24 metric 3
>
> If I read
>
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-26/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c
> correctly, NM 1.26.0 should still support this syntax, but when I try
> it, reading the interface configration fails, without any error
> message.
>
> The nmcli man page doesn't mention "unreachable" or "blackhole"
> routes.
> nmcli does not accept this syntax when I try to set the ipv4.routes
> property of a connection.
>
> Any hints?
Hi,
Currenlty, NetworkManager only supports "type=unicast" and "type=local"
routes. It would be nice to add support for other route types.
Anyway, as it is, the options are:
(1) not use NetworkManager but a script/tool of your choice that works
for you (like "network-script" from "initscripts" package).
(2) use a dispatcher script, that would call `ip route add`. See `man
NetworkManager`.
(3) use "NetworkManager-dispatcher-routing-rules". That is basically a
dispatcher script ([1]) which does what "network-scripts" do. You would
configure the routes and rules in /etc/sysconfig/network-
scripts/{rule,route}. I don't think this is the best solution. If you
go with the dispatcher script way, then (2) is simple enough without
requiring you to configure routes in ifcfg format.
I would get inspired by (3) (see the script at [1]) and write a simple
dispatcher script that works for you (2).
[1]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/e3a7f29e2af2acd6b03b313115396bb6872e3cd0/examples/dispatcher/10-ifcfg-rh-routes.sh
Can you elaborate why you use "unreachable" routes? It's the first time
I encounter somebody actually using this. Seems you hav specific
requirements, and while NetworkManager should support them, I think it
may be warranted that for now you roll your own special solution (that
is, a script).
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Device unavailable
On Mon, 2021-02-22 at 10:54 +0100, Guillaume Betous wrote: > Hi list ! > > We are producing iMX6 based products. We flash the exact same image to > all of them. The image contains Wi-Fi setting for a first connexion. > Sometimes (say one > of ten), the device is not connecting. > > On those devices, we see that the wlan0 is "unavailable". > > $ nmcli dev > wlan0 wifi unavailable -- > lo loopback unmanaged -- > > $ nmcli device show wlan0 > GENERAL.PÉRIPHÉRIQUE: wlan0 > GENERAL.TYPE: wifi > GENERAL.ADR.-MAT.: 9A:DD:10:B2:43:FD > GENERAL.MTU: 1500 > GENERAL.ÉTAT: 20 (indisponible) > GENERAL.CONNEXION: -- > GENERAL.CON-PATH: -- > > Restarting NetworkManager is enough for recovering a functional Wi-Fi, > meaning that everything around seems ok (wlan kernel module correctly > probed, > configuration files are ok...) > > 1°) Any idea on what could happen here ? > 2°) Is restarting NetworkManager the only way to modify the interface > status ? I am planning to write a small script at boot-up which would > detect this > situation and then run the appropriate command > > Thank you very much, Hi, when a Wi-Fi device is unavailable, it's usually because wpa_supplicant is not running (or NM wronlgy thinks it isn't). The way to answer such questions is by looking at the debug logs. Enable level=TRACE logging. See [1] for hints about logging. No, restarting NetworkManager is not at all the way to change an interface status. There are few reasons why NetworkManager should be restarted, and if you do that, there is probably something wrong. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.30.0 released
Hi everybody, On behalf of the NetworkManager community, I am happy to announce a new release of NetworkManager: 1.30.0. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/fc29a96097e0f11ab963c27036b6b8b3e1f3d42b Find the tarball at our usual location: https://download.gnome.org/sources/NetworkManager/1.30/ https://download.gnome.org/sources/NetworkManager/1.30/NetworkManager-1.30.0.tar.xz md5:dce168235c2b86ebc598d0e13e078ee3 sha1: 550918f97f1614532a317465220d6b5cab08d47a sha256: 39f01232628bc2ecbca1a931b8f45fdd8f0b7150be65332901c97ecdee98c3f9 sha512: e4ed1866af5fd06d4bc6cec65b0fc87b3301ff4cc7d791ac71a3b98036f811d961bb3743a7fd497ef7cbc3f6b3f6ffa1d91751afcd4e5f943179946dc8b8fc24 To see what's new check the NEWS file: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/fc29a96097e0f11ab963c27036b6b8b3e1f3d42b/NEWS And Beniamino wrote about some highlights here: https://networkmanager.dev/blog/networkmanager-1-30/ Thanks to everybody who contributed to this release with patches and translations: Adarsh J, Aleksander Morgado, Alfonso Sánchez-Beato, Andrew Zaborowski, Antonio Cardace, Beniamino Galvani, Benjamin Berg, David Rheinsberg, Fernando Fernandez Mancera, Fernando Fernández Mancera, Frederic Martinsons, Jonas Jelten, Jonathan Lebon, Juliano de Souza Camargo, Leo, Matt Bernstein, Michael Biebl, Mikhail Novosyolov, Peter Hutterer, Rasmus Thomsen, Roy Marples, Thomas Haller, Tom Stellard, Yuri Chornoivan, orbea, scootergrisen. And special thanks to Vladimír Beneš, Filip Pokryvka, and Vitezslav Humpa for testing NetworkManager. Enjoy, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
