Linux WiFi works, only while logged in

I am running MX Linux (Debian based) on a laptop.

The WiFi works without any issues, but only while I am logged in. I am able to ping the laptop.
But when I log off, the WiFi goes down – pings cannot find the destination host.

I have searched all of the distro’s WiFi related tools. I have asked in the MX Linux forum, etc, and cannot find an answer on how to keep the WiFi enabled, regardless of whether or not I am logged in.

Lots of folks here run a flavor of Ubuntu, which is also Debian based.
Perhaps you can point me to a configuration file, or some non-distro-specific related tool that controls WiFi settings on Debian based systems?

Thank you.

https://askubuntu.com/questions/1064959/stay-connected-to-wifi-when-all-users-log-out

Found this on Ubuntu.
Don’t have WiFi on my Linux boxes so can’t check it out.

1 Like

From the article, I used the GUI.
I changed the “Connection priority for auto-activation:” from “0” to “10” (my other settings already matched).

That worked. Alas, it did not solve my underlying problem:
I am trying to have my Windows box connect to my MX Linux box via Remote Desktop.

I installed “xrdp” on my Linux box, to act as the Remote Desktop server.

Unlike the Windows version, if the server box is already logged in, the client box will be presented with a blank screen after connecting and entering login credentials.

The Windows server would simply lock the screen on the server, and bring the server’s desktop to the client that made the connection.

So the next step is to make sure that the Linux box (the server box) is not logged in.
That is when I encountered the no WiFi issue.

While logged in:
WiFi is up.
xrdp will not release the session to the client.

While not logged in:
No WiFi

This is a bit maddening.

The fix from your (@Jacek) link got me a step closer, because I am now able to connect to my Linux box’s xrdp service, and enter my login credentials, even when no one is logged in to the Linux box. But I still get a blank screen on my Windows client side.

The xrdp tool should not be so complicated.
Perhaps it is not xrdp’s fault? I am at my computer skill’s limit. I am stuck.

I could use a different screen sharing tool, like vnc. But that would mean installing 3rd party software on my Windows chia box, and I would rather not install anything on my Windows box. I am making a heroic effort to keep that box free of everything other than the chia installation. And I cannot be sure that vnc will work.

Could you (temporarily) use a wired connection to isolate the WiFi issue?
I use xrdp to login from windows all the time and recognize the blanc screen issue in case a user is logged in on the linux box.
Do you enforce a password to login on linux? Otherwise the default user will be logged in automatically on startup so xrdp shows the blanc screen.

1 Like

Good idea. I will give that a try.

My login does require a password.

Did you open the RDP port on the linux box.
Don’t know what firewall MX uses but on Ubuntu:

sudo ufw allow from any to any port 3389 proto tcp

No. But it might be open.

My Windows Remote Desktop client is able to get to the xrdp “xorg” login screen.
I am assuming that if I see that screen, I am connected to the xrdp server. Or am I mistaken?

Before I try that, how can I view the status of the firewall for that port?

Don’t know MX so also not what fw MX is using…

Think you may be right to expect that port is open when you get to the login screen (not sure though).
Do you get something like this:

@xkredr59
Yes, that is exactly the login screen that I get.

Is this the issue (missing package)?

https://www.networkshinobi.com/xrdp-on-mx-linux/

1 Like

Looks promising.
I will find out in the next 24 hours and post my results.

Agreed that Linux XRDP is not the most user friendly package to get it running (especially when shit happens). However, once it starts working, it is really nice thing to have, and beats other packages hands down.

As far as the problem with user being logged, just create a new user that you will use only for xrdp (you can add it to your sudoers list). This will fix all potential quirks around that issue.

Also, as I mentioned in the other thread already, check xrdp logs, maybe there are some clues there.

Lastly, you know the drill, screenshots / logs are the king. From my point of view, the one you have provided (xrdp login screen) implies that all is working fine already (from protocol point of view), and most likely there are still login issues. So, maybe somehow that “user” part is still messed up.

1 Like

You are 100% correct.
My apparent negligence in uploading that data is due to me being over-the-top careful with allowing “stuff” to muck up my Chia computers.

So I never run a browser on my Chia computers (that javascript can do awful things).
As such, in order to upload logs and screen-captures, I have to save them to a flash drive, and plug them into this computer (non-Chia, general use computer), and then upload them.

It kind of sucks, but keeps my Chia systems clean.

In the next hour, I will be testing:
$ sudo apt install -y xrdp xorgxrdp (probably don’t need the “xrdp” argument) – posted by @xkredr59

I have a good feeling about it. Hopefully that will end this saga.

For that reason, I am using two highly specialized programs (one to manipulate images, the other to save text files) that are called paintbrush and notepad respectively. Highly recommended :wink: The process you use to get them off your box to this forum is really irrelevant in this context.

Although, your laptop (as I understand it) is just used for plotting (so you xfr your USB drives when ready), as such the risk is really low, as you should have no chia stuff on it but just the plotter. The second thing is that you can lock that box down almost completely, but still xfr files from it to Win shared folders (on boxes that you are using on daily basis). That setup will not compromise your box / chia in any way.

In case you are running harvester on that laptop, it may be possible to just copy harvester binary and relevant portions of .chia folder (stripped down config.yaml, removed wallet db). This way, that harvester will also have nothing related to your chia account.

Lastly, you are killing yourself with that MXLinux (and the rest of us here), as looks like no one has any experience with it. I installed xrdp on Fedora (used as plotter / harvester), and that was done using yum / dnf without too many problems. Yes, I got stuck on that logged in user account (almost gave up because of it, as for a long time I couldn’t find that solution, and logs were saying nothing about it). @xkredr59 looks like is using either Ubuntu or Debian, and looks like his install was also straightforward. Maybe one way to get out of that rabbit hole would be to install one of those two on a different box, tar your home folder on MXLinux, and just swap that SSD, and bring back that home folder (or whatever is relevant).

By the way, this is most likely the page I followed to install xrdp - How To Install XRDP (Remote Desktop) on Fedora – TecAdmin. On RedHat based distros, you run systemctl status xrdp (listed there just before Step 3) to see whether it runs properly. If it doesn’t, there are two command lines given to check on errors, plus again, there are xrdp logs. I don’t know what is the equivalent of systemctl on Debian side, though.

By the way, have you tried pinging your laptop after disconnecting from it? Does the WiFi dies instantaneously, or rather takes some time (few mins)? Maybe your laptop just go to some WiFi power saving state?

I have not read that page, but that was the very first search results for me - WiFi keeps dropping - power saving option? - MX Linux Forum (mx linux laptop power saving wifi).

Copper wire is King!!!

1 Like

I have no technical issues saving images, etc, and then uploading them here.
It is just a but tedious to do the whole sneaker-net thing. But I realize that it is my responsibility to make the effort when I am seeking support.

The PC (daily driver) that I am using to chat here has some sort of firewall issue (possibly when I chose the type of network, a decade ago). I am not able to share a folder (short of another trouble-shooting project).

Until Chia, I never had a need to do so. And this daily driver PC works for me, and I do not want to tinker with it.

The good news is that my Remote Desktop is working! (Windows client / Linux server)
$ sudo apt install -y xorgxrdp … did the trick!

In other news, it is a bit quirky, but I have it doing what I need it to do.

Unlike the Windows Remote Desktop server, the Linux xrdp neither sends over a copy of its screen to the client, nor does it lock its local account.

When I login via xrdp, it simply creates a separate login session. It kept my existing login going on my xrdp server box. The two were acting independently of each other. But both are logged in with the same username.

When I ran my madmax chia script, it complained about non-existing directories.
This turned out to be because on the xrdp session, disk partitions had different mount points.

It was simple enough to point the script to the mount points for the plotting job, but it is bizarre that I have new mount points. The new mount points are only on the client side. My other box (the xrdp server) retains its mount points.

I had a Conky app that did not show up on the client end. But when I went to set it up, it was already chosen. I had to un-click it and then click it – and – viola! it appeared on my desktop.

My client session had the default wallpaper. On the server, I use a black, blank background. So I had to set that, too. The default flowery photo was a network hog for remote screen capture. With the black desktop, things zip along (I can still feel the network delay a bit, but it is fine).

It is all working, and my plotting is going. This will be helpful, because I can do all of my Chia activity from one seat.

By the way, had I known that MX Linux would be a chore for obtaining help, I would have not chosen it. It is nearly always the top downloaded OS from distrowatch. So I thought it was a good choice.

But now I have it configured 98% the way I like to work. So hopefully this will end my need for support.

Thanks all!

1 Like

Yeah, sharing folders is getting more and more complicated. When I get stuck, i xfr files through my Linux box that has Samba installed. Although, maybe your WiFi router has USB slot, and you can stick that Flash drive in it. Maybe sharing that one would be easier.

Great that you got it finally working! It really sucks when xrdp has issues, and there is nothing about it in the logs.

Well, my WiFi problem is not yet licked.

I checked on my plotting progress, via remote desktop, and found the session had ended.
I could not reconnect. The WiFi on the server (the Linux box) went on vacation.

Until I can figure out how to make the WiFi persistent, and independent on whether or not a user is logged in, I am trying the following work-around:

I created a new user on the Linux box, and I am keeping that user logged in. Why?
It seems that the Linux box is somehow enabling the WiFi only while a user is logged in.

Hopefully my work-around works. Hopefully the user that is logged in will not report that there has been X minutes of inactivity, resulting in the WiFi deciding to take a nap.

But if anyone knows how to configure Debian based WiFi to connect, and stay connected, upon booting up, please let me know.

@xkredr59 offered a solution, which I tried (and it seemed to be working). But the WiFi eventually went down.

I asked in the MX Linux forum, and no one has replied.

Plan “B” was to try “nohup” or “screen”. At least I would be able to reconnect to the plotting job.
But when the WiFi dropped, my mounted temp partition unmounted (you can’t make this stuff up), and that killed the plotting job.

My temp partition is an external Samsung T5.

Maybe you can take a look at screen utility. I love it and use it all the time. It is a way better solution than nohup. Using screen should also get you fixed with your mount points problem.

Kind of dirty solution would be to run ping 24/7 against your router IP on that laptop, at least as long as you will not figure it out.