dragonresearch / rpki.net

Dragon Research Labs rpki.net RPKI toolkit
54 stars 30 forks source link

rpki-rtr version negotiation not working quite as expected #711

Closed sraustein closed 10 years ago

sraustein commented 10 years ago

This probably only affects our rpki-rtr client code, and only when stable storage (sql) is enabled.

{{{ sra@minas-ithil> ./rpki-rtr client --sql foo.db --force-version 0 loopback localhost 0 2014-06-11T03:47:11Z rpki-rtr/client[4885] [Startup] 2014-06-11T03:47:11Z rpki-rtr/client[4885] [Using direct subprocess kludge for testing] 2014-06-11T03:47:11Z rpki-rtr/client[4885] [Session 1 version 0 nonce None serial None refresh 3600 retry 600 expire 7200 updated 1970-01-01T00:00:00Z] 2014-06-11T03:47:11Z rpki-rtr/client[4885] [ResetQueryPDU] 2014-06-11T03:47:11Z rpki-rtr/client[4885] [Last client poll 2014-06-11T03:47:11Z, next 2014-06-11T03:57:11Z] 2014-06-11T03:47:11Z rpki-rtr/client[4885] [CacheResponsePDU, nonce 35451] 2014-06-11T03:47:11Z rpki-rtr/client[4885] [Nonce changed, resetting] 2014-06-11T03:47:11Z rpki-rtr/client[4885] + 3320 79.192.0.0/10-10 00:04:00:00:00:00:00:14:01:0A:0A:00:4F:C0:00:00:00:00:0C:F8 2014-06-11T03:47:11Z rpki-rtr/client[4885] + 3320 84.128.0.0/10-10 00:04:00:00:00:00:00:14:01:0A:0A:00:54:80:00:00:00:00:0C:F8 2014-06-11T03:47:11Z rpki-rtr/client[4885] + 3320 87.128.0.0/10-10 00:04:00:00:00:00:00:14:01:0A:0A:00:57:80:00:00:00:00:0C:F8 ^C

sra@minas-ithil> ./rpki-rtr client --sql foo.db --force-version 1 loopback localhost 0 2014-06-11T03:47:19Z rpki-rtr/client[4887] [Startup] 2014-06-11T03:47:19Z rpki-rtr/client[4887] [Using direct subprocess kludge for testing] Traceback (most recent call last): File "./rpki-rtr", line 23, in main() File "/Users/sra/rpki/subvert-rpki.hactrn.net/trunk/rp/rpki-rtr/rpki/rtr/main.py", line 94, in main return args.func(args) File "/Users/sra/rpki/subvert-rpki.hactrn.net/trunk/rp/rpki-rtr/rpki/rtr/client.py", line 464, in client_main client.setup_sql(args.sql_database) File "/Users/sra/rpki/subvert-rpki.hactrn.net/trunk/rp/rpki-rtr/rpki/rtr/client.py", line 329, in setup_sql self.version = version File "/Users/sra/rpki/subvert-rpki.hactrn.net/trunk/rp/rpki-rtr/rpki/rtr/channels.py", line 152, in version self.reader.check_version(version) File "/Users/sra/rpki/subvert-rpki.hactrn.net/trunk/rp/rpki-rtr/rpki/rtr/channels.py", line 124, in check_version "Received PDU version %d, expected %d" % (version, self.version)) rpki.rtr.pdus.CorruptData: Received PDU version 0, expected 1 }}}

The first session works as expected. The second blows out because of the version mismatch between SQL and --force-version. Not the expected behavior.

This might just mean that the SQL setup code needs to check whether a version is already set when figuring out which session entry to reuse.

Trac ticket #699 component rpki-rtr priority minor, owner sra, created by sra on 2014-06-11T04:00:06Z, last modified 2014-06-11T18:22:06Z

sraustein commented 10 years ago

The immediate problem is indeed that the SQL lookup doesn't allow for the possibility of a version override, but it turns out that there is a minor architectural issue lurking here.

We define a session as being unique to a particular (host, port) pair, so while we track the version used in a session, we don't allow there to be two sessions for the same (host, port) pair with different version numbers. This is probably correct.

This means that, when given an explicit version number by the user and we already have a session to the same (host, port) with a different version, our only choices are either to blow away the existing session or refuse to start. I'm going with the first option.

Trac comment by sra on 2014-06-11T17:24:41Z

sraustein commented 10 years ago

In [changeset:"5865"]: {{{

!CommitTicketReference repository="" revision="5865"

Handle version mis-match when forcing protocol version. Closes #699. }}}

Trac comment by sra on 2014-06-11T18:22:06Z

sraustein commented 10 years ago

Closed with resolution fixed