Unexpected RIP route output with Bird 2.0.11 vs Bird 2.0.10

[Maria Matejka]

On 12/14/22 19:01, Ondrej Zajicek wrote:
> On Wed, Dec 14, 2022 at 06:36:06PM +0100, Maria Matejka via Bird-users wrote:
>>> During testing of Bird 2.0.11 I noticed something a bit odd in terms of
>>> the output for RIP routes, is the below  "RIP.02" and "<type 16>"
>>> expected?
>>>
>>> 0001 BIRD 2.0.11 ready.
>>> 1007-Table t_kernel4:
>>>    192.168.21.0/24      unicast [rip4 2022-12-14 15:03:21] * (120/3)
>>>       via 192.168.0.2 on eth0
>>> 1008-    Type: RIP univ
>>> 1012-    RIP.metric: 3
>>>       RIP.tag: 0000
>>>       RIP.02: *<type 16>*
>>
>> It's not expected to be written out, yet it's harmless otherwise. That
>> attribute has always been there, just hidden. It looks like an incomplete
>> backport of internal refactoring from v3 made it through to 2.0.11 and this
>> attribute got unwantedly unhidden.
> 
> Seems like similar issue is in Babel with seqno attribute, but it presents differently:
> 
> 10.7.11.0/24         unicast [babel1 18:47:17.708 from fe80::b881:37ff:fe9f:ebc5] * (130/354) [00:00:00:00:0a:00:00:07]
>      via 10.0.1.1 on ve2
>      Type: Babel univ
>      Babel.metric: 354
>      Babel.router_id: 00:00:00:00:0a:00:00:07
>      Babel.

OMG, what the hell got there.

> We definitely should improve tests for checking not only 'show route'
> output, but full 'show route all'.
Definitely we shall. I think "autotest improvement" is gonna be one of 
the most prominent items of our todo list for 2023.

Maria
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2839 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221214/a550cc92/attachment.p7s>