I've solved this.

Turns out to be a combination of "features" of the DHCP code in the server and the client. The client includes a Vendor Class (empeg:mercury) in the DHCP request. The server (Windows Server 2003) returns a DHCP lease _without_ including option 3, (router / default gateway - I assume it does this because of the presence of a Vendor Class - it shouldn't do according to the specs, but it does). The client, not receiving the expected option 3, uses the really useful default of 0xffffffff. When Slimrio loads, this default causes the IP stack to crash.

Now all I need to do is knock up a utility to provide the correct DHCP response, and coexist with my current DHCP setup and I'll be laughing.

Cheers

Tim