FS#1463 - netifd disagrees with static route documentation

Open
#6,429 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
c
Domain
networking

Research direction

Start in netifd's interface-ip.c where ROUTE_GATEWAY is decoded, then follow struct device_route into system-linux.c and the system_rt route handling. Confirm how omitted and 0.0.0.0 gateways are distinguished, and verify that the resulting route behavior matches the static-route documentation, including use of the configured default gateway when appropriate.

Written by the indexing model from the issue text.

Description

core packages flyspray

nwf:

https://openwrt.org/docs/guide-user/network/routes_configuration says, of the static route "gateway" configuration variable, "If omitted, the gateway from the parent interface is taken; if set to 0.0.0.0 no gateway will be specified for the route". However, netifd HEAD does not distinguish all zeros from unset. In particular, https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-ip.c;h=1c84d4f8afed8bbe8af9fcc868fb1472b048019d;hb=HEAD#l343 is the only place where ROUTE_GATEWAY is decoded from a blob message and will leave route->nexthop all zeros if none is provided:

343 if ((cur = tb[ROUTE_GATEWAY]) != NULL) { 344 if (!inet_pton(af, blobmsg_data(cur), &route->nexthop)) { 345 DPRINTF("Failed to parse route gateway: %s\n", (char *) blobmsg_data(cur)); 346 goto error; 347 } 348 }

When it comes time to actually use the resulting route->nexthop value, https://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c;h=0ca525602d9ea63ac5b845b2be9c6c7bdec7c26c;hb=HEAD#l1851 just checks for all-zeros and, if so, declares it to be a link-local route:

1851 if (alen == 4) 1852 have_gw = !!route->nexthop.in.s_addr; 1853 else 1854 have_gw = route->nexthop.in6.s6_addr32[0] || 1855 route->nexthop.in6.s6_addr32[1] || 1856 route->nexthop.in6.s6_addr32[2] || 1857 route->nexthop.in6.s6_addr32[3]; ... 1882 rtm.rtm_scope = (have_gw) ? RT_SCOPE_UNIVERSE : RT_SCOPE_LINK; ... 1925 if (have_gw) 1926 nla_put(msg, RTA_GATEWAY, alen, &route->nexthop);

I believe that struct device_route needs a flag to indicate whether the incoming blobmsg had a ROUTE_GATEWAY or not, and that system_rt should use the device's configured default gateway if not. There is, at present, no workaround except to hard-code the next hop in the configuration, which is gross.

Dominant language
C
Stars
28.5k
Forks
13k
Avg merge
3d 1h
Merged PRs (30d)
160

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openwrt/openwrt

All issues in openwrt/openwrt

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.