IPFire 2.25 - Core Update 153
For testing purposes, one should always rename the original file before importing a replacement. I had assumed that.
1 Like
I apologize if my comment came off bad, I was only making sure Scott doesn’t try to test it on a live server.
I’m gonna check out your script in the coming weeks, if it’s polished enough maybe we should give it to the ipfire devs to implement on the next core upgrade.
While looking for where to start, I noticed a few things that could be reworked. Is there interest in doing so? But I don’t know how much time I can invest.
Hey all, I just wanted to check in as I haven’t forgotten this post. I’ve been tied up with a bit of work, some ongoing health issues, and the learning curve of trying to run ipfire in a QEMU/KVM environment. Given my resources, I’m very close to just grabbing a spare box to test this out as I’ve got more “old machines” than hours available to test. Anyway, I’ll be back on this one soon. Thanks!
SLT
Hi anon, Juan, Bernhard,
I’ve loaded anon’s file onto a WiFi bridge unit I was building using ipfire and it was basically what I was looking for. So was I right that this is a fairly trivial change/addition or is it a huge pain to incorporate?
Hi @sltaway
This needs some more work before it is ready to be sent as a patch to the IPFire Development list for proposing to be built into IPFire.
The image has the fixed IP address now shown in the Current dynamic leases tables, which is not correct. It is not one of the dynamic leases.
Another table titled “Current connected fixed leases” is probably needed so that the connected status is shown separate from the dynamic leases.
A Current connected fixed leases table probably doesn’t need the “Lease expires” or “Add to fix leases” columns.
It is not clear to me what this provides that the Who Is Online page does not.
1 Like
Hi Adolph,
I’m not the coder of the proposed patch, so I’m not invested in it specifically as a solution. Your critiques are valid and your solutions sound like they’d satisfy my request just as well. Which leads me to the second point.
WIO definitely provides this same information if you dig first to find & install it, then configure it. It does a wonderful job and has abilities beyond this that make it very useful outside of these parameters; my request in no way intends to downplay or denigrate WIO. My point is simply that “most” other modern routers in my experience provide this simple bit of information in the DHCP configuration & status area of their GUI (whether Reservations are currently in some vague sense connected or active). My query was admittedly born of my lack of experience with ipfire and WIO but I consider myself something of a decent litmus test at this stage: if I didn’t find this often useful information fairly quickly, it’s likely many other users will run into the same problem early on. Small issues like this can lead new users (regardless of their general level of competence) to decide against using ipfire when they’re testing, especially given that they’re likely testing with very little invested in their test example. I’m not saying it’s massively important but the cumulative effect of small pieces that aren’t where the new user expects them to be can matter since ipfire is so very competent in so many other areas.
Basically, yes, I get what I wanted from WIO but wouldn’t it be logical and a small improvement to have that bit of info at your fingertips when you’re in the middle of setting up a Reservation if it’s not a large undertaking for the backend? I’m still asking this as I don’t know, not having written code since the days of ProDOS and only at a very amateur level back then.
Would it be simpler/easier to include WIO as a stock patch and integrate it’s functionality into the DHCP page? Or at least the parts that relate to the LAN side of the firewall?
Thanks for your attention. If there’s anything regarding this I can do to assist, let me know.
SLT
1 Like
Hi Scott,
Thanks for the explanation. Based on that I can understand where you are coming from. It could well be a useful update to have.
The IPFire development group is very small and are doing this work in their spare time. Their concentration is on improvements within the existing core parts of IPFire and working on bugs that have been raised.
There are other people who try and support the core devs by providing patches for updates of all the various packages and add-ons in IPFire.
So for improvements like this someone needs to be willing to pick this up and code it and provide a patch to the IPFire devs for it to be included in the IPFire build. The devs are very open to people who are willing to do this. The only thing they request is that whoever provides the update is willing to continue supporting it if any updates are needed or bugs are found.
So if you or @anon79392304 are willing to have a go at making it into a patch that would be good.
Normally this would be something I would be happy to have a look at but currently I am working on some bugs related to OpenVPN and also trying to support one of the devs on the changes needed with regard to the new options etc available from OpenVPN-2.5.0 while making sure that all legacy users can still operate without hiccups.
You could maybe raise it as a bug in the IPFire bugzilla using the explanation you have given to me. That way it is recorded and can be worked on by someone who has the time. Your IPFire People login details work for the IPFire Bugzilla which you can reach via this link https://bugzilla.ipfire.org/
Adolf
1 Like
Hi Adolph,
Thanks for the insight. I am not a coder nor do I have the bandwidth to begin being one at this point, so I’m not a good candidate to assist much with the patch. That said, I have an old friend who is a coder and happens to have a good history with Perl. She has expressed a willingness to help out and I will only have to provide her with a unit running ipfire for her to test on. Since I have more than couple of old PCs around that will be fine for testing, I plan to set her up and get her connected with the community.
This brings up the next question: where do I point her to get involved with the community for development? Just sign up and post on this thread, create one in bugzilla, or is there a more official way that I’ve glossed over due to my lack of interest or ability to contribute in that manner?
Thanks again. I have to say I’m quite impressed both with ipfire and it’s community. As a recent new user, it’s a pleasure to discover.
SLT
Hi Scott,
Here is the link to the wiki to get involved in the development activity.
https://wiki.ipfire.org/devel
I followed that a year or so ago and have been helping where I can. I am also not a formal coder but I have learnt as I have gone along and I have been very helpfully supported by the devs.
Information on the git repository is here https://wiki.ipfire.org/devel/git and how to set up a build environment is here https://wiki.ipfire.org/devel/ipfire-2-x/build-howto and how to submit patches is here https://wiki.ipfire.org/devel/submit-patches
Any questions about how all of this works that the wiki doesn’t asnwer or isn’t clear can be asked on the development mailing list. See here to how communicate with the developers which includes details for joining the mailing list. https://wiki.ipfire.org/devel/contact
Thanks Scott and look forward to your friend joining the IPfire development community. She will be welcomed.
Regards,
Adolf
2 Likes
Wow! Thanks Adolf! That was extremely informative and helpful.
I’ll work on getting her testbed up and running so we can work on getting her involved. I think she’ll enjoy getting into it once she gets her feet under her again.
Thanks again!
SLT