If I connect to a wireless network which uses WEP encryption, I can't launch any other desktop app, no matter if QT or GTK nor if from a desktop icon, Krunner or Konsole. When I try to launch them from Konsole I get: No protocol specified QXcbConnection: Could not connect to display :0 Abortado I remark this happens only when connecting to WEP secured networks and only when using the network management applet. No problem at all with WPA or wired nor when exiting Networkmanager and connecting from a terminal vía iwconfig. All the programs I have opened before connect to said WEP network keep functioning well. Reproducible: Always Steps to Reproduce: 1. Connect to a wifi spot secured with WEB encryption 2. Try to launch any desktop program the way you want: clicking its icon, from a terminal, opening a file that should launch the program... 3. Actual Results: Nothing happens, the program doesn't run, nor the files are opened. Expected Results: Programs should open normally.
What is the output of the command below? $ xauth list Run the following command and send me the log.txt file that it will create: $ strace -f -o log.txt kcalc
I don't have strace nor kcalc. I understand the purpose of Strace and if necessary I'll install it, but are you sure I need a calculator program I have never used?
In case Kcalc were just an example and any other app would serve the same, I've installed Strace and tried: $ strace -f -o log.txt kate With the same results: No protocol specified QXcbConnection: Could not connect to display :0 Abortado «$ xauth list» returned: PC_name/unix:0 MIT-MAGIC-COOKIE-1 a2a8264bf3e364f4894097ee0cdc9a17
kcalc was just example. I need the log.txt file that strace command created.
That I supposed. Well, the problem is that inmediately anter executing $ strace -f -o log.txt whatever I always get: No protocol specified QXcbConnection: Could not connect to display :0 Abortado Seems that no action is peforrmed, only that error message.
Ignorant me... Despite the abortion of the action there's a log.txt file, yes. Here I attach it
Created attachment 100596 [details] log.txt
Please repeat the the command when no problem happen (when using wpa for instance): $ xauth list $ strace -f -o log.txt kate
Ok. «xauth list» returns: PC_name/unix:0 MIT-MAGIC-COOKIE-1 a2a8264bf3e364f4894097ee0cdc9a17 $ strace -f -o log.txt kate says: QObject::connect: invalid null parameter QObject::connect: invalid null parameter QObject::connect: Cannot connect (null)::returnPressed() to KUrlRequester::returnPressed() QObject::connect: Cannot connect (null)::returnPressed(QString) to KUrlRequester::returnPressed(QString) XmbTextListToTextProperty result code -2 XmbTextListToTextProperty result code -2 XmbTextListToTextProperty result code -2 XmbTextListToTextProperty result code -2 XmbTextListToTextProperty result code -2 and Kate opens itself correctly. The log is attached below
Created attachment 100597 [details] log.txt (WPA network)
By what I can see in the logs, somehow the WEP connection is changing your computer's hostname and that is probably breaking Xorg. Your computer should be named Juan-PC (name used in xauth's cookie) but strace shows it is dhcppc4 for the WEP connection. One should always use localhost in xauth's cookies and DISPLAY to prevent that (and for performance reasons too) unless you really need Xorg's network transparency feature. What is the output of the commands below in both working and non-working setup: $ hostname -f $ host $(hostname -f) $ ip addr $ ip route If you create a new connection to the same WEP access point does the problem still happen?
I set the machine's name when I installed the OS, and, to be sincere, I had no idea at all one could nor should use localhost -you mean «localhost» as the computer's name, right?- in xauth's cookies and DISPLAY, amont other things because I have no clue about how to set the name in xauth's cookies, nor in DISPLAY. :/ Here is what you asked: $ hostname -f Juan-PC $ host $(hostname -f) bash: host: no se encontró la orden (command not found) $ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1 link/sit 0.0.0.0 brd 0.0.0.0 3: wlp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 0e:9b:57:62:68:cc brd ff:ff:ff:ff:ff:ff inet 192.168.1.37/24 brd 192.168.1.255 scope global dynamic wlp12s0 valid_lft 259197sec preferred_lft 259197sec inet6 fe80::c9b:57ff:fe62:68cc/64 scope link valid_lft forever preferred_lft forever 4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:1c:23:ae:83:50 brd ff:ff:ff:ff:ff:ff $ ip route default via 192.168.1.1 dev wlp12s0 proto static metric 600 127.0.0.0/8 dev lo scope host 192.168.1.0/24 dev wlp12s0 proto kernel scope link src 192.168.1.37 metric 600 Recreating the connection does behave the same, yes. I have stopped Networkmanager and connected with iwconfig from Konsole, and I have seen the name doesn't change (I think I had never paid attention to this detail). Seems that is NM the one that changes the PC name. Why iwconfig doesn't need to change it but NM does. Do you think there's a justified motive for it or is it a bug? Anyway you still advice me to set my PC name as «localhost» in xauth's cookies and DISPLAY? If yes, would you be so kind to tell me how or pointing me to some page where it's explained? Many thanks for your time, Larmarque.
Since you do not have the host command installed, the output of the second command is useless. Can you ping your hostname? Like this: $ ping -c 1 Juan-PC NetworkManager does not directly change computer's hostname. The dhcp client does. Let's first try to understand what is causing your problem before messing with xauth and DISPLAY. What is you Linux distribution? I need you to send me NetworkManager's log and the way to retrieve it depends on which distribution you use. If you use one that uses journald you can retrieve it running the following command as root: journalctl -u NetworkManager.service
I only have dhclient installed for DHCP. Aren't NM and iwconfig using it equally? What you asked: $ ping -c 1 Juan-PC PING Juan-PC (127.0.0.1) 56(84) bytes of data. 64 bytes from Juan-PC (127.0.0.1): icmp_seq=1 ttl=64 time=0.053 ms --- Juan-PC ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms I'm on Gentoo. It doesn't use Systemd by default, but OpenRC. To see system logs I have Metalog, that I'm aware of, don't know if I could have anyone else installed as dependency of something.
Hi, Lamarque. I suppose you probably have many bugs and stuff to take care of, but do you remember this one is still pending? Not in a hurry at all, take your time; just wanted to make sure you didn't miss it. Regards.
Hi, I also use Gentoo and but long ago I decided to keep using sysklogd instead of metalog. You can find the metalog's log in /var/log/everything/current. NetworkManager can use dhclient, dhcpcd or its internal dhcp client. I use the internal one because it is stabler for me. If you want to try it add these lines to /etc/NetworkManager/NetworkManager.conf: [main] dhcp=internal and restart NetworkManager NM passes some arguments to the dhcp client which can change its behaviour, so NM and iwconfig can work differently. By the way, why use WEP? It is not secure. Can you still ping Juan-PC when the problem happen?
(In reply to eemantsal from comment #15) > Hi, Lamarque. > > I suppose you probably have many bugs and stuff to take care of, but do you > remember this one is still pending? > Not in a hurry at all, take your time; just wanted to make sure you didn't > miss it. > > Regards. Hi, can you please try reproducing the problem, then using the following command and check if the problem still happen? xhost +
Excuse the delay. Lamarque. I've been on travel for a couple of weeks. Ok, I'm at home now and have a ton of packages to emerge, so, let me do it and I'll test all what you say once my system is up to date, hopefully tomorrow (gentooers' curse, hehe)
Ok, I upgraded my system to Plasma 5.7.5 and Framewoks 5.26 yesterday, and the problem has gone. I can connect to the same formerly problematic WEP network and open other programs as it's due. I suppose I can mark this bug as resolved. Thanks for your attention, Lamarque.