Can you explain what you mean by that?
And why is the technical wiki password protected?
Huh? How is one free to compile and use anything they want, yet also required to use the existing firmware? That makes no linguistic sense.
So how would an informed person decide if they want to be a customer, when the key technical information (vs glossy marketing sheet) is hidden from them?
Or do you only try to sell to those with no previous LoRaWAN awareness?
Who exactly are you trying to keep out? Surely not competitors, who could simply buy a box to take apart
What part can’t one recompile?
Do you comply with the license terms of those? Are you aware that, unless you ship the correspond source with the product and each binary update thereof, that means you have to make sources available to anyone and not just your customers?
That’s precisely why an informed user would need to see all of the available information before making a decision.
Keep in mind you walked into a discussion that was covering precisely these kind of details of other gateways, nominated your product as an alternative, and said it had “open firmware”
…except some apparently critical part you refuse identify, which we’re not actually free to change…
As above, the part we’re not allowed to recompile if your version of it doesn’t meet our needs.
So I’m not allowed to change any of those? In that case, how can I change or add anything at all?
The only reason this is going in circles is because you persist in dodging the question of what aspects of the functionality one can vs. cannot change.
Have you really never had experienced Embedded Linux developers as customers?
Showstopper, no way is such an unmaintainable platform a sound investment.
Just about everyone else has you beat there, and it’s not even something you would have needed to do (since actually, you do have to release the build scripts even if the box refuses to boot the result), but simply something you would have needed not to, which is enable signature enforcement.
It rather sounds like you don’t really understand the technical mechanism behind your claim that the kernel can’t be replaced.
Since the Linux kernel’s license requires that you let people build new kernels, and you literally have to provide the scripts used to do so, it can’t be that.
What you can do, if you want to prevent customer maintenance of their gateway fleet (and it sounds like you do) is use a code signing mechanism to prevent the box from being willing to run those kernels.
But then you go and say:
Which implies that you actually do let the customer uses the code signing mechaism to their advantage.
So we’re back to the non-answer territory.
I have moved these messages to a new topic to allow the topic to focus in the original question and answers to it.
So I can install my own kernel build after all?
Or is it that your employer actually is using code signing to prevent a customer (or yes, anyone else) from installing their self-built kernel?
So if it’s disabled by default, then unless the customer enables it, the customer can install their own kernels?
These are entirely normal, everyday, and critical questions in the world of Embedded Linux devices.
So what exactly is the mechanism which prevents the customer from installing their own kernel?
Surely it’s not missing the pieces to build one, as that would be license violation. And you say it’s not code signing, as that is not enabled…
It’s a simple technical question, which you’ve spent all day doing everything but actually answer…
As you’ve still not provided a technical answer to any of those which did not immediately contradict itself, yes
Is it actually code signing which prevents a customer’s kernel from booting or being flashed, while yours built from the same sources can be?
If not, what is it?
And if customers chose to load firmware that isn’t signed? Or is signed by themselves not Kerlink?
Oh that’s right, customer’s don’t have a choice.
Except, you still haven’t actually answered the simplest question…
Right now you are hinting, but not quite literally saying that signature enforcement is enabled.
But earlier in this thread, you quite explicitly said signature enforcement was off by default. (“This feature is disabled by default.”)
So which is it?
Or are you going, again, to refuse to state an unambiguous answer?
Why is making a simple statement of facts such a challenge?
Why these hours and hours of dancing around, but never actually being willing to stand by any simple statement of fact?
If it is in fact signature enforcement that prevents flashing or booting a customer’s own kernel build, why is it that you have spent hours and hours and hours avoiding simply saying so?
Please, no more of this doublespeak “customers may chose…”
Just admit the truth: “Kerlink’s box will only boot kernels signed by Kerlink”
Why is that so hard?
You could have done so hours ago, but preferred to dance around in circles rather than commit to a simple fact.
Why?
So if I don’t enable it, then actually I can flash my own custom kernel build from your your sources, and it will boot and run?
I, or more exactly, my clients, are extremely interested if the capabilities meet our needs.
But we don’t seem to be able to get a straight answer about what those are…
First you say we can’t boot our own kernel, then you say we can.
One or the other, it’s way past time to pick your truth.
Until you give a straight honest answer why not.
If it’s not code signing, what is it? Surely not incomplete GPL sources…
And what is the technical mechanism which prevents the box from booting my kernel, if not missing source code or code signing?
Do you not know?
Or are you not allowed to say?