I believe that there is a bug in the print_route function in iproute.c.
If one creates a custom IPv6 routing table (for source-based routing, in
our case), the table is not visible using the "ip -6 route show table
<tablename>" command. Nothing is returned if this command is run. This is
not the case for custom IPv4 tables; "ip route show table <tablename>"
works fine, showing whatever has been added to the custom table. This
difference in behavior appears to be due to the following lines in
print_route in iproute.c:
if (r->rtm_family == AF_INET6) {
if (G_filter.tb) {
if (G_filter.tb < 0) {
if (!(r->rtm_flags & RTM_F_CLONED)) {
return 0;
}
} else {
if (r->rtm_flags & RTM_F_CLONED) {
return 0;
}
if (G_filter.tb == RT_TABLE_LOCAL) {
if (r->rtm_type != RTN_LOCAL) {
return 0;
}
} else if (G_filter.tb == RT_TABLE_MAIN) {
if (r->rtm_type == RTN_LOCAL) {
return 0;
}
} else {
return 0;
<--------------------------------------------
}
}
}
This code appears to prevent any custom IPv6 table from being viewed,
though the table creation (also using the "ip -6 route" command) works fine
as far as I can tell.
In order to view custom IPv6 tables, I replaced the above code with:
if (r->rtm_family == AF_INET6) {
if (G_filter.tb) {
if (G_filter.tb < 0) {
if (!(r->rtm_flags & RTM_F_CLONED)) {
return 0;
}
} else {
if (r->rtm_flags & RTM_F_CLONED) {
return 0;
}
if (G_filter.tb == RT_TABLE_LOCAL) {
if (r->rtm_type != RTN_LOCAL) {
return 0;
}
} else if (G_filter.tb == RT_TABLE_MAIN) {
if (r->rtm_type == RTN_LOCAL) {
return 0;
}
} else if (G_filter.tb != r->
rtm_table){ <----------------
return 0;
}
}
}
This change makes the AF_INET6 code closer to the logic used by the AF_INET
code and results in the "ip -6 route show table <tablename>" command
correctly showing the custom table.
To test this:
ip -6 route add default via EEEE::01 dev eth2 table 5
ip -6 route show table 5
If the fix works, you'll see a 1-line custom routing table.
"Route -A inet6" does not show the custom table, but since the "route"
command doesn't support custom tables, that is expected.
We are using Busybox 1.22.1 on an old Angstrom version, but the
above-mentioned code is present in recent downloadable source (2020-03-03
00:20 is the last I checked), and I don't see any mention of the above in
the bug tracker, so I suspect that this issue is still present,
particularly given the simplicity of the workaround and the unlikelyhood of
a fix being applied elsewhere.
--
--
Jeremy Royal
Senior Software Engineer I
ATTO Technology, Inc.
Phone: +1.716.691.1999 ext. 507
Fax: +1.716.691.9353
www.atto.com
Dear Loyal Partners:
Each year we look forward to meeting with our customers and partners at
Avid Connect, Dell Technologies World and NAB in Las Vegas but we also
strongly support the decisions to cancel these shows this year as a
protective measure against the spread of COVID-19. We will be providing
more information regarding our plans to engage our community through
alternative mediums including virtual online events along with our industry
partners who had plans to attend this year.
This electronic transmission and any attachments hereto are intended only for
the use of the individual or entity to which it is addressed and may contain
confidential information belonging to ATTO Technology, Inc. If you have reason
to believe that you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution or the taking of any action in
reliance on the contents of this electronic transmission is strictly
prohibited. If you have reason to believe that you have received this
transmission in error, please notify ATTO immediately by return e-mail and
delete and destroy this communication.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
