Potential issue in RIP: missing handing rtes in rip_receive_request
Hi, I am doing testing work on network protocols and there is one possible issue I noticed in RIP: When packet command is RIP_CMD_UPDATE_REQUEST, the protocol will call function rip_receive_request to respond to request called from rip_rx_hook. In RFC2453: https://datatracker.ietf.org/doc/html/rfc2453#section-3.9.1 Examine the list of RTEs in the Request one by one. For each entry, look up the destination in the router's routing database and, if there is a route, put that route's metric in the metric field of the RTE. If there is no explicit route to the specified destination, put infinity in the metric field. Once all the entries have been filled in, change the command from Request to Response and send the datagram back to the requestor. However in the function rip_receive_request, it seems that only one rte is examined. Could you please take a look at this part? I would really appreciate it. Thank you! Best, Mingwei
On Sun, Apr 23, 2023 at 07:37:02PM -0400, Mingwei Zheng wrote:
Hi, I am doing testing work on network protocols and there is one possible issue I noticed in RIP: When packet command is RIP_CMD_UPDATE_REQUEST, the protocol will call function rip_receive_request to respond to request called from rip_rx_hook.
In RFC2453: https://datatracker.ietf.org/doc/html/rfc2453#section-3.9.1
However in the function rip_receive_request, it seems that only one rte is examined.
Hi We handle only the special case: There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table. That is a case used by routing daemons to trigger full table update, while the generic route request was used just for monitoring and is obsolete. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Mingwei Zheng -
Ondrej Zajicek