After upgrading to 7.20beta2 my IPSec tunnel to a Proton server is failing with:
digital signature verification failed
Advice?
Move back to 7.19.1
Perhaps good idea. But I’d at least “Make supout.rif” before downgrading, so you can report it if desired.
Another option is to enable more IPSec logging in /system/logging/add topics=ipsec,!raw which might have some clues on what causing it. (And if you capture the supout.rif AFTER adding logging, you’d at least save potential clues for MT support).
I also encounter this
Just showed up digital signature verification failed
Perhaps you should NOT use “S” as /container flag for STOPPED as it “conflicts” the the usual “slave”/etc & started also starts with letter “S”.
While “flag letters” may overlap in other places, this one confuses me (now perhaps just history that “no flag means not working”, but still S means slave or static, not also stop or wrongly start). And the new red “exited with” comments, it’s pretty obvious it’s stopped – so flag is kinda redundant given that feature .
I’d prefer “stopped” state did not have a flag – which may be an a good idea before the stopped reason were also added. But perhaps used something different/“unusual” like lower-case “s” or “x” be fine too. Or if there is no exit code but stopped, that could be a “red comment” that says “stopped”.
But the already overload “S” flag does NOT need any more. And IMO the “transitory” container states like “extracting”/“stopping”/“starting” could be also be lower case – which convey the “-ing” part more clearly.
I had some containers working (including a faucet container, see posting* above)… Not anymore.
I downgraded to 7.19.1 to test something, and the upgraded back to 7.20beta2 — however my containers all disappeared. I know it’s beta & been lot of [good] changes in this release for containers… BUT… it’s not always easy to re-create them & doubly annoying since the root files are still on disk — and there is no config to “recover” them using the existing root-dir on disk when adding back container config.
* But thankfully I did write a script to “reincarnate” the Faucet /container, including some hideous :delay usage, but it did bring up everything again, after adding MORE :delay time
It’s taking a long time to release a 7.20beta3, isn’t it?
They’re going to take forever to release betas, which should be frequent.
And they’re going to speed up RCs and stable, which should be very cautious.
How long did the last RC before the stable version of 7.18 (the one with the ROSE Data Server) last? Was it more than 48 hours?
Stable betas are the foundation of any stable release.
Difference between beta and RC is very small … RC is beta that developers consider to be almost ready for release. Neither are stable and RC doesn’t have to be any better than preceeding betas. Active development still goes on during beta testing, it’s just that focus shifts (or at least should IMO) to fixing bugs in RC stage.
If there are bugs in RC which should be fixed before release, and are harder to crack, then it’s normal not to see frequent RCs. And it’s probably not feasible to release RC for every bug fixed. Specially so if bug is easy to replicate so devs can verify the fix easily.
Hopefully they are working on 7.19.2 instead!
I’m a “bazaar guy” myself, not a “cathedral one”. But I must admit: I’m finding this “new” Mikrotik cadence MUCH better than the previous “oh dear, here we go again” previous one.
Case in point: Mikrotik have just closed two bugs I opened. Both were marked as “solved”. True, they were simple bugs. But one of them was solved in 2 days (!). Another one took about 2 months. I’m fine with this: slow and steady is FAR better than “go fast and break things”.
Also, since I’m a sys admin, I’m heavily biased towards “more boring is more better”. So there’s that. Give me stable and monotonous every time of the week. The more boring, the “more better” - screaming and frights belong to an Amusement Park, not my systems.
Both, probably? I don’t see 7.20.0 getting released before 7.19.2.
1 Like
+1
Its supposed to be a beta. Not an “alpha”/nightly.
If you want nightly check the nightly: mt.lv/nightly-build
I know MikroTik uses Box for “cloud files” sometimes… But the nightly build seem like an ideal way to “dogfood” their own “back-to-home-files”… #self-hosting
If they ran into usability/missing features/bugs with back-to-home-files themselves all the better. But back-to-home-files UI is cleaner/nicer IMO than Box’s public view, and think it supports everything they’re using in Box.
1 Like
Mikrotik is already dogfooding their RDS. I suppose TikTube is running in a container for example. That’s probably why we see so many changelog items in these areas.
It be a good application for RDS… but is that what it’s actually running?
If so, I just hope they don’t need to downgrade from this beta, otherwise possible the container gets “lost”/removed. 
Newsletter #125 it says: “Runs entirely on our own RDS and hardware”
Maybe it can run back-to-home-files to start replacing Box.com too 
in RB5009 with 7.20 beta 2, if i enable VLAN filtering performances are very poor, if i disable it performances are regulary.
with VLAN Filtering
https://eolo.speedtestcustom.com/result/9882dd60-4759-11f0-aa17-af6d9a99bf80
without VLAN Filtering
https://eolo.speedtestcustom.com/result/1d8bb810-475a-11f0-bd84-a1780d4ad900
Different from previous versions?
Any queues running on specific VLAN’s?
Config might be helpfull.