I have this IPv6 issue with my ADSL. It's kinda bizarre and I'd be interested in whether anyone has any ideas or has seen anything similar themselves.

I don't get IPv6 packets smaller than 71 bytes (excluding the PPP header).

Small IPv4 packets? No problem. Sending small IPv6 packets? Also fine. Getting them back again? No go.

I first noticed the problem because I couldn't get to Google's IPv6 site. I ended up getting some quite useful help from various Google engineers, who were prepared to take my report seriously even though I'm just an end user these days. I've promised to get back to them with what the problem was when I find out. If.

My ADSL is provided by Enta, through a reseller. My parents also use them, but via a different reseller. My understanding is this shouldn't make a difference, as Enta are responsible for terminating the connection in both cases. On my parents' line IPv6 seems to work fine. They have a Linux box with a Conexant based PCI card. I have an AR7 router running OpenWRT. My first thought was that it might be some weird hardware issue, so I dug out my Speedtouch, hooked it up to my laptop and tried that. Still no small packets. I tried a different AR7 ADSL router. I downgraded to a 2.6.16.x kernel (which is what my parents are on). All gave the same results; anything over 70 bytes would get through fine, anything under wouldn't.

So I took my router to my parents'. I unplugged their kit and plugged the router in, with only my laptop attached. I left it configured with my username/password. And it worked. Small packets came though fine. To make absolutely certain I tried the same thing again at home. And it didn't work.

Now. Exactly the same kit at my end in both instances. Exactly the same ISP at the other end (who confirm all their end points are configured identically and even if they're not I'd have expected to get a duff one at my parent's once or twice and a working one at my end given the number of reconnections I've made over the period of trying this all out). That leaves BT as the variable (we're about 100 miles apart, so very different exchanges).

My questions to you, the reader:

• Does this line of logic seem reasonable? If not, what have I missed?
• Have you ever heard of anything similar? I know BT used to have an issue with IPv6 and PPPoE and corruption of the packet length field, but I'm using PPPoA (I've tried PPPoE as well and it wasn't any better).
• Is there an ATM packet sniffer for Linux, along the lines of Wireshark? If I could hook up the Speedtouch to my laptop and try a connection while sniffing the ATM packets I could see if there was any corruption or oddities happening at that level, which might provide a clue.

Update: will-h has pointed out it's 70 bytes excluding the PPP header, not including it.

(Not a great picture as it's taken with my phone, but I think you'll get the rough gist.)

I'd been putting off booking flights for Debconf8 while the house wasn't sold, as I just couldn't justify the money when I wasn't sure what my outgoings would be like. However today I finally got round to booking something, figuring that I either needed to do so now or the prices would go up far too much for me to be able to. My flights are as follows:

This does mean I'm arriving a day early, but it halved the cost of the flights and hopefully paying for an extra night won't cost that much...

Just before the New Year we accepted an offer on our house in Norwich, which had been up for sale since September. It was a bit lower than we'd hoped for, but the buyer was an investor and so we hoped it would be quick and not involve too much hassle.

How wrong we were. We finally completed on Friday, with the money hitting our account today (thanks to the Ulster Bank being a bit shit about telling our solicitor how much was outstanding on the mortgage). I'd become convinced that it was going to fall through, that we wouldn't be able to find a new buyer and that we were going to end up having to rent out a house that it wasn't convenient for us to check up on (due to the radioactive body of water between us and it). So I am somewhat relieved to finally be rid of it.

I've been asked about the v3 DG834G in the past (mine is a v2) and always answered that I don't know anything about it. Earlier this week Ben asked me about it and let me have a login to his. He also took pictures, which are on the OpenWRT DG834G page.

Some comments, based on this:

• The ADAM2 bootloader is different. Looking at the output of strings on it I can't see the checksum message seen in the v2 version. I also can't see the FTP server strings I'd expect. However the default config appears to specify an IP of 169.254.87.1 so it might be worth nmaping that when the router is coming up and seeing if anything is open.
• The wireless card is no longer on a mini PCI card. I assume it's still connected electrically the same way, but I guess this is cheaper for Netgear to manufacture.
• The CPU is slightly different, a TNETD7200ZDW instead of a TNETD7301GDU. No idea if this makes any major difference.
• The board appears to have JTAG and serial port headers easily accessible. And possibly even JTAG for the wifi.

I think it should be easy enough to get OpenWRT up and running on this (possibly someone has even done so already); someone just needs to hook up a serial console and do some prodding.