Tip for next release

It may be stupid, and I apologize in advance, but in my opinion in the firewall log if there was an indication of the number of the rule that causes a DROP, but also an OUTGOINGFW (for example) it would be easier to identify a problem.

By the way, many commercial firewalls (CheckPoint, Fortinet, WatchGuard, etc.) already do this

4 Likes

Why not opening a bug report asking for this feature?

1 Like

hi @cfusco, just because it’s not a bug but a feature request

The IPFire Bugzilla platform is utilized not only for reporting bugs but also for submitting feature requests. For example, you can see a feature request at https://bugzilla.ipfire.org/show_bug.cgi?id=10430. It serves as a centralized system for developers to track improvements, both for fixing issues and for enhancing the system’s capabilities.

1 Like

done https://bugzilla.ipfire.org/show_bug.cgi?id=10430 thanks

2 Likes

This is the bug report that I posted as an example. Probably a copy/paste error.

EDIT: no, you commented on that bug report. You should have opened one dedicated to your issue. I have no idea how to fix this. @bonnietwin maybe you could advice @attilay2k what do do here?

1 Like

Once a comment has been made in bugzilla, it is there for keeps so that for any bug the actual process, mistakes and all is kept to understand how any improvement/fix has been reached, especially if it later on turns out not to work as expected.

In terms of the bug report on the gmp request, the simplest would probably be for @attilay2k to select reply on his original comment and add a comment that indicates the entry was placed in that bug report by accident and should be ignored.

Then a new bug report should be created, using the one you provided as an example of how to create one, together with this wiki page.

https://wiki.ipfire.org/devel/bugzilla

2 Likes

I was about to suggest the same, which is now done, but the Wiki does not clarify you can actually submit bugs that may be considered feature requests …

Pages that do not mention feature requests, in assumed browsing order:

  1. wiki.ipfire.org - Bugzilla
  2. Bugzilla Main Page
  3. Log in to Bugzilla
  4. Bug Writing Guidelines

From experience I know that devs may or may not be very picky as to what is considered an appropriate submission.

The main focus of the devs is not on new function additions for IPFire-2.x but on developing IPFire-3.x so they prefer not to actively encourage lots of feature improvements to be added into the IPFire Bugzilla.

There are already a lot of actual bug reports still open because there are not enough devs to work on them.

If a user has a feature request and submits a patch(es) for the improvement via the IPFire patch submission process defined in the wiki then the devs are open to reviewing that and implementing it if appropriate. In the patch submission process a discussion can occur to review and understand why the feature request is being proposed and that it makes sense in the context of IPFire.

Various feature improvements over the last few years have either been security related and therefore worked on by the devs, such as dropping packets from and to hostile networks, of patch sets submitted by users, such as the IP Blocklist.

If someone raises a feature request here in the forum and another user is willing to do the code modifications and patch(es) submission for the improvement that is also an opportunity for more users to get directly involved in supporting IPFire.

In the wiki are two links to suggestions for how to help write a good bug report that also highlight why bug reviewers tend to be picky about the report submission.

http://blog.ipfire.org/post/how-to-write-a-good-bug-report
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

If you follow these then the likelihood is that the bug report will be in line with the expectations which helps the devs who are very busy both on IPFire and with their day jobs.

6 Likes

I am aware of that and I am sorry for not being able to contribute with more than a bit of cash every month… still I think I might somehow do a bit more, but my “speciality” is tech administration / support and processes in windows, so maybe a bit off considering IPFire’s environment.

2 Likes

Don’t be sorry. Thank you very much for donating to IPFire. It is highly appreciated. The more people that do that the better for the project.

If you have an interest in doing more, don’t worry about your background.

Before I retired I worked in the semiconductor industry in a range of engineering areas. High Tech but nothing to do with programming or computing other than using computers for controlling and analysing the processes etc.
What I am doing in IPFire is totally based on hobby interest. I can’t do the sort of programming of network stacks etc that some of the other devs do but I am able to support with things like package updates, simple bug fixes etc.
What I can do know has increased immensely compared to when I first started supporting IPFire and that has been due to just trying things, sometimes failing and then learning from that, together with support from the devs mailing list.

@jon is in a similar situation as me I think. He is also not an experienced programmer but has worked on patches and bugs related to things he was having problems with.

You would be welcomed if you decided to have a go at supporting some simpler things but if not then we will continue to value your contribution to the forum.

4 Likes