Devuan image in Qemu

(No. 0)  No. 1  No. 2  No. 3  No. 4  No. 5  No. 6  No. 7  No. 8  No. 9    No. 10  

For the reasons described in this thread on qemu-discuss mailing list, for days I wasn't able to connect to internet with my Qemu:

How to set the network card for qemu to use?,

I'll post on that thread as Aleksei suggests , just let me tell what progress I have made so far.

UPDATE: There's, 20 hours later, another, faster, successful booting of opennebula Devuan image, read further below.

In the first place, since I absolutely use grsecurity-hardened kernel (just remember not NSA Linux, ah I meant SELinux-hardened, but grsecurity-hardened), wouldn't go online without it on a system that I don't intend to throw away, I had to set some learning rules into my policy:

 # Role: miro
subject  /usr/bin/qemu-system-x86_64 ol
	/				h
	bind	disabled
	connect	disabled


( and one of my motives to step into these VM waters is Use Tor browser on grsecurity-hardened system? )

Now, the command I used in this (primitively) successful (I'm new at [V]irtual [M]achines generally) Qemu deployment:

qemu-system-x86_64 -display gtk -m 1024M \

My qemu install got (the default) pass-through network set up.

I used my (simple) uncenz program:

That is, I plugged in to the router (I'm offline when I don't do things on internet), and started my uncenz.

The network trace, transparent as fresh mountain spring (no SSL), is in this cap-161015-qemu-devuan/ directory where you're at right now:


The screencast of how my

Devuan image:


booted is this one (but you had better use the links below, it's 15 minutes altogether, TL;DR ) :


These open in separate tabs/windows:

This is the pass-through network connection successfully set up (38 seconds):


here I installed the links package from devuan repositories (1 min):


and here I connected to my NGO's website (26 seconds):



UPDATE: 20 hours later, a more successful try is here. This is 5 minutes 36 seconds, it's actually fast booting, but it stops unable to connect to the cloud at, for which pls. see the trace): dump_161015_2050_g0n.pcap (so you need to only see the first some 30 seconds, realize how it stalls there, and go to just about 4:00 and there's 1minute 36 seconds to end then).

The command I used worked thanks to Aleksei's advice:

qemu-system-x86_64 -machine type=q35,accel=kvm -enable-kvm \
	-cpu host -display gtk -m 1024M \

I'll also try and ask on Devuan mailing list about the stalling for (won't necessarily update about it here, find it in the archives there).


As I promised, I went back to what the title of the thread on Qemu says, Aleksei's first advice.

First I thought it will work, and wrote this message.

This is the command that I used and it also includes the second suggestion by Aleksei):

qemu-system-x86_64 -machine type=q35,accel=kvm -enable-kvm -cpu host \
	-display gtk -m 1024M -device virtio-net,netdev=internet -netdev \
	bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper \

Unsuccessful, and only in the screencast it can be seen it doesn't work (well, I could probably tell from the dump_161016_0501_g0n.pcap analyzing the (fake, always fake, use macchanger program) by [analyzing the] MAC's):


And it paid off, my following of Aleksei's kind advice. I have to repeat here that I almost veered off and away from the solution that was in front of me, were it not for Aleksei's informal supervision.

The command that I used is the same as the previous posted uncenz set, just above):

The trace is sanitized for my password and some more dump_161016_1114_g0n.pcap with this command:

tshark -r dump_161016_1114_g0n.pcap -Y \
	'!((ip.addr==' \
	-w dump_161016_1114_g0n_noZTE.pcap

and I renamed it:

mv -iv dump_161016_1114_g0n_noZTE.pcap dump_161016_1114_g0n.pcap

The screencast needed to be as precisely as possible sanitized, guess at which stretches and how? Well, forget the first, and as for how: with mkvmerge of Mkvtoolnix the cutting, and the finesse manipulation with FFmpeg of course (but out of time to give you the tips on that; elsewhere, some day):


It's not over yet for me, but the topic [Qemu-discuss] How to set the network card for qemu to use? can be considered done. As I say in the last messages of that thread as of the timestamps of the last uncenz set above, I only need to fix iptables policy for this Qemu setup, but that is a question that I need to search elsewhere for solution.

I solved it on my own. Can't give you the that I run to create and save my iptables, but usually those rules include these lines (the $ipt being /sbin/iptables or whatever it is on your system):

echo " * Set default policies for INPUT FORWARD OUTPUT"
read FAKE

Right after those lines you need to, for an arrangement like mine, add:

echo " * allowing tap0 in"
$ipt -A INPUT -m physdev --physdev-in tap0 -j LOG --log-level warning --log-prefix mrfw_tap0_in
$ipt -A INPUT -m physdev --physdev-in tap0 -j ACCEPT
read FAKE

echo " * allowing tap0 out"
$ipt -A INPUT -m physdev --physdev-out tap0 -j LOG --log-level warning --log-prefix mrfw_tap0_out
$ipt -A INPUT -m physdev --physdev-out tap0 -j ACCEPT
read FAKE

echo " * allowing tap0 fwd in"
$ipt -A FORWARD -m physdev --physdev-in tap0 --physdev-out eth1 -j LOG --log-level warning --log-prefix mrfw_tap0_fwd_in
$ipt -A FORWARD -m physdev --physdev-in tap0 --physdev-out eth1 -j ACCEPT
read FAKE

echo " * allowing tap0 fwd out"
$ipt -A FORWARD -m physdev --physdev-in eth1 --physdev-out tap0 -j LOG --log-level warning --log-prefix mrfw_tap0_fwd_out
$ipt -A FORWARD -m physdev --physdev-in eth1 --physdev-out tap0 -j ACCEPT
read FAKE

I found it at Building Bridges with Linux, and for my setup I needed to modify it like above. YMMV.

Ah, and you may need to recompile the kernel: CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y (or m) is needed.


There's more.

Qemu worked like a charm with Refracta CD:

The trace is sanitized for my password and username (all in one packet) and nothing more dump_161018_0245_g0n.pcap with this command:

tshark -r dump_161018_0245_g0n.pcap -Y '!(frame.number == 20985)' \
	-w dump_161018_0245_g0n_NO_login-N.pcap

and you got:

mv -iv dump_161018_0245_g0n_NO_login-N.pcap dump_161018_0245_g0n.pcap

Unfortunately I'm not a wizard to edit and add a modified optimized build of Firefox to the packages of the new Refracta CD, to be able to log SSL keys upon connections... But it's this posting here refractasnapshot 10.0.0 (arrived) that is in the screencast (6 minutes 17sec):


And so my Qemu install with all the kernel necessities and other accessories can work fine!

And yet, there is no way for me to get Tails to do its work.

The trace is as was taken, non-modified in any way. I would need anywhere from days to weeks or even months of study to figure out from that trace (and the system logs, not included yet, but they seem to be telling...) why it doesn't work: dump_161018_0337_g0n.pcap.

Is it some trivial reason like it was with Devuan images? Or is it something more sinister, like ISP's blocking some traffic?

The network/internet they have very precise rules, and it is inexorably unforgiving, the lack of precise understanding of all the RFC's that set those particular rules: you can't get into it's secrets.

Open that up in Wireshark. You can also use the SSL keys for some non-related bits of conversation with a site that was open in my browser dump_161018_0337_g0n_SSLKEYLOGFILE.txt

Here is the screencast (3 minutes 47sec):


There is also another successful Refracta in Virtual Machine online browsing, but in a separate page (called that page 7th because it's the 7th video, however, there are no pages 1st to 6th), because I think I may need to discuss it with developers.


The files necessary for this study are listed in: ls-1 and verify to: ls-1.sum signed by: ls-1.sum.asc