Gargoyle Forum

I have all of our devices set with static ip's at my house, but not at the other 2. They are short drops. It's almost like the connection just drops for a minute or two here and there with no discernible pattern to it.

I reverted back to the manufacturer's firmware on the v2 a few days ago, and am experiencing no drops at all. This is definitely a Gargoyle/Exede incompatibility. Anyone have any ideas?

I'm having the same problem here.
About a month ago my internet stopped working. Some times this happens due to network maintenance, so I waited until the next day. I cheked that everything on the router was ok, but could not ping any internet sites. After DHCP release/renew on WAN internet goes back on from 1-2 minutes and them starts dropping packets again.
I tried several Gargoyle and OpenWRT builds, tried reseting router and changing settings, anything works. Reverted back to original firmware and It's working without issues.
I'm thinking maybe my provider changed something on the network that started this.

Router: TP-Link TL-WDR4300
WAN Type: Cable modem (Webstar, no logs on admin console)
WAN Provider: Net Virtua - Brazil
Tested on Gargoyle 1.7, 1.6.1, 1.6.2 -> not working
Tested OpenWRT Barrier Breaker -> not working

I am experiencing a similar problem using v 2.1 of the router and Gargoyle 1.6.2.

Comcast is the isp with a dynamic ip address. I am just experiencing slowdowns that cut download speed from about 30 Mbps to 6. Upload speeds are similarly degraded.

I was using version 1.7 for a month or two without issues and downgraded when it began. The problem returned this week even though no other changes have been made to settings, etc. If I reboot the router I can run speedtest and get 30Mbps for about 2 min. Then the reduced speed problems return. It have also been able to temporarily get good speed by making any change to the router than requires a save procedure - switching DNS servers for example.

Is there a cache that may fill after a certain amount of time. I would like to keep the records on bandwidth usage for each day, but no other logs are needed.

I will try to clear some logs local to the router and report back. If others have suggestions, please post.

PW

Ok, file mine under user error - I suppose.

I continued to play around with settings and finally determined that the problem is related to QoS settings.

I finally realized that the Total Download Bandwidth value sets a hard limit on usable bandwidth. If your service is faster than this value, the default service class will override this setting to cap your bandwidth at the specified level. The description underneath this value indicates that the restrictions only kick in if the WAN link is saturated, but if you specify a value lower than your maximum bandwidth the firmware appears to cap the speed at the specified values.

Again, I observed full speed downloads for about 90 seconds after a reboot or after certain parameters (DNS settings) were changed and saved. Then, speed degraded to comply with the QoS settings specified.

PW

Hello All,

I may have found the area that causes the spontaneous reboot of routers when using the 1.7.x firmware.
I am currently using:
Gargoyle Version:1.7.X (Built 20150527-1912 git@7d816bd) - (I have also tried it with 1.7 and 1.7.1)
Model:D-Link DIR-835 rev. A1

Note: I was using the very same hardware and configuration manually configured with the older firmware 1.6.2 and it was running without any reboots for over 6 months.

Symptom:
Whenever I perform a speed test, the router would reboot. I have used http://www.speedtest.net and http://speedcheck.rogers.com/en.html
Usually the router would reboot almost everytime, occasionally it would not and you would have to do the speedtest back to back.

How to reproduce:
1) Configure your router with Quotas as shown by my examples below.
2) Ensure that they are all enabled.
3) Perform a speed test from one of the above sites.

Where I believe the root cause for this issue is in the "Firewall" - "Quotas" section.
My configuration that confirm this:

All Always 9GB/NA/NA
Max Total Up+Down: Limit to 9.5 GBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 64 kBytes
Download Limit: 512 kBytes

192.168.1.66 Always 1024MB/NA/NA
Max Total Up+Down: Limit to 1024 MBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 16 kBytes
Download Limit: 64 kBytes

192.168.1.67 Always 1024MB/NA/NA
Max Total Up+Down: Limit to 1024 MBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 16 kBytes
Download Limit: 64 kBytes

192.168.1.68 Always 1024MB/NA/NA
Max Total Up+Down: Limit to 1024 MBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 16 kBytes
Download Limit: 64 kBytes

What are the details of the QoS class you throttle them into?

Lantis wrote:What are the details of the QoS class you throttle them into?

I simply throttle the bandwidth when the limits have been met...

fr example:
I set a quota for the entire network to 9.5 GB per day and when this is reached, I throttle the entire network to an Upload Limit: 64 kBytes and
Download Limit: 512 kBytes...
A simple if exceed 9.5 GB do the throttle.
and so on for the rest of the quotas....

Need a screenshot of your QoS classes, up and down, as well as what classes your throttle applies.
e.g. if you want someone to try to replicate your scenario and test for a crash, this is important.
it could be very simple, or it could be a strange interaction of your particular set of settings.

dlogictech wrote:Hello All,

I may have found the area that causes the spontaneous reboot of routers when using the 1.7.x firmware.
I am currently using:
Gargoyle Version:1.7.X (Built 20150527-1912 git@7d816bd) - (I have also tried it with 1.7 and 1.7.1)
Model:D-Link DIR-835 rev. A1

Note: I was using the very same hardware and configuration manually configured with the older firmware 1.6.2 and it was running without any reboots for over 6 months.

Symptom:
Whenever I perform a speed test, the router would reboot. I have used http://www.speedtest.net and http://speedcheck.rogers.com/en.html
Usually the router would reboot almost everytime, occasionally it would not and you would have to do the speedtest back to back.

How to reproduce:
1) Configure your router with Quotas as shown by my examples below.
2) Ensure that they are all enabled.
3) Perform a speed test from one of the above sites.

Where I believe the root cause for this issue is in the "Firewall" - "Quotas" section.
My configuration that confirm this:

All Always 9GB/NA/NA
Max Total Up+Down: Limit to 9.5 GBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 64 kBytes
Download Limit: 512 kBytes

192.168.1.66 Always 1024MB/NA/NA
Max Total Up+Down: Limit to 1024 MBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 16 kBytes
Download Limit: 64 kBytes

192.168.1.67 Always 1024MB/NA/NA
Max Total Up+Down: Limit to 1024 MBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 16 kBytes
Download Limit: 64 kBytes

192.168.1.68 Always 1024MB/NA/NA
Max Total Up+Down: Limit to 1024 MBytes
Quota Resets: Everyday
Reset Hour: 12.00 am
Quota Is Active: Always
When Exceeded: Throttle Bandwidth
Upload Limit: 16 kBytes
Download Limit: 64 kBytes

Update:
It would seem that the Quotas may not be the root cause of the spontaneous router rebooting issue.
I had disabled the quotas from my configuration but the router just rebooted spontaneously.
I do know for a fact that the router reboots when there is high traffic.

I am willing to do further testing, I need to know what else I can try to resolve this issue.
Any assistance in this area is most helpful.
If there is a way for me to retrieve logs, please let me know and I will be happy to get and forward them for troubleshooting / investigation.