Month: June 2025

Like Mikrotik but don’t speak Mikrotik CLI eh? I’m with ya.

I took advantage of a deal and joined Sky for broadband. I’ll spare you the details, but even though they don’t offer fixed price contracts, the fact that they don’t use PPPoE and the generous new customer offer swayed me, and I think over the length of the contract, it works out cheaper than my previous provider.

This post was helpful in convincing me that it was possible to use my own router since I really don’t want the disruption of having to reconfigure my entire home network, which is filled with smart devices that don’t have great interfaces for updating connection settings. I extracted my username and password using wireshark, even though it’s argued that it’s not necessary — better to have the real credentials, since it’s straightforward to capture them.

You should go read that blog post if you don’t yet have IPv4 internet access from Sky over your Mikrotik. Think of this post as as a supplement that covers only IPv6 connectivity.

Only the clientid – option 61 appears to be required, and you set that to the same value as described in the linked blog post above. Request ‘prefix’ only, and choose a name for the pool and set prefix length to 56 — see screenshot.

On the advanced tab, I simply selected that it should send the clientid option:

That was enough to get a prefix bound within a few seconds. The prefixes seem to renew every hour, but as far as I can tell, the prefix has not changed since it was first acquired.

The final piece of the puzzle is to assign an IPv6 address on your “bridge” (LAN). This means you go to the IPv6 > Addresses and create a new address. On my router whose model is irrelevant, ether1 is designated as my WAN port, and the remaining ether2 to ether5 are all part of a “bridge” which serves as the LAN part of my network. The interface name for the bridge is conveniently called “bridge”, so you need to assign an IPv6 address from your prefix to the bridge. Really, all you need to specify is “::1/64” as the Address, set the Pool you created in your DHCPv6 client as the “from pool” value, and select “bridge” as the interface and Mikrotik will automatically generate a /64 subnet, and assign the first address to the interface once you hit apply.

The other values were left as their defaults.

Once this address was assigned, the hosts on the LAN automatically acquired an IPv6 address and were able to reach IPv6 only sites.

This doesn’t cover any additional configuration you might need for IPv6 — the Mikrotik wizard creates a reasonable default set of firewall rules and you can explore the web for any further customisation tasks.

This is a long and hopefully interesting story about how I resolved the inability to stream Disney Plus on my IPv6 enabled internet connection that had a non-standard MTU of 1492 bytes.

The short summary is:

• Zen Internet, GB appears to support Layer 2 MTU of 1508. Just set your WAN interface MTU accordingly, and your PPPoE session when established will allow you to continue to advertise an MTU of 1500 bytes for IP (TCP/IP), which most apps and services on the internet prefer.
• You may not have to disable IPv6 if you’re having issues with streaming Disney Plus, it’s probably just getting tripped up if you have a lower MTU than 1500.

And now for the rest of the fun story.

I recently re-subscribed to Disney Plus so I could catch up on new seasons of my favourite series. I settled in on a saturday evening, followed their email, subscribed for one month of the highest quality picture they offer. Login on my TV to watch, the cursor spins for a very long time, then tells me there was an error, and that I should contact their subscription support.

I chatted with two different people because I was using my mobile phone, and whenever my screen was locked because I needed to reboot something or other at the suggestion of their support personnel, the app would get suspended, and on resume, the chat session would be lost.

On the following day, I used my PC to start a chat session with the support team, and this time I chose Technical Support. Got a knowledgeable person who went through several tests, turn off wifi, reboot router etc all to no avail. I had a sneaky feeling that something about my internet connection’s MTU was causing trouble for Disney Plus, or some of it’s content delivery networks. I wasn’t supper confident about this however, since I couldn’t believe that a network as large as Disney Plus would fall prey to something so basic, especially since I had been an on and off customer of Disney plus for nearly 3 years without trouble. It couldn’t be IPv6 either, since I’ve also had IPv6 for 3 years as well.

My PS5 was the only thing that worked consistently, and I knew that the PS5 even though it accepted IPv6 addressing, generally had an OS level preference for IPv4, which the Disney Plus app was happy about. My PC would sometimes work, my phone didn’t work. All these devices were happy the last time I had a subscription, and nothing about my network had changed, so it was likely something that Disney Plus had introduced or changed.

Since I had a few hours to spare after a busy week and weekend, I decided to delve into the matter some more. Wireshark on my PC and packet captures on my router suggested that ICMP was working as expected, sending “packet too big” messages as required, however, a lot of the connections I attributed to Disney Plus seemed to stall after the ICMP message was sent by my router. The client would retry a few times, and then eventually the app would show a message advising you to contact support.

I observed that the app was actually trying to establish IPv6 connections to the relevant content servers, which I could tell from inspecting the TLS Client Hello packets, as they had distinctive domain names. Despite what Disney Plus help pages say, IPv6 is in use, and surely, they can’t expect me to disable IPv6 when they *should* design their app and infrastructure to avoid using IPv6 if they weren’t ready for it.

My ISP is currently Zen Internet, GB, and like so many ISPs in the UK, they use PPPoE, and since PPPoE has an overhead of around 8 bytes per packet, the MTU on internet bound connections in my home is lowered by 8, which is not the typical convention on the internet. However, with ICMP working correctly, this should pose no problem with any modern apps or services. I lived with this fact, having inspected network traffic and confirmed that it takes about 1ms after connection established for the relevant ICMP message is sent by my router to both ends of the connection… and I thought that’s not bad. In practice, the way TCP handles packet loss actually adds a slightly longer delay than 1ms LAN latency would imply, but nothing frustrating enough to act on.

Well, since I wanted to watch Disney Plus, this was finally the time to investigate how to address this in the hopes that it might fix Disney Plus streaming too.

I did some Google searches, and found some speculative information that Zen Internet will accept an a Layer 2 MTU (Ethernet) of 1508 in order to compensate for the overhead of PPPoE. Heh! Really? It’s that simple? Why didn’t I bother to check this two years ago?

Anyway, logged into my Mikrotik router, tweaked the L2 MTU for “ether1” which is acting as my WAN port up by +8 bytes. PPPoE session drops and restarts, and voila! MTU is now 1500 bytes.

Okay, that’s good. No more wasting precious milliseconds retransmitting packets due to ICMP packet too big. Great. I launch the Disney Plus app on my phone, it feels snappier than before, and instantly starts streaming.

Wow. I could have done this two freaking years ago 🙂

The moral of this story is that the Disney Plus app and infrastructure development team probably needs to pay more attention into how their infrastructure handles variable MTU values on the internet. Their app seems to suffer from significantly higher latency when used on networks with the non-typical MTU, and in addition, some of the servers in their video delivery CDN appear unable to deal with path MTU discovery when processing IPv6 traffic. Hopefully one of you stumbles upon this blog and puts some effort into improving this. Netflix and Youtube handle this stuff flawlessly, and there’s no reason why you cannot. Also, if you really don’t want users to use IPv6 on your service, don’t advertise AAAA records :).

Puzzled by the mass of USB type C cables that seemingly only support USB 2.0 speeds in 2025, I did some searching on Amazon, each time increasing the USB version number.

To my surprise, when I searched “usb 4 cable” on Amazon, I found actually decent quality results, for decent prices. To be clear, from experience, I consider Cable Matters, Anker and Amazon Basics to be of acceptable quality. You may have different rankings.

I ended up buying this one: https://amzn.eu/d/hNqvNSg on sale for £10, which is a good price if it actually works as advertised.

They are thicker than normal, but worth it in my view, to not have to think too much about what features the cable supports.