Page 9 of 10

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Tue Oct 23, 2018 7:00 am
by Lantis
Good ideas, certainly things to think about and jog my memory and thought processes.
Unfortunately, bwmon and quotas are actually some of the harder things to pull out! Trust me, i looked lol.
Plus, i think that bwmon and quotas are very useful components of the firmware. I know that people trying to push faster internet speeds aren't the biggest fan of bwmon, but, if you're trying to do 300 down the autobahn in a Daihatsu Charade that's not my problem ;)

So we have some firmware profiles where USB is not included, but i think it is important that where a device has a USB port that we include support for it. Particularly, this allows us to go down to a minimal firmware where you can then use that USB environment to extend the filesystem onto it and regain a full version of Gargoyle. We'll see how that works. In my testing, not too bad!
VPN is definitely out, but again once you've got a usb stick in there you can add it back no problems.
Tor is the same story, though i agree with your assessment.

The time server is more about keeping the router in check and the bandwidth history accurate rather than the clients. Not sure i agree with this one but i know some people prefer a local time server.

Geolocation was a necessary step for me to provide any regulatory features at all (at least, any exposed to the user) as it was not approved without them. I tried this before and the idea was rejected. That module is only 4KB so no big savings to be had by cutting it out.

IPv6 is actually now very hard (read: i don't think possible) to remove. A lot of the dual stack code in the kernel is now fully integrated and there aren't heaps of savings to be had by cutting out what you can. The web of complex dependencies also means that we have to include bits and pieces of it these days. Plus, in the future i'd like to make Gargoyle fully IPv6 compliant so it's nice to keep for now.

The regulatory stuff is basically all controlled upstream and i have no intention of touching it. If you are experiencing the problem only in Gargoyle (i.e. Openwrt behaves fine) i'm happy to look at the individual case though. Your regulatory settings may need some tweaking (within the extent of the law, that is).

DDNS has been pulled out and turned into a plugin.

QoS has been pulled out and turned into a plugin (and boy was that a mission). That module takes up almost 250KB on its own.

If you've got great ideas and the knack for this kind of thing, please feel free to jump in and give a hand too! I'm always happy to take assistance.

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Wed Oct 24, 2018 1:57 pm
by danielwritesback
At the moment, I've only got 4 little ideas to contribute. They're all for reliability.

1
/etc/config/firewall
config zone (wan)
option input 'DROP'
Its a bit less cpu intensive not to respond to scans. Also, http://www.grc.com/shieldsup The router needs default settings that pass that quality control test.

2
As for the 2.4ghz atheros regulatory, a rather straightforward thing to do is allow Typing the real figure in the GUI (30 for USA, actually resulting in less than 150mw). Mine had a shortfall at 25 limit in the gui (actually resulting in far less). Other than preventing me from typing the correct figure, the remaining 2.4ghz power loss issues are located at Openwrt.
Fortunately, there's good news to be had--the 5ghz works normally.

3
To make the time server really useful, we'd need a "Make clients use the router's time server" checkbox. That is fantastic for keeping the whole lan on the same time, and preventing excessive wan traffic from iot's desperately checking the time. Here's a iptables example, iptables -t nat -A PREROUTING -i br-lan -p udp --dport 123 -j REDIRECT which may work in /etc/firewall.user.

4
In with the connection limits, it would be wonderful to have "Connections per each client" with checkbox to enable it and a textbox to enter it.
Possibilities include connlimit options of 60, 150, 280, 400. So, 60 would be for protecting the hotel from torrent related crashes, 150 is more than enough for ordinary use, and 400 connections per client is very transparent but still enough to restrain a crazed iot device before it jams the router.
EDIT: Scroll down a few posts to the working script.
The benefits of this proposed feature is in making the router more durable as well as being able to support many more simultaneous clients from one Gargoyle router.

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Wed Oct 24, 2018 8:19 pm
by Lantis
1. Will consider looking at this in the future
2. I'm still not sure i understand your problem. The GUI probes the driver (which references the regulatory db) and presents the maximum available power for each channel in the GUI. It doesn't do any reductions at all. There's no point offering more than what the driver says it can do, because it will ignore the instruction.
Your second point is again an openwrt problem i think. IF the router pre-sets the regulatory domain in an exposable way, Gargoyle detects this and doesn't offer to allow changing the country. The mvebu devices all do this properly, and a handful of others.
3. Sure, that seems sane and easy enough to do. Again will look at in the future.
4. Does this rule apply per client or across the entire range specified? This one sounds like a bit of work. Its not a bad suggestion, but also not something i'm overly sold/interested in.

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Wed Oct 24, 2018 8:21 pm
by Lantis
RC2 update
Ar71xx now has about 30 more devices than RC1. This includes the popular wr1043 series, archer c7 v1, wdr3600 and a few other classics.
This was achieved by shrinking the firmware as much as possible for devices where a USB external drive could allow.

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Wed Oct 24, 2018 11:30 pm
by ispyisail
RC2 update
+1

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Thu Oct 25, 2018 1:46 pm
by danielwritesback
Lantis wrote:4. Does this rule apply per client or across the entire range specified? This one sounds like a bit of work. Its not a bad suggestion, but also not something i'm overly sold/interested in.
Got it done. And I added the mask to specify per client.

QOS+Connlimit is how Linux supports numerous devices, more effectively than ever-increasing internet costs. That, is, interesting.

First step, on the firewall / connection limits gui page, for how long to keep disused connections, I set udp 60 and tcp 600.

And, then here's the firewall command:

Code: Select all

iptables -I INPUT -s 192.168.1.0/24 -m connlimit --connlimit-mask 32 --connlimit-above 180 -j REJECT
Just lower the number until utilization stays Under the thresholds of the modem cpu, router cpu and ISP netbalance/limiter. That way, the item that gets backed up is the misbehaving client, not your wan link.

Edit: Wifi-only application:
Wifi appliances could overload the router easily with simultaneous wifi and routing workload. So, right after INPUT, you can use -i interfacename (ifconfig can reveal names) and apply the rule to wifi. Now when appliances misbehave, the router doesn't go down.

Edit2: By the book:
Although the simpler command (above) works well in home networks, here's a full size version for large networks.

Code: Select all

iptables -I INPUT -p tcp -s 192.168.1.0/24 -m connlimit --connlimit-mask 32 --connlimit-above 120 -j REJECT
iptables -I INPUT -p udp -s 192.168.1.0/24 -m connlimit --connlimit-mask 32 --connlimit-above 60 -j REJECT
This example allows for simple checkboxes in the gui! For automation, 1/5th TCP timeout = Tcp connlimit; and, UDP timeout = UDP connlimit. That will scale connlimit to fit timeouts.

Edit3: Where to put the command:
Any iptables -I has to go in rc.local (startup script) so that the new rule is inserted only once per startup.

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Fri Oct 26, 2018 2:08 am
by ninderrycomp
Look forward to trying 1.11.0 RC2. I have been using an Archer C7 v2 on 1.10.0 and it works great, but it drops DHCP on the lan periodically, which is weird. Would also be nice to squeeze more performance out of QOS. Is there a build available to download yet?

Edit: I am also very interested in the x86 version, I see people are making it run in virtual environments. Cool!

Edit edit: Just booted up x86_64 gargoyle in a proxmox VM. Was able to access the WebUI without any worries. Once I can work out how to assign a WAN and LAN config, I think I'll make this my primary router. Awesome. https://i.imgur.com/kk1ogZn.png

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Mon Oct 29, 2018 9:05 am
by Lantis
pp98 wrote:Thanks. That file does exist on my build but the commands do not retrieve the MAC address for my device. You are probably correct that this needs to be fixed upstream in the openwrt or ath10k. I'll post in the appropriate forum to see if they have suggestions.
I’m not sure if this user is also you, but a solution looks to have been found
https://github.com/openwrt/openwrt/pull/1495/files

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Mon Oct 29, 2018 9:23 am
by pp98
Yes. That was my contribution and that has solved the bssid issue on my Gargoyle build.

I still have an issue with setting up WDS on the 5G radio. Gargoyle does not have the option to specify setting WDS+AP on this interface and I have to edit the wireless config manually to achieve this. Unfortunately this gets reset anytime a change is made on any of the interfaces. Would it be possible to set the wds flag on both interfaces if specifying WDS+AP as the mode?

Thanks.

Re: Gargoyle 1.11.0 Release Candidate 1

Posted: Mon Oct 29, 2018 4:05 pm
by Lantis
That is on my list of things to look at.
I wasn’t sure of the implications of setting the WDS flag on an interface that won’t actually use it. I don’t know if any clients will panic.

So the solution is either:
1. Push the flag to both
Or
2. Make it selectable

Do you have any comments on #1? Because it is certainly much easier if there is no downside