Re: Route script, ifup and IPv6.
torsdag den 2 december 2010 klockan 16:53 skrev Axel Beckert detta:
> Hi Mats,
>
> Mats Erik Andersson wrote:
> > will someone finally begin listening to my comments on GNU/kFreeBSD.
>
> Hmmm?
Those were not on freebsd-utils, but FTBFS and socket/sockaddr failures.
I just expected corrections from experts om my solutions. No worries now.
The present attention makes up for that silence!
My work on IPv6 applications for Debian has had benefits also for kfreebsd,
but it is only now that I managed to identify why the system level services
fall short in GNU/kFreeBSD with respect to IPv6. Late, but interested!
>
> > The script /sbin/route is really a tie-down for GNU/kFreeBSD.
>
> Right. It's also one of the "not yet done" points on my GNU/kFreeBSD
> talk slides.
>
> > It is completely tied to IPv4 and to exactly handle ifup/ifdown.
> > Nothing else. The patch reprinted below, begins making those
> > alteration that let "/sbin/route" catch all "route add"-commands
> > that "ifup" care to send, be it IPv4 or Ipv6.
>
> Yay! So I don't have to code this patch. (It was on my todo list, but
> farther down.)
On the contrary! Now the work begins, now there are more eyes to report
the intricacy of the task. Suitable compromises must be identified,
now that contributors interested in IPv6 are coming forward!
> > The new script is not able to set up IPv6 properly, simply because
> > the call to "ifconfig" from "ifup" is a pure gnu-linux-ism:
> >
> > ifconfig bge0 add 2001:fake:beef::1/64
> >
> > This fails with a bad address under GNU/kFreeBSD. The correct call
> > needs a domain specifier:
> >
> > ifconfig bge0 add inet6 2001:fake:beef::1/64
> >
> > The format string in "ifup" will never catch this.
>
> Sounds doable nevertheless.
Better: the _present_ C-coded "ifup" will never capture this format.
I certainly think that "ifupdown", being a Debian invention, should
be expanded to encompass format strings suitable to the kernels for
which a Debian port exist. Today that would be GNU/Linux and GNU/kFreeBSD.
The day after next year perhaps Nexenta/OpenSolaris.
The effort in C code is minimal, the only new ingredient is to code
and insert a kernel sensing snippet, thus determining which of the
alternate formats that should be applied.
>
> > Given my changes to the script "/sbin/route", it is now able to
> > configure my native IPv6 support using a boot script
>
> Yay!
>
> > The script still distroys most capacieties of /lib/freebsd/route.
>
> Destroys? Did you mean "ignores"?
No, "destroy" ought to be the most correct vocable. Bear in mind that
the wrapper should ideally not interfer with any valid call that
"/lib/freebsd/route" can carry out. The text in route(8) contains
a multitude of particular points. Since all system tools expect to
use a routing command located at "/sbin/route", the wrapper script
can not be allowed to mangle command line arguments, just because
"ifup" or "ifdown" are not sufficiently idiomatic.
Take the pattern "*[0-9]", functional in the script where it is
ignoring all context and semantics. It seems to be contrived to
digest a bare standing interface name, all the more so since the
pattern preceding this one is rescueing all IPv4 addresses from
destruction. Now think about this command
route add -host server12 10.0.0.1
This is a valid routing command. Do you see what the wrapper scripts
are doing to this?
The problem is that also host names are allowed to end in a digit.
If the context indicates that a particular string is the name of
a network device, then the wrapper should only translate the name into
-interface name
which in turn must be inserted in the command string. But this must
only be done if the string preceding the name was _not_ "-interface"
or "-iface". To rescue numerical IPv6 addresses I had to insert a
further pattern before "*[0-9]". This new patter is unfortunately
so clumsy as to be embarrasing, but it does catch slightly better
that the old wrapper could do it.
The brute force trick on "del" inside the script is truly destructive
when one wants to delete single routing stanzas. Targetting "ifupdown"
leaves many blind spots, also with me, as to the functionality needed
to retain in "/lib/freebsd/route".
>
> > These are harsh words, but my disappointment with GNU/kFreeBSD
> > for IPv6 has grown steadily ever since Summer.
>
> Understandable.
>
> Will try to test your patch. Can't though promise any date for that.
> So if anyone else wants to jump on this bandwaggon, feel free. :-)
Petr Salinger suggested to submit the proposed patch to BTS immediately,
but as you will see in the above few remarks, I personally see so many
points to be addressed in a wrapper that it seemed better to get the
developmental process a push using this list and thus collect better
input on needed alterations.
I do not expect, nor believe, that a new wrapper could be publishable
with Squeeze, but testing of suggestions should examine and identify
the pitfalls of IPv6 in GNU/kFreeBSD. That would improve the possiblities
to document the upcoming release and foresee complaints.
Somewhat out of breath, I send my regards,
Mats E A
Reply to: