|
Bugzilla – Full Text Bug Listing |
| Summary: | route shows "default" for non-default route | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Christian Boltz <suse-beta> |
| Component: | Network | Assignee: | Marius Tomaschewski <mt> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Minor | ||
| Priority: | P5 - None | CC: | b.eckenfels |
| Version: | 13.1 Milestone 0 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | openSUSE 12.3 | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Christian Boltz
2013-05-21 21:48:06 UTC
I think we should fix this cosmetic issue, because it may confuse people, that route (and of course also a "netstat -r") shows "default" already for the 0.0.0.0 destination network address without to consider the mask: Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 nic0 0.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 nic0 0.0.0.0 0.0.0.0 192.0.0.0 U 0 0 0 nic0 0.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 nic0 0.0.0.0 x.x.x.x 0.0.0.0 UG 0 0 0 nic0 Destination Gateway Genmask Flags MSS Window irtt Iface default * 255.0.0.0 U 0 0 0 nic0 default * 240.0.0.0 U 0 0 0 nic0 default * 192.0.0.0 U 0 0 0 nic0 default * 128.0.0.0 U 0 0 0 nic0 default edge-20 0.0.0.0 UG 0 0 0 nic0 For completeness, "ip route" shows them correctly: 0.0.0.0/8 dev nic0 scope link 0.0.0.0/4 dev nic0 scope link 0.0.0.0/2 dev nic0 scope link 0.0.0.0/1 dev nic0 scope link default via x.x.x.x dev nic0 BTW: More funny is: # route -n 172.42.40.0 0.0.0.0 255.255.255.0 U 0 0 0 nic0 # route default * 255.255.255.0 U 0 0 0 nic0 # grep ^default /etc/networks default 172.42.40.0 => IMO low prio minor. This is fixed here (you might need to pull other changes as well to apply that change): https://github.com/ecki/net-tools/commit/c0d46405eb1d58bb5e2e2f5555a05fe10db703c6 (this does not skip the lookup of networks [BTW in Comment #3], therefore if you have a broken /etc/networks entry it will (still) show a broken output for ipv4 - how would you fix it?) the lib/inet6.c also does not observe the prefixlen, but it is not a problem for inet6 route as it uses the numeric flag (and no /etc/networks file). (In reply to comment #4) > This is fixed here (you might need to pull other changes as well to apply that > change): > > https://github.com/ecki/net-tools/commit/c0d46405eb1d58bb5e2e2f5555a05fe10db703c6 Thank you very much!! (In reply to comment #5) > (this does not skip the lookup of networks [BTW in Comment #3], therefore if > you have a broken /etc/networks entry it will (still) show a broken output for > ipv4 - how would you fix it?) I'd keep it as is. A broken /etc/networks entry is a broken entry, IMO no fix is needed. Except of it, /etc/networks assumes class networks, there is no length. The man page we have says: This file is read by the route(8) and netstat(8) utilities. Only Class A, B or C networks are supported, partitioned networks (i.e., network/26 or network/28) are not supported by this facility. 0.0.0.0 is a class A and partitioned networks (0.0.0.0/4) are not supported. (In reply to comment #6) > the lib/inet6.c also does not observe the prefixlen, but it is not a problem > for inet6 route as it uses the numeric flag (and no /etc/networks file). Yes, this is fine, the truncation of ipv6 addresses in netstat -A inet6 -atun is a thorn in the eye (-T disables the truncation but breaks the columns). I just tested (on latest Tumbleweed), and the issue I reported in this bug was fixed in the meantime :-) Bernd, I didn't check the additional issues you mentioned - if they weren't fixed in the last 4 years, please open a new bugreport for them ;-) |