catalyst

Why doesn't hardware have changelogs?

Perhaps I've been using open source software for too long, but I like to scan through the changelogs (a log of changes that the authors have made before releasing a new version) to see what has changed. This can give me hints to new features to checkout, or changed behaviour that it would be helpful to know about.

But hardware (and closed source software) typically don't have changelogs. An example is my Brand New Replaced Under Warranty D-Link DGS-1008D. The old one was hardware revision C3. The new one is C4. What has changed? Will it not brick itself like the old one did after a years usage? Is this one going to be faster because they've improved the code or silicon in some fashion?

I'll never know...

The IPv6 .nz name servers and whois server are now up and running. The announcement from .nz Registry Services sent to NZNOG:

---

NZRS is today pleased to announce that the .nz name servers are now operating
with IPv6 connectivity in what can be regarded as the first phase of the .nz
IPv6 rollout. The name servers are named ns8.dns.net.nz and ns9.dns.net.nz, and
are located in Wellington and Albany repsectively.

Both are connected to the NZ IPv6 Internet Exchange and there is a .nz Whois
server accessible at whois.ipv6.srs.net.nz.

NZRS thanks Open Contributors Corporation for Advanced Internet Development
(OCCAID) and US telco Sprint for providing the IPv6 tunnels, and thanks Citylink
for help in connecting to the NZ IPv6 Internet Exchange.

.nz Registry Services is responsible for the operation of the register of domain
names and the Domain Name System (DNS) in the .nz domain name space.


For further information contact:

support< at >nzrs.net.nz

---

There might be a few more tweaks to the setup, but otherwise, it is looking good.

If anyone is using IPv6 in New Zealand but are not peering with the v6ix then please contact Andrew Ruthven at Catalyst (puck in catalyst.net.nz) to talk about tunnels or other peering arrangements.

Well, it had to happen sometime. I ran the install.sh script included in a tarball (which had to run as root) and it screwed my system.

Running:
chmod -R 775 /$VARIABLE

When $VARIABLE is undefined it does bad things, very bad things. I managed to repair enough of the files to be able to login remotely, and I'm currently going through and reinstalling all the Debian packages on my box, fixing other issues as they arise. It is highly likely this cockup will hang around for years and years to come.

Bug report has been filed.

I'm going to install Xen on this box and do any testing of applications in a clean room which I can just blow away if things go horribly wrong again.

Everybody thinks that running a virus scanner on a Windows box is a good thing, right?

Well, it seems that it can be bad if you want to have working IPv6.

I spent several hours at a customers site yesterday working on IPv6 enabling their Windows XP workstations, but was having issues. I did the usual trick of turning off any and all Windows firewalls and the virus scanner, but we still had issues.

The behaviour was that IPv6 addresses were being allocated, we could ping and tracert6 to IPv6 hosts, we could telnet to port 80 on them, but neither Internet Explorer or Firefox wanted to work. Going to an IPv6 website would cause the browser to just hang. Looking in a network dump I could see an initial connection being made to the server, but then no actual requests.

I decided to blame the virus scanner, on the basis that they quite often interfere with the normal flow of events. Even though it was turned off, it might still be interfering. After actually uninstalling it (and rebooting, uninstalling it caused Internet Explorer to crash), everything worked!

Moral of the story, if you're using a virus scanner (in this case NOD32 from ESET) and you're having issues using IPv6, uninstall the virus scanner!