Got my Qubes running nicely on my Asus UX303UA (got a crucial 12GB RAM for it so it has 20GB RAM).
It identified the WiFi network automatically, BUT after being supplied with the correct Password, and checking it had the right encryption, it still doesn’t want to connect !!
-Any thought of what might be wrong? (I do have a MAC based filter on, BUT it worked fine previously with Linux Mint I had on it (another SSD), so its WiFi MAC should appear in the filter table.
Earlier versions of Qubes did not randomize the MAC by default. According to information found at the Whonix site, MAC randomization is not that helpful these days since there are more sophisticated methods of probing, all the way up to spectrum analyzers.
So you should have connected since you did not change your hardware MAC. You own your AP so you have selected your MAC as the only one allowed? There should be no problem.
Maybe an expert in nmcli could help you find out what is missing.
But I suspect not. Maybe you have to incorporate your own ISP to remove all network obstacles and then lobby heavily so your local spy agency remains friendly to you and permits you to operate on the infrastructure… Damn, that’s someone being paid the big bucks! Big man!
One the thing I changed just after asking the Q was latching my identification to the router to my physical MAC, which I found was already on the “allowed” list. -HOWEVER, even when disabling the list altogether, just to see if it connects, it failed to.
I came to the opinion that the three active machines on my qubes: sys-fw, sys-net & sys-whonix, have something to do with with it.
It might be that I have to change the general settings to start only 2 of the 3 automatically on login, or create a rule that allows for the wifi connection to complete the “handshake” with the router.
Only sys-net is relevant to connectivity issues. You are saying that when you select the wifi SSID and enter the password through the Network Manager GUI, you still dont connect? Is Fedora or Debian your default template, the one being used for sys-net? I have found that Fedora is usually the better default sys qube since it has drivers that Debian does not so far as hardware compatibility goes. I suggest going into sys-net terminal and looking at the manpage for nmcli. There you can specify exact options that might help you connect, but I still cant determine from only what you have told us why there would be a problem connecting. We need more information. Should work.
I selected Debian.
I did get to the sys-net settings, and try and find out why
Debian-wise, it too identifies the network and tries to connect unsuccessfully.
However, in a tutorial, I found out that I selected in the initial configuration to use sys-net for all networking and USB. -Might this be a factor? -and if so, how do I change it, and to what?
Second thing I noticed is that by default 3 machines run - The ZEN, (1) the firewall, (2) the sys-net and (3) the whonix gateway. This is without me starting any whonix client machine. -his may be a consideration, and if the whonix gateway should not work by default, I would appreciate knowing how to set it up not to.
My sys-net, was initially somehow detached from the Debian template, and only going into cubes settings, if I remember correctly enabled me to attach it (which also eliminated yellow stop signs on it…
However, trying to modify running machines is not permitted (of course), but restarting them requires restarting the whonix gateway, since the other two claim dependency on it.
As before, any help in resolving thiese issues will be greatly appreciated.
When you start a qube, all other qubes that provide network to that qube start also. For example, if you start whonix-ws-16-dvm then sys-net sys-firewall and sys-whonix will also automatically start. The best way to see how that is working is to examine Qube Manager.
Then, if you go to “settings” for a qube in Qube Manager, you will see the option “start qube automatically on boot.” That way, you could have Whonix Gateway running by default. Memory requirements are the only possible constraint. I had to add memory to my computer so that I can have as many qubes running simultaneously as I need. So if you have enough RAM, you could start all qubes automatically on boot although for security purposes it is probably preferable to start only what you need.
Why don’t you try to make a new standalone qube that provides network with a Fedora template and add the appropriate wireless pci under “devices” and see if this doesn’t resolve the problem for you.
Thank you procShiled for your advice.
By now I’m trying to figure out why my dm0 says it needs an update, fails to discover its version, “updates” but really does nothing, and any update I want to perform says that loop backs are unsupported.(I am working with a USB J45 for internet - successfully).
-Will try the Fedora thing, but I’m skeptic of its success, since it’s not a HW are driver issue as far as I can tell.
On lots 2 of 3 machines (sys-fw, sys-net, whonix-fw), when I go to settings, there are warnings for linked template, and whenever I try and change it, it basically says that it can’t because its running, but then if I take the down and try the same, the “unsupported loop back” appears, and they don’t change.
Thank you for your help.
Today I reinsalled the Qubes (clean install), persisted with fedora 37, and did not change anything while finalizing the setup at 1st run.
-The WiFi problem persists. Again I have checked that the identification is strapped o the WiFi MAC.
No joy.
–I’m using a USB J45 for internet, for now.
This time, most of the updates ran successfully,
but I’m still stuck with no wifi connection, and no idea how to resolve this.
–Also, tried to run cmdln updating of all the templates (using the manual specified script), and again - no joy.
-I am interested in installing a version of Mint & Kali as a virtual machine, as well as win 10 (HW doesn’t support win 11).
I assumed at first that it would be close to establishing a VM on VM worksation/ Virtualbox, but the controls per machine seem very limited so far.
-I know that I may be trying “too many things at once”, but actually the three issues as far as I can see are not related, and so ANy help in resolving at leas some of my issues, will be greatly appreciated.
Have you tried turning off MAC address filtering to see if it works? Or looking at the logs on your router to see why it’s denied?
One of my Qubes boxes ran my LAN out of IPs once. I had very long leases set up, and that plus random MACs plus a habit of shutting down instead of sleeping… yeah.
Thanks Syonyk,
Earlier I already menitoned trying without MAC filtering (no joy), and discovering that the MAC was already included anyways in the CLI-allowed table (sill no joy).
Turning from Debian 11 to Fedora 37 was only the latest step of many (all included in the chain from OP to now).
Since it’s a home LAN, running out of IPs is practically impossible (out of possible 254 addresses, I have two that are static, and the rest dynamic.
Whet I’m thinking now is that there is an address table on the Qubes manager, which starts with 10.0.0.1 basically. If my router is on 192.168.0.1 for instance, we cannot be on the same network, and therefore cannot connect.-So the question now appears to be twofold: (1) If so, how come I see the router (wifi) network? (2) If for some reason this is the obstacle, how do I migrate the whole range to 192.168.0.0 range.
Tried to see using the log button on sys-net - no joy
I get var/log/xen/console/guest-sys-net-dm.log
or var/log/xen/console/guest-sys-net.log
or var/log/qubes/guid.sys-net.log
or var/log/qubes/qrexec.sys-net.log
It does not offer what you suggested.
Also, while doing that I found out that I don’ know how to make a vm appear on screen. They seem to run only in the background.