ukl's blog

IPv6 in my home network

2017-09-17T12:15:00+02:00

I am lucky and get both IPv4 (without CGNAT) and IPv6 from my provider. Recently after upgrading my desk router (that is an Netgear WNDR3800 that serves the network on my desk) from OpenWRT to latest LEDE I looked into what can be improved in the IPv6 setup for both my home network (served by a FRITZ!Box) and my desk network.

Unfortunately I was unable to improve the situation compared to what I already had before.

Things that work

Making IPv6 work in general was easy, just a few clicks in the configuration of the FRITZ!Box and it mostly worked. After that I have:

IPv6 connectivity in the home net
IPv6 connectivity in the desk net

Things that don't work

There are a few things however that I'd like to have, that are not that easy it seems:

ULA for both nets

I let the two routers announce an ULA prefix each. Unfortunately I was unable to make the LEDE box announce its net on the wan interface for clients in the home net. So the hosts in the desk net know how to reach the hosts in the home net but not the other way round which makes it quite pointless. (It works fine as long as the FRITZ!Box announces a global net, but I'd like to have local communication work independent of the global connectivity.)

To fix this I'd need something like radvd on my LEDE router, but that isn't provided by LEDE (or OpenWRT) any more as odhcpd is supposed to be used which AFAICT is unable to send RAs on the wan interface though. Ok, probably I could install bird, but that seems a bit oversized. I created an entry in the LEDE forum but without any reply up to now.

Alternatively (but less pretty) I could setup an IPv6 route in the FRITZ!Box, but that only works with a newer firmware and as this router is owned by my provider I cannot update it.

Firewalling

The FRITZ!Box has a firewall that is not very configurable. I can punch a hole in it for hosts with a given interface-ID, but that only works for hosts in the home net, not the machines in the delegated subnet behind the LEDE router. In fact I think the FRITZ!Box should delegate firewalling for a delegated net also to the router of that subnet.

So having a global address on the machines on my desk doesn't allow me to reach them from the internet.

Update: according to the German changelog firmware 6.83 seems to include that feature. Cheers AVM. Now waiting for my provider to update ...

Installing Debian Stretch on a Turris Omnia

2016-11-08T21:56:00+01:00

Recently I got "my" Turris Omnia and it didn't take long to replace the original firmware with Debian.

If you want to reproduce, here is what you have to do:

Open the case of the Turris Omnia, connect the hacker pack (or an RS232-to-TTL adapter) to access the U-Boot prompt (see Turris Omnia: How to use the "Hacker pack"). Then download the installer and device tree:

# cd /srv/tftp
# wget https://d-i.debian.org/daily-images/armhf/daily/netboot/vmlinuz
# wget https://d-i.debian.org/daily-images/armhf/daily/netboot/initrd.gz
# wget https://www.kleine-koenig.org/tmp/armada-385-turris-omnia.dtb

(The latter is not included yet in Debian, but I'm working on that.)

and after connecting the Turris Omnia's WAN to a dhcp managed network start it in U-Boot:

dhcp
setenv serverip 192.168.1.17
tftpboot 0x01000000 vmlinuz
tftpboot 0x02000000 armada-385-turris-omnia.dtb
tftpboot 0x03000000 initrd.gz
bootz 0x01000000 0x03000000:$filesize 0x02000000

With 192.168.1.17 being the IPv4 of the machine you have the tftp server running.

I suggest to use btrfs as rootfs because that works well with U-Boot. Before finishing the installation put the dtb in the rootfs as /boot/dtb.

To then boot into Debian do in U-Boot:

setenv mmcboot=btrload mmc 0 0x01000000 boot/vmlinuz\; btrload mmc 0 0x02000000 boot/dtb\; btrload mmc 0 0x03000000 boot/initrd.img\; bootz 0x01000000 0x03000000:$filesize 0x02000000
setenv bootargs console=ttyS0,115200 rootfstype=btrfs rootdelay=2 root=/dev/mmcblk0p1 rootflags=commit=5 rw
saveenv
boot

Known issues:

rtc doesn't work (workaround: mw 0xf10184a0 0xfd4d4cfa in U-Boot)
SFP and switch don't work, MAC addresses are random
wifi fails to probe

If you have problems, don't hesitate to contact me.

Also check the Debian Wiki for further details.

Fixing Debian bug #794266

2016-08-01T23:13:00+02:00

After finally being able to fix Debian bug #794266 I want to thank those who made this possible:

Some time ago my colleague Bjørn offered an Arietta G25 to me. After Jochen, another colleague, helped me to solder pin headers on it, this machine served as host computer for my tests.

As I didn't have a machine with the relevant RTC chip, I contacted Seiko Instruments and they provided me a few chips including oscillators. It was again Jochen who then created a break-out board from these components that I could wire to my Arietta board.

Finally Wolfram Sang's i2ctransfer helped me a lot to access and so understand the chip. It's has not landed in i2c-tools.git, but I hope this will change soon given that this is a really useful tool.

A big thank you to all who helped me. It was fun and would have been less so without your efforts!

Christoph Hellwig vs VMware

2016-02-23T09:20:00+01:00

On Thursday the lawsuit about GPL compliance of VMware's ESXi products starts. I support Christoph's position and share his view that VMware's product is in conflict with the GPL.

I keep my fingers crossed!

Let's encrypt

2015-12-04T09:30:00+01:00

Let's encrypt entered public beta and there is a Debian package in experimental for their client available.

After some reading and testing I came up with the following commandline to give me what I want:

letsencrypt --manual --config-dir $HOME/letsencrypt/etc \
--work-dir $HOME/letsencrypt/var --logs-dir $HOME/letsencrypt/logs \
--server https://acme-v01.api.letsencrypt.org/directory \
--domains kleine-koenig.org,www.kleine-koenig.org,blog.kleine-koenig.org,lists.kleine-koenig.org,cgi.kleine-koenig.org,wiki.kleine-koenig.org,caldav.kleine-koenig.org,mail.kleine-koenig.org \
certonly

So now you can read this message via https and probably don't be bothered by your browser for an invalid certificate any more. Hurray!

Alternative Firmware for a squeezebox

2015-02-08T12:52:00+01:00

My Squeezebox Radio does its duty most of the time. Unfortunately it depends on a single central service run by Logitech. Well, from time to time this service doesn't work which makes me wish for an alternative firmware that doesn't depend on such a service. Moreover it doesn't feel too good that I can login to mysqueezebox.com, press "Remote Control" and can control the box from there.

So here is my wish list for the alternative firmware:

free and open source
local configuration without a central server
optionally controllable by http directly on the box
support DLNA to play music available in the local network
and last not least it should of course still play streams from the internet

As a starter I ported barebox to the Squeezebox. Currently only second stage loadable for the vendor supplied Redboot and apart from the UART no devices working yet. But still ...

Until I get further with porting a recent bootloader and Linux to it, feel free to contact me if you have a link to a free internet radio firmware.

Installing Debian Jessie on a Netgear ReadyNAS 104

2014-11-20T09:12:00+01:00

The Netgear ReadyNAS 104 comes shipped with U-Boot. To access its "shell" remove the small quadratic sticker at the backside to reveal the UART pins (3V3, pinout available at Arnaud's NAS page[1]) and connect a matching adapter. Also connect a network cable to the lower jack.

Then on a different machine in the same network setup a tftp server (e.g. apt-get install tftpd-hpa). As of today the latest beta netboot installer (Beta 2) doesn't work any more because the kernel in jessie was updated since the installer was released. So pick up the armhf netboot installer from the daily snapshots. You need initrd.gz and vmlinuz. Furthermore armada-370-netgear-rn104.dtb.

Update: As jessie is released now, download the following images:

To make the installer ready to boot do:

# apt-get install u-boot-tools
$ cat vmlinuz armada-370-netgear-rn104.dtb > vmlinuz-rn104
$ mkimage -A arm -O linux -T multi -C none -a 0x04000000 -e 0x04000000 -n "Debian Jessie armhf installer" -d vmlinuz-rn104:initrd.gz uImage-installer-rn104
# cp uImage-installer-rn104 /srv/tftp

Then on the U-Boot shell setup networking and start the installer by issuing the following commands:

dhcp
setenv serverip 192.168.1.17
tftp uImage-installer-rn104
bootm $load_addr

With 192.168.1.17 being the IPv4 of the machine you set up the tftp server above, adapt accordingly to your setup.

While in U-Boot the default ethernet device is the lower jack, the installer is only able to use the upper, so replug the ethernet cable to the upper receptacle.

Go through the installation, and before rebooting do the following: Select "Change debconf priority" and set it to "low". Then "Download installer components" and check "mtd-modules-3.16.0-4-armmp-di". After that "Execute a shell" and do:

# echo "The following is dangerous, see Note below!"
# depmod -a 
# modprobe pxa3xx_nand
# mount --bind /proc /target/proc
# chroot /target
# cat >> /etc/flash-kernel/db << EOF
Machine: NETGEAR ReadyNAS 104
DTB-Id: armada-370-netgear-rn104.dtb
DTB-Append: yes
Mtd-Kernel: uImage
Mtd-Initrd: minirootfs
U-Boot-Kernel-Address: 0x04000000
U-Boot-Initrd-Address: 0x05000000
Required-Packages: u-boot-tools
EOF
# flash-kernel

You then need to adapt the u-boot environment to pass the right root parameter to Linux. Alternatively add Bootloader-Sets-Incorrect-Root: yes to /etc/flash-kernel/db.

Note: flash-kernel as of now (flash-kernel 3.35+deb8u2 and also 3.56) doesn't handle bad blocks correctly. This might damage your flash beyond repair! So maybe better don't setup flash-kernel as suggested above. Use at your own risk.

[1] Note this page is about a ReadyNAS 102, the pinout is identical though.