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