Offline Update Possibility

Hi guys,

Apologies, if I have missed it: Is there an option to update IPFire offline (like QNAP or OpenWRT etc.)?

Many thanks,
Minime

No, you can take a backup, reinstall the system from media and then restore the backup. That would come close, but is a lot of work.

Thanks, that’s a pity. Any chance that you would consider offering this way of updating IPFire?

No, not really. I do not see much demand for it.

Mainly that is because IPFire is a firewall. It is normally connected to the Internet. This is a use-case that only very few people would benefit from, and quite frankly, we have only limited development resources and therefore should focus on things that are relevant to more users.

2 Likes

Hey there, I would like to warm up this old topic a bit because I basically have the same issue and this one seems to be the most related one to what I was searching for…

My setup is an offline IPFire. I use IPFire to separate networks that all do not have any connection to the internet.

I still have the possibility to mirror the contents of pakfire into that network and my DNS is configured to name the pakfire mirrors.
When I run pakfire on the ipfire it actually can get the list of servers, choose one, get the list of packages and tries to download updates.

My internal mirror has a couple of pakfire mirrors configured as hostnames in the apache config and the DNS resolves to that IP, so connection is not the problem.

But: of course, it is https, it refuses to download with a 500 error due to hostname mismatch in the certificate…

In my eyes the easiest way would be to allow pakfire to ignore the hostname or just trust the certificate.
Yeah, that’s something I would never do while being on the internet, but since the system has only internal connections this could be an option to get the downloads done.
The thing is I cannot find anything to configure pakfire to skip this check, use http instead of https or to install my internal certificate to be trusted.

@Michael Tremer: I can see your point in limited development resources but one simple way of configuration to allow pakfire to ignore such issues (probably not via GUI but via config file) for such special environments should not be too much work, is it? I don´t think the is any development necessary since all the tools involved should have such an option when downloading via https.

1 Like

I would like to warm up this topic again. I’m interested in this procedure because I use a “customized” version of IPFire (with a different linux kernel), which I build by myself with every new core-update.

Obviously I cannot use the official update-path because it would destroy my installation because of the various modifications (I guess), but I build a new image every time and therefor I have a new ISO.

So uploading the ISO to IPFire is not a big problem thanks to scp but is there really no possibility to “tell” IPFire to “scan” the ISO and do an update from there?

Greetings

Alex

Doesn’t the build process create an update file also, named core-upgrade-xx-yy.ipfire?
The mirrors serve this file in ipfire/pakfire2/2.29-x86_64/paks/

The decryption and unpacking in pakfire is done by
cd $Conf::tmpdir/ && gpg -d --batch --quiet --no-verbose --status-fd 2 --output - < $Conf::cachedir/$file 2>/dev/null | tar x

This would degrade the security of Pakfire as a package management system and cause information leaks which we don’t want.

If you don’t have a valid certificate, don’t bother with HTTPS. It is nice that packets are encrypted, but you want integrity, too.

If you have a local mirror that is reachable from your firewall, you can simply configure it manually as described here:

www.ipfire.org - Using the Pakfire Console

HTTP should be supported as well as HTTPS.


You will however run into further problems where loads of databases (like IPFire Location) cannot be updated as we don’t ship them as part of the updater. They will automatically be downloaded. The same is true for IPS rulesets, IP blocklists, etc.

The ISO does not hold the same files as the updater. So there is no way to perform an update like that.

What I can recommend if you either have no chance for any internet access whatsoever or if you have a custom build is simply to rebase your development tree, rebuild a fresh ISO, create a backup, install from the ISO and restore the backup - unless you want to bake your own updater.

3 Likes

Thanks for the answer, Michael! :slight_smile:

I guess for now I have to stick to my routine of reinstalling and restoring the backup every now and then, even though I’m not a big fan of that (had a lot of bad experiences with restoring back-ups on other devices → configs lost, functions don’t work anymore, etc.).

But thankfully IPFire’s got the most time-consuming configurations in simple text-files, so this is done very quickly manually with copy&paste. :smiley:

Hopefully at some not so far point in the future a new LTS-kernel with the features I need is going to be released and implemented in IPFire. Until then I can live with that and I’m happy that this software is so versatile and adaptable. :heart:

1 Like

What do you need a fresher kernel for? Hardware support? It so which?

We are already on 6.6 which is the current LTS and therefore far ahead of others. Some commercial products are still on 4.x and that even just so.

We will however jump to the next LTS kernel as soon as it comes out. That is quite likely not going to happen this year though.

3 Likes

I got two “Mini Appliances” here (one from LWL (APU.4D4), one “self made” (APU.6B4)). One has the Compex-modul (wle600vx) in it, the other one did not have a wifi-modul. Since I wanted to use WiFi on the other one as well, I looked for moduls, compared prices, checked availability, etc.

Because of the minor differences in pricing, I thought “why not” and got a WiFi7-modul with a Qualcomm Atheros Chipset. I know, I know this is way overpowered but I don’t care. I’m always fond of learning something new and get to know stuff.

So, I did a looooot of testing and I need the most recent linux kernel (6.10) because the ath12k-driver in the older ones (even 6.9) is just not that “far developed” that the modul works without any flaws.

Because of my very very limited, if not to say not existent, programming skills, backporting is not an option (way too many necessary adjustments in the kernel). So I swapped the kernel (6.10.3 at the moment), did some patching in udev/systemd, implemented the most recent hostapd (2.11) and a more recent linux-firmware and everything works reaaally great (I use the modul in 802.11ax-mode at the moment because no need for 802.11be yet).

Based on the history of LTS-releases

https://www.kernel.org/category/releases.html

the next one might come out at the end of the year and maybe at some point next year IPFire will adopt it. Hopefully it (the next LTS release) has the same ath12k driver like (at least) 6.10 and I will switch back to “standard” IPFire. Until then I can wait. :slight_smile:

What module are you using? I have recently been testing a lot with ath11k and did not have a lot of success… I did built a RC of 6.11 and it runs just fine.

The LTS kernel is usually the last release of the year and unless something happens, 6.11 is going to be released to early so that 6.12 might just make it into 2024.

2 Likes

I got my hands on an “emwicon WMX8402”.

Actually I wanted to get an ath11k module from Compex because I was really satisfied with the one in the Mini Appliance. But the one I wanted is only available from Compex itself and you have to buy them in a set of two (for almost 400$) directly from Singapure. The emwicon I got from techship, they also sent me the board-files.

Additional firmware-files I got from CodeLinaro.

Up until kernel 6.10.2 I had problems when there was heavy load on the module. It lead to a buffer overflow of some kind. But from 6.10.3 on everything is working great (tested 802.11ac and 802.11ax, I haven’t got any 802.11be devices yet).

The only drawback (for now) is, that I got two board-files, one for for 5Ghz and one for 6Ghz, and I have to choose between them. It’s ok since I got only one device which is capable of 6Ghz but on the other hand it’s not what “wideband” is supposed to be. I’m still in contact with techship and I hope that emwicon will release updated board-files eventually.

Good to know! But even if not, like I said, I can wait, it’s worth it. :slight_smile:

Thank you for that. I registered an account with TechShip and will try to get my hands on one in time for this year’s IPFire Developer Summit so that we have something to play with, but it currently seems to be out of stock.

It currently is a little bit of a problem that many new technologies don’t seem to catch on fast enough. I think most end user devices barely support 802.11ax, let alone 802.11be. And I don’t think we will see that any time soon. Therefore I have no idea how well supports 6 GHz would be, or if it just works.

Could you send me all the files that I need to get this module working? (Kernel not included).

To be honest, I think the current development is all excessively exaggerated and a bit scary but maybe I’m just getting old… some developers / engineers spit out new technologys every other month (it seems) and the pre-predecessors haven’t even arrived in the public yet…

WiFi7, 5G, every street ripped apart for fibre, more bandwith, higher throughput, but what for?

I just bought the module for fun and testing purposes, do I need it? No, absolutely not.

IMHO no private person, not even a whole family needs 300mbit upstream, they don’t even need 300mbit downstream… but hey it’s an offer now for only 19,99 for the next 6 months bla bla bla…

However, sorry for that, I guess I belong to this rare species of “anti progressive IT guys” :smiley:

You’ve got a PM with the files by the way, have fun with it and a nice weekend! :slight_smile:

2 Likes

I think there are many reasons why we would want more, higher, faster, but at what cost? A wireless module or AP used to cost peanuts and now they cost so much more because they require so much more power. Is that being used in the average office/home? No, not at all. You are right, peak usage will be capped by so many other things way before it would saturate the wireless link.

But we do have more devices, we have many more realtime applications where we want faster response times, so bandwidth is only one of many reasons to upgrade.

I agree though that it is hard to catch up with these developments because hardware changes slowly. And it should. We are currently producing so much e-waste for pretty much no real improvement for the end users.

On WiFi, I would say we have just about reached 802.11ac in most commercial environments that I am dealing with. Some phones and so on have 802.11ax, but you will only use that if you recently upgraded your APs which you would only have done because something broke. It would not be worth the money to change from 802.11ac to 802.11ax. And now 802.11be seems to be here.

This kind of creates a bit of a problem because we have to spend a lot of time to migrate to new technologies which is totally fine and fun as a developer. At the same time, we need to jump through higher hoops every time to keep the legacy stuff going.

With 802.11be it will be nice to use a 320 MHz channel spanning across multiple bands. But the reality is that people would rather have a 2.4 GHz-only device out there that needs to be supported. They won’t ever feel the benefits of the developments of the past 10-15 years.

I am basically trying to say that we are not transitioning to newer technologies and leaving the legacy stuff behind. We add the new stuff and will still have to carry around and support the legacy stuff as a first-class citizen. A huge amount of work which obviously is not where people want to put their money. They should, but it does not feel obvious.

No, maybe not need, but once the fibre is there, what is the point of artificially limiting it? Just pump 10G through it and everyone will be happy.

I have been called that on here a lot. I disagree with the term :slight_smile: I would rather say that we have to be reasonable and find a good middle ground. As stated above it will be great to support 802.11be, but more people would need 802.11g instead. It simply is the reality out there.

Thank you very much. I will look at that later.

Do you know if there are screws that hold the heat sink so that it can be detached? I cannot tell from the picture. It might be, it might not.

2 Likes

I see pictures available on the following page

Regards

I saw those too and to me they look like screws. @dweismueller disagreed :slight_smile: He was a solid “maybe”.

It would be nice if the heat sink was detachable because then this would integrate much better into the new IPFire Mini Appliance.

I found other pictures

After zooming in
obraz

If it’s not screws, what is it? :wink:

3 Likes

I would really like to tell you but I’m not going to unplug that thing again from my “IPFire Mini Appliance Limited Supreme Deluxe Edition” (pictures will follow)… :sunglasses: It took me ages to lay the 6 antenna cables in a satisfying way (4 for the WiFi-Module and 2 more for a WWAN-module) just to calm down the Mr. Monk in me :nerd_face:… and I really really really don’t want to do it again. :sweat_smile:

All I remember is, that my module looks like the one on the techship site (regarding the sticker with the MAC-adress on it) and not like the one from alibaba. It has these pins inside the cooler but unfortunately I cannot remember if it has screws on the backside.

It’s a pretty high cooler compared to the compex module but there still is some room (about 1 or 2 cm) to the “roof” in the classic APU-board-housings… so if the new Mini Appliance will have the same dimensions, it will definitely work. :slight_smile:

1 Like