From what I already read here, I understood that you came up with a new solution that does not display real-time traffic information. 2 questions: #1 - Is that right? #2 - And do you expect this to be a good substitute for iptstate?
My simple advice or help for anyone willing and able to install or try iptstate on any Linux Operating System would be to also install and activate gufw (Graphic interface of Uncomplicated Firewall). The obvious question here, would be why also install and activate gufw?
The simple answer is: Because activating gufw instantly applies some basic firewall rules that allow iptstate to start displaying live trafic info..
this is not a new solution, i patched only the already available connections.cgi (WUI) to deliver also filtering via IPFire zones and search possiblities for IP, port and protocols.
ā#1ā - Yes the WUI does not updates itself but you need to click/search/filter something (in the patched version), or you make a reload of the page (in the old version) to get actual data.
ā#2ā - Not that bad in my opinion and yes, for me it is.
You can check it by your own also without the patched version which i linked above, go simply to Status ā Connections and you can see the behavior of connections.cgi.
Have nevertheless uploaded the patched version (see above) of IPTstate for you so if you want to check it on IPFire, you can find it in here Index of /~ummeegge/IPTstate but let me say it again, the project seems to be dead or at least off so you need someone else to deliver a merge request for thisā¦
Hi,
I truly appreciate your efforts in this.
So, if you can come up with any other solution that actually displays real-time traffic information in a way similar to iptstate, that should be be fine for me. Otherwise, Itās not really worth the effort in my view!
For any other questions or concerns about the iptstate package or project, Iād recommend you contact Phil Dibowitz directly.
We already have iptraf-ng in ipfire which is very similar to iptstate. Would you like us to now believe itās very hard or impossible for you to integrate iptstate to ipfire?
I think you have more than enough information and resources to get this right. So be careful about what you intend to say nextā¦!!!
The IPFire developers are a very small team of people and all of them provide their activities as volunteers. The vast majority of them have day jobs that they have to do to pay the bills and these days they have to work longer to pay those bills.
Most of them do not have the time to look regularly into the forum but only have a peek every now and then to see what is happening.
Your best bet would be to raise your question in the IPFire development mailing list.
Bear in mind their workload so a response may take a bit of time.
The dev mailing list would be a good place to raise this also because if the package is of interest to the team then you could offer to create the patch(s) for this and submit it into IPFire.
In your initial discussion in the mailing list it would be worth bearing in mind that IPFire is designed to be a Firewall/Router where the administration etc is done via the WUI, so patches that submit packages without any WUI aspect are much less likely these days to be supported.
In the past packages were implemented that were only command line based on the basis that a WUI page would follow on. That has virtually never happened and in many cases even the package maintenance has ended up being left to the small team of IPFire developers.
Hi,
I truly appreciate you taking the time to provide these explanations.
If given the right accesses to the IPFire Project, Iād be glad to get technically involved and get this done myself. On the other hand, I donāt personally see much of a technical difference in terms of level of difficulty between implementing IPTraf-ng (which already present in IPFire) and implementing IPTState. Any unjustified resistance here only makes me think about other unspoken reasons.
In terms of the package itself, there is no difference. However that package is one that was installed on the basis that it would end up with a WUI page created to be able to use it but that has never happened. So any users of the firewall have to go and use the command line to use it which if an incorrect command is used can completely break the IPFire installation.
It is because there have been so many addons installed where no WUI page has ever been created for it that the view now is that for any new addon to be accepted it should not only consist of a patch to install it as an addon but also to create a WUI page for setup (if required) and output presentation.
You may consider it unjustified but that viewpoint I described above is not considered unjustified by the developers and there are no hidden or unspoken reasons and I donāt like the insinuations that you make with those sorts of phrases and others used previously.
IPFire is Open Source software. That does not mean that you can ask for new features for free. It is not free in terms of money, it is free in terms of freedom. You have the freedom to take the code and add to it and to give back your changes. Nothing more nothing less.
Throwing your toys out of the pram because nobody is doing your job for you is not good style.
I understand what you all wrote, but there are a few things I may need to remind you about:
#1 - Considering IPFire is an open source project, I raised this suggestion not just for personal interest, but to everyoneās benefit.
#2 - Whether you run IPTState or IPTraf-ng via command line, any available commands from experience for any of these programs are just designed to display information with layout option (similar to running a SELECT Command with a Database). So I can hardly believe thereās a risk to BREAK IPFire with those commands. The only thing that could become broken if any, could be the data display itself. Not IPFire. Feel free to prove me wrong on this!
#3 - The best trouble free, risk free and most simple way to display any system information is via terminal. Thatās what both IPTState and IPTraf-ng do accomplish. So hoping to migrate that view into a WUI interface for REAL-TIME visibility of data is a lot more work and potential trouble and additional attack surface that could actually risk breaking IPFire as you seem to fear. Iām afraid, taking this path as a priority could considerably delay or even prevent this project from ever seeing the light of day.
#4 - So my suggestion would be to start with the basics and just make sure the IPTState package properly works via terminal as it was designed to workā¦ Regardless of whatever future improvement plans or integrations you may have. Simply note that this could be a great tool to help enhance firewall ruleās effectiveness, help with network real-time threat visibility/analysis and the overall security posture of routing and endpoints. In my my view, you just leave the access via command lines for those who wouldnāt mind using them. They are extremely simple by the way! Remember that I already told you (wrote) that a tool like iptsate could even expose some weaknesses you probably didnāt know about the current state of ipfire. Finally, you may NOT like this question, but: Am I the only one who understands and cares about making this project a priority here?
IPFire being an open source project doesnāt mean it is an āplaygroundā for SW whatsoever.
IPFire is security software, consisting of open source parts.
Security SW demands chosing well the parts and approving them ( starting with kernel hardening).
Open source enables all users of the product to check the content, and letās users take part of the development process.
Adding new programs is possible, but
the program must be checked by the core devs ( they know best the dependancies )
to be usable by many users, the SW must be maintained by someone ( watching the source for updates and error fixes, implementing them in IPFire )
This is of some effort, which has to be done by someone for a longer time.
The core devs canāt do this additionally.
I didnāt find in this thread a post āinteresting, I take this module and am responsible for the next 2-4 yearsā.
@pokspeter I think that the majority of people in this threat agree with the statement that we are no longer talking about whether iptstate is actually a good addition to IPFire or not. You have been loud, and tried to shout at people to get them to do the work that you want to see in IPFire for you.
It has been explained in great detail to you what the path is to get changes into IPFire. We are very open to it. But we donāt like to be shouted at.