Re: NetworkManager GNOME mailing list migrated to new "networkmana...@list.freedesktop.org"
Signed up to the new list :) On 11/2/22, Thomas Haller via networkmanager-list wrote: > 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 > ___ 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
As soon as the list has been archived (today, tomorrow) when a new email is sent to the old list it'll bounce back, yes, we can add an alias to the new location although I'm not a particular fan of landing aliases between lists living on different infrastructures as it gives the idea the list has never been retired and it's still alive although that is not true and that can confuse participants in the long run. It's important wiki pages and other references are updated to reflect this particular migration and former members are invited (which you did already) to participate on the new list. On Wed, Nov 2, 2022 at 11:15 AM Thomas Haller wrote: > 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 > > -- Cheers, Andrea Principal Systems Engineer at Red Hat, GNOME Infrastructure Team Coordinator, Former GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership & Elections Committee Chairman Homepage: https://www.dragonsreach.it ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
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
Re: Network Manager enabling 802.11r - fast Transition
On Mon, Oct 24, 2022 at 12:52:48PM +0200, Shawn Adams via networkmanager-list
wrote:
> All,
>
> Perhaps I'm missing something, but do not see a UI option to enable 802.11r.
>
> I can edit the /etc/system/NetworkManager/ and manally set
> the key-mgmt:
>
> [wifi-security]
> key-mgmt=FT-EAP FT-EAP-SHA384
This is not a valid key-mgmt from NM point of view. When you restart
NM (or after, a "nmcli connection reload") you should see something like:
failed to load connection: invalid connection:
802-11-wireless-security.key-mgmt: 'ft-eap ft-eap-sha384' is not a valid value
for the property
in logs and the profile is not loaded. The valid values are those
listed in "man nm-settings".
key-mgmt
Key management used for the connection. One of "none" (WEP or no
password protection), "ieee8021x" (Dynamic WEP), "owe"
(Opportunistic Wireless Encryption), "wpa-psk" (WPA2 + WPA3
personal), "sae" (WPA3 personal only), "wpa-eap" (WPA2 + WPA3
enterprise) or "wpa-eap-suite-b-192" (WPA3 enterprise only).
> Then restart NM and this works (yes provided the driver supports, which it
> does).
>
> FYI - can set OKC via wpa_cli.
>
> However; when NM is restarted, the UI config tool shows the ESSID connection
> profile, but is missing
> the certificate selection, i need to reconfigure via the UI.
>
> am I missing a more elegant method of enabling 802.11r ?
Currently there isn't a way to explicitly enable or disable FT. NM
automatically enables FT when wpa_supplicant reports that the wireless
interface supports it. The detection is based on whether the
"Capabilities" D-Bus field of the wireless interface contains
"KeyMgmt=wpa-ft-psk".
If you increase NM logging level to trace and restart it, you should
see what capabilities are reported ('+' means supported):
[1666943325.0852] sup-iface[ad2675fb588f7c6b,2,wlan0]: interface
supported features: AP? FT+ SAE+ BIP+
And when connecting, you can see which configuration is passed to
wpa_supplicant:
[1666943444.7227] Config: added 'ssid' value 'test'
[1666943444.7227] Config: added 'key_mgmt' value 'WPA-EAP FT-EAP
FT-EAP-SHA384 WPA-EAP-SHA256'
[1666943444.7227] Config: added 'password' value ''
[1666943444.7227] Config: added 'eap' value 'PEAP'
...
Beniamino
signature.asc
Description: PGP signature
___
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
Paul, that's surely something we could have done better there including sending the per-list announcements earlier, in either case if a specific list requires 2-3 more weeks to sort things out, that's fine, we're currently waiting for a set of code changes in damned-lies and are accepting any exceptions in case the migration to Discourse or to a different hosting is still in the works. Thanks, On Thu, Oct 27, 2022 at 4:47 PM Paul Smith wrote: > 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. > > As has been stated before, I don't understand how anyone considered it > sufficient to announce this ONLY on the desktop-devel list. > > There are thousands of people subscribed to individual lists for > individual applications that have no interest in subscribing to a > general list like "desktop-devel", but whose existing lists are still > being shut down. > > It's clear, since an announcement was made last week that did it, that > sending an email to all the lists was possible. I don't understand why > it wasn't done back when the decision was made. > > -- Cheers, Andrea Principal Systems Engineer at Red Hat, GNOME Infrastructure Team Coordinator, Former GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership & Elections Committee Chairman Homepage: https://www.dragonsreach.it ___ 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. As has been stated before, I don't understand how anyone considered it sufficient to announce this ONLY on the desktop-devel list. There are thousands of people subscribed to individual lists for individual applications that have no interest in subscribing to a general list like "desktop-devel", but whose existing lists are still being shut down. It's clear, since an announcement was made last week that did it, that sending an email to all the lists was possible. I don't understand why it wasn't done back when the decision was made. ___ 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, 26 Oct 2022 23:16:44 +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? > You mean other than it being a forum where we have to go to it rather than a mailing list where it comes to us? I don't see how to bridge this chasm. -- Brian Morrison ___ 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, Oct 27, 2022 at 8:56 AM Thomas Haller wrote: > 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. > 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. > > > > > 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? > 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. [1] https://discourse.gnome.org/t/common-questions-re-mailman-to-discourse/11841/9 [2] https://mail.gnome.org/archives/desktop-devel-list/2022-August/msg4.html [3] https://mail.gnome.org/archives/desktop-devel-list/2022-September/msg00018.html -- Cheers, Andrea Principal Systems Engineer at Red Hat, GNOME Infrastructure Team Coordinator, Former GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership & Elections Committee Chairman Homepage: https://www.dragonsreach.it ___ 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
Hey! Great too know, can you subscribe me to the new list, when its created and moved? On Thu, Oct 27, 2022 at 8:56 AM Thomas Haller via networkmanager-list wrote: > > 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 ___ 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
On 26/10/2022 22.45, Greg Oliver via networkmanager-list wrote: On Wed, Oct 26, 2022 at 2:29 PM Thomas Haller via networkmanager-list 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. 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 Yes - just FYI - I am on another Gnome hosted list "Evolution" that is trying to figure it out as well. Like I said on that list, I may not contribute much, but I am an avid reader and help when I can.. I forced to a forum, I will be gone :) Please re-host! I second that! ___ 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, 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? 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. Thanks, -- Cheers, Andrea Principal Systems Engineer at Red Hat, GNOME Infrastructure Team Coordinator, Former GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership & Elections Committee Chairman Homepage: https://www.dragonsreach.it ___ 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, Oct 26, 2022 at 9:10 PM Martin wrote: > Hi Andrea, > > I already have an account at discourse.gnome.org and I'm happy to > receive emails from either Discourse or Mailman. Now I have two > questions. Maybe you could point me to the right answer: > > 1. How do I subscribe "networkmanager"? Is it by "Watched" or by >"Tracked" tags under notifications? > > 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 :) > 2. How do I open a new topic from my MUA? Esp. what is the correct >syntax to set e.g. tag "networkmanager"? > The approach with Discourse is different: you can only create topics against a particular category using your MUA, what happens after your post is created is Discourse applies the tag automatically based on a specific keyword that is present on either the subject or the body of your email. We encourage any interested party to let us know what mapping they need so we can land the automated tagging rule in place. Thanks! -- Cheers, Andrea Principal Systems Engineer at Red Hat, GNOME Infrastructure Team Coordinator, Former GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership & Elections Committee Chairman Homepage: https://www.dragonsreach.it ___ 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, Oct 26, 2022 at 2:29 PM Thomas Haller via networkmanager-list 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. > > 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 Yes - just FYI - I am on another Gnome hosted list "Evolution" that is trying to figure it out as well. Like I said on that list, I may not contribute much, but I am an avid reader and help when I can.. I forced to a forum, I will be gone :) Please re-host! ___ 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: Announcement: this mailing list will be retired by the end of Oct 2022
Hi Andrea, I already have an account at discourse.gnome.org and I'm happy to receive emails from either Discourse or Mailman. Now I have two questions. Maybe you could point me to the right answer: 1. How do I subscribe "networkmanager"? Is it by "Watched" or by "Tracked" tags under notifications? 2. How do I open a new topic from my MUA? Esp. what is the correct syntax to set e.g. tag "networkmanager"? Thanks in advance! Cheers, Martin ___ 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, 26 Oct 2022 14:00:14 +0200 Andrea Veri wrote: > Hi, > > I’ve received several questions during the past days which possibly > makes sense to summarize in a single topic [1] which I can then > reference. Hopefully this specific post will help anyone looking for > the same set of answers as well. If any additional common question > arises I’ll make sure to add it to this same topic in Discourse. > > Thanks and please let us know if you have any questions around > Discourse or your onboarding process! > > [1] > https://discourse.gnome.org/t/common-questions-re-mailman-to-discourse/11841 From there: "It definitely is, if anyone wants to use their mail client to interact with Discourse, they can. That’s exactly one of the features we looked into when we originally deployed Discourse back then. The workflow mainly is: You watch a category or a tag or both You receive mail sent to the registered mail address for your account, hit the reply button in your mail client and respond as you’d do with Mailman, the reply is then stored in Discourse, simple as that" So, I have to register for yet another system and faff about with its interface just to get all the email to the NetworkManager group sent to me? And this is somehow reliant on other people using the correct tags/categories? Consider me utterly underwhelmed. -- Brian Morrison ___ 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’ve received several questions during the past days which possibly makes sense to summarize in a single topic [1] which I can then reference. Hopefully this specific post will help anyone looking for the same set of answers as well. If any additional common question arises I’ll make sure to add it to this same topic in Discourse. Thanks and please let us know if you have any questions around Discourse or your onboarding process! [1] https://discourse.gnome.org/t/common-questions-re-mailman-to-discourse/11841 On Thu, Oct 20, 2022 at 1:09 PM Andrea Veri wrote: > Hi, > > As we have been communicating during the past few months GNOME's Mailman > platform is being decommissioned (python2 deprecation, major burden in > managing lists spam). The deadline is currently set to the end of October > 2022. Mailing list subscribers are invited to migrate to GNOME's Discourse > instance [1]. Neil made sure [2] to create a set of tags you can re-use to > initiate a new topic in the new platform, if a tag is missing please reach > out to me directly. > > Jehan (from the GIMP Team) kindly provided some instructions you can > follow [3] in order to safely migrate your reading workflow to Discourse. > The new platform supports several login methods including your GNOME > Account and other major OpenID providers. > > After the deadline of the end of October Mailman archives will remain > alive in read only mode for posterity. If the mailing list was used behind > an alias, please let me know so we can re-do the same setup but on > Discourse instead. > > Thanks, > > P.S All the l10n lists are still pending code changes in damned-lies, the > deadline to decommission those lists may slip by a week or two depending > how soon those changes will be made available in DL codebase > > [1] https://discourse.gnome.org > [2] > https://mail.gnome.org/archives/desktop-devel-list/2022-September/msg00018.html > [3] > https://discourse.gnome.org/t/welcome-to-gimp-forum-on-gnome-discourse/11534/5 > > -- > Cheers, > Andrea > > Principal Systems Engineer at Red Hat, > GNOME Infrastructure Team Coordinator, > Former GNOME Foundation Board of Directors Secretary, > GNOME Foundation Membership & Elections Committee Chairman > > Homepage: https://www.dragonsreach.it > -- Cheers, Andrea Principal Systems Engineer at Red Hat, GNOME Infrastructure Team Coordinator, Former GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership & Elections Committee Chairman Homepage: https://www.dragonsreach.it ___ 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 co
Re: Preventing network scans once connected via libnm
On Mon, Oct 03, 2022 at 09:04:47PM +, Charles Lohr wrote:
> Thank you for the prompt and clear reply.
>
> Will BSSID locking interfere with explicit (controller-based) handoff for
> mesh networks? (Not regular roaming where the station would be responsible
> for selecting a new ap)
BSSID locking is relevant only when the interface is connected to a
network through NetworkManager. If the connection profile sets AP or
ad-hoc mode, BSSID locking is not necessary because background
scanning is already disabled. For other modes (infrastructure and
mesh), it's necessary to set the BSSID to avoid scanning:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.40.0/src/core/supplicant/nm-supplicant-config.c#L585-614
When the interface is not connected to a network via NM, the only way to
disable periodic scanning is to set the interface as unmanaged by
NetworkManager. See also:
https://mail.gnome.org/archives/networkmanager-list/2022-June/msg5.html
https://mail.gnome.org/archives/networkmanager-list/2022-July/msg1.html
> The lockout during our application running won't work for us because there
> are some processes running as root. But this isn't crucial.
Polkit rules are quite flexible and probably there is a way to achieve what you
want.
https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
Beniamino
> -Original Message-
> From: Beniamino Galvani
> Sent: Monday, October 3, 2022 1:13 AM
> To: Charles Lohr
> Cc: 'networkmanager-list@gnome.org'
> Subject: Re: Preventing network scans once connected via libnm
>
> On Sat, Oct 01, 2022 at 12:46:24AM +, Charles Lohr via
> networkmanager-list wrote:
> > In our application, we need to maintain connection to an AP and it needs to
> > stay low latency for a variety of reasons. Whenever networks are scanned,
> > for us they create an unacceptable level of latency (>50ms in many cases)
> > on the connection.
> >
> > Sometimes we stop NetworkManager from running with `pkill -STOP
> > NetworkManager` and `pkill -CONT NetworkManager` but, for a variety of
> > reasons this is disadvantageous.
> >
> > I've seen references to people online saying you can prevent scanning once
> > connected by specifying a BSSID, but I don't see how that can be done with
> > libnm.
> >
> > Currently we use the following, where path can be gotten from either a
> > scan or `nm_connection_get_path`
> >
> > ```
> > nm_client_activate_connection_async ( m_pClient, conn,
> > (NMDevice*)m_pDevice, sAccessPointPath.c_str(), nullptr, []( GObject*
> > pObj, GAsyncResult* res, gpointer pContext ) {...} ); ```
> >
> > What mechanism can we use to specify that a given path should lock it's
> > BSSID when using NetworkManager via libnm?
>
> Hi,
>
> to disable scanning, you can set the property NM_SETTING_WIRELESS_BSSID of
> the setting NMSettingWireless to the AP's BSSID when the connection profile
> is created. To get the AP's BSSID use nm_access_point_get_bssid().
>
> References:
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.40.0/examples/C/glib/add-connection-libnm.c#L44
> https://networkmanager.dev/docs/api/latest/nm-settings-dbus.html#id-1.2.9.4.48
> ("bssid property")
> https://networkmanager.dev/docs/libnm/latest/NMAccessPoint.html#nm-access-point-get-bssid
> https://fedoramagazine.org/using-python-and-networkmanager-to-control-the-network/
>
> > Second question: Are there any mechanisms we can use to lock out other
> > apps from requesting scans from NetworkManager? This solution would be
> > preferred for our application because scans have such a significant impact
> > on the system. Or is there a way to just outright disable all scanning via
> > NetworkManger for a period of time?
>
> If the feature is enabled at build time, NM can use polkit to authorize D-Bus
> requests. In particular, there is a "Wi-Fi scan"
> permission that grants access to scans. I think you can use polkit rules to
> restrict the access to a certain user or process; however, note that any
> process running as root bypasses polkit checks and is always authorized.
>
> References:
> https://networkmanager.dev/docs/libnm/latest/libnm-nm-dbus-interface.html#NMClientPermission
> https://networkmanager.dev/docs/api/latest/nmcli.html (nmcli general
> permissions)
>
> Beniamino
>
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Preventing network scans once connected via libnm
Thank you for the prompt and clear reply.
Will BSSID locking interfere with explicit (controller-based) handoff for mesh
networks? (Not regular roaming where the station would be responsible for
selecting a new ap)
The lockout during our application running won't work for us because there are
some processes running as root. But this isn't crucial.
Charles
-Original Message-
From: Beniamino Galvani
Sent: Monday, October 3, 2022 1:13 AM
To: Charles Lohr
Cc: 'networkmanager-list@gnome.org'
Subject: Re: Preventing network scans once connected via libnm
On Sat, Oct 01, 2022 at 12:46:24AM +, Charles Lohr via networkmanager-list
wrote:
> In our application, we need to maintain connection to an AP and it needs to
> stay low latency for a variety of reasons. Whenever networks are scanned,
> for us they create an unacceptable level of latency (>50ms in many cases) on
> the connection.
>
> Sometimes we stop NetworkManager from running with `pkill -STOP
> NetworkManager` and `pkill -CONT NetworkManager` but, for a variety of
> reasons this is disadvantageous.
>
> I've seen references to people online saying you can prevent scanning once
> connected by specifying a BSSID, but I don't see how that can be done with
> libnm.
>
> Currently we use the following, where path can be gotten from either a
> scan or `nm_connection_get_path`
>
> ```
> nm_client_activate_connection_async ( m_pClient, conn,
> (NMDevice*)m_pDevice, sAccessPointPath.c_str(), nullptr, []( GObject*
> pObj, GAsyncResult* res, gpointer pContext ) {...} ); ```
>
> What mechanism can we use to specify that a given path should lock it's BSSID
> when using NetworkManager via libnm?
Hi,
to disable scanning, you can set the property NM_SETTING_WIRELESS_BSSID of the
setting NMSettingWireless to the AP's BSSID when the connection profile is
created. To get the AP's BSSID use nm_access_point_get_bssid().
References:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.40.0/examples/C/glib/add-connection-libnm.c#L44
https://networkmanager.dev/docs/api/latest/nm-settings-dbus.html#id-1.2.9.4.48
("bssid property")
https://networkmanager.dev/docs/libnm/latest/NMAccessPoint.html#nm-access-point-get-bssid
https://fedoramagazine.org/using-python-and-networkmanager-to-control-the-network/
> Second question: Are there any mechanisms we can use to lock out other apps
> from requesting scans from NetworkManager? This solution would be preferred
> for our application because scans have such a significant impact on the
> system. Or is there a way to just outright disable all scanning via
> NetworkManger for a period of time?
If the feature is enabled at build time, NM can use polkit to authorize D-Bus
requests. In particular, there is a "Wi-Fi scan"
permission that grants access to scans. I think you can use polkit rules to
restrict the access to a certain user or process; however, note that any
process running as root bypasses polkit checks and is always authorized.
References:
https://networkmanager.dev/docs/libnm/latest/libnm-nm-dbus-interface.html#NMClientPermission
https://networkmanager.dev/docs/api/latest/nmcli.html (nmcli general
permissions)
Beniamino
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Preventing network scans once connected via libnm
On Sat, Oct 01, 2022 at 12:46:24AM +, Charles Lohr via networkmanager-list
wrote:
> In our application, we need to maintain connection to an AP and it needs to
> stay low latency for a variety of reasons. Whenever networks are scanned,
> for us they create an unacceptable level of latency (>50ms in many cases) on
> the connection.
>
> Sometimes we stop NetworkManager from running with `pkill -STOP
> NetworkManager` and `pkill -CONT NetworkManager` but, for a variety of
> reasons this is disadvantageous.
>
> I've seen references to people online saying you can prevent scanning once
> connected by specifying a BSSID, but I don't see how that can be done with
> libnm.
>
> Currently we use the following, where path can be gotten from either a scan
> or `nm_connection_get_path`
>
> ```
> nm_client_activate_connection_async ( m_pClient, conn, (NMDevice*)m_pDevice,
> sAccessPointPath.c_str(), nullptr, []( GObject* pObj, GAsyncResult* res,
> gpointer pContext ) {...} );
> ```
>
> What mechanism can we use to specify that a given path should lock it's BSSID
> when using NetworkManager via libnm?
Hi,
to disable scanning, you can set the property
NM_SETTING_WIRELESS_BSSID of the setting NMSettingWireless to the AP's
BSSID when the connection profile is created. To get the AP's BSSID
use nm_access_point_get_bssid().
References:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.40.0/examples/C/glib/add-connection-libnm.c#L44
https://networkmanager.dev/docs/api/latest/nm-settings-dbus.html#id-1.2.9.4.48
("bssid property")
https://networkmanager.dev/docs/libnm/latest/NMAccessPoint.html#nm-access-point-get-bssid
https://fedoramagazine.org/using-python-and-networkmanager-to-control-the-network/
> Second question: Are there any mechanisms we can use to lock out other apps
> from requesting scans from NetworkManager? This solution would be preferred
> for our application because scans have such a significant impact on the
> system. Or is there a way to just outright disable all scanning via
> NetworkManger for a period of time?
If the feature is enabled at build time, NM can use polkit to
authorize D-Bus requests. In particular, there is a "Wi-Fi scan"
permission that grants access to scans. I think you can use polkit
rules to restrict the access to a certain user or process; however,
note that any process running as root bypasses polkit checks and is
always authorized.
References:
https://networkmanager.dev/docs/libnm/latest/libnm-nm-dbus-interface.html#NMClientPermission
https://networkmanager.dev/docs/api/latest/nmcli.html (nmcli general
permissions)
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [meetup] Next Monthly NetworkManager Online Meetup (2022.09.14)
Won't attend sadly busy with a private thing, but will try to attend again in October On Tue, Sep 13, 2022 at 7:08 PM Thomas Haller via networkmanager-list < networkmanager-list@gnome.org> wrote: > 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 > ___ 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 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. If you say that editing it is OK it is fine for me. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [meetup] Next Monthly NetworkManager Online Meetup (2022.08.10)
/me will attend the social today On Tue, Aug 9, 2022 at 8:01 PM Thomas Haller via networkmanager-list < networkmanager-list@gnome.org> wrote: > 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 > ___ 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
Re: Does NetworkManager support WiFi 6 IEEE 802.11ax USB wireless adapters?
On Tue, Jul 26, 2022 at 8:37 PM Turritopsis Dohrnii Teo En Ming via networkmanager-list wrote: > I think WiFi 6 is still using 5 GHz frequency band if I am not wrong. > Yes - I have an intel WiFi 6 adapter and it works just fine with NetworkManager. > Mr. Turritopsis Dohrnii Teo En Ming > Targeted Individual in Singapore > > On Tue, 26 Jul 2022 at 02:07, Thomas Haller wrote: > > > > 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 > ___ 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?
I think WiFi 6 is still using 5 GHz frequency band if I am not wrong. Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore On Tue, 26 Jul 2022 at 02:07, Thomas Haller wrote: > > 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: 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
Once upon a time, Thomas Haller said: > 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. Ahh, that's also good to know - I wasn't aware of how to use NM for temporary configs (I'd just used "ip" directly and hoped that I wouldn't conflict with NM). Thanks. -- Chris Adams ___ 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
Re: Changing IP on bridge without disconnecting VMs
Once upon a time, Dan Williams said: > 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 Ahh, "dev reapply" was the magic thing I didn't know. :) I've always done "con up" after making a change, but that does reset more things. "dev reapply" does not delete all the non-NM bridge members, which is correct for me. Thanks! -- Chris Adams ___ 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 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 Dan ___ 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: Autoconnect backoff
On Wed, Jul 6, 2022 at 10:03 AM Sven Schwermer via networkmanager-list < networkmanager-list@gnome.org> 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 > Sounds like a device that is going to be remotely controlled over LTE / GSM / CDMA.. If it is unreachable, what does it matter until it comes back up? You will not get to it anyhow :) ___ 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
Re: Disabling periodic scans
On Fri, Jul 01, 2022 at 02:12:45AM +0300, Slava Monich wrote: > Actually, this wasn't about connected interfaces. When the interface is > connected, AP roaming has to be supported, locking connection to BSSID of > the AP is not an option, there's no way to avoid active scans. > That's fine. > > 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. > > It seems to make every bit of sense to disable scans on all but one > disconnected Wi-Fi interface, and let the UI use the list of available APs > produced by that one single interface. And since no connection is involved > at this stage, it can't be a connection property, right? It's got to be an > org.freedesktop.NetworkManager.Device.Wireless property. Correct. > And yes, it means that this property is not going to be persistent but it > doesn't need to be, since it has to be updated every time when the system > state changes (e.g. an interface appears or disappears, gets connected or > disconnected). Which is fine since this scenario implies a separate service > choosing which interface will do the scanning, that logic is product > specific and out of scope. > > Am I missing something? I don't know others' opinion, but this seems a legitimate use case to me, and I'm in favor of adding such D-bus property to the Device.Wireless interface. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling periodic scans
On 20/06/2022 18.08, Beniamino Galvani wrote: On Sun, Jun 19, 2022 at 09:01:12PM +0300, Slava Monich wrote: Hi! Are there any objections to adding e.g. BackgroundScanEnabled readwrite property to org.freedesktop.NetworkManager.Device.Wireless D-Bus interface? The idea is to allow to disable periodic background scans for those WiFi interfaces which don't need it. There are use cases for that in the embedded world. Hi, if the Wi-Fi connection profile is locked to a specific BSSID, that disables periodic scanning while connected. Is this a suitable solution for your use case? Or, what is the use case? If we want to make this behavior configurable, perhaps it should be in the connection profile and not on the device D-Bus object, so that the property can be changed persistently and it depends on the network. See also: https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/ Beniamino Thanks for the reply! Actually, this wasn't about connected interfaces. When the interface is connected, AP roaming has to be supported, locking connection to BSSID of the AP is not an option, there's no way to avoid active scans. That's fine. 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. It seems to make every bit of sense to disable scans on all but one disconnected Wi-Fi interface, and let the UI use the list of available APs produced by that one single interface. And since no connection is involved at this stage, it can't be a connection property, right? It's got to be an org.freedesktop.NetworkManager.Device.Wireless property. And yes, it means that this property is not going to be persistent but it doesn't need to be, since it has to be updated every time when the system state changes (e.g. an interface appears or disappears, gets connected or disconnected). Which is fine since this scenario implies a separate service choosing which interface will do the scanning, that logic is product specific and out of scope. Am I missing something? Cheers, -Slava ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [meetup] Announcing monthly online meetup for NetworkManager
Hey! I like this idea, will try to attend when i can :) On 6/29/22, Aleksander Morgado wrote: > Hey! > >> >> 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. >> > > That's a great idea! > > -- > Aleksander > https://aleksander.es > ___ > 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: [meetup] Announcing monthly online meetup for NetworkManager
Hey! > > 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. > That's a great idea! -- Aleksander https://aleksander.es ___ 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 6/27/2022 12:48 AM, Thomas Haller wrote: On Fri, 2022-06-24 at 17:39 -0700, Jim Garrison via networkmanager-list wrote: [snip] 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. I was trying to debug a problem with a DHCP server. Having worked in the past with dhclient, I was expecting to find the lease time stored somewhere, but couldn't find it. Thanks for clarifying the use of nmcli to examine the current lease. -- Jim Garrison j...@acm.org ___ 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: Disabling periodic scans
On Sun, Jun 19, 2022 at 09:01:12PM +0300, Slava Monich wrote: > Hi! > > Are there any objections to adding e.g. BackgroundScanEnabled readwrite > property to org.freedesktop.NetworkManager.Device.Wireless D-Bus interface? > The idea is to allow to disable periodic background scans for those WiFi > interfaces which don't need it. There are use cases for that in the embedded > world. Hi, if the Wi-Fi connection profile is locked to a specific BSSID, that disables periodic scanning while connected. Is this a suitable solution for your use case? Or, what is the use case? If we want to make this behavior configurable, perhaps it should be in the connection profile and not on the device D-Bus object, so that the property can be changed persistently and it depends on the network. See also: https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/ Beniamino signature.asc Description: PGP signature ___ 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
I have took a look inside into nss-mdns. Its implementation just forwards queries name to avahi daemon, but does not send actual packets right from plugin. I guess avahi might receive instructions to disable/enable interfaces via dbus or more advanced method. It already contains ability to exclude or include selected interfaces. But I am not sure if it supports modification of that list runtime. So at least for mdns the proper solution would be in avahi-daemon. On 03. 06. 22 19:11, Thomas Haller wrote: Hi, On Fri, 2022-06-03 at 13:55 +0200, Petr Menšík via networkmanager-list wrote: 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. 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 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: Would Provision Domain Names be hard to implement in NM? (RFC 8801)
On 5/31/22 11:18, Beniamino Galvani wrote:
> On Mon, May 30, 2022 at 01:14:51PM +0200, Petr Menšík via networkmanager-list
> wrote:
>> Hi,
>>
>> RFC 8801 [1] is standard tracks already. Would it be difficult to
>> implement it in NM? I think it provides very nice way to make profiles
>> on ethernet connections for example. Not sure if I can have multiple
>> configurations switched automatically withou Radius used for port security.
> Hi,
>
> I have quickly read RFC 8801 and RFC 7756, and it's not clear to me
> how the PvD model would fit in the NM picture.
My nmcli c on older laptop shows several wifi profiles, but just single
ethernet profile. I would like to have also pvd profile, which could
configure some properties of a connection. Obviously not an address, but
could configure DNS domain list, additional services. A nice start it
would be (dbus?) event emitted from NM that PvD name were received on a
connection.
>> But this RFC allows specification of domains and prefixes used on given
>> connection. That would be useful for VPN connected to work for example,
>> but when I still want to reach some local resources. For example printer
>> or local file storage, when I work from home. Unlike Radius it can work
>> fine at home networks too. But it can use TLS for obtaining basic
>> infromation, so those information can be secure at the same time.
> From what I understood, the RFCs define the concept of PvDs
> (provisioning domains) that contain related network configuration as
> DNS servers, DNS domains, default gateways, etc. A PvD can be explicit
> (provided to the client via e.g. a RA option), or implicit when a
> client automatically creates a different PvD for each interface.
I think implicit matches already different connections in NM. But it
would be nice, if it could at least record received PvD identifiers in
DHCP[46].OPTION entry for a start. Then additional experimental service
could reconfigure extra services based on that.
> What is not clear to me is how to use that information. For PvD-aware
> nodes, the recommendation is to use the received information
> consistently (for example, use the DNS server from one PvD for the
> domains of the same PvDs, etc.). Note that NM already does something
> like that implicitly when using one of dns={dnsmasq,systemd-resolved}:
> it queries a nameserver only on the interface that announced it, and
> it routes queries according to the automatically-received domains.
Yes, but it uses list of domains intented for search option in
resolv.conf for list of domains. Which serves different purpose and does
not have to be complete. Especially when multiple connections specify
search, it is questionable whether you want them all searched and in
which order. RFC 8801 can provide list of domains and ranges related to
connection when only RA is used. Does not require DHCP and can be more
secure. RFC 6731 can provide list of domains, I think Kea server can
send it.
> The RFC also talks about PvD-aware applications that can choose the
> PvD, but I don't think infrastructure for that exists outside NM.
I think PvD matches purpose of NM. I doubt there should be separate
service for handling it.But I admit I would like to have some
customization depending on connected network. For example I would like
to have sshd started on trusted networks. But have complete firewall
protection on less trusted networks.
>> It requires some kind of autoconfiguration of IP addresses. But I would
>> like to have possible LLMNR or mDNS configuration configured just on
>> some kind of networks. Could provision domain allow profiles in NM,
>> which would be autoconfigured via network? It would be great for laptops
>> connected via ethernet.
> I don't know, there seems no mention of LLMNR or mDNS in the RFC. I
> see that it allows the nodes to fetch a JSON that contains more
> information, and that probably can be extended to do everything.
I meant I would be able to configure LLMNR and mDNS on PvD profile for
ethernet. For example on corp.redhat.com connection I would enable mDNS
to be able print on local printer. But on hotel.example.com with
ethernet port I would like to disable similar services. I can do that
already on different connections, but how can be a connection
autoselected in case they don't use 802.1x security? I think this RFC
allows to have different profiles on single device, similar to SSIDs on
wifi networks. Of course the json can specify anything. Another question
is whether you would like to trust all information provided by the
network by default. I think that is important on public transport
connections or conferences, where I would like to have option to accept
just minimal trust in its network and refuse any optional features.
> While I agree that in theory this feature would be nice, I think the
> use cases are not well defined yet and it seems that implementing this
> in NM will require a significant effort.
>
> Does any existing DHCP/RA server implement the needed o
Re: Would Provision Domain Names be hard to implement in NM? (RFC 8801)
On Mon, May 30, 2022 at 01:14:51PM +0200, Petr Menšík via networkmanager-list
wrote:
> Hi,
>
> RFC 8801 [1] is standard tracks already. Would it be difficult to
> implement it in NM? I think it provides very nice way to make profiles
> on ethernet connections for example. Not sure if I can have multiple
> configurations switched automatically withou Radius used for port security.
Hi,
I have quickly read RFC 8801 and RFC 7756, and it's not clear to me
how the PvD model would fit in the NM picture.
> But this RFC allows specification of domains and prefixes used on given
> connection. That would be useful for VPN connected to work for example,
> but when I still want to reach some local resources. For example printer
> or local file storage, when I work from home. Unlike Radius it can work
> fine at home networks too. But it can use TLS for obtaining basic
> infromation, so those information can be secure at the same time.
From what I understood, the RFCs define the concept of PvDs
(provisioning domains) that contain related network configuration as
DNS servers, DNS domains, default gateways, etc. A PvD can be explicit
(provided to the client via e.g. a RA option), or implicit when a
client automatically creates a different PvD for each interface.
What is not clear to me is how to use that information. For PvD-aware
nodes, the recommendation is to use the received information
consistently (for example, use the DNS server from one PvD for the
domains of the same PvDs, etc.). Note that NM already does something
like that implicitly when using one of dns={dnsmasq,systemd-resolved}:
it queries a nameserver only on the interface that announced it, and
it routes queries according to the automatically-received domains.
The RFC also talks about PvD-aware applications that can choose the
PvD, but I don't think infrastructure for that exists outside NM.
> It requires some kind of autoconfiguration of IP addresses. But I would
> like to have possible LLMNR or mDNS configuration configured just on
> some kind of networks. Could provision domain allow profiles in NM,
> which would be autoconfigured via network? It would be great for laptops
> connected via ethernet.
I don't know, there seems no mention of LLMNR or mDNS in the RFC. I
see that it allows the nodes to fetch a JSON that contains more
information, and that probably can be extended to do everything.
While I agree that in theory this feature would be nice, I think the
use cases are not well defined yet and it seems that implementing this
in NM will require a significant effort.
Does any existing DHCP/RA server implement the needed options? Do you
know of any existing real deployment of this feature?
Beniamino
signature.asc
Description: PGP signature
___
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 NetworkMana
Re: dnsmasq integration improvement suggestion
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. > /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. It is possible to make generic query to dbus (or varlink?) which services provide some interface? Then VPN could send required configuration to all interested providers. I am not working with dbus often. What would be the best way for other services to provide unified API? I doubt we want each VPN provider to implement all possible DNS caches. Can generic api be used instead? > best, > Thomas -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
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.
Ok I see and these dbus call can fail silently (no error propagation), the timeout hypothesis seems to match my cases. Changing to dbus-broker is indeed a big step for our system for such a low frequency issue we have. Thanks for all the info Thomas. From: Thomas Haller Sent: Tuesday, May 17, 2022 10:49 AM To: Fr�d�ric Martinsons ; networkmanager-list@gnome.org Subject: Re: Unable to determine UID of the request whan adding a connection. CAUTION: EXTERNAL EMAIL. Do not click links or open unless you recognize the sender and know the content is safe. 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 Your privacy is important to us. Please see our Privacy Notice<https://www.sigfox.com/en/privacy-and-cookies-policy> for further details. The information contained in this Message is confidential. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this Message in error, please delete it and all copies from your system and notify the sender immediately by return message. Any use of information contained in this Message not in accordance with its intended purpose, any dissemination or disclosure (either whole or partial), is prohibited unless expressly authorized. Email communication cannot be guaranteed to be timely secure, error or virus-free. The sender cannot be held responsible for any alteration, errors or omissions, which arise as a result. .. La protection de vos données personnelles est primordiale pour notre établissement. Merci de consulter notre notice sur la protection des données personnelles <https://www.sigfox.com/en/privacy-and-cookies-policy> pour plus d’informations. Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires. Les informations qui y figurent sont confidentielles. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Veuillez également en avertir immédiatement l'expéditeur par retour du Message. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expre
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.
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. > 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. > Are you using `hidepid` mount option for procfs? It should also work > with that, but it could cause problems. Nope, just rw, relatime > 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 ? From: Thomas Haller Sent: Tuesday, May 17, 2022 9:36 AM To: Fr�d�ric Martinsons ; networkmanager-list@gnome.org Subject: Re: Unable to determine UID of the request whan adding a connection. CAUTION: EXTERNAL EMAIL. Do not click links or open unless you recognize the sender and know the content is safe. 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. Your privacy is important to us. Please see our Privacy Notice<https://www.
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
Hi Thomas That is already very helpful for me. I will have a look at it and try to write a patch. Let's see if something comes out that works. Regards, Adrian On Sat, 2022-05-14 at 21:33 +0200, Thomas Haller wrote: > 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
On Sat, 2022-05-14 at 21:54 +0200, Thomas Haller via networkmanager- list wrote: > 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. Yes, we are already doing that. But it's only part of the solution. > > > > > > > > > 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". > > > It solves the problem after a reboot but it does not allow to disable a port via DBUS API. > > > > Sure, but usual question is - what are the expected threats? Simply > > having interface up does not hurt anyone (except may be audit > > company). That's exactly the point here. The use case is very similar to a switch where the user can enable or disable a port. The expectation is that the LEDs go off when the port is disabled and the link establishes as soon as the port gets enabled. The enable part is perfectly handled by NetworkManager. But the disable case is at least not obvious to me. In more detail: The use case is that Linux manages a switch via DSA. Creating a bridge with NetworkManager configures the switch chip to do all the switching in hardware. It's really great. Only the disabling of a port via DBUS API is not really ready for a security audit or a perfect responsive UI. That's why I'm asking if the "ip link down" feature could be somehow provided via DBUS API and nmconnection file by NetworkManager. Adrian > > 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 ___ 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 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. ___ 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: connection to disable an interface
On 14.05.2022 00:23, 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. > It sounds like no-auto-default=* mostly does what you want. > 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 > ___ > 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: New connection appears after unplugging Ethernet
On 2022-04-26 10:27, Thomas Haller wrote: > 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`. This is the case, indeed. I was not aware of that flag, thank you! > That usually means that some other program is configuring the device. > Or it would be a bug... to investigate, check the `level=TRACE` log. I can see, that an NM connection is created as "nm-generated, volatile, external". Now I only have to find out, which program is the culprit. So far, I have no idea. At least, it does not seem to be a NM bug! ___ 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
Re: PSK+SAE when creating an Access Point
On Mon, Apr 04, 2022 at 11:08:26AM +0200, Beniamino Galvani wrote: > On Tue, Mar 22, 2022 at 11:52:00AM +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) > > Hi, I can reproduce the problem with mac80211_hwsim. The root cause is > that NM passes both SAE and FT-SAE as key-mgmt to > wpa_supplicant. wpa_supplicant currently doesn't support FT in AP > mode, but still advertises FT-SAEit to the STA, leading to a key > derivation mismatch. > > This patch works for me: > > http://lists.infradead.org/pipermail/hostap/2022-April/040352.html > > Arguably, we could also fix this in NM by not passing FT-SAE in AP > mode; however I prefer that the fix is done in wpa_supplicant so that > in the future, when FT support is added to AP mode it will work > automatically with NM. I changed my mind. FT requires special configuration in the AP and so it doesn't make sense that NM automatically enables because it would be useless and in some cases (FT-SAE) harmful. In the end, I did this patch to disable FT when NM configures the supplicant in AP mode: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1184 Beniamino signature.asc Description: PGP signature ___ 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, Mar 22, 2022 at 11:52:00AM +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) Hi, I can reproduce the problem with mac80211_hwsim. The root cause is that NM passes both SAE and FT-SAE as key-mgmt to wpa_supplicant. wpa_supplicant currently doesn't support FT in AP mode, but still advertises FT-SAEit to the STA, leading to a key derivation mismatch. This patch works for me: http://lists.infradead.org/pipermail/hostap/2022-April/040352.html Arguably, we could also fix this in NM by not passing FT-SAE in AP mode; however I prefer that the fix is done in wpa_supplicant so that in the future, when FT support is added to AP mode it will work automatically with NM. Beniamino signature.asc Description: PGP signature ___ 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: Is gtk4 support in libnma still EXPERIMENTAL?
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. OpenPGP_signature Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PSK+SAE when creating an Access Point
Am 23.03.22 um 08:57 schrieb Alfonso Sanchez-Beato via networkmanager-list: On Tue, Mar 22, 2022 at 10:56 PM Thomas Haller wrote: sounds related to https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638#note_1306214 ? Looks related, but in my case I was creating the AP with NM instead of connecting to an external AP. It is interesting to see that the problem starts to happen with wpa_supplicant 2.10, the same version as the one I am using. See my findings in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907#70 https://w1.fi/cgit/hostap/commit/?id=7a9c36722511ce4df88b76cceceb241d6c6a151e older wpasupplicant versions did not allow to set the SAE flag via D-Bus (which NetworkManager uses to talk to wpasupplicant). OpenPGP_signature Description: OpenPGP digital signature ___ 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, Mar 22, 2022 at 10:56 PM Thomas Haller wrote: > > 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 > ? Looks related, but in my case I was creating the AP with NM instead of connecting to an external AP. It is interesting to see that the problem starts to happen with wpa_supplicant 2.10, the same version as the one I am using. > > 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?
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. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature ___ 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: Is gtk4 support in libnma still EXPERIMENTAL?
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 OpenPGP_signature Description: OpenPGP digital signature ___ 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()`. > > I looked into this and basically I'd have to reimplement event_handler_read_netlink which reads from priv->nlh where I need to read from genl... The pick of priv->nlh and very deep in the code. I guess I could add DELAYED_ACTION_TYPE_READ_NL80211 just like we have DELAYED_ACTION_TYPE_READ_NETLINK and make that call event_handler_read_nl80211 which would set a parameter in the platform so that event_handler_read_netlink will read from genl instead of priv->nlh? Since everything is single thread, that could work? OTOH, it'd mean that the handling of the nl82011 messages would be in nm-linux-platform which isn't desirable either. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding experimental arguments to nmcli tool
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. Cheers Till -- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role Red Hat GmbH, https://de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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: CSME integration - next steps, network selection
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. 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
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). yes, vendor commands API and those APIs are upstreamed. > > > Which header is this? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/nl80211-vnd-intel.h?h=v5.17-rc6 > > 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. Ok, the header is fairly short, so I guess we can copy and fail on runtime if the kernel doesn't support? > > If this gets fetched via nl80211, then src/libnm-platform/wifi/nm- > wifi-utils-nl80211.c is the right place. > Thanks! I'll try to get some time for this. This is still sort of a side project for me, so, things can take time... ___ 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
Re: System-Wide 802.1x configuration?
Yes, you understand correctly, I (and my team) provision and pre-configure machines for employees. What I mean by “globally system-wide” is I want to configure 802.1x and have it work regardless of which ethernet interface in the machine that’s used. I’d rather not have to have multiple configurations for multiple interfaces. From what I understand from your reply this should be possible. This sounds like exactly what I’d like to do: "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.” Now I just have to figure out how to do it. Thanks Thomas! > On 2 Jan 2022, at 10:02, Thomas Haller wrote: > > 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: 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: relocate dnsmasq --conf-dir location?
Hi, Another option is also possible. You can add conf-dir=/modifiable/dnsmasq.d,*.conf into /etc/NetworkManager/dnsmasq.d/modify.conf That would be fixed part, which would stay read-only. And any configuration generated on-fly would be in modifiable directory. dnsmasq should support multiple directories read for configuration. It allows additional directory instead of moving existing directory. Cheers, Petr On 10/29/21 11:14, Thomas Haller via networkmanager-list wrote: > 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 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
