Sunrise Road

I’m having a weird problem with irssi and IPv6. The long and the short of it is that irssi is trying to connect to an IRC server on the Internet with a source IP address of ::1, which is incorrect, as ::1 is the loopback address.

My server, glenstorm, is the IPv6 router, which contains the ppp0 interface that connects it to the IPv6 Internet. I am also running irssi on the same machine. It’s a router, so /proc/sys/net/ipv6/conf/all/forwarding is 1.

So, basically, when I fire up irssi, and type “/connect irc.ipv6.freenode.net“, it hangs when connecting. And for good reason: here’s the (edited for clarity) tcpdump output:

IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667

So obviously that’s wrong. And in violation of RFC 4291, I might add (“The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node.”).

I can hack around it by typing “/connect -host 2001:44b8:7df3:b970::14 irc.ipv6.freenode.net” into irssi, which forces it to use the source IP that I specified. But that’s just a hack — I’d like to get to the bottom of what actually causes it.

Update: Finally solved this. It’s because in my irssi config, I had the following directive:

core = {
    real_name = "Jeremy Visser";
    user_name = "jeremy";
    nick = "jayvee_zzZZ";
    resolve_prefer_ipv6 = "yes";
    host = "glenstorm";
};

It was being told to use “glenstorm” as the “host”, which translates to “resolve the IP address of glenstorm and use that as the source IP address” (I think I misunderstood the meaning of the directive when I put that configuration flag in).

Of course, in /etc/hosts, I had the following entry:

::1 glenstorm

So, naturally, irssi decided to use ::1 as the source IP address. So removing the “host” line from the irssi config fixed the problem. While I’m sure that because of the aforementioned RFC, that shouldn’t have resulted in the subsequent symptoms, at the end of the day, it was simply Unix allowing me to shoot myself in the foot.

You may have seen the workaround I presented to Python-iView users who wanted MP4 support, and wanted it now.

Also, (this has probably got to be the biggest duh moment for me in a year) I discovered Python-iView actually didn’t support those of you who use Akamai-based servers with iView. This includes all users who don’t have iView unmetered, as well as iiNet users. Sorry about that!

Well, now, if you type bzr pull, both MP4 and Akamai support work beautifully.

One thing to keep in mind is that the iview-cli programme has been changed to print out .flv and .mp4 extensions, which you mustn’t strip off when you paste it on to iview-cli --download. This is so it knows which version to ask for. No, they are not interchangeable — keep it what it prints out. (iview-gtk users don’t have to worry about any of this.)

Now all I need is Save dialog support for iview-gtk, and to package it up in .deb and .rpm formats, and it’ll take over the world! Oh, category support would be nice too.

I’ve updated Python-iView to support the latest iView version, 316. To get the latest update, change to your python-iview directory, and type:

$ bzr pull

In this update:

• New programme API supported, which permits faster loading times.
• The entire programme is no longer loaded. Instead, the individual series are loaded when you select them in the GTK+ interface, making for faster startup times.
• SWF verification keys updated.
• RC4–encrypted programmes supported (was required in version 306, though subsequently disabled by the ABC again and made unnecessary).

Here is a roadmap for what I would like to achieve in the next couple of releases:

• GIO–based saving (e.g. so you can save into an SFTP share).
• Ability to run from read-only system directory (the previous point is a prerequisite for this), and packaged into .deb or .rpm format for easy installation.
• Category browsing, thumbnail display, and metadata such as ratings, duration, size, etc.

Python-iView users are invited to update their setups to support the latest JSON–based index the ABC pushed yesterday. The index is in a more compact format, which means that loading the GTK+ interface should be faster for you.

Not only that, but the ABC have cleaned up all their blank programmes from the index, which should make picking and choosing something to watch.

Without further ado, here is the usual to get you to the latest version:

$ bzr pull

This latest update requires the use of the json module, which is only available for Python 2.6 users. I fall back to the user of simplejson if json is not available, so you may need to install the module manually (either from the simplejson website, or from your distribution’s package manager, e.g. python-simplejson for Debian or Ubuntu) if you use Python 2.5.

The past week I’ve been watching the Australian Open. It’s been really awesome to watch, and that’s coming from someone who is normally bored stiff of just about any form of sport.

But one thing struck me over and over again: the Bunnings ads had horrible MPEG rendering artifacts at the end of each one. At first I thought it was due to poor reception, but this weekend we completely re-wired our house’s coax connections with quad-shielded cabling to our TV antenna and bought a new masthead amplifier, which greatly increased our signal quality.

(And no, we didn’t replace it just to watch the Bunnings ads.)

But this remained:

Yuck. That is definitely not signal loss — that’s crappy encoding. I can give people a (non-reencoded) AVI file of the original if they want proof.

I think it’s mainly a result of the fact that the ad is being rendered at 1080i with the outdated MPEG-2 codec. We desperately need an upgrade to H.264, or even better, Dirac.

G’day Python-iView’ers. As you might know, the ABC has been transitioning to MP4 (with H.264 video) for a lot of their videos.

iview-gtk doesn’t yet support it, but here’s how to do it with iview-cli. First, find an MP4 video:

$ ./iview-cli --programme
[...]
Compass Series 23:
	Compass Series 23 Episode 47	(compass_09_23_47.mp4)
[...]

Then, download it like so:

$ ./iview-cli --download mp4:compass_09_23_47

So, basically, strip the .mp4 off the end, and add mp4: at the beginning.

The pattern seems to be slightly inconsistent, so I haven’t been able to code up something to do it automatically, but once I figure it out, I’ll make it all automagic for you. This is just something to use in the meantime.

Hope this helps.

Well, it’s official. Conroy and the DBCDE (hey, that could be the name of a band!) have released the results of the much-debated Clean Feed.

From the pretty performance graphs in the report, the filter doesn’t appear to be performing too badly. Implemented correctly, this filter could be put to use without a major impact on performance. However, that’s missing the point!

The point being that with the filter in place, it is basically equivalent to being wiretapped all day every day. Wiretapping in itself is not bad — it is sometimes plays an important role in solving crimes, or thwarting conspiracies. However, all wiretapping to date requires prior evidence of criminal activity, and a warrant is needed to perform it.

This “clean feed” is effectively wiretapping without a warrant. In other words, treating the general public like criminals. Guilty until proven innocent.

Once you establish that, how well the filter performs is a moot point. Admittedly, it is entirely possible BGP will be used so that only certain websites will be run through the filter (i.e. selective proxy). However, there is no guarantee that this technique will be used, and it is only a technical difference — the legislation to implement would be exactly the same. So the government could effectively change at will to monitoring all web traffic.

One quote I found interesting from the report:

Telstra reported that heavy traffic sites could overload its trial filtering solution if included in the filtering blacklist. This is also the case for all filters presented in the pilot.

So basically they are admitting the filter will be vulnerable to denial-of-service attacks. This could be exploited by criminals around the world with access to large botnets. Not only that, but a large amount of personal information is still transmitted over HTTP. Though unencrypted, the links between me and the website I am exchanging with are largely trusted. However, putting a filter in the middle that is explicitly designed to read the information suddenly makes the situation far scarier.

I also found no mention of IPv6 in the report. Because the trial has been reported to depend heavily on proprietary software, no mention of IPv6 is made, and of which it is common knowledge that proprietary software is more often than not lagging behind in cutting edge technologies, it is entirely likely that the filter will: (a) possibly hinder IPv6 adoption by ISPs, (b) cut off access to IPv6–enabled sites, or (c) be ineffective at blocking sites that are accessible via IPv6.

Today, I noticed while I was using Google today (which is a website some of you may of heard of), and I noticed they jazzed up where the URL is normally listed:

I don’t know whether to puke or have a seizure. I liked having the URL there. But then again, the URL is meaningless to 99% of users, because people like to put their head in the sand and create absolutely useless URLs. I’m looking at you, Dell and HP. And a whole lot more.

So yeah, probably a usability improvement. And you can click on the little segments. Personally I don’t like it, but that’s ’cause I’m a power user that looks at URLs. And if I really want to, I can always just hover over the link to get the URL anyway.

I wonder how it works. XML Sitemaps, maybe?

Update: Google has written about it. Looks like they analyse anything that looks like breadcrumbs. Too bad it’s not standardised, and they don’t actually tell you how to do it.

I’m headed to Myall Lakes on a canoeing trip with our youth group. Should be wild, hopefully not wet, but hopefully fun.

Here’s hoping the Internets don’t break while I’m AFK. Until then, adiós, weird world.

On Friday the 6th, Internode went public with the announcement of a native IPv6 trial for their customers. As a fan of IPv6, I’m particularly excited about this, especially seeing as though now Internode is the first ISP in Australia to offer native IPv6 (albeit in an opt-in trial form) to its residential customers.

I’m not going to bore you with details or a dodgy rehash, so I will instead invite you to read the announcement and the IPv6 ADSL Trial pages for yourself.

For those that like to dive in head-first without checking the depth or for the presence of sharp rocks, you can opt-in by changing the @internode.on.net part of your PPP username to @ipv6.internode.on.net.

I got it working on my own connection, and I am very impressed with the performance. The speed of my IPv6 connection is now no slower than my IPv4 connection (unlike connections that use tunnels to get v6 connectivity), and all users are allocated a static /60 subnet, which is absolutely the right way to implement it, in my opinion.

Internode supports up to 4 concurrent PPPoE connections on a single ADSL line, which is handy to know for testing. You can have your IPv4-only “production” connection, and a second IPv6-enabled “experimental” connection that you can play with and not worry about disrupting family members if it breaks. :)