Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 475302 - netifrc - /lib64/rc/net/ has two problems
Summary: netifrc - /lib64/rc/net/ has two problems
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: netifrc (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: netifrc Team
Whiteboard: netifrc:ip6rd
Keywords: PATCH
Depends on:
Reported: 2013-06-30 09:56 UTC by Alexander E. Patrakov
Modified: 2021-05-01 21:04 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

ip6rd fixes (,1.63 KB, patch)
2021-05-01 09:50 UTC, Fredrik Eriksson
Details | Diff
prefix and routing fixes (,1.87 KB, patch)
2021-05-01 21:04 UTC, Fredrik Eriksson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander E. Patrakov 2013-06-30 09:56:32 UTC
There are multiple issues with the /lib64/rc/net/ file. They were found by attempting to treat a 6in4 tunnel as a special case of 6rd. Please fix them.

1. There is no way to pass the 6rd-relay_prefix option to the "ip" binary. This option should go together with 6rd-prefix. Probably (not sure) the correct value is ${ip}/${ipv4mask}.

2. The _ip6rd_prefix_shave_bits function produces empty output if $2 -eq 32 (i.e. if someone wishes to treat his 6in4 tunnel as a special case of 6rd). This results in the eval ip6=... line producing unexpected result (containing "::" at the end) in ip6rd_pre_start().

Reproducible: Always
Comment 1 Christohper Harrington 2017-05-28 19:58:01 UTC
Not sure if this bug the right place to drop this, but I've noticed that the 6rd method for calculating the prefix is wrong.

CenturyLink provides 2602::/24 as a prefix, which means (assuming the host mask is 0 and the IP is WW.XX.YY.ZZ) the derived address should be of this format:
Instead it derives this:

In essence, it seems to ignore the prefix length specified.

I'll mess around with this and see if my sick bash skills are enough to derive the correct address and submit a patch.
Comment 2 Christohper Harrington 2017-05-28 23:38:50 UTC
(In reply to Christohper Harrington from comment #1)
> I'll mess around with this and see if my sick bash skills are enough to
> derive the correct address and submit a patch.

I have a patch, and it's hideous, but I'll attach it if anyone is actually watching this bug. Otherwise I'll just carry it in my /etc/portage/patches. It correctly handles all n*4 masks: /4 /8 /12 /16 /20 /24 /28 /32 (whereas previously only /16 and /32 were actually being handled)
Comment 3 Christohper Harrington 2017-12-23 20:44:54 UTC
Is this bug dead? It's been over a year. Nobody has any interest in fixing this?
Comment 4 Fredrik Eriksson 2021-05-01 09:50:18 UTC
Created attachment 704940 [details, diff]
ip6rd fixes

I'm no expert on 6rd or even networking in general; but I really wanted this fixed so here's a patch to get started.

In this version the 6rd-relay_prefix is always added (calculated from local ip and provided ipv4mask).

_ip6rd_inet_get_network previously did not return the network address as expected, but is fixed in this patch. It is needed to calculate the 6rd-relay_prefix (previously I think it was only used to (unsuccessfully) verify that ip addresses was not RF1918).

As mentioned the ipv6 address was incorrectly calculated (at least for my prefix). I went the lazy route and added a dependency on the ipv6calc program to calculate the proper ipv6 address and mask. I'm sure it's possible to make an all-bash solution, but I don't think it's worth it; the few of us who uses 6rd can probably live with an extra dependency...
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2021-05-01 19:43:14 UTC
This shouldn't have been assigned to openrc@ in the first place, and that's why it seemed to get lost.

Will review for inclusion.
Comment 6 Fredrik Eriksson 2021-05-01 21:04:37 UTC
Created attachment 705069 [details, diff]
prefix and routing fixes


Minor revised patch which also sets a proper default route. 2000::/3 is probably enough, as it contains all current ipv6 unicast addresses, but I had some issues with some automation scripts which expects there to be a ::/0 route on the public facing interface...