RIP packet sequence number starts with 1 rather 0

[Jagadeeshnagaraju]

Description

RFC (https://datatracker.ietf.org/doc/html/rfc2082#section-3.2.2) clearly mentions the sequence number should be non-decreasing and if the connection is lost for any reason (like RIP daemon is restart) then the sequence number should be 0(zero) or increment of the previously sent number

Previously the time value was used in the sequence number but with the below PR, The sequence number is initialised with 0 but incrementing 1 before sending the first packet
1568e88

One more issue is even during the receiving the packets RFC says receiver should reject the packets if it is arrived with lower sequence number except for zero

Logs for the reference
-----Last packet before restart of the RIP daemon-----
2025-01-31T06:38:56Z RIP: [NDAGH-Z85V7] rip_send_packet 11.11.11.11 > 224.0.0.9 (Port2)
2025-01-31T06:38:56Z RIP: [G4HZH-53B3V] SEND RESPONSE version 2 packet size 64
2025-01-31T06:38:56Z RIP: [NV3Q6-5S5XW] family 0xFFFF type 3 (MD5 authentication)
2025-01-31T06:38:56Z RIP: [JRENT-C3G18] RIP-2 packet len 44 Key ID 1 Auth Data len 20
2025-01-31T06:38:56Z RIP: [Y55WS-JJ0CY] Sequence Number 1055
2025-01-31T06:38:56Z RIP: [XHCQJ-PBD83] 94.94.94.0/24 -> 0.0.0.0 family 2 tag 0 metric 1
2025-01-31T06:38:56Z RIP: [VER1M-YZK0G] family 0xFFFF type 1 (MD5 data)
2025-01-31T06:38:56Z RIP: [GZHT4-3KF9V] MD5: 7EBE87E4E64F3BA922609CE3930811FA
2025-01-31T06:38:56Z RIP: [NDAGH-Z85V7] rip_send_packet 94.94.94.94 > 224.0.0.9 (Port4)
2025-01-31T06:38:56Z RIP: [G4HZH-53B3V] SEND RESPONSE version 2 packet size 44
2025-01-31T06:38:56Z RIP: [XHCQJ-PBD83] 11.11.11.0/24 -> 0.0.0.0 family 2 tag 0 metric 1
2025-01-31T06:38:56Z RIP: [XHCQJ-PBD83] 80.80.80.0/24 -> 0.0.0.0 family 2 tag 0 metric 2
2025-01-31T06:38:58Z RIP: [P2JVH-8PCQ6] RIPv2 MD5 authentication success
2025-01-31T06:39:01Z RIP: [N4CEB-XCAK5] Terminating on signal

-----First packet after restart of the RIP daemon-----
2025-01-31T06:39:02Z RIP: [NDAGH-Z85V7] rip_send_packet 11.11.11.11 > 224.0.0.9 (Port2)
2025-01-31T06:39:02Z RIP: [NDAGH-Z85V7] rip_send_packet 94.94.94.94 > 224.0.0.9 (Port4)
2025-01-31T06:39:05Z RIP: [NDAGH-Z85V7] rip_send_packet 11.11.11.11 > 224.0.0.9 (Port2)
2025-01-31T06:39:05Z RIP: [G4HZH-53B3V] SEND RESPONSE version 2 packet size 64
2025-01-31T06:39:05Z RIP: [NV3Q6-5S5XW] family 0xFFFF type 3 (MD5 authentication)
2025-01-31T06:39:05Z RIP: [JRENT-C3G18] RIP-2 packet len 44 Key ID 1 Auth Data len 20
2025-01-31T06:39:05Z RIP: [Y55WS-JJ0CY] Sequence Number 1
2025-01-31T06:39:05Z RIP: [XHCQJ-PBD83] 94.94.94.0/24 -> 0.0.0.0 family 2 tag 0 metric 1
2025-01-31T06:39:05Z RIP: [VER1M-YZK0G] family 0xFFFF type 1 (MD5 data)
2025-01-31T06:39:05Z RIP: [GZHT4-3KF9V] MD5: 7D853255CBD8339915BAA362BEBADB8D
2025-01-31T06:39:05Z RIP: [NDAGH-Z85V7] rip_send_packet 94.94.94.94 > 224.0.0.9 (Port4)
2025-01-31T06:39:05Z RIP: [G4HZH-53B3V] SEND RESPONSE version 2 packet size 24
2025-01-31T06:39:05Z RIP: [XHCQJ-PBD83] 11.11.11.0/24 -> 0.0.0.0 family 2 tag 0 metric 1
2025-01-31T06:39:07Z RIP: [KQRFA-9A2E8] rip_read: cannot find interface for packet from 120.120.120.100 port 520 (VRF default)
2025-01-31T06:39:07Z RIP: [P2JVH-8PCQ6] RIPv2 MD5 authentication success

Version

FRRouting 8.4.2 (localhost) on Linux(4.14.336).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

How to reproduce

1. Establish RIP connection between two peers
2. Share routes from a peer to the other
3. Enable debug logs
4. Restart the peer or RIP daemon on the peer which is sharing the routes to the other
5. Check the sequence number which would be set 1 rather than 0 or the time value

Expected behavior

1. The sequence number should start with 0 or a value greater than the previously sent
2. The packet should be rejected if the sequence number is not zero or the greater than the previoulsy sent

Actual behavior

1. The sequence number starts with 1
2. Packets are accepted even the sequence number is not greater than previously sent

Additional context

Although it works fine when both peers are running FRRouting, it is causing problem in interop tests with other vendors.

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[eqvinox]

While you are technically correct on this, the first RIP packet after a restart is also easily lost for example due to ethernet bridge state still converging in STP. The RFC rule to accept sequence number 0 in this regard is notably a SHOULD:

       When connectivity to the neighbor has been lost, the receiver
       SHOULD be ready to accept either:

         - a message with a sequence number of zero.

         - a message with a higher sequence number than the last
           received sequence number.

And it is a really bad idea to only accept 0 there and not e.g. anything below some small number.

That said the best fix here is to implement saving the sequence number, ospf6d already does this (look for frr_daemon_state_save in the code.) We'd be happy to review a PR that implements that. To prevent disk write cycle exhaustion, only the upper e.g. 16 bit of the sequence number should be saved (such that some sequence numbers to be skipped on restart, but that is fine.)

[ton31337]

Related: #16233.

[eqvinox]

Ah, right, it's already fixed on frr ≥ 9.0. We have still pushed some fixes to 8.4 but not sure this qualifies.