Qubes 3.2: Network doesn't connect automatically with hidden wifi

25 views
Skip to first unread message

Max Andersen

unread,
Feb 21, 2018, 2:13:44 PM2/21/18
to qubes...@googlegroups.com
Hi,

I've noticed that after disabling SSID broadcast on my wifi, I need to
disable and reenable my network, every time I login.

I've tried to describe it in detail here: https://militant.dk/?p=174

Maybe anyone has ideas to resolve this?

Sincerely

Max

Yuraeitha

unread,
Feb 21, 2018, 3:19:46 PM2/21/18
to qubes-users

How come you try to hide the SSID? It'll only give you more attention. Out of the many identical wi-fi networks out there in the wilds, if a hacker comes across a wi-fi that's behaving different, and towards that, trying to "hide", it might act as a bait.

Hackers don't look for SSID's anyway, they look for the actual "signals", and no matter how you try to slice it, any working network will require a signal, otherwise there will be no network. So it's impossible to hide your wi-fi, and it's all the more true when trying to hide it against hackers who will see it anyway.

Basically the result is that you'll hide your network from people that poses no threat to your digital life anyway. But maybe that's the goal, to try hide the network from people with no hacking background for other reasons?

If you're trying to hide it for security reasons, then it's better you make it visible and try to "blend in" in the masses. Even if there is no other wi-fi nearby, try make it look as normal and "boring" as possible.

Yuraeitha

unread,
Feb 21, 2018, 3:23:05 PM2/21/18
to qubes-users
On Wednesday, February 21, 2018 at 8:13:44 PM UTC+1, Max Andersen wrote:

Think of it this way. Hackers love challenges. By the act of trying to hide that way, you're giving a hacker a challenge. He or she, may even get a kick out of showing you how insecure your network really is by messing with you, simply because you do something that has no effect, such as hiding the SSID.

You're either giving them a challenge to work on, or it might even be schadenfreude https://en.wikipedia.org/wiki/Schadenfreude

Tbh, you're better off just enabling SSID again.

Max Andersen

unread,
Feb 21, 2018, 9:20:32 PM2/21/18
to Yuraeitha, qubes-users


Sendt fra min iPhone
So, the solution is actually security by nudging?

Don’t do it, or we will make qubes network manager crash to nudge you back :)

I’d bet my network is not that interesting for a wardriving kali hacker, but it still seem like a bug that I would love to get fixed.

Sincerely
Max


Yuraeitha

unread,
Feb 22, 2018, 2:09:38 AM2/22/18
to qubes-users
hehe, well you can probably find a hack to get what you need, for example making a script that automatically repairs your connection at boot. I'm not seeing the particular details atm, but it seems like it might just work. I'm no expert though.

The bug itself is likely not related to Qubes btw. It's very likely that it belongs upstream in Fedora, and even in Fedora the Network Manager may come from up further upstream. Even if you track down the Network Manager developers, the piece of code they're using may come even further upstream, and even there, it may yet again come from another upstream. This is usually called upstream/downstream movements. Linux is like lego, many pieces comes elsewhere, and no one have the resources to do everything. If they tried, they'd drawn in work to do. And if they change upstream code, then it becomes really, really messy when new updates arrive from upstream, and you need to incorporate the code changes you made to all your packages every time a new update arrives. To make matters worse, it's not their code, so it can be hard to find your way around and find the right places in the code, wasting a lot of time. And then there is the aspect that security can be tough to enforce if you spread out too far. You have to trust other developers to some extent, otherwise you'd spend all your time looking for security flaws and never get anything else done.

The closer to you get to the source upstream, the higher your odds are that a developer will track it down and report the issue. Qubes is pretty far away from the source, and operates on a more broad level of coding (macro-perspective, piecing a lot of different codes and mechanism together). You can kind of look at Qubes as an infrastructure, and not an organ like operation systems are. Qubes in and on itself is not an operation system, it's a network or "mesh" of operation systems. So this issue has to be tracked down.

It's also an issue if developers have to spend time reporting all the bugs to each others, they'd spend a huge amount of time on that. A single bug may not seem like wasting a lot of time, but it piles up. Say one spends 20 dollars, it's pennies, not a lot of money (well at least in some countries). Now imagine if you had to pay for 1.000 pieces, then it becomes 20.000 dollars, and it suddenly became very expensive.

That's why developers have to prioritize their time and focus, because if they do not, they'd drawn in everything else. Qubes top priority is security. I doubt they will be looking into this bug.

But the community can help, by reporting the bug closer to the source, or at the actual source. This way the bug can get fixed, and it may go faster too (not always though) if the actual developers behind it are reported about it directly. If the community does this, it'll save all developers a huge amount of time. So this kind of bug, may be a matter of tracking down the actual Network Manager developers.

But if you'd like a fix though, a sort of "hack", then as mentioned earlier, a script may work out. But before trying to look into it, I'll ask if this is something you need? or do you prefer to wait for a real bug fix? (It can take a long time for what may be deemed minor bugs, and also requires someone reporting it at the appropriate issue-tracker).

I may not be able to make such a script though, I'm only an average Linux user. But I'll try see if I can work something out, however, sleep/work/responsibilities up ahead, and things I gotta do, so it might take a while before I can find time to see if I can work out how to do it or not. Maybe someone else knows how and drops a solution meanwhile (would be nice too). But then, is a script kicking in at boot to fix your network credentials something you'd want?

Max Andersen

unread,
Feb 22, 2018, 3:15:30 AM2/22/18
to Yuraeitha, qubes-users
Thank you for your offer, but Instead of spending too much time on it,
the nudging approach worked. Made the network visible, change the name
to not include manufacturer and model name to decrease the attack vector
was the easiest fix.

But for people needing such a workaround, the idea could be:

Placed in .bash_profile, /etc/profile, gnome-session-properties,
.config/autostart or somewhere else so it executes  directly after login
#!/bin/bash
echo "Checking network..."
if ping -c 2 $ROUTER_IP
Else
systemctl network restart
fi

Thanks for your time
Sincerely
Max


Reply all
Reply to author
Forward
0 new messages