| Message ID | 20240912141440.314005-1-guyavrah1986@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] net:ipv4:ip_route_input_slow: Change behaviour of routing decision when IP router alert option is present | expand |
diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 13c0f1d455f3..7c416eca84f8 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -2360,8 +2360,12 @@ out: return err; RT_CACHE_STAT_INC(in_slow_tot); if (res->type == RTN_UNREACHABLE) { - rth->dst.input= ip_error; - rth->dst.error= -err; + if (IPCB(skb)->opt.router_alert) + rth->dst.input = ip_forward; + else + rth->dst.input = ip_error; + + rth->dst.error = -err; rth->rt_flags &= ~RTCF_LOCAL; }
When an IP packet with the IP router alert (RFC 2113) field arrives to some host who is not the destination of that packet (i.e - non of its interfaces is the address in the destination IP address field of that packet) and, for whatever reason, it does not have a route to this destination address, it drops this packet during the "routing decision" flow even though it should potentially pass it to the relevant application(s) that are interested in this packet's content - which happens in the "forwarding decision" flow. The suggested fix changes this behaviour by setting the ip_forward as the next "step" in the flow of the packet, just before it (previously was) is dropped, so that later the ip_forward, as usual, will pass it on to its relevant recipient (socket), by invoking the ip_call_ra_chain. Signed-off-by: Guy Avraham <guyavrah1986@gmail.com> --- The fix was tested and verified on Linux hosts that act as routers in which there are kerenls 3.10 and 5.2. The verification was done by simulating a scenario in which an RSVP (RFC 2205) Path message (that has the IP router alert option set) arrives to a transit RSVP node, and this host passes on the RSVP Path message to the relevant socket (of the RSVP deamon) even though upon arrival of this packet it does NOT have route to the destination IP address of the IP packet (that encapsulates the RSVP Path message). net/ipv4/route.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)