Networkmanager last updates caused problems

After NM update this night, my usb wireless adapter device is no longer activated. My laptop has a wireless chip onboard that has never provided a stable connection. Then, I acquired a usb wireless adapter that used to work pretty well till this NM last update.
When connected, NM used to show two WLAN lines (wpl number one and wpl number two). Then, to force using the usb adapter I just disconnect the wpl related to the onboard chip.
Now, without the usb adapter connection, I have to use my cell phone as a wireless rooter to be able to write this message.

I already turn the computer off and on for no help.

Does anybody know what could be wrong? Hope this is just a false alarm.

Thanks

I tested the usb wireless network adapter in another computer with OMV LX 3.0 with all updates but the last one. It is working fine. So I think something related to the last NM update caused the problem. What I am not sure is if it is a new feature or a real NM bug. In fact, having two wireless devices, NM has to use just one of them. Before the last update I could choose which one NM should work with. Now, it might be that NM decides by it self which device to use. This is not desirable if one of the network chips has such an unstable behaviour.
NM network configuration offers the option to “restrict to device” which I guess would allow me to bind my network to the device I prefer. But it doesn’t seem to have any effect.

I tried to remove the kernel module that support the network chip I don’t like,

$ rmmod rt2800pci

But it seems that NM does not work with r8188eu kernel module anymore. No network.

I successfully started the usb network wireless adapter after deactivating the onboard wireless in NM applet and with,

$ /sbin/ifup wlp0s29u1u2

in command line as root.

After rebooting, NM again does not start the usb wireless. Tried ifup command again. After a few attempts it worked again. I still think there is something (a new feature) wrong with NM.

Time for a bug report.

Still don’t know exactly what to report to file a bug. The command,

$ ifup wlp0s29u1u2

can be launched many times before it works and I don’t know why it is like that, what makes a successful attempt different of so many others.

Once it get started, NM recognizes it and show this connection as if nothing was wrong. Also, it seems that the ifup command does not works if I turn the network down in NM, so NM plays its role.

I have seen some reports of problem with the kernel module r8188eu that supports my usb network wireless adapter but all seems to be either too old or of a different nature.

So, still investigating since all that I can say is that this problem begun when NM was updated.

Linux is fun.

Here is some of related dmesg messages. When ifup fails it stops with the message about “entering promiscuous mode”. When I launch ifup again the message “device wlp0s29u1u2 left promiscuous mode” appears. Then, if follows another sequence of “link is not ready” that, if ifup succeeds, ends up with the message “link becomes ready”. Didn’t find anything useful googling around.

These are dmesg messages:

[seg mai 1 14:07:02 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:02 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:03 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:03 2017] device wlp0s29u1u2 entered promiscuous mode
[seg mai 1 14:07:03 2017] device wlp0s29u1u2 left promiscuous mode
[seg mai 1 14:07:04 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:05 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:05 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:06 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:07 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:08 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:08 2017] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u2: link is not ready
[seg mai 1 14:07:10 2017] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s29u1u2: link becomes ready

It seems that NM should have set the link for wlp0s29u1u2 in a “ready” state. I think so because the other link (wlp8s0) became “not ready” when I disconnected it in NM applet. If I’m right, why NM takes so long to set usb wifi adapter link ready?

New possibly related messages:

> zcip uses obsolete (PF_INET,SOCK_PACKET)

and

LoadPin: firmware pinning-ignored obj="/lib/firmware/rtlwifi/rtl8188eufw.bin" pid=7344 cmdline="/usr/sbin/NetworkManager --no-daemon"

Both messages seems to be related to firmware problems but if so why ifup can eventually set the connection? Still no clue.

Do you use IPV6? I f not, you can configure the connection to ignore it.

It is already configured to ignore IPV6.

This seems to link these two posts …