It happens on my laptop, which I have connected via thunderbolt USB-C cable to a docking stations. Sometimes when I reconnect it back, it does not refresh the configuration correctly. It starts spamming NetworkManager but fails to recover even after long time automatically. Reproducible: Sometimes Steps to Reproduce: 1. configure dns=dnsmasq in Network Manager and restart NetworkManager 2. connect to docking station, which creates ethernet interface 3. disconnect the laptop 4. connect back to it again 5. interface is of the same name, but it has different ifindex Actual Results: # journalctl -xeu NetworkManager říj 31 16:12:36 pemensik-t490 dnsmasq[1597235]: failed to bind server socket to enp9s0u1: Požadovanou adresu nelze přiřadit říj 31 16:12:36 pemensik-t490 dnsmasq[1597235]: failed to bind server socket to enp9s0u1: Požadovanou adresu nelze přiřadit říj 31 16:12:36 pemensik-t490 dnsmasq[1597235]: failed to bind server socket to enp9s0u1: Požadovanou adresu nelze přiřadit failed to bind server socket $ journalctl -xeu NetworkManager | grep 'failed to bind server socket' | wc -l 998 any resolution fails with REFUSED and printing this line. Expected Results: dnsmasq notices there is some problem and reiterate interfaces after each failure to bind a local socket. It is quite likely it cannot work without it. By a coincidence, I have found a single dig -4 @localhost +tcp fedoraproject.org unfreezed the dnsmasq. TCP query does interface enumeration always and fixes such stuck dnsmasq without restart or cache flush.
Created attachment 1996399 [details] candidate patch enumerating interface on local bind failure
Posted for upstream review: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q4/017309.html
Created attachment 1996405 [details] dnsmasq.gdbinit helper scripts for gdb I use this to print list_servers using gdb. There is no simple way to print nice addresses inside, but we need just interface indexes anyway. For some reason, sometime they are used and sometime they are not.
I am not sure why, but after systemctl restart NetworkManager, dnsmasq entries set over DBus have ifindex set to 0. 0120 (len=0) iface:enp9s0u1(#0) But for failing dnsmasq it is set already to old interface index. I am not yet sure how it happens and based on what it changes to non-zero indexes. I suspect that happens somehow during packages upgrading. My laptop has uptime 22 days. In so far undiscovered events it has changed to: 0120 (len=0) iface:enp9s0u1(#15), where it started failing.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Still happens on f39. Exact reproduction steps still now known.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26. Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.