techblog 

Wireshark is a free, open source network protocol analyzer. It can be used as a graphical interface when viewing tcpdump files. Alternatively, it can be used to capture live network traffic. For this, it must be able to read raw data from network interfaces. Using the standard install from DMG package under Mac OS X this is not straightforward.

By default the /dev/bpf* interfaces are owned by root with permissions set to rw-------. They can be opened for reading using sudo chmod go+r /dev/bpf*, but this is not persistent across reboots. To permanently ensure that Wireshark can be used in capture mode it is necessary to run this command on start up. The mechanism to do this is explained here. I made a slight modification to the ChmodBPF script to run the command above. The gzipped file is attached. Simply unzip this and put it in /Library/StartupItems.

I recently upgraded my OS X Java development environment to
the Java SE 6 Developer Preview 9 release. After the upgrade I encountered the following error when running code which relied upon the AWT libraries:

seventh-circle$ java AWTExample
2008-04-24 12:15:12.061 java[1035:10b] Apple AWT Startup Exception : *** -[NSCFArray insertObject:atIndex:]: attempt to insert nil
2008-04-24 12:15:12.087 java[1035:10b] Apple AWT Restarting Native Event Thread


Ugoogalizing the stack trace indicated this was a rare but not unknown problem, with no obvious solution. A known unknown, if you will.

After blaming everyone else I retraced my steps and realised that I had changed the CurrentJDK and Current symlinks in /System/Library/Frameworks/JavaVM.framework/Versions to point at 1.6, in a misguided attempt to make this the default version of Java for the shell. Specifically by repointing the Current symlink from A to 1.6 I had broken the Java Native Foundation framework. I reset the symlink and chalked the lost hours up to the arrogance of youth:

cd /System/Library/Frameworks/JavaVM.framework/Versions
sudo rm Current
sudo ln -s A Current

In summary, if you want to change the default version of Java to 1.6 for a command line process on OS X, I’d recommend using the Java Preferences Application. If you want to be sure add the following to your .bash_profile:

JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH


After upgrading to Lotus Notes 8 on my Windows XP PC I found that I could not send emails. I eventually discovered that the problem was caused by PGP Desktop.

When attempting to send an email, Lotus Notes provided the following, typically cryptic, message:

Operation stopped at your request: mail.box

The problem is caused by these two lines being present in the Lotus Notes notes.ini file:

EXTMGR_ADDINS=nPgpOvid.dll
NSF_HOOKS=nPgpOvid.dll

The lines are inserted each time I start PGP Desktop 9.7. This is despite the fact that, within PGP Desktop, in Tools -> Options -> Messaging, I have not selected “Secure Email” and, in Tools -> Options -> Notifier, I have not selected “Use PGP Notifier”.

Removing the two lines shown above from notes.ini and restarting Lotus Notes solved the problem. Unfortunately this is really a workaround rather than a proper fix.

I wanted to connect a (fairly old) laptop running Windows XP to my home wireless router the other day. With WEP discredited, I have the security on the router set to WPA2. Since the laptop doesn’t have inbuilt WPA2 support, I bought a new WPA2 wireless LAN adapter. After installing the the accompanying software and plugging in the adapter to one of the USB sockets, I tried to set up the connection - and failed. When I scanned for wireless networks, the network was visible, but nothing I did could persuade the laptop join it.

An email to the manufacturer’s support desk brought the answer. Windows XP doesn’t have WPA2 support included by default. To enable it, you must install the KB893357 update. Once I did that, I connected with no further problems.

For any number of reasons, you may find yourself wanting to create only part of a Spring context without satisfying all of its @Required dependencies (and their dependencies, and their dependencies’ dependencies…) with real objects:

• Reducing the number of Spring beans your integration tests need can drastically speed up your unit tests, since Spring container startup can take a while and consume a lot of heap space.
• In my case I wanted to write an integration test that only needed a thin vertical slice of beans to get Hibernate working, without the (rather large number of) other beans in the rest of the context definition.

In conventional unit testing, this is easy: you use mocks or stubs at the boundaries of your test objects. Why not extend this to Spring beans?

By rejigging some import statements, I was able to use Spring’s instance-factory bean declarations and dynamic mocking to do just that. The process has two parts: creating the factory class, and declaring the stub beans…

Creating the factory

package uk.nominet.testing;
 
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;
 
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
 
/**
 * Stub spring bean factory class. Call createStubBean("classname") to stub out a bean.
 */
public class StubBeanFactory
{
    /**
     * Factory method to create stub beans.
     * @param className to create a stub bean for.
     * @return stub bean.
     * @throws ClassNotFoundException if className doesn't match a real class.
     */
    @SuppressWarnings("Unchecked")
    public <t> T createStubBean(String className) throws ClassNotFoundException
    {
        // get the class to proxy
        Class</t><t> proxyClass = (Class</t><t>)Class.forName(className);
 
        // the specifics of proxy creation depend upon whether we need to proxy a class
        // or an interface - which is it?
 
        if (proxyClass.isInterface())
        {
            // proxying interfaces is easy with the standard java proxying classes
            return (T)Proxy.newProxyInstance(proxyClass.getClassLoader(),
                                             new Class[]{proxyClass},
                                             new StubMethodHandler());
        }
        else
        {
            // proxying classes requires some cglib magic...
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(proxyClass);
            enhancer.setCallback(new StubMethodHandler());
            return (T)enhancer.create();
        }
    }
 
    /**
     * Helper class to handle method invocations on stub beans.
     */
    private static class StubMethodHandler implements InvocationHandler, MethodInterceptor
    {
        /**
         * @see InvocationHandler#invoke(Object, Method, Object[])
         */
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
        {
            // you could put some logging here...
        }
 
        /**
         * @see MethodInterceptor#intercept(Object, Method, Object[], MethodProxy)
         */
        public Object intercept(Object o,
        			Method method,
				Object[] objects,
				MethodProxy methodProxy) throws Throwable
        {
            // you could put some logging here...
        }
    }
}
</t>

Creating stub beans

Stubbing out a spring bean is simply a case of creating and using the factory:

<beans>
    ...
    <!-- this is our stub bean factory -->
    <bean id="stubBeanFactory" class="uk.nominet.testing.StubBeanFactory"></bean>
 
    <!-- stubbing out either interfaces or classes is exactly the
         same - just call the factory -->
    <bean id="tokenDao">
</bean>          factory-bean="stubBeanFactory"
          factory-method="createStubBean"&gt;
        <constructor -arg value="uk.nominet.authentication.TokenDao">
    </constructor>
    ...
</beans>

What’s the point?

By stubbing out the unneeded beans:

• the number of beans in the testing context was reduced from nearly 400 to less than 40;
• the running time for the integration test was reduced from 40 seconds to 10 seconds.

The second point here is key - faster tests leads to tests that get run at all…

Last year, Duane Wessels published some maps of the IPv4 address space. These were static maps containing one dimensional IPv4 addresses plotted along a 12th order Hilbert curve, resulting in a two dimensional “heatmap”.

In these maps, consecutive networks are grouped nicely together. However, trying to orientate in the map is hard. This is due to the stringent locality preserving properties of hilbert curves. Since we only need to group networks together that share the same prefix, I looked for a curve that has better orientation at the cost of less locality preserving properties. A Morton curve, or Z-order curve does exactly that.

Every pixel represents a /24 network. To cover the entire IPv4 address space, the size of a map is 4096 x 4096 pixes. If this is plotted in three dimensions, the map would be 256 x 256 x 256 pixels.

I’ve created a proof of concept tool to view these three dimensional IPv4 maps. The input is a file with IPv4 addresses, one per line. There are many controls to orientate the cube, select address blocks, highlight problem parts, change focus, zooming, etc.

A few examples:

The 3d image above represents open resolvers on the internet. The more open resolvers per /24, the hotter the color.

The 3d image above shows a small detail of the internet. It shows the open resolvers in 64.0.0.0/8.

Though the data source for the proof of concept was a list of open resolvers, the uses for this vizualizing technique are numerous. The software is available here. Let me know if you’ve created any nice imagery with it.

I gave a presentation about this at the 70th IETF

Having been brought up on C# and .Net, Java enumerations are a breath of fresh air - you can do all sorts of fun stuff like give them methods and properties like any other object. Well, almost.

I’ve been writing some code to interact with a payments system. The rules as to whether specific types of payments can be taken are rather procedural, and so don’t instantly lend them to OO’s usual easy encapsulation. Typically I’d end up writing something like this:

public enum ProductType { SHOES, SOCKS, SHIRTS; }
 
public static boolean isBuyable(ProductType product, Account payeeAccount)
{
    // nasty procedural rules and switch statements to 
    // determine whether things are buyable for the given account...
    switch (product)
    {
        case SHOES:  /* ... */ break;
        case SOCKS:  /* ... */ break;
        case SHIRTS: /* ... */ break;
        default:
            // panic! someone added an enum instance 
            // without updating the business process!
            throw new PanicException("run!");
    }
}

This time I thought I’d try putting the rules about product types on the product type itself. Easy enough in Java: stick an abstract method on the enum instances and let them do their own work:

public enum ProductType
{
    SOCKS
    {
        @Override
        public boolean isBuyable(Account payeeAccount)
        {
            // rules about sock availability only
        }
    },
 
    // other product types go here, each looking after its own rules
    // and only its own rules:
 
    SHOES  { /* ... */ },
    SHIRTS { /* ... */ };
 
    // abstract base method for all enum instances in the group
    public abstract boolean isBuyable(Account payeeAccount);
}
 
// the nasty method previously required could then be reimplemented easily:
public static boolean isBuyable(ProductType product, Account payeeAccount)
{
    return product.isBuyable(payeeAccount);
}

The advantages of this approach include:

• Business rules are ‘close to’ the objects they concern. In this case I could have written a method like isBuyable(ProductType) on the account object, but the payments logic is naturally separate from the rest of the system, and this approach keeps it that way.
• Business rules for the availability of specific products are cleanly separated - each product only has to manage its own rules.
• There are no switch statements (the equivalent for enums of the dreaded instanceof for objects) and the associated PanicExceptions.
• It’s just not possible to add enumerated instances that don’t respect the business rules - that abstract prevents their compilation…

Unfortunately, having instance methods on enums breaks their serialisability. Or at least it does with our combination of Hessian and Java for remoting - I’ve not tracked down the precise cause. My first thought was that enum deserialisation was using reflective instantiation under the hood, so I removed the abstract keyword from the root declaration of isBuyable, but no such luck.

A quick refactor put each enumerated instance’s business logic into a discrete interface implementation, but this slightly bloats an otherwise neat solution to the problem. Reality trumps design once again…

One of my colleagues has already blogged about getting IRIS Explorer running on 64-bit Ubuntu 7.10.

A rather trickier problem that had to be solved first was getting X11 working reliably with the official NVidia drivers for his Quadro FX 3500 graphics card.

On first downloading and installing the drivers as per the NVidia instructions everything worked as expected. However on starting the machine up next morning X11 would only start in 800×600 resolution and wouldn’t run in Twinview (aka “Dual Head”) mode. At this point I was called in to help.

Installing the drivers again got X11 working again, but only until the next reboot. Looking at the list of loaded modules (with lsmod) I could see that an NVidia driver was loaded, but there was no explanation for why it wouldn’t work. Eventually, having run the driver installation process yet again again I noticed that according to lsmod the working driver appeared to be taking ~12MB of memory, whereas the non-working driver only used 8MB. Could it be that there were two different drivers?

I then verified (by looking at dmesg output) that there did indeed appear to be two different drivers - the non-working driver was actually being loaded into the kernel at boot-time, before any of the rest of the OS had been started. It seems that the boot image for starting the system has an NVidia driver built-in which is being used to support Ubuntu’s flashy boot screens!

I found that simply unloading the boot-time driver and loading the official driver (rmmod nvidia; modprobe nvidia) was sufficient to get X11 working again.

For now then, the work around is simple - in /etc/rc.local we’ve just put in:
/sbin/rmmod nvidia


This ensures that the boot-time driver is unloaded before any user programs are started. When X11 starts the module loader then automatically loads the correct driver and everything works as expected!