AP_Stats: Ignore fraudulent posts

[muramura]

I was able to set the BOOT COUNT in APM PLANNER2.
I was not able to set FLIGHT TIME and RUN TIME.
I think that BOOT COUNT is the same as FLIGHT TIME and RUN TIME.

[khancyr]

Make sense, maybe we should also mark all the parameters as AP_PARAM_FLAG_INTERNAL_USE_ONLY ?

[muramura]

@khancyr san.
Config Parameters RESET is written to initialize other parameters.
The other parameters are READ ONLY.

[magicrub]

In the old days we used boot_count=0 to trigger a factory reset.

[peterbarker]

@muramura this should also be marked as @ReadOnly in the parameter metadata

As far as I can see this PR simply doesn't work; I can reset the parameters just fine. The crucial thing with flttime and runtime is that these stats are updated within the stats library so are periodically rewritten. Technically there's a race condition between someone setting the parameters by hand and us writing fresh statistics out. This wasn't ever supposed to be protection against malicious actors....

We should probably add the internal-use-only flag as @khancyr suggests. Note that still won't stop users changing the parameter if they really want to - it makes it less likely to be overwritten, 'though.

[peterbarker]

In the old days we used boot_count=0 to trigger a factory reset.

AFAIK ArduPilot's never done that :-)

[peterbarker]

@amilcarlucas I think you're one of the few people who've provided feedback on stats. Do you see any problems in disallowing the set of STAT_BOOTCOUNT as a parameter?

[amilcarlucas]

Hello Peter. No, I see no drawbacks. I think it should have been a read-only parameter since day one.

I actually have a PR that only changes the stats only on very specific circunstances:

// Only reset statistics if the user explicitly sets AP_STATS_RESET parameter to zero.
// This allows users to load parameter files (in MP, MAVProxy or any other GCS) without
// accidentally reseting the statistics, because the AP_STATS_RESET value contained in
// the parameter file will be ignored (unless it is zero and it is usually not zero).
// The other statistics parameters are read-only, and the GCS should be clever enough to not set those.

but that never got merged.

[peterbarker]

This approach is flawed. There's a race condition between the user writing the parameter and this code triggering, setting the thing back to the expected value.

As @amilcarlucas points out, this could probably be set to @readonly.

I'm going to close this one, but a PR along the other lines might be good.