You are not logged in.
Pages: 1
I have recently re-installed arch linux but this time with deepin DE (desktop environment), previously I was using GNOME. Everything is fine except the Wi-Fi. It is very unstable as it keep showing me that it is connecting to the wifi network and continuously keeps on connecting without successful connection. When I reboot my PC, then it gets connected to the wifi network which it was meant to be connected. But after sometime, it gets disconnected and is unable to connect again and it shows same "connecting" notification.
I know there isn't problem with wifi card as I have used it previously on GNOME(previous installation) and in Windows(Dual booted)
name: wlp9s0
Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)
Subsystem: Lenovo QCA9565 / AR9565 Wireless Network Adapter
Kernel driver in use: ath9k
Kernel modules: ath9k
EDIT: Some old wifis which were already added in the list easily connect. New ones don't
dmesg: https://pastebin.com/PBDDQdZY
journalctl: https://pastebin.com/ufnckAwX
Last edited by khatrimann (2019-11-12 15:00:04)
Offline
Please post a complete system journal and ensure to disable https://wiki.archlinux.org/index.php/Du … t_Start-Up
Edit: also "systemctl list-unit-files --state=enabled"
Last edited by seth (2019-11-10 08:24:48)
Offline
UNIT FILE STATE
autovt@.service enabled
bluetooth.service enabled
dbus-org.bluez.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.timesync1.service enabled
dhcpcd.service enabled
display-manager.service enabled
getty@.service enabled
lightdm.service enabled
mongodb.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager-wait-online.service enabled
NetworkManager.service enabled
systemd-timesyncd.service enabled
teamviewerd.service enabled
remote-fs.target enabled
16 unit files listed.
journalctl is too big
Last edited by khatrimann (2019-11-11 09:19:49)
Offline
No, it's not.
a) please edit your post and wrap the output in code tags. Also use code tags for the journal.
b) "sudo journalctl -b", you can also use https://wiki.archlinux.org/index.php/Pastebin to feed that output directly into a pastebin service.
However:
…
dhcpcd.service enabled
…
NetworkManager-dispatcher.service enabled
NetworkManager-wait-online.service enabled
NetworkManager.service enabled
…
You're running dhcpcd and NM concurrently, they'll get into a race over the NIC, causing that instability.
Please read https://wiki.archlinux.org/index.php/Ne … figuration
Offline
One by one I have stopped the dhcpcd and NM service. No luck
Some old wifis which were already added in the list easily connect. New ones don't
journalctl output too big for pastebin
Offline
journalctl output too big for pastebin
If the journal of a single boot is too big for even pastebin, there's gonna be some *severe* issue with the system. Nothing should spill so much log data.
Stop and disable dhcpcd, reboot, dump a journal after the first disconnect and then post it. We won't be able to guess us to the solution here.
Offline
journalctl output: https://pastebin.com/ufnckAwX
Offline
That's
a) horizonzally capped
b) no way a complete journal.
Please read the pastebin link I posted in comment #4 and use that approach.
Offline
No, it's not.
a) please edit your post and wrap the output in code tags. Also use code tags for the journal.
b) "sudo journalctl -b", you can also use https://wiki.archlinux.org/index.php/Pastebin to feed that output directly into a pastebin service.However:
… dhcpcd.service enabled … NetworkManager-dispatcher.service enabled NetworkManager-wait-online.service enabled NetworkManager.service enabled …
You're running dhcpcd and NM concurrently, they'll get into a race over the NIC, causing that instability.
Please read https://wiki.archlinux.org/index.php/Ne … figuration
Pastebin -> http://ix.io/21wq
Sorry for the bad posts before.
Now I have disabled dhcpcd.service. As I said, no lucks.
UNIT FILE STATE
autovt@.service enabled
bluetooth.service enabled
dbus-org.bluez.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.timesync1.service enabled
display-manager.service enabled
getty@.service enabled
lightdm.service enabled
mongodb.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager-wait-online.service enabled
NetworkManager.service enabled
systemd-timesyncd.service enabled
teamviewerd.service enabled
remote-fs.target enabled
15 unit files listed.
EDIT: I don't know why, but the wifi was being turned down and up again. It is shown in the pastebin
Last edited by khatrimann (2019-11-12 06:02:26)
Offline
The initial part of the log is clearly interference between dhcpcd and NM.
=> reboot the system w/ dhcpcd disabled and see whether the problem remains.
Afterwards it looks like interference by the P2P device, but that could still be a continuation of the original issue.
If the problem remains after a clean reboot, disable the p2p device and see whether that stabilizes the connection.
If it does and you rely on the p2p device (for adhoc networks, this isn't related to filesharing…), disabling the MAC randomization might help: https://wiki.archlinux.org/index.php/Ne … domization
Offline
Yes, I guess problem persists through p2p, maybe. But a little issue in here, I don't know how to disable it ?
EDIT: I have tried creating new user, this method also doesn't works either
Last edited by khatrimann (2019-11-12 12:06:55)
Offline
If your NM GUI doesn't allow this, either find a better GUI config or use nmcli. But I suggest you do not "guess". Actually ensure it's not due to the previous dhcpcd interference.
Offline
If your NM GUI doesn't allow this, either find a better GUI config or use nmcli. But I suggest you do not "guess". Actually ensure it's not due to the previous dhcpcd interference.
Now I have used external USB Wi-Fi adapter and it workd, like a charm!! But I still needs the solution for the old one
Guess this is not GUI issue
Offline
seth wrote:I suggest you do not "guess".
... Guess this is not GUI issue
I see no evidence of that at all.
Your "GUI" tools were controlling / configured for the internal interface, so it's not surprising that the problems in that configuration did not affect the new external device.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I have fixed the issue
The problem was as you suggested. The Mac randomization
I have added line in
/etc/NetworkManager/NetworkManager.conf
which is
[device]
wifi.scan-rand-mac-address=no
This problem is in deepin desktop environments, atleast in mine
Thanks
Offline
I have fixed the issue
The problem was as you suggested. The Mac randomizationI have added line in
/etc/NetworkManager/NetworkManager.conf
which is
[device] wifi.scan-rand-mac-address=no
This problem is in deepin desktop environments, atleast in mine
Thanks
Thank you sir! You saved my day!
Offline
I have fixed the issue
The problem was as you suggested. The Mac randomizationI have added line in
/etc/NetworkManager/NetworkManager.conf
which is
[device] wifi.scan-rand-mac-address=no
This problem is in deepin desktop environments, atleast in mine
Thanks
Thanks, it's solved my problem.
Offline
Pages: 1