DNS from router going to my "Jail" / bulk bucket

[bastion]

Note: Fixed by upgrading to 1.15

DNS from router going to my "Jail" / bulk bucket -- that is, outbound DNS from the router.

I have a catch-all quota, which may be being applied to the router's IP itself.

I've tried making a separate quota for the router's IP, but to no visible effect.

I tried the solution suggested on github's ericpaulbishop/gargoyle/issues/997 - but it seems to have had no effect, and I'm not even sure it's the right solution for the problem I'm having.

I'm getting this information from the 'conections' page.

Thanks in advance for any help provided.

Any ideas on how I can go about debugging this?

Happy to post info here as needed. Comfortable with cli.

[Lantis]

What version are you running?

[bastion]

1.14.0 -- specifically, gargoyle_1.14.0-ramips-mt7621-zbtlink_zbt-we1326-squashfs-sysupgrade.

Altogether, this is functioning better than OpenWRT, and allows me to affect traffic in ways that improve / decrease bandwidth usage, so thank you (all who have contributed to Gargoyle, and who are helping).

[Lantis]

There has been a lot of fixes done with the firewall and quotas since 1.14. I can't say for certain that what you are experiencing is fixed, but it would certainly be useful to know if you still see the same on the latest 1.15.x betas.

As far as "can the router IP be caught up in a quota?", yes that should be possible. We hook the OUTPUT iptables chain which would capture dnsmasq outbound queries.

[bastion]

Changed over to 1.15.X (Built 20250330-2253 git@ca9ca6a5)

That seems to address it.. ..but, the WiFi LED blinks red constantly and regularly (as opposed to the normal, traffic-based green flashing) as though there's some kind of emergency.

It *also* blinks green, at either a different rate, or to indicate traffic (hard to tell, as they blend rather chaotically, and the red dominates).

Is this indicating some kind of error condition?

Note: In case the issue was caused by keeping the config, I did a reinstall with clean config. The warning-blink persists. I have since restored my prior config, but I can do testing and am comfortable in the cli, and can occasionally take the router down for experimentation.

Edit: This was just OpenWRT handling LEDs better. I poked around in /sys/class/leds to discover that (although I don't like the default mode) everything is fine, and the LEDs are just configured to respond differently than in the prior versions of openwrt and gargoyle I had on there.

[Lantis]

I doubt it means anything significant. Potentially a regression in the upstream code that maps the LEDs correctly. But let’s see if we can figure it out…

What is the device model?
And it may be worth showing the contents of /etc/config/system which contains some LED configuration.

[bastion]

Ah, you had replied -- I thought I got my edit in, above, before a response, but looks like you responded first.

I looked into it, and this is what I found:

Previously, the phy1 (red, associated with 5ghz) LED was not mapped to anything, or perhaps wasn't working at all. Now, it works and was set to react to the phy1tpt trigger -- which provides a steady blink when there's steady network activity. Same for the phy0 / 2.4ghz, but the 2.4ghz activity was intermittent.

This caused the steady blinking red light, and the irregular green light.

Just for completeness -- I don't have any relevant config in /etc/config/system, just:

Code: Select all

config system
	option ttylogin '0'
	option log_size '64'
	option urandom_seed '0'
	option compat_version '1.1'
	option cronloglevel '9'
	option timezone 'EST5EDT,M3.2.0/2,M11.1.0/2'
	option hostname 'wifi'

config timeserver 'ntp'
[...]
config button 'reboot_button'
[...]
config button 'reset_button'
[...]
<eof>

[Lantis]

That’s good news