|Sound Blaster Z preventing sleep||Saturday 16th February 2013|
Since installing my Creative SoundBlaster Z, I've noticed that my computer won't go into sleep automatically.|
This seems to be caused by using Dolby Digital Live (DDL) or DTS Connect. Both these technologies work by taking the audio going to the driver and encoding it into a surround sound digital stream for a receiver. It's constantly running, so there is always a stream open. Windows interprets this as there is music playing, so doesn't allow the system to sleep.
There is a workaround though, which applies to all Creative Sound cards.
Using a privileged command prompt, you can use the powercfg command:
powercfg -requestswill show what is currently blocking any sleeping. You'll see the sound card listed here, for example, mine is
SYSTEM:To ignore this driver, you can use the following command:
[DRIVER] Sound Blaster Z (HDAUDIOFUNC_01&VEN_1102&DEV_0011&SUBSYS_11020023&REV_10095&25018f92&0&0101)
An audio stream is currently in use.
powercfg -requestsoverride DRIVER "Sound Blaster Z" SYSTEM.
Your system should now be able to sleep peacefully!
|Opera mail||Monday 11th February 2013|
A fresh operating system install always provides a good chance to try alternative software to whatever one has been stuck using previously.|
Previously I was running a Firefox and Thunderbird combo for web/mail. Although I have become disillusioned recently due to the heavy memory footprint and sluggishness of Firefox. On my main PC I have reverted to SeaMonkey (the original star of the Mozilla project until Firefox got the lime-light). It is far faster, but not quite as snazzy - a compromise that I think I'll be able to live with.
On another computer though I thought I'd take a step away from my clear Mozilla fandom and try something else. Opera is a long-standing browser and mail suite that has long been loved by many but never made it to the populate mainstream. Being the underdog then, gives ample reason to support it. It has a slick interface and runs seemingly quickly - but to be honest, browsers are all fairly similar these days. The real test comes from how good it handles mail.
Opera mail gives you the standard mail view by default along with some useful and easy to use filters for finding and organising your mail. It is more accessible than Thunderbird's quick search bar but lacks the ability to combine filters, so more complex searches get complex quickly (e.g. attachments with a certain tag/label). Unfortunately my whole experience falls flat by the lack of support of a core technology: LDAP. LDAP is the de-facto method for storing contact information in a central server - even Microsoft has made Active Directory compatible with it. In fact, there is no support at all in Opera for a centralised address book - meaning if you use mail from more than one device, you'll have to enter in all your contacts multiple times. Searching around the net suggests that this feature has long been asked for but has never surfaced. So whilst I've enjoyed using Opera I'm afraid I'm going to have to return to my Mozilla combo.
|Windows 2012 - Intel HD Graphics driver||Friday 8th February 2013|
I've just installed Windows 2012 Server onto a new workstation and started installing drivers. I dislike muchly low resolution, so graphics is one of the first things I do.|
When attempting to install the latest (15.28) Intel HD 4000 Graphics driver I receive the error:
"An error occurred while registering one or more components.
Setup will exit."
Looking at the progress screen of the installer, you can see the last step to run was
"Registering DLL: C:\Program Files (x86)\Intel\Media SDK\mfx_mfg_h264ve_32.dll"
h.264 is a video codec - and as we know, server's aren't really geared towards video consumption. So this leads us to the solution.
You need to install the "Desktop Experience" feature, which is a part of the "User Interfaces and Infrastructure" feature on Windows Add Roles and Features Wizard (from the Server Manager). Install this, bounce the box and try the driver install again.
|SNAT confusion||Sunday 3rd February 2013|
I have recently setup a SixXS IPv6 tunnel as my ISP only provides IPv4 currently.|
Having a static IP address I have opted for a static tunnel to be configured - this works great until my Internet connection gets interrupted. The tunnel then disappears for an indeterminate period of time, eventually coming up sometimes many hours later.
I wasn't entirely sure if there was any "initiation" that needed to be done to get a tunnel to wake up, but some investigation showed that a tunnel is dumb - the packets just flow to the parent address, there is no establishing of a connection or such (like you would with a SSL VPN tunnel or similar).
So the question I was presented with was why were my dumb packets not getting to the other end of the tunnel?
After some time filtering out the chaff from tcpdump I could see that my packets were leaving my network with the incorrect IP4 address. How does this happen? For most people, it won't, but I have multiple IP4 addresses (might be worth something one day, right?) and my tunnel is configured against a non-default one or, a virtual interface on my router.
Whilst I had already setup a DNAT (aka forwarding) for the inbound tunnel data, I hadn't setup an outgoing SNAT rule. This meant that when data came in from my PoP (tunnel provider) it would setup ok - but if I tried to send data out first then it would attempt to setup a connection from the default address on the router. iptables (the Linux firewall) doesn't allow you to bind to virtual/alias interfaces (e.g. eth0:1), so instead you just have to hard-code the external address you want to use (PITA):
iptables -t nat -I POSTROUTING -o eth0 -p 41 -j SNAT --to-source XXX.XXX.XXX.XXXWhere the X's is the external IP address you wish to use (and replace eth0 with your external interface device).
Alas, whilst this command was the correct one, alone it did not work for me. Thanks to some help from #ipv6 on Freenode I discovered that the outgoing connection was already getting established before I could type in my new SNAT command. As such all outgoing data for this was on the default address. This is because the NAT table is only used initially on NEW connections, everything else follows the established configuration. To view this, you can search for "unknown" in your connection tracking file:
grep "unknown" /proc/self/net/ip_conntrackThis lists your current NATs. In my case I found that for protocol 41 (IPv6 tunnels) there was already one established on the default address.
By adding in the new SNAT rule into my firewall startup script, the command was in place before any such connections could be established and everything suddenly started to work.