OpenWrt Forum Archive

Topic: Miredo Support - Petition

The content of this topic has been archived on 17 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi.

I was trying to post at #19918 ticket but I'm getting "potential spam" errors.

I'm kindly asking the developers: Please do maintain Miredo.

It is not about getting to IPv6 internet. It is because using it is the only way to receive inbound connections at places where all you got is a (CG-)NATed IPv4 internet access. This scenario is becoming increasingly common due to IPv4 pool exhaustion. I know that native IPv6 everywhere and for everyone is the “right” solution but it is often not in control of the user.

If the ISP is only providing CG-NAT and no v6 Miredo is your only resort that doesn’t rely on redirecting all traffic through an intermediate host on the internet which could be very slow. This is possible because teredo client-to-client connections are not relayed if symmetric type NAT is not involved. It creates a fast direct v4-to-v4 tunnel that finds its way through several layers of NAT.

Having a dynamic teredo address for receiving inbound connections is not a problem since there are many free DDNS services that can do AAAA records.

I have successfully used teredo(windows)-to-teredo(miredo) to start SSH and even OpenVPN sessions towards an OpenWrt router that is behind CG-NAT. The way I achieved this with Chaos Calmer was by installing miredo-common and miredo-client packages from the oldpackages feed from Barrier Breaker but I'm afraid it might not work with future releases if it is not being actively maintained.

I consider miredo-client a very powerful tool and wish to see it working until the day that every piece of network equipment that cannot route IPv6 end up in a garbage can.

André L.

I created packaging files for Miredo, currently the pull-request is waiting for review: on github.com /openwrt/packages/pull/4201 (I can't post links).

In the meantime, the packaging files for building it manually are available at github.com ppetr/openwrt-miredo.

(I also wasn't able to comment on the Trac issue.)

Hi ppetr,

Meanwhile I have installed the Barrier Breaker build system into VirtualBox and recompiled miredo for ar7xx without the annoying log messages that keep flooding some info about maintenance routine calls. Have you noticed this issue ? The package size was also reduced considerably after this change, which was done simply clearing a debug option flag.

I also modified the client-hook script, which now includes:
- New routing
- Hotplug script call for the tunnel iface
- Highest possible tunnel MTU, assuming ethernet-like links on the path (not everyone may want this, but it works for my use case)
- Cleanups for "don't know that this is for" parts of the code (haha)

Here's how it is now:

#! /bin/sh
#
# Miredo client hook script for Linux/iproute2
# Copyright Denis-Courmont.
# Distributed under the terms of the GNU General Public License version 2.
# Modified by AndreL

# MTU for the tunnel interface
# (default: specified by the Teredo server, or 1280)
MTU=1472

# Destination route
# Teredo only: 2001::/32, Global IPv6: 2000::/3
ROUTE='2000::/3'

# Nothing to do with destroy event
[ "$STATE" != 'destroy' ] || exit 0

ip -6 route flush dev "$IFACE" 2>/dev/null
ip -6 address flush dev "$IFACE" 2>/dev/null
ip -6 link set dev "$IFACE" "$STATE" 2>/dev/null

if [ "$STATE" = 'up' ]; then
    ip link set dev "$IFACE" mtu "$MTU"

    ip -6 address add "${LLADDRESS}/64" dev "$IFACE"
    ip -6 address add "${ADDRESS}/32" dev "$IFACE"
        
    ip -6 route add "$ROUTE" from "${ADDRESS}" dev "$IFACE" proto static 2>/dev/null

    ACTION=ifupdate INTERFACE="${IFACE}" DEVICE="${IFACE}" /sbin/hotplug-call iface
fi

# This should be required when changing policy routing rules, but it
# seems to confuse certain kernels into removing our default route!
ip -6 route flush cache 2>/dev/null

exit 0

So far I've been using it on Chaos Calmer, with the only problem being the high memory footprint that it is taking, compared to other processes. Unfornutately it seems to high for a 32MB router.

But I wanted to go to the next step, which is to find a way to port it to LEDE. As you might have noticed, I'm not a Unix programmer/developer so I'm just trying to put pieces together. I'd be glad to see someone smarter upgrading and porting this package seriously.

Regards,

(Last edited by AndreL on 23 Apr 2017, 14:45)

The discussion might have continued from here.