| Summary: | Web interface iptables drop down menus incorrect | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Private Zimm <jaegers49> |
| Component: | iptables | Assignee: | Robin Roevens <robin.roevens> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | - Unknown - | ||
| Priority: | Will affect all users | CC: | adolf.belka, bbitsch, cab_77573, jon.murphy, michael.tremer, peter.mueller, robin.roevens |
| Version: | 2 | ||
| Hardware: | all | ||
| OS: | Unspecified | ||
| Attachments: | getipstat debug file | ||
|
Description
Private Zimm
2022-08-10 02:43:03 UTC
Besides some 'little' bugs in the Perl script ( I'll try to correct them ), is this bug related to #12886? A quick comparison of the output of getipstat -m | grep -i chain and iptables -L -t mangle | grep -i chain lets assume that. getipstat is used get the chain names for the drop down menus. Is this a general Core Update 169 issue or is it only biting us that have pulled in the testing version of ipblocklist add-on? As far as I see in the moment, it is a general CU 169 problem. Haven't managed to replace the getipstat calls with a temporary Perl solution, yet. getipstat -m definitively doesn't give the mangles table. A comparison of the output for the three tables getipstat -f getipstat getipstat -n shows that they are identical. So all functionality using these lists is buggy. (In reply to Bernhard Bitsch from comment #4) > A comparison of the output for the three tables > > getipstat -f > getipstat > getipstat -n > > shows that they are identical. So all functionality using these lists is > buggy. getipstat -m Here is some debug output from a print added to getipstat showing the arguments passed to iptables. It seems somehow the --table argument is getting preceded by a null. *** iptables --list --verbose --numeric --wait 5 (null) (null) (null) (null) *** *** iptables --list --verbose --numeric --wait 5 (null) --table nat (null) *** *** iptables --list --verbose --numeric --wait 5 (null) --table mangle (null) *** The debug line: "fprintf(stderr, "\n*** iptables %s %s %s %s %s %s %s %s %s ***\n\n", args[0], args[1], args[2], args[3], args[4], args[5], args[6], args[7], args[8]);" -cab To my simple cave-man brain, it seems ... line 32: unsigned int pcount = 6; should be line 32: unsigned int pcount = 5; Created attachment 1077 [details]
getipstat debug file
Here is the result from calling getipstat with -n and -m after changing ...
line 32: unsigned int pcount = 5;
See attached.
-----------------------
I am not familiar with your build/make architecture -- I had to do a clean in order for my debug tweaks to get compiled. How do you shortcut the process to get a single c-file change for a standalone executable to compile and link?
-cab
(In reply to Charles Brown from comment #7) > To my simple cave-man brain, it seems ... > line 32: unsigned int pcount = 6; > should be > line 32: unsigned int pcount = 5; Yes, this is correct. Would you like to submit a patch for this? (In reply to Michael Tremer from comment #10) > (In reply to Charles Brown from comment #7) > > To my simple cave-man brain, it seems ... > > line 32: unsigned int pcount = 6; > > should be > > line 32: unsigned int pcount = 5; > > Yes, this is correct. Would you like to submit a patch for this? Ugh, I snapped a few of my remaining geriatric synapses looking at the Wiki for how to submit ... it scares me :-) I'll leave official work on this bug to someone competent with your tools and processes. -cab Seems that I made this error; I submitted a patch for this: https://patchwork.ipfire.org/project/ipfire/patch/20220817125848.11809-1-robin.roevens@disroot.org/ Patch was shipped in CU170 which has been released. Confirmed that iptables display is back to how it should look. works A-OK in CU 171 for the items I saw: https://community.ipfire.org/t/cu169-iptables-wui-dropdown-menus/8372/5?u=jon |