Installer disconnects wifi (after choosing download while installing, 3rd party)

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1867465

FYI: I get the same wifi-disconnect with today's Xubuntu daily image.

FWIW: I also tested today's daily image for Kubuntu, Mate & Budgie (and Lubuntu). I didn't have this experience with them. As mentioned previously, Lubuntu had a problem connecting to wifi after rebooting (when install was finished). I had to reboot a 2nd time for wifi to work. But, I haven't experienced that with any other of today's daily images.

Choosing to install the third party drivers installs the bcmwl-kernel-source driver which may or may not work well with the BCM4313. When booting the ISO this device will use open source drivers from the kernel, bcma and brcmsmac

@Jeremy, I'm sorry I haven't returned sooner. I've been keeping an eye on how this works (and have experienced it again today with Budgue & Kubuntu 20200321).

Are you saying that it is downloading and installing that particular driver when I click "continue" from the installer page saying "download while installing; install 3rd party?"

That never occurred to me. I assumed that the disconnection would actually interfere with the install's ability to download while installing. (I didn't manually reconnect Kubuntu today, and it looks like a lot of updates are pending to be installed when I rebooted. I imagine those would have been downloaded while installing if I had reconnected before proceeding with the install?).

Should the installer inform the user that it's replacing the wifi driver with a 3rd party (and the user might have to reconnect before proceeding)? I did notice that it takes a long time for the "installation type" screen to be active. I guess that behind-the-scenes wifi replacement is what's happening. I think a status msg would be useful during that time (especially if the wifi is being disconnected. The user's going to see that disconnection and start fiddling with things before it's ready.).

Even better, should the installer reconnect? If it has the intelligence to replace the driver, it seems like it could restore the connection? (If so, I still think a progress msg would be needed so the user knows to wait for it. It's kind of unnerving to see the disconnection, and try to connect when it's not ready yet. Now that I know what's going on, it's not bad. But, the average person would stumble on this.

I'm going to agree with what Jeremy said, this might be an issue with your specific hardware. Please keep in mind that Linux isn't guaranteed to work on all hardware, but we try to get it to work on as much as possible. That means making some things work for the biggest cross-section while leaving others out.

@Erich, the hardware works fine except during that screen transition. If the installer is replacing the 3rd party driver at that point, it seems reasonable to expect some communication that the connection is going to be dropped (maybe reconnect for the user). The user was just asked whether to download updates during the install. Dropping a working connection (without any notice to the user) doesn't seem right. Or, it doesn't seem like a "hardware issue."

@Erich, sorry for replying twice. Let me put it this way. Whatever you guys decide is fine with me.

From the user's perspective they don't have a "hardware issue." Everything's working. The installer tries to help the user in a way the user isn't aware they need help. It could be very useful help. But, the user is left with what looks and feels like a "hardware issue" -- after the improvement. The improvement is being done to help the user as a convenience. But, they can't receive a helpful communication because it's their "hardware issue?"

I understand that this isn't a high priority. It might not affect many people. But, that approach doesn't seem reasonable (intuitive) to me. A new user wouldn't know what happened. It can take a minute for the connection to work again. I was clicking trying to reconnect. It looked even more like a real problem (not just a dropped connection). If there had been a msg "We've discovered a 3rd party driver for your network connection. We are going to install that now. When this window disappears, please reconnect to the internet..." I would have been happy. (Maybe even display the driver name & give the user the opportunity to install that later, if they prefer to keep their working connection. The would be ultimate.).

I just don't see how the status quo is the right thing to do. (But, I do accept that it's low priority.).

The key part of dmesg is:

[ 214.287602] wlp2s0b1: authenticate with 74:da:88:50:00:47
[ 214.292003] wlp2s0b1: send auth to 74:da:88:50:00:47 (try 1/3)
[ 214.294069] wlp2s0b1: authenticated
[ 214.295333] wlp2s0b1: associate with 74:da:88:50:00:47 (try 1/3)
[ 214.299380] wlp2s0b1: RX AssocResp from 74:da:88:50:00:47 (capab=0x431 status=0 aid=2)
[ 214.299928] brcmsmac bcma0:1: brcmsmac: brcms_ops_bss_info_changed: associated
[ 214.299932] brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: true (implement)
[ 214.299942] wlp2s0b1: associated
[ 214.331657] brcmsmac bcma0:1: wl0: brcms_c_d11hdrs_mac80211: txop exceeded phylen 159/256 dur 1778/1504
[ 214.371947] brcmsmac bcma0:1: wl0: brcms_c_d11hdrs_mac80211: txop exceeded phylen 137/256 dur 1602/1504
[ 214.408585] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0b1: link becomes ready
[ 214.439835] brcmsmac bcma0:1: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
[ 491.393622] wlp2s0b1: deauthenticating from 74:da:88:50:00:47 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 491.396079] brcmsmac bcma0:1: brcmsmac: brcms_ops_bss_info_changed: disassociated
[ 491.396086] brcmsmac bcma0:1: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
[ 491.396089] brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: false (implement)
[ 491.472322] wl: module verification failed: signature and/or required key missing - tainting kernel
[ 491.516220] wl 0000:02:00.0 wlp2s0: renamed from wlan0
[ 491.596460] wlp2s0: Broadcom BCM4727 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)

So when using the default driver, your wlan interface came up as wlp2s0b1. After the bcmwl driver has been installed, the interface comes up instead as wlp2s0.

So this new interface doesn't match the configuration that NetworkManager was using before, and so you do not automatically reconnect after disconnect (the disconnect itself is unavoidable when changing driver).

I think this is probably not sanely fixable, short of imposing some additional rules to force the network device name to be the same in the two drivers.

@Steve Langasek, thank you for your time triaging that. I was thinking the problem is that the installer doesn't handle this in a user-friendly way. From my perspective the installer should:

1. Inform the user that it located a possibly better driver, and the connection will drop. (In my case, I had a seemingly perfect wifi connect, then it dropped without explanation. I was clicking, trying to get it to reconnect -- when it probably wasn't ready yet. I almost got up to reboot the router. An informative message would be nice if the network is already connected.).

2. An additional courtesy (not as important as #1) would be to detect that the wireless interface reappeared under a different name, and connect using that. I.e., I don't think the underlying process for replacing drivers has to preserve the name. It seems like the installer could know that it's replacing a driver for an active connection, and anticipate that the device name will change.(But, manually reconnecting wouldn't be bad. I think what's bad is #1, not knowing what's happening.).

Thanks. If either point is worth pursuing or advancing to the installer maintainer, I know that it's low priority. I'm sure it doesn't affect many people. Once someone knows what's happening, they can live with it, etc. (It just seems rough for the first-timer. A courtesy msg seems appropriate so the user knows what's happening. I've used Linux for quite some time. It never occured to me that it was installing the 3rd-party driver then.).

[ 129.282522] brcmsmac bcma0:1 wlp2s0b1: renamed from wlan0
[ 491.516220] wl 0000:02:00.0 wlp2s0: renamed from wlan0

So, i would have expected for systemd udev net_id to produce the same name for the wlan0 device, irrespective of the two drivers used.

I wonder where the b1 is coming from and why it's present for one driver, and not the other.

it seems the brcmsmac driver creates a device whose direct parent doesn't report that it's a pci device, so udev's net_id builtin moves past the NET_PCI naming and instead uses the NET_BCMA naming, since it's a BCMA device. That naming format is the same as pci, but appends bcma_core, which is set to 'b%u' for all cores > 0.

I appreciate everyone's time looking into this. I just wanted to add: if it is a driver problem, and can't be any better than that, I still think it would be friendlier if the installer informed the user that "a new driver is available. Your connection will disconnect while this driver is installed. It should automatically reconnect. If not, please wait at least until you see the next page, and reconnect manually." Maybe even a "yes/no" prompt so the person could elect to keep the working driver?

To me, it wasn't so much about whose fault it is, but that I thought my router dropped the connection (that it was a coincidence, and I needed to go reset my router). Even if the underlying bug with the device name didn't exist, I think there could be a better user experience in this "on the fly" replacement of the driver. The "wifi connection lost" msg is a little unnerving if you don't know what's happening. It seems like it should be simple for the installer maintainers to make that more informative.

Thanks again!

@ddstreet

Indeed, https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html b1 seems to stand for "Broadcom bus (BCMA) core number"

So it seems to me that our stock vanilla kernel has gained support for this broadcom wifi chip with proper Broadcom bus support.

Yet we also have some other implementation that claims to support the same chip, and then doesn't quite work the same way.

I guess wl & bcmwl-kernel-source should not be both declaring support for the same chip? Such that user is not receiving one or the other, at random, or switching between the two, just because they ask installer to enable Nvidia.

This change was made by a bot.

@Alberto Milone

Something odd is happening for the user of BCM4313 wifi chip.

The devices appears to jump from bus1 to bus0, and thus getting a new name.

Or as if, there are two different drivers offered to the user and/or operational via different buses. Such that udev identifies the same card on bus1 at first, and then later at bus0 and thus generates wlp2s0b1 name at first, and then wlp2s0 device name (not that when bus is 0, b0 is ommitted).

@MarkF (az2008)

What you have experienced is abnormal. Normally there is only one driver for device, we offer the best driver we have, and once connected to the internet, the connection persists without any disconnects. And copies wifi config into the target installed system. Such that one never has to type the WiFi password a second time.

I'm trying to troubleshoot what went wrong. As normally, we shouldn't cause such disruption at all. And thus there should be no need for confusing popups saying things about disconnects, waiting, redoing things.

Status changed to 'Confirmed' because the bug affects multiple users.

I had this same bug. This was fixed?

Sorry, this bug is not fixed.

After getting better wifi driver, it gains a different kernel name. And hence NetworkManager "disconnects" and doesn't reconnect.

When this happens, you need to setup Wifi connection again.

I do not know how to fix this, and/or anticipate the new wifi card name.

@Dimitri John Ledkov I had also this issue. I know now that this will be not fixed. This problem is not affect my security? I am safe? This worried me because Network Manager save wi-fi password. Can you answer?

@Piotr, I've given up on this. I was less concerned about security than I was about the user experience. If the installer knows it's going to drop the connection, why not inform the user of this? It's really unnerving to have your connection drop, and think there's some kind of bug going on. It's little satisfaction to learn later it's not a bug.

I don't know what it is with *buntu, but I've given up. They don't care about attracting more people. It's a circle-the-wagons approach. I say it to anyone who will listen: Re-open Bug#1. *buntu has lost its way. Shuttleworth should look at his contemporaries (who've moved on to launching cars into space, and being the richest men in the world). He should ask why he got left behind. Windows 10 was a windfall to the Linux Desktop, and we're still missing the point.

I've moved on to a non-buntu based distro. Peace be upon all.