Would a bit more information be useful?

I am certainly not a newcomer anymore to OpenWrt, but I still am a newcomer to linux networking, or rather networking in general.

I have been breaking my head for more than a year now (not effective time, just calendar wise) to get these iptables to do what they need to do.

Sure I have bragged about getting log servers in place but the fact of the matter is I have not got around to it yet.

Truth be told it is because I am considering using the proxmox firewall as a starting point.
Now this in no way means that OpenWrt is off the table for me. NOOO. This carefully constructed piece of software has ingrained itself into my mindset as the best of the best so it is not easy to be discarded.

However there are no easy mechanisms to see where things go wrong. Let me rephrase. One needs a damned good understanding of linux networking to debug when ever things go not as planned (even though setup using UCI)

I'd like to first probe if this message makes any sense to any of the developers and if so then I can elaborate on where I think (given my extensive experience with the recent software) can benefit of an update.
@trendy is one of the ones that have been helping me along. Perhaps he can suggest some pointers

1 Like

sorry, I meant to have something of an iptables debugger or logger or whatever. Just to see what packet is going where thus enabling us to deduce why things are not as expected

A good starting point is to state what is the expected behavior. Then what actually happens. From that point we can decide which troubleshooting steps are needed. Regarding firewall the iptables-save -c is a good starting point. Also tcpdump can show if packets are sent and received.

1 Like

Thank you for your valuable input.
However this kind of underlines the whole premise. Again there is the assumption one knows how to debug.
I am opting for more information / debugging opportunities for the uninitiated amongst us. Preferably right there in the Luci web interface.

and to add. the expected behavior is to have packets allowed or denied as intended. The challenge for the uninitiated is how to get it so when things are getting a bit more complex than the standard home setup.

A built in (optional) logger that is easy to find for newcomers, I'd imagine, would make a world of difference.

There is a page for firewall status in Luci which includes the rules and the hits. This is a good start to verify in Luci whether the rule works.

1 Like

I'm afraid you can only achieve precise control and flexibility with CLI.
It's problematic to adapt WebUI to all possible use cases at the same time.

Not only you need to collect comprehensive diagnostics for a specific problem.
You also need knowledge and experience to analyse the collected data.

1 Like

Come on brothers. Please allow me to respectfully disagree.

Should I have missed something obvious then please forgive what I am going to say next.

For example, the system log is always at one level which is info. What ever we configure in the luci interface it should output. There is/was a debate about this amongst developers up until recently.

Also the latest entries are always at the bottom with no way of getting to the most recent info quickly. I spend a lot of time scrolling down to the bottom of the screen. I think we should reverse tail that log at the least.

Better yet would be to filter/group messages. For example I am now still fighting with DHCP and am not interested in all the other stuff for now.

Also what is difficult for new comers is that sometimes I see a rejected package message in the kernel log rather than in the one place where a new comer would expect it, in a central place.

Please do not get me wrong, I love OpenWrt and I really hope I can learn to tame this powerful masterpiece.

My one critique is that most of you lot seem to be not be able to empathize with non CLI minded people having years of experience under your belt.

My request still stands. Please open up OpenWrt some more to the masses.

Apparently there's not enough resources to solve everything in a short time.
Also, changes only happen when there are sufficiently motivated developers.
You are welcome to help with own PRs: https://github.com/openwrt/luci/pulls

1 Like


And I could. I have the skills on the front end. But first I need to tame this brilliant beast before I can steer it.

Metaphors aside. I have decided that I will gladly contribute my skills, other than my monetary contributions that I have done, as soon as I have a setup that I am comfortable with given the current state of the code.


did you edit remove the mention of good ideas? as in you no longer think they are?

I also thought about reversing the log output to minimize scrolling.
But this concept is controversial as it goes against natural reading experience.
It may be confusing to some users, adding more problems than it solves.

To implement this kind of change, you need to study all the pros and cons.
And then prove that the pros prevail and the cons are negligible.

There's already a built-in page search in the browser that just works.
I'm not sure if you can implement a better one and prove its efficiency.

That part is actually really easy, as the javascript in browser can do that for you. I have made that modification for my own WNDR3700 build, where I have an additional log view showing the last 50 lines reversed.

--- /dev/null
+++ b/modules/luci-mod-status/htdocs/luci-static/resources/view/status/recentlog.js
@@ -0,0 +1,33 @@
+'use strict';
+'require fs';
+'require ui';
+return L.view.extend({
+	load: function() {
+		return fs.exec_direct('/sbin/logread', [ '-e', '^' ]).catch(function(err) {
+			ui.addNotification(null, E('p', {}, _('Unable to load log data: ' + err.message)));
+			return '';
+		});
+	},
+	render: function(logdata) {
+		var loglines = logdata.trim().split(/\n/);
+		return E([], [
+			E('h2', {}, [ _('Last 50 lines of System Log (recent on top)') ]),
+			E('div', { 'id': 'content_syslog' }, [
+				E('textarea', {
+					'id': 'syslog',
+					'style': 'font-size:12px',
+					'readonly': 'readonly',
+					'wrap': 'off',
+					'rows': 52
+				}, [ loglines.slice(-50).reverse().join('\n') ])
+			])
+		]);
+	},
+	handleSaveApply: null,
+	handleSave: null,
+	handleReset: null
--- a/modules/luci-mod-status/root/usr/share/luci/menu.d/luci-mod-status.json
+++ b/modules/luci-mod-status/root/usr/share/luci/menu.d/luci-mod-status.json
@@ -35,9 +35,18 @@
+	"admin/status/recentlog": {
+		"title": "Last 50 lines in log",
+		"order": 4,
+		"action": {
+			"type": "view",
+			"path": "status/recentlog"
+		}
+	},

That is otherwise the same as the normal system log LuCI routine in
except the lines saying "last 50 lines, reversed, please" :wink:

'rows': 52


(Looking at it now, it might be even simpler if the slice and reverse would be on the variable declaration line. Then the view length (rows) would be automatic.)

(Note that the menu modification above is for 21.02, as master has slightly different menu log structure after commit a62a6c0f3)

Yeah, I didn't like it in the end, so I have not pushed the change forward and to my other builds.


@hnyman thank you for your participation.

@hnyman can you please elaborate a bit on what you did not like about your solution?

Didn't look natural, just like vgaetera speculated.

well in that case making a sortable/filterable table out of the output is the most flexible way to proceed regarding log output.

I mean if one's settings could be stored then for users wanting the traditional output they have to do nothing. But for users like me they could sort on date and/or even choose not filter.

I will get back to this if you guys think that might be a valuable UI improvement.

First I am going to post some questions regarding passing through a wireless adapter to an OpenWrt VM