@pmueller and @spikerguy:
I didn’t want to open the discussion about best processor architectures once more.
Just wanted to explain, why it isn’t such easy as many users think.
We live in a world where nearly everybody uses a microcomputer, capable of (nearly) everything: surfing, communicating per messenger and phone, …
But this is possible, because companies pay some money to develop devices they can sell in big quantities.
An open source project with non-profit developpers, like IPFire; must concentrate on the available ressources. The history of IPCop and IPFire is based in the reuse of hardware. This was mainly Intel based.
As more and more boards with other processors/controlers appear, which are more or less well-documented, it is worth a discussion and a call for support on other HW bases.
Maybee but i think also the serial console is not correct configured. The Rockchip platform is enabled in kernel but im not sure if 4.14 support the specific soc.
for debuging you should set matching earlyprintk parameters in the kernel config and also add earlyprintk to the kernel commandline in uboot.
I also have the NanoPi R2S on my list but it has no priority because one of the nic’s is connected via usb which may produce heavy cpu load. I have a USB to LAN adapter with the same chipset that cannot reach full speed with a 2Ghz Quadcore Intel system so i fear this will not perform well.
For small applications I suggest the NanoPi R1 (without S) it is 32bit arm7 quadcore 1GB Ram two LAN (one 1GBit and one 100Mbit) and 1wlan. Which is full supported by IPFire.
I did find the dtb for a similar soc so it should be supported and I also found the kernel config file which is used so I will look into it to see if the config file have the required configs needed for rk3328 soc.
We can know this only after trying.
If we already have full support for this then I might order one of this also.
Can you help me in understanding what are the additional config needed to harden the kernel, I can do a diff but it is better to understand the config in specific to know the reason for its users.
I see that the nightly image have many boot scripts I will try to go through it one by one and see what is it for.
That depends on what you define as cheap. The plastic ISP routers are not much cheaper either.
And under no circumstances they consume 40W. You max our at 10W and usually would be in the 6W region. A Raspberry Pi consumes the same.
Used hardware is always an option. However when a whole business relies on it, you would have to consider the cost of an outage when a ten year old power supply unit dies. That is the risk there.
That board has one network controller and a switch. All ports share the bandwidth which is not acceptable to me.
And this again is the general issue I am complaining about. This board is available for years now and still does not work with a stock distribution.
Same, but no matter what it is what people buy.
A clustered firewall?
Why not? That is exactly our problem here. Not the technical differences of the architectures.
But in the end IPFire will only run well when the hardware underneath the software does a good job, too. Now we have a totally fragmented ARM market making every update a gamble. Intel is full of security issues and does not care a bit about fixing them - neither in their old products nor the new ones. RISC-V simply has no production-grade products available, yet.
So what is left? If there is no clear “good” product, people will at least choose cheap and then invest into an upgrade as soon as they can. Fine. That works for some (@Roberto), but I am not sure if that is general way to run IPFire in a business, or for me, even at home.
I am sure that we all can agree on wanting a better world, but we alone are not the people who can make that happen. To be honest - I do not want to deal with hardware at all. I want something that just works.
I do not think anyone wants to drop ARM. We are going to drop ARM 32 bit in IPFire 3, but that is another story.
I was just suggesting that I do not want to put any more resources into it, but the community seems to disagree which is fine with me.
Proprietary, binary, sometimes even encrypted boot loaders are a no-go for us. Samsungs stuff is full of them. We have no idea what is in it and if you want to remotely trust your hardware, we just gotta know.
What do you need? Since there is another thread on this, maybe consider asking the question there.
I have it since a year now and it is just lying around, there is uboot and linux support provided by 1 community developer and mtk dev who works on it as part time.
Yes as they are very cheap and have good support from rpi foundation as they do maintain their own distro which have almost everything needed for most use cases.
Yes a cluster which can be used for computation as a firewall. There are core boards which can take multiple daughter boards and combine the professing.
I am learning the build process slowly.
Now I need to know how to build pkgfire package so I can get uboot and kernel for the device and then try to build ipfire along with it.
That might be true, but that isn’t really open source done right, is it?
No, this makes no sense. You will need bus throughput, you will need very high single-core performance. You cannot parallelise everything. Latency matters. Sending a packet to another processor core already takes too long.
Have a look at “lfs/linux” and “lfs/u-boot” in your source directory.
Michael, I agree with you, but as it is said in Spain: “No tienes para pan y quieres comprar jamón” I am trying to provide a Security solution to a niche market which, I doubt very much can buy a Ferrari.
I speak of an Electrician, a Plumber, A small store that the one that attends is the owner, those types of Freelancers who do not have or do not want to have computer knowledge and less in security.
I understand that for Clients who have economic capacity, we must equip them with equipment that can meet the needs at all times and respond at specific times. I have two Clients with more than 50 Users which I put an HP Proliant Micro-Server and they work perfectly. For the rest, the APUs are perfect, but what can be put in this market niche that we are talking about? Nothing?. An antivirus on the PC ?. A picture of the guardian angels? We have to give some answer.
I fully understand your posture but this type of Client is a reality and as much as we do like ostriches, they will still be there. If we do nothing, they will always be vulnerable.
With this I don’t want to make a bad review or anything like that, it is so that you see different points of view for different needs. I can only thank you for this wonderful product that is IPFire.
However, I think that it is important to make sure that if you run IPFire in those businesses you need to make sure that the system is regularly updated, checked for any problems, security breaches and so on. This will take time and I suppose you will have to be paid for it.
Just installing it and then leaving it won’t make the network secure. It probably does the opposite.
So it is an investment to run a business. If you cannot budget for this, you should probably give up your business. For me it sounds a bit like opening a restaurant but you cannot afford the cleaner. There is certain things that just have to be there. Otherwise you are in big trouble.
And to put the icing on the cake: You should still urge those people to set up a monthly donation to the project. They would otherwise buy something that costs a lot of money. Here, they get something for free. I am sure that they can afford a 5 EUR monthly donation to keep us going.
Yes, all my machines are installed as an Annual Payment Service. Within the Service they have the advice and maintenance of the machine. Hence getting hardware for that niche that gives certain profit margins. The Nano R2s seems cheap and feasible for those types of Clients although it is not the most powerful and recommended on the market.
A question Michael about donations (I ask it in another thread so as not to contaminate this one).
The build process is still going on.
It have been more than 12hours now. It is still building, I think it would be better to just build kernel and uboot instead of building all the packages again, but yea LFS
Any ways it is still building, Is there any way I can re-use the pre-compiled packages and only build kernel and uboot for the specific device?
I have found the file used to build pkgfire for linux and uboot from git. It is new way of packaging for me.
Let me know if there is any short cuts just for testing purpose.
Thanks.
Yeah, it can take around that time on a SBC. We use cloud servers which build the whole distribution in about 1:33 hrs.
The build system is going to be replaced in the future that no longer requires to build the whole distribution all in one. But we are stuck with it for now.
The second time you build this, you will take advantage of the compiler cache that you have built in the first pass.
And you can simply delete the log files in log/ for the package that you want to rebuild and run ./make.sh build again. I would not recommend to build anything by hand because you will lack all compiler flags and optimisations and of course in the end the build process needs to be scripted and repeatable.
Currently we are on 4.14 and we have no short-term plans to change that.
The main reason for being on this kernel is that it is an LTS kernel which is required for our purposes and that we have invested so much time to get all ARM hardware to run on it. Jumping to a new kernel would be a lot of work and since @arne_f is the only one working on the hardware ports, there is not enough man power available to jump to every LTS kernel.
We are expecting 5.9 to be the next LTS kernel and are looking to migrate to this one.
I’ve tried to build all the packages and it took another day to get the rest to build but now I’ve got busy with other project in hand and also the fact that my build devices hdmi port stopped working
I will continue with this soon. I also found 4.14 kernel branch for the device I have, can I use it for ipfire?
I strongly suggest to enable Fireinfo. At the moment we have only 6 NanoPi R1/R1s so this may the reason for droping future support.
Not directly but it is helpfull. You can try to checkout my 4.14-multi branch and merge the device branch to create a new diff. (And hope that it is not to heavy patched.)
Hello,
I’ve been busy lately but I have a long weekend ahead, so will be looking into the kernel for the device.
My R1 is on the way and I hope I get it before my long weekend to play around with.
Also getting R2S both will be for ipfire and opnsense. Let’s see if we can get ipfire to work on it and how will it works.
