<div dir="ltr"><div><div><div><div><div>Hello again,<br><br></div>Error 1:<br><br></div>You are right, it seems that quagga (ripd) really sends two packets when it starts - the first one is unencrypted with metric 16, the others are properly encrypted.<br></div><br>tcpdump output on the machine running quagga:<br><br><div style="margin-left:40px"># tcpdump -i any port 520 -vvnn<br>tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes<br>15:06:46.408403 IP (tos 0xc0, ttl 1, id 17048, offset 0, flags [DF], proto UDP (17), length 52)<br>    172.16.0.9.520 > 224.0.0.9.520: [bad udp cksum 0x8c54 -> 0x6e69!] <br>        RIPv2, Request, length: 24, routes: 1 or less<br>          AFI 0,         <a href="http://0.0.0.0/0">0.0.0.0/0</a> , tag 0x0000, metric: 16, next-hop: self<br>        0x0000:  0102 0000 0000 0000 0000 0000 0000 0000<br>        0x0010:  0000 0000 0000 0010<br>15:06:46.408488 IP (tos 0xc0, ttl 1, id 17049, offset 0, flags [DF], proto UDP (17), length 92)<br>    172.16.0.9.520 > 224.0.0.9.520: [bad udp cksum 0x8c7c -> 0xe9db!] <br>        RIPv2, Response, length: 64, routes: 3 or less<br>          Simple Text Authentication data: test....<br>          AFI IPv4,        <a href="http://10.0.4.0/24">10.0.4.0/24</a>, tag 0x0000, metric: 1, next-hop: self<br>          AFI IPv4,      <a href="http://10.10.11.0/24">10.10.11.0/24</a>, tag 0x0000, metric: 1, next-hop: self<br>        0x0000:  0202 0000 ffff 0002 5365 6331 3233 2124<br>        0x0010:  2f28 2923 0000 0000 0002 0000 0a00 0400<br>        0x0020:  ffff ff00 0000 0000 0000 0001 0002 0000<br>        0x0030:  0a0a 0b00 ffff ff00 0000 0000 0000 0001<br>15:06:56.328594 IP (tos 0xc0, ttl 1, id 10361, offset 0, flags [none], proto UDP (17), length 112)<br>    172.16.0.4.520 > 224.0.0.9.520: [udp sum ok] <br>        RIPv2, Response, length: 84, routes: 4 or less<br>          Simple Text Authentication data: test....<br>          AFI IPv4,        <a href="http://10.2.4.1/32">10.2.4.1/32</a>, tag 0x0000, metric: 1, next-hop: self<br>          AFI IPv4,        <a href="http://10.0.4.0/24">10.0.4.0/24</a>, tag 0x0000, metric: 1, next-hop: self<br>          AFI IPv4,      <a href="http://172.16.0.0/24">172.16.0.0/24</a>, tag 0x0000, metric: 1, next-hop: self<br>        0x0000:  0202 0000 ffff 0002 5365 6331 3233 2124<br>        0x0010:  2f28 2923 0000 0000 0002 0000 0a02 0401<br>        0x0020:  ffff ffff 0000 0000 0000 0001 0002 0000<br>        0x0030:  0a00 0400 ffff ff00 0000 0000 0000 0001<br>        0x0040:  0002 0000 ac10 0000 ffff ff00 0000 0000<br>        0x0050:  0000 0001<br></div><br></div>The same happens if ripd is configured with MD5 authentication.<br><br></div><div>Error 2: <br><br></div><div>Just a notice - in the documentation you find that 'id' format is allowed in the range 0-255. But 0 is not configurable.<br><br></div><div>Thanks,<br></div><div>Alexander Velkov<br></div><div><br></div><br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 23, 2016 at 1:14 PM, Ondrej Zajicek <span dir="ltr"><<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jun 23, 2016 at 11:41:18AM +0200, Alexander Velkov wrote:<br>
> Hello,<br>
><br>
> I have some issues with configuring RIP 'authentication'.<br>
> I connect a bird v1.6.0 running on an ARM machine with a quagga v0.99.23.1<br>
> on a 64bit Ubuntu 14.04 machine.<br>
><br>
</span>> *Plaintext* (authentication plaintext):<br>
<span class="">><br>
>   ERROR - bird writes erroneous auth error msg.<br>
>   the two peers connect successfully and exchange routes, but bird writes<br>
> auth error msg -<br>
>   'bird: RIP: Authentication failed for 172.16.0.9 on eth0 - wrong password<br>
> (0)'<br>
>   Maybe, a variable was not correctly set at init ?<br>
<br>
</span>Hello<br>
<br>
It seems to me that quagga sends two packets, first (at 15:21:34,<br>
presumably without authentication) was rejected, second (at 15:21:35,<br>
presumably with password) was accepted and contains routes.<br>
<br>
See:<br>
<span class=""><br>
> Jun 22 15:21:34 AVILA debug bird: RIP: New neighbor 172.16.0.9 on eth0<br>
> Jun 22 15:21:34 AVILA err   bird: RIP: Authentication failed for 172.16.0.9<br>
> on eth0 - wrong password (0)<br>
...<br>
</span><span class="">> Jun 22 15:21:35 AVILA debug bird: RIP: Response received from 172.16.0.9 on<br>
> eth0<br>
> Jun 22 15:21:35 AVILA debug bird: RIP > added <a href="http://10.0.4.0/24" rel="noreferrer" target="_blank">10.0.4.0/24</a> via 172.16.0.9 on<br>
> eth0<br>
<br>
</span>Could you verify that, e.g. with tcpdump?<br>
<br>
<br>
> *Cryptographic* (authentication cryptographic):<br>
<span class="">><br>
>   ERROR 1 - peers cannot connect with "id 0".<br>
>   The ripd keychain allows setting 'key 0' but bird does not - error<br>
> 'Password ID has to be greated than zero.'<br>
<br>
</span>That is true, for some reason BIRD does not allow key id 0 (for both RIP<br>
and OSPF crypto authentication) and uses id 1 by default. I will check if<br>
there is a reason for that.<br>
<span class=""><br>
<br>
>   If I omit setting id parameter (passwords{password "secret"; password<br>
> 'secret2'; password 'secret 3'}), then the peer authentication is not<br>
> successful.<br>
<br>
</span>In that case BIRD uses IDs 1,2,3, while Quagga is configured with IDs 0,1,2,<br>
therefore keys are not properly matched.<br>
<span class=""><br>
<br>
>   ERROR 2 - On successful md5 authentication (using different keys), bird<br>
> writes again false error messages.<br>
<br>
</span>Probably the same issue like in the first case?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</div></div></blockquote></div><br></div>