Previously StayRTR would copy the client's Session ID back into the Cache
Response send to the router, even though the cache's internal Session ID
was something different.
The purpose of the Session ID is to help both router and cache understand
whether they are synchronized or not. There are two opportunities to fix
desyncs: if the cache recognises the router is desynced, the cache informs
the router (through an Error Report) to reconnect and send a Reset Query.
If the router recognises it is out of sync with the cache, the router can
send a Reset Query.
According to RFC 8210 section 5.1 the cache should send "Corrupt Data" when
a router sends a Serial Query with an unknown Session ID:
```
Session ID: A 16-bit unsigned integer. When a cache server is
started, it generates a Session ID to identify the instance of the
cache and to bind it to the sequence of Serial Numbers that cache
instance will generate. This allows the router to restart a
failed session knowing that the Serial Number it is using is
commensurate with that of the cache. If, at any time after the
protocol version has been negotiated (Section 7), either the
router or the cache finds that the value of the Session ID is not
the same as the other's, the party which detects the mismatch MUST
immediately terminate the session with an Error Report PDU with
code 0 ("Corrupt Data"), and the router MUST flush all data
learned from that cache.
```
Reformat with gofmt from Ties
Previously if you had a very slow backend, the refresh timer for a reload
would only start after the current refresh has finished.
Now the timer will run after the timer fires for the last one.
This helps avoid the client being torpedod by very slow backends
Tag: https://github.com/bgp/stayrtr/issues/53
First, VRPs that have expiry times are now checked, and they are
filtered out at import time.
Second, If a VRP JSON file is too old, and the "current state"
(in the case of a update) is too old, the state will empty to avoid
routing on old data.
Third, Every time a refresh cycle now happens, the file is reprocessed
to check for expiry, if the resulting VRPs from that procesing changes
then a new update+serial is pushed
Tag: https://github.com/bgp/stayrtr/issues/15
We right now have two different ways of packaging stuff up, one
involves a Makefile and one involves https://goreleaser.com/
I was having issues with goreleaser outputing binaries in /usr/local/bin
rather than /usr/bin (To the best of my understanding, /usr/local/
is for stuff outside of the package managers remit, however we are
producing things that /are/ inside that)
Rather than fight with goreleaser, it's better to look at we have
two different ways, and the Makefile is a lot more approchable than
goreleaser (at least, strongly likely to the average person just
wanting to build the thing ™️)
Right now CI produces deb's and rpm's, and pushes a docker image to
https://hub.docker.com/r/rpki/stayrtr
I think that is likely good enough ™️ for now.
Seemingly a FPM bug? I poked around in FPM for a while and /could
not/ get it to actually use --package at all, nor it's little -P.
So a quite move back into place should solve it instead.
Mildly Related Tag: https://github.com/bgp/stayrtr/issues/58
The package installs in /usr/bin/ but the systemd unit starts
a binary (that wont exist) in /usr/local/bin
Sinec this service file is only ever mentioned in the Makefile
for packaging, I belive this is a bug fix that has no other side
effects.
The strings.HasPrefix() call was used with flipped argument order,
allowing incomplete rows in the authorized_keys file to any key matching
that prefix. In worst case, a line like
ecdsa-sha2-nistp256
with no key at all would match all keys of that type.
On the other hand, when the key was followed by a comment as is common
in authorized_keys files, it wasn't matched at all.
When a VRP disappears from one input, but it still present in the
other input, an immediate difference between sources is created.
This commits adds a grace period during which elements that disappear
do not cause alerts (yet).
