Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 475302 - sys-apps/openrc-0.11.8 - /lib64/rc/net/ has two problems
Summary: sys-apps/openrc-0.11.8 - /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
Depends on:
Reported: 2013-06-30 09:56 UTC by Alexander E. Patrakov
Modified: 2017-12-23 20:44 UTC (History)
1 user (show)

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


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?