I’ve been writing a static library that uses multicast for work over the past few days. Today I wanted to statically link in the winsock calls to my library so that the user themselves didn’t have to include winsock.

After specifying Ws2_32.lib as a dependancy my program started failing when it tried to join a multicast group. I narrowed it down to the following call:

int joinResult = ::setsockopt( nativeSocket,
                               IPPROTO_IP,
                               IP_ADD_MEMBERSHIP,
                               (char*)&joinRequest,
                               sizeof(joinRequest );

The call was returning with SOCKET_ERROR, and a call to ::WSAGetLastError() returned WSAENOPROTOOPT (Bad protocol option)

After a lot of soul searching and trawling through code I found that the issue occurs when you explicitly specify to link ws2_32.lib. By default it seems that if the dependency is not set, Windows will choose to use winsock.lib instead, which performs the join operation without any issues.

The resolution was to instead specify winsock.lib as a link dependency rather than Ws2_32.lib. After this change, I’m happy to report that everything is now working fine again.

Here’s a brief article on how to setup and use your scanner from the command line.

I currently have a HP Deskjet F300 all in one printer/scanner connected to my ubuntu server. While network machines can access the printer half of the device through CUPS/Samba, I’ve traditionally had to unplug it from the server and plug it into my laptop to use the scanner.

So I did a bit of research and have figured out how to scan from the command line, which means I can just ssh in, execute the appropriate command and retrieve the resulting image from the samba share on my laptop.

The technology is based around the SANE (Scanner Access Now Easy) library, and its very, very simple to get working on Ubuntu.

Here are the steps:

1. Install SANE

From the command line, execute the following command:

$ sudo apt-get install sane sane-utils

2. See if SANE recognises any of your scanning devices

From the command line, execute the following command:

$ sudo scanimage -L

The resulting output should be something like:

device `hpaio:/usb/Deskjet_F300_series?serial=CN68FGJ10Q04KH' is a Hewlett-Packard Deskjet_F300_series all-in-one

If no scanner devices are detected, you may need to install the relevant drivers to support your particular hardware.

3. Add users to the ‘lp’ group

To access the scanner as an ordinary user, you must be a member of the ‘lp’ group. To make yourself a member, execute the following command:

$ sudo gpasswd -a username lp

Then log out/log in and you should now have user level access to the scanner. Try running scanimage -L without the sudo qualifier to test this.

4. Scan an image

To scan an image, execute the following command

$ scanimage --format=tiff > scannedImage.tiff

As always check the scanimage man page for more options!

Just had an interesting situation where we were unable to start a Swing application under Windows while an OpenGL app was currently running in fullscreen. The symptoms were a JVM crash, citing a null pointer exception (Exception Code: c0000005) in java.dll.

After some research we found that for some environments, the JVM may choose to use a Direct3D pipeline for its 2D drawings. It seems that internally the JVM maybe trying to initialise Direct3D, but unable to get hold of a context as it is already reserved for OpenGLs use in fullscreen.

To overcome this, you can prevent the JVM from using the Direct3D pipeline by either:

• Specifying the JVM argument -Dsun.java2d.d3d=false
• Setting the environment variable J2D_D3D=false

After making this change, the Swing app was able to start behind the scenes while the OpenGL app was running in fullscreen.

For more information on how you can configure the behavior Java2D, check out the official System Properties for Java2D at http://download.oracle.com/javase/1.5.0/docs/guide/2d/flags.html

Just blogging this in case to avoid anyone else having the same hair pulling experience that I’ve had for the day.

I was recently asked by a friend to put together a machine for stock trading. The main feature was that the computer had to support 8 displays (for tracking market charts and news etc).

In the end we went with an ASUS P8H67-V motherboard as it supported PCI-Express and 3 standard PCI slots.

The Graphics cards we got were:

• 1x Radeon HD6450 (PCI-E)
• 3x Radeon HD5450 (PCI)

Anyway we plugged in the PCI-E card and everything worked fine. Howver, we then plugged in the PCI card and the machine refused to post, displaying nothing on the monitor. Unplugged the PCI-E card so that only the PCI was left, and still nothing.

After a lot of fluffing around, I got the latest BIOS update (v0712) from ASUS (http://www.asus.com.au/Motherboards/Intel_Socket_1155/P8H67V/#download) and applied it using their BIOS flash utility.

Happy to report now that everything is working fine.

Short Version: In order to run PCI graphics cards on the ASUS P8H67-V motherboard you need to flash the BIOS to the latest version.

One thing I always forget and have to look up is the command syntax for dd that enables you to make an ISO image of a CD/DVD. In the end, it’s a really simple process, it just keeps popping out of my head because I rarely use it :)

Anyway, the syntax is:

$ dd if=/dev/cdrom of=image.iso

Where the parameter:

• if is the device (file) of the CD/DVD you want to make the image of
• of is the target file where the resulting iso will be stored

The one caveat is that the device denoted by the if parameter must be unmounted before you call dd.

Every now and then it seems that Comedy Central/MTV/Viacom/The Empire decides for whatever reason that The Daily Show/Colbert Report full episodes shouldn’t be available to anyone outside the US.

It seems that the system is doing some basic IP inspection and denying the service to anyone that does not have an IP address assigned to the US. One solution is to use a proxy server, however the performance hit is usually significant and it affects the rest of your browsing experience.

A more ideal solution is to add a forwarding header to your HTTP request to make the remote system think that your machine is actually a proxy forwarding a request originating in the US. Modifying the HTTP headers that Firefox sends out can be achieved through the Modify Headers addon

To set it up:

1. Download/Install Modify Headers from (https://addons.mozilla.org/en-US/firefox/addon/modify-headers/)
2. Select Tools | Modify Headers from Firefox’s main menu to display the Modify Headers ui
3. Click on the Selection action combo box and select the Add option
4. In the Header name text field type X-Forwarded-For
5. In the Header value text field type a US IP Address (eg 11.1.1.1)
6. Press the Add button to add the rule
7. Dismiss the Modify Headers UI, navigate to The Daily Show website and enjoy :)

Acknowledgements:

Phat props to saiftk (http://www.reddit.com/r/canada/comments/8zjv7/instructions_on_how_to_watch_thedailyshowcom/) and Samy (http://samysnotes.wordpress.com/2011/02/13/accessing-the-daily-show-streams-from-outside-the-us/) for their previous guides on how to do this.

I recently had to set up a home office and wanted to maintain a separate network that used a dedicated server machine as a gateway. The server would also provide DHCP/DNS services to the work network.

The setup is as follows:

The server machine, named “Nibbler” is running Ubuntu Natty (server) and has both wired ethernet interface “eth0” and wireless network interface “wlan0”. Nibbler connects to the work network through eth0 and to the internet (via the home network) wirelessly through wlan0.

Note: My home office is in a different room to the rest of my computer setup at home and we have no cables running through the wall, hence the wireless router :)

To set up the bridge I created the following iptables script under /etc/iptables.sav

*mangle
:PREROUTING ACCEPT [1661:128402]
:INPUT ACCEPT [1586:123941]
:FORWARD ACCEPT [34:1860]
:OUTPUT ACCEPT [1093:112966]
:POSTROUTING ACCEPT [1114:115726]
COMMIT

*nat
:PREROUTING ACCEPT [7069:621197]
:OUTPUT ACCEPT [312:68686]
:POSTROUTING ACCEPT [131:32808]
-A POSTROUTING -o wlan0 -j MASQUERADE
-A POSTROUTING -j MASQUERADE
COMMIT

*filter
:INPUT ACCEPT [2520:198290]
:FORWARD DROP [85:4188]
:OUTPUT ACCEPT [1744:176962]
-A FORWARD -s 192.168.2.0/24 -i eth0 -o wlan0 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT

Then added the following line into /etc/rc.local (before the line ‘exit 0’)

iptables-restore < /etc/iptables.sav

The final step is to enable ip4 forwarding in the kernel. This is done by uncommenting the following line in /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

Then apply the kernel parameter changes by executing the following

$ sudo sysctl -p

And that’s it! Traffic is now forwarded from the network to the internet via the server’s wireless link.

Note: I found that after an Ubuntu release upgrade, the net.ipv4.ip_forward setting in sysctl.conf was recommented. If your kernel or sysctl.conf is modified as a result of an upgrade, you’ll probably need to re-uncomment it.