Computing – Page 21 – More Zonkyness

VirtualBox, Windows Guest Virtual Machines, and The VirtIO Network Interface

Apr 302017

Despite how long I have been running Windows in virtual machines (as far back as Vmware Workstation 1.0), I have never gotten around to looking at the virtio network interface – except for naïvely turning it on once, finding it didn’t work, and turning it off – so I decided to have a look at it. I was prompted to do this by a suggestion that emulating the NIC hardware as opposed to simply using a virtual communications channel to the host would hurt network performance. Good job I chose a long weekend because I ran into a few issues :-

Getting appropriate test tools took a while because most of the tools I know of are very old; I ended up using iperf2 on both the Linux main host and the Windows 10 guest (within the “Windows
The “stable” virtio drivers (also called “NetKVM”) drivers didn’t work. Specifically they could send packets but not receive them (judging from the DORA conversation that was more of a DODO). I installed the “latest” drivers from https://fedoraproject.org/wiki/Windows_Virtio_Drivers. Note to late readers: this was as of 2017-04-30; different versions may offer different results.
Upgrading my ancient Debian Jessie kernel to 4.9 on the off-chance it was a kernel bug turned into a bit of an exercise what with ZFS disappearing after the upgrade, and sorting out the package dependencies to get it re-installed was “interesting” (for small values of course). No data loss though.

I ran two tests :-

sudo nping –tcp -p 445 –count 200 –data-len 1280 ${ip of windows guest) – to judge how reliable the network connection was.
On the Linux host: sudo iperf -p 50001
On the Windows guest (from within the Ubuntu-based environment): sudo iperf -p 50001 -c ${ip of Linux host}

Device	nping result	iperf result
Windows guest (virtual Intel Pro 1000 MT Desktop	1 lost	416 Mbits/sec
Windows guest (virtio)	0 lost	164 Mbits/sec
CuBox running ARM Linux	n/a	425 Mbits/sec

Which is not the result I was expecting. And yes I did repeat the tests a number of times (I’ve cheated and chosen the best numbers for the above table), and no I did not confuse which NIC was configured at the time of the tests nor did I get the tests mixed up. And to those who claim that the use of the Ubuntu environment screwed things up, that appears not to be the case – I repeated the test with a Windows compiled version of iperf with much the same results.

So it seems despite common sense indicating that a NIC “hardware” custom designed for a virtual environment should perform better than an emulation of a hardware NIC, the actual result in this case was the other way around. Except for the nping result which shows the loss of a single packet with the emulated hardware NIC.

Unicode Passwords?

Computing, Security No Responses »

Apr 062017

One of the possibilities when setting a password is to use non-ASCII characters, such as ¨þ¨ (that is a thorn). Well perhaps something a little more secure than just a single character.

But just how sensible is it?

The first thing to bear in mind is that you need to be able to enter the password reliably in all circumstances. A tale from the mists of time: I once set a root password on a Unix machine that included the ¨@¨ character, which normally worked fine but failed on the system console because on that terminal the old Unix tty was still active and ¨@¨ would erase a line, making it impossible to enter the password.

Fortunately I realised what the problem was before it became more than a little annoying.

But the point still remains – if you cannot type a password, you cannot authenticate. So for passwords such as firmware passwords, system encryption passwords, or normal computer account passwords, a password containing Unicode characters is probably a very bad idea.

But for when you have full control over your computer(s), such as for web account passwords, a password containing Unicode characters is worth considering.

So how safe is a password containing a Unicode character anyway? Well, on my usual password cracking machine, john the ripper is unable to crack the password ¨þ¨ in approximately 24 hours. Of course that is a bit of a cheat as john the ripper does not by default check Unicode characters, and if it did it would be able to crack a one character password. But it would take longer; adding Unicode characters increases the space that john the ripper needs to search in order to find your password.

And perhaps more importantly makes it less likely for a password guesser (Hydra for example) to be successful.

So if you normally use a password such as thistlethinthorn, changing it to þistleþinþorn is worth considering. Or indeed changing the separator between words in a multiword password to a Unicode character: thistle☠thin☠thorn, or red¡whistle¡wheel.

Increasing the Size Of HTML Emails In Claws Mail

Computing, Working Notes No Responses »

Apr 032017

Since getting a HiDPI screen, I have been plagued with claws mail merrily doing the right thing with proper emails, but showing HTML emails at a tiny size.

Whilst it doesn’t appear to be a preference you can change in the normal way, there is a zoom variable you can change within the Claws preferences file. Quit claws, and edit ~/.claws-mail/.clawsrc and scroll down through the file until you find the “[Fancy]” section :-

[fancy]
enable_images=1
enable_remote_content=1
enable_scripts=0
enable_plugins=0
open_external=1
zoom_level=100
enable_java=0
enable_proxy=0

Change the “zoom_level” to a suitable percentage (such as 200).

Programming a TiPro in a Virtual Machine (VirtualBox)

Computing, Keyboards No Responses »

Mar 182017

The TiPro programmable keyboards are quite fun for those who are into their keyboards, but with one big problem: the programming tool is Windows only. Well at least if you happen to have a USB-based TiPro; otherwise you need to set up the serial interface as the PS/2 interface is only usable for programming with a 32-bit Windows.

As it turns out, if you try to run it under a virtual machine and assign the USB device of the keyboard to the virtual machine, it still fails – somehow it doesn’t like staying assigned to the virtual machine. However there is a fix for this – using the command-line VirtualBox tools to set up a permanent USB filter.

To assign, first of all determine the name of your virtual machine with :-

VboxManage list vms

Next, add a USB filter – you can normally assign it to “slot” (or index) 1, but you may have to check what slots are available if you already do this :-

VBoxManage usbfilter add 1 --target "W10" --name TiPro --vendorid 0x1222 --productid 0xfaca

Once that is done, the Windows tool should be able to find the keyboard to start programming it. If necessary, reboot the virtual machine or try assigning the USB device via the menu option.

During programming it is helpful to remember than raw USB HID codes can be used by right-clicking in the input field for a key, selecting “Text Input” and inputing the code in the form “/${hex hid code} ${hex hid code}\” – such as “/69 69\” (a list can be found at: http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)

Removal at the end:

VBoxManage usbfilter remove 1 --target "W10"

After the removal it seems that disconnecting and reconnecting the device is necessary for Linux to pick it up (or possibly a udevadm trigger).

How Cloud Services Do Mail Wrong

Computing No Responses »

Feb 272017

Strictly speaking how some cloud services do mail wrong, but whilst it is not all, there are still quite a few that do which is why there are no names contained within this rant.

When you have some cloud-based service send email, it makes sense for the “From” header (i.e. what sensible normal people think of as the sender address) to contain the email address of the person using the cloud-based service.

Fair enough.

But if the real sender address or envelope sender address (which is contained within the SMTP transaction) comprises the email address of the person using the cloud-based service you may well run into problems. Many organisations publish an SPF record in their DNS to indicate what network addresses are approved for, and many mail servers check the envelope sender against the published authorised network addresses.

If the network address used by the cloud service provider does not match what is in the organisation’s SPF record then the recipient’s mail server is free to reject the mail. And they often do.

Now the most obvious “fix” for this is to add the cloud service provider’s network address to the organisation’s SPF record.

The only trouble with that is that it isn’t always possible. There are various limits to how long an SPF record can be so adding addresses to the SPF record recklessly is unwise, and a sensible DNS administrator will only add to the SPF record for important services. So if the cloud service is being evaluated or being used by something less important, or is being used for non-work related purposes, then it likely won’t meet the “important enough to get added to the SPF record” criteria.

So why not fix the source of the problem?

All that has to be done is to use a different address for the envelope sender, and you can even arrange things to send bounces back to the right place.

Set the envelope sender to something like “customer+${original email}@${cloud service address}” (obviously when replacing the ${original email} you will have to change the “@” sign to something reversible). All of a sudden you are no longer “forging” the envelope sender, and not tripping over anyone’s spam defences.

Process the bounces to “customer@${cloud service address}” and you can send the bounces to the right place.

Older Entries Newer Entries