Description of problem: Installed a new Allegro 4 USB 3.2 Gen 2 Type A PCIe card. On bootup, wifi interface changed from wlp6s0 to wlp10s0. Mostly empty /etc/sysconfig/network-scripts/ifcfg-wlp10s0 was created. Using mcc, was unable to configure it because /etc/sysconfig/network-scripts/ifcfg-wlp6s0 was still present. Had to manually rework these files to get networking up. System knew to add what looked like a new interface; but failed to recognize the current interface was no longer present. Please consider updating config files appropriately when wifi interface changes due to hardware changes (removing a card would likely cause this renaming too). This might not be obvious to novice users. Version-Release number of selected component (if applicable): How reproducible: on adding hardware Steps to Reproduce: 1. 2. 3.
Operating System: Mageia 9 KDE Plasma Version: 5.25.90 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-server-1.mga9 (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 125.5 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT Manufacturer: Dell Inc. Product Name: XPS 8950
Thank you for this report, whose point we take. When you say "network would not come up", that is understandable. Were you able to go through the MCC Network Centre to configure and enable the new interface? I did not see any way to delete a previously configured WiFi connection. And cannot judge what you would see with a new WiFi card. For the moment, CC'ing MageiaTools and kernel/drivers for their view.
CC: (none) => kernel, lewyssmith, mageiatools
Created attachment 13420 [details] journal log before and after hardware installation
Created attachment 13421 [details] lppci -nnvv output after card installed I don't have lspci output from before the USB card was installed; but this output shows the USB card was inserted just before the network interfaces causing the WiFi to be renamed from wlp6s0 to wlp10s0.
(In reply to Lewis Smith from comment #2) > When you say "network would not come up", that is understandable. Were you > able to go through the MCC Network Centre to configure and enable the new > interface? When I went into mcc, the interface was now wlp10s0 and totally unconfigured. Not realizing why at first, I started to configure it; but got a message saying the address was already in use, and that I should remove it first; but with no obvious way to do so. My only choice was to go into /etc/sysconfig/network-scripts and manually rework ifcfg-wlp6s0 into ifcfg-wlp10s0... > I did not see any way to delete a previously configured WiFi connection. And > cannot judge what you would see with a new WiFi card. Since wlp6s0 no longer existed, the only WiFi card available was wlp10s0. HTH
There is no way for the system to know whether or not the new interface is intended to replace the existing one, or be in addition to it. If you know that the interface will be moved around from one port to another, then one thing you can do is to use a line with net + detect in /etc/shorewall/interfaces and /etc/shorewall6/interfaces to ensure shorewall will allow connections on any interface found in the system. Then it will work as long as the interface uses a simple dhcp configuration. If the config requires custom configuration, best is to make sure you always use the same port. Closing as invalid since this is the way it's intended to work. While it would be simpler for the user if the system assumed the nic may move from port to port, that may reduce security and interfere with more complicated configurations.
Resolution: (none) => INVALIDCC: (none) => davidwhodginsStatus: NEW => RESOLVED
Forgot to add. To remove a connection, use mcc/Network & Internet/Remove a connection.
(In reply to Dave Hodgins from comment #6) > There is no way for the system to know whether or not the new interface is > intended to replace the existing one, or be in addition to it. The new 4-port USB card was totally unrelated to the WiFi interface. > If you know that the interface will be moved around from one port to another, There was no reason to suspect that a new USB card would shift a network interface's position (PCI address) and rename it. > then one thing you can do is to use a line with > net + detect > in /etc/shorewall/interfaces and /etc/shorewall6/interfaces to ensure > shorewall > will allow connections on any interface found in the system. > > Then it will work as long as the interface uses a simple dhcp configuration. > If > the config requires custom configuration, best is to make sure you always use > the same port. I had no idea this would happen. > Closing as invalid since this is the way it's intended to work. This is not a bug report, it was filed as an enhancement request... > While it would be simpler for the user if the system assumed the nic may move > from port to port, that may reduce security and interfere with more > complicated > configurations. From my perspective, the system [design] chose to move a port by inserting a new cards info into a previously long standing configuration. The journal contains: Oct 14 22:00:02 pf.pfortin.com kernel: iwlwifi 0000:0a:00.0 wlp10s0: renamed from wlan0 vs the previous Oct 09 16:05:00 pf.pfortin.com kernel: iwlwifi 0000:06:00.0 wlp6s0: renamed from wlan0 The way I see it is: - system inserted new card into PCI list, changing network adapters' bus number - system still uses wlan0 and renames it without keeping track of that mapping - wlan0 was renamed to a new bus with no current wlp<bus>s<device> defined - a wlp<bus>s<device> already existed with no current mapping from wlan0 - so no conflict/confusion should occur -- system had to have been used previously on wlp<bus>s<device> that no longer maps to wlan0, and no wlan0 to a new wlp<bus>s<device> exists; that's a clue that this is a relocation of an existing interface... Since you mentioned security... I see another issue: iptables is still pointing to the old <bus>! Most users would likely never notice this... $ grep -is wlp /etc/sysconfig/* iptables::wlp6s0_out - [0:0] iptables::wlp6s0_fwd - [0:0] iptables::wlp6s0_in - [0:0] iptables:-A INPUT -i wlp6s0 -j wlp6s0_in iptables:-A FORWARD -i wlp6s0 -j wlp6s0_fwd iptables:-A OUTPUT -o wlp6s0 -j wlp6s0_out iptables:-A net_frwd -o wlp6s0 -j ACCEPT iptables:-A wlp6s0_fwd -o wlp6s0 -g sfilter iptables:-A wlp6s0_fwd -m conntrack --ctstate INVALID,NEW,UNTRACKED -j dynamic iptables:-A wlp6s0_fwd -p tcp -j tcpflags iptables:-A wlp6s0_fwd -j net_frwd iptables:-A wlp6s0_in -m conntrack --ctstate INVALID,NEW,UNTRACKED -j dynamic iptables:-A wlp6s0_in -p tcp -j tcpflags iptables:-A wlp6s0_in -j net-fw iptables:-A wlp6s0_out -j fw-net Even after reconfiguring the firewall, the above remains; while: $ iptables -L | grep wlp wlp10s0_in all -- anywhere anywhere wlp10s0_fwd all -- anywhere anywhere wlp10s0_out all -- anywhere anywhere Chain wlp10s0_fwd (1 references) Chain wlp10s0_in (1 references) Chain wlp10s0_out (1 references) Will the next reboot use 10 or 6 as the WiFi's bus number? Again, it's an enhancement request (though the title does sound more like a bug report) that probably should be pushed upstream... https://bugzilla.kernel.org/ tells me to report to the distro; not directly.
Resolution: INVALID => (none)Status: RESOLVED => REOPENED
Summary: new hardware card caused wireless to be renamed; network would not come up => new hardware card causes wireless to be renamed; should handle changes to network scripts and iptables.
Assigning to the kernel team to consider how to handle, if possible. Just fyi, another option is to add net.ifnames=0 to the kernel parameters so that as long as there is only one wireless nic, it will always be wlan0 no matter how it's connected.
Assignee: bugsquad => kernel
Thanks Dave.
CC: lewyssmith => (none)