A Note on SIT Tunnel at Home

This blog article records the progress of setting up IPv6 tunnel to Hurricane Electric at home where my ISP has not provided IPv6 access over a PPPoE pile of sh*t.

Shorthands and Assumptions in This Note

  • eth0 connects to the Internet via IPv4. This note shall also apply to encapsulated interfaces, e.g. [email protected], lte0 or pppoe0.
  • eth1 connects to local LAN. Similar as above, the process shall be the same when LAN side is a VLAN or bridge (or both).
  • tun0 denotes the sit tunnel interface created in this step.
  • A line beginning with # denotes comments in the configuration notes.

Setting up the Tunnel Interface on ER-X

If registered correctly on TunnelBroker, it should provide the following information:

  • Logical address at local endpoint, e.g. 2001:444:111:222::2/64
  • Logical address at remote endpoint, e.g. 2001:444:111:222::1/64
  • IPv4 address at remote endpoint where encapsulated traffic is sent, e.g. 66.220.18.42, the HE tunneling endpoint in Paris.
  • A routable prefix for client side delegation, e.g. 2001:444:112:222::/64. This is usually different from the v6 addresses for the endpoint, and HE will show segments of the prefix in bold.

Now fill ER-X configuration nodes with corresponding information and default routing for IPv6:

interfaces:
    tunnel:
        tun0:
            address: [Fill logical v6 address in CIDR at endpoint]
            description: [Give a name to this tun]
            encapsulation: sit
            local-ip: [Fill in IPv4 address at eth0]
            remote-ip: [Fill in IPv4 address at tunneling endpoint]
protocols:
    static:
        interface-route6:
            ::/0:
                next-hop-interface: tun0
            # This creates a default IPv6 routing table entry that
            # routes all non-link-local address to the tunnel.

At this point, one should be able to ping any IPv6 address from the ER-X. If this is working, continue to instruct the LAN interface to delegate the prefix

interface:
    <path-to-interface-config-node>:
        ipv6:
            dup-addr-detect-transmits: 1
            # Stateless SLAAC configuration might produce identical
            # IP addresses. This allow the network to detect whether
            # a stateless address already exists.
            address:
                autoconf
                # Set autoconf to allow stateless delegation by SLAAC
            router-advert:
                prefix:
                    [Fill routable delegated prefix here]:
                        autonomous-flag: true
                        # Instructs computers on this network to auto
                        # discover DNS servers
                        on-link-flag: true
                        # Indicates that this prefix exists on the
                        # same Ethernet link, i.e. these addresses
                        # does not require routing

IPv6 enabled devices shall now receive globally unique IPv6 address assigned via SLAAC and prefix delegation.

Subsequent Steps

  • Confirm IPv6 assignment on LAN devices
$ ip addr
<------ MORE INTERFACES REDACTED ------>
2: eno1:  mtu 1480 qdisc fq_codel state UP group default qlen 1000
     link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
     inet 192.168.5.4/24 brd 192.168.5.255 scope global dynamic noprefixroute eno1
        valid_lft 80444sec preferred_lft 80444sec
     inet6 2001:470:d:XXXX:XXXX:XXXX:XXXX:dfd3/64 scope global dynamic noprefixroute 
        valid_lft 2591976sec preferred_lft 86376sec
     inet6 fe80::be40:XXXX:XXXX:XXXX/64 scope link noprefixroute 
        valid_lft forever preferred_lft forever
<------ MORE INTERFACES REDACTED ------>
  • Trace IPv6 connections to an IPv6 enabled website
$ traceroute -6 ac.cth451.me -n
 traceroute to ac.cth451.me (2606:4700:30::681c:1b16), 30 hops max, 80 byte packets
  1  2001:470:d:XXXX:XXXX:XXXX:XXXX:XXXX  0.415 ms  0.533 ms  0.624 ms
  2  2001:470:c:XXXX::1  185.353 ms *  203.802 ms
  3  2001:470:0:9d::1  178.603 ms  167.001 ms  189.255 ms
  4  2001:504:0:3:0:1:3335:1  196.520 ms  179.737 ms  196.117 ms
  5  2400:cb00:12:1024::6ca2:d61d  185.036 ms 2400:cb00:12:1024::6ca2:d614  175.573 ms 2400:cb00:12:1024::6ca2:d608  185.263 ms
  • It is advisable to setup network wide firewall on the router, as addresses can be reached by any other IPv6 connected devices from the Internet.

Further Notes

  • The sit tunnel shall also work if setup correctly on any other router or even a personal computer with public IPv4 address. I am unable to replicate the settings on a Linux router via raw commands as I do not own a linux machine with public IPv4 address.
  • I am not sure if the method would work if the local endpoint is behind NAT. This scenario will be experimented on after I return to campus.

“Certified” Androids?

The story begins with the moment I bought Cytus II on the very first day of its release from google play, expecting some real music gaming on my Surface Pro 3 running homebrew Android 7.1 (yes, that’s totally possible and it runs suprisingly fine with all hardware buttons and touchscreen working). However the game quits immediately and no logs are shown through the adb interface. I contacted Rayark for support and got reply like this:

Cytus II might only be compatible for native Android devices at the moment. Please also check if you have installed Xposed, firewalls, block ads, or any rooting software. If yes, these may effect the performance of the game. We’d like to suggest you to remove these software to ensure the game runs smoothly and properly.

(Probably) 3 weeks after the game’s release, I ended up playing Cytus II on my crammed 5′ mobile phone, not by choice though. Someone asked me, why I can’t buy a regular Android tablet or an iPad to do the same job. Well that could be an option if those people would donate in any means for a new one, and I really don’t think utilizing an existing hardware piece could cause any troubles for commercial devs and companies (Google: really?).

After some searches I reached conclusion that Cytus II has integrated an “compliance check” called SafetyNet and the underlying Compatibility Test Suite (CTS), a framework introduced by Google to verify if any android device falls into the category of “compatible”. Since Surface Pro 3 has never got an official Android release (it’s a Microsoft thing, of course) and the base android x86 is shipped with root and development mode on, there is probably no way that any CTS tests on Surface Pro 3 would pass any time sooner.

Just earlier this day, I saw the news that Google is attmpting to block Gapps from running on “uncertified” devices, where modding the android device or unlocking bootloader would void the “certified” status. There’s even a webpage letting people to “register” their Androids with their device identifier which is absolutely not working after I attempted to register my Surface only getting an unknown error.

I would not blame Rayark for their attempt to place a layer of piracy protection on such a nice game while hurting the ones who modded their devices properly exactly to play these games. My question is: If such a lockdown is so important that this system had been deployed to thousands of android software by now, why make android an open standard? Why not switch to the Apple production mode if a centralized control force seems so vital to the whole android community? Such blockage wouldn’t be easily tolerated if the so called “register uncertified devide page” is just a lie, and I believe there will be a solution to circumvent such unreasonable restrictions eventually. Before that, the vast population of “uncertified” androids and modders wouldn’t be so comfortable and I might really need to ask myself: Why I should spend 3 months porting an open source OS to a new device just to find nothing should works by design.

The Hot City?

When I told someone Chengdu is a hot city, I meant both food and the city itself. Hopefully, I finally remembered that I forgot procrastinated to post my photos I took when I travelled to Chengdu and stayed for a few days this winter. Still, these pictures are taken from my old Canon 50D DSLR and the mediocre lens.

Continue reading The Hot City?

The season of white (photo) album

It’s -30 degree celcius in Madison. It’s snowing. It’s the season of white album again.

白い雪が街に——
優しく積もるように
アルバムの空白を全部——
埋めてしまおう——

Camera: Canon EOS 50D (a really old DSLR)
Lens: Canon EF-S 17-85mm f4-5.6 IS USM (yes, the very mediocre default)
Aperture: f/5.6
Exposure: 1/500
Location: In my room [precise location redacted]

[Errata] Windows upgrade to 1703 broke grub

What happened?

After windows upgrading itself to release 1703 aka. the creator update, Grub bootloader can no longer start and says error: unknown filesystem and dropped in to grub rescue shell. Windows boots up fine from firmware memu.

TL; DR

Manually doing hexediting just taught me another valuable lesson: @Windows has the worst upgrade handling.

— @cth451 July 28, 2017

  1. Prepare a USB linux live environment.
  2. Find the correct partition number, it might have been changed during upgrade.
  3. Look for grubx64.efi in your EFI system partition and use a hex editor to open it
  4. Search for /boot/grub and notice the (,gptN) where N is your original partition number for linux OS.
  5. Change N to the new parition number, save the file and reboot.

Analysis

Before upgrade, my partition scheme was:

  • sda1 fat32: EFI system parition
  • sda2 ext4: Archlinux root filesystem
  • sda4 ntfs: Windows drive C
  • sda3 ext4: AOSC OS root filesystem

Partition numbers were not exactly in physical order of data, for I shrinked Archlinux to make room for Windows installation. However after upgrade, it became:

  • sda1 fat32: EFI system parition
  • sda2 ext4: Archlinux root filesystem
  • sda3: Windows drive C
  • sda4: Windows recovery environment
  • sda5: AOSC OS root filesystem

So what did windows do down there? It shrinked drive C and made a little recovery partition, then re-sorted the partition numbers. However grub bootloader looks for partitions by partition number. It tried parition 3 (which was a valid linux filesystem), but it’s an ntfs now.

This partition number is hardcoded into the bootloader efi image, so we need to manually hexedit it.

大阪

梅田

A photo of the Yodo-gawa (淀川) from the skyscrapers with the old DSLR Canon 50D. Juusou-suji (十三筋) and Hankyu railways are visible in this picture.

EXIF:
Camera   = Canon EOS 50D
Lens     = EF-S 17-85mm f/4-5.6 IS USM
ISO      = 100
Aperture = f/11
Exposure = 30"

Shot from 梅田スカイビル 空中庭園

天満橋

A shot of the only double decked bridge in Osaka. Taken with my Xperia Z5 on the cruise ship during sunset.

天満橋 Geotag: 小川