Thank you. I will, but only on the weekend, because that is the time when I can stay awake after midnight when the family is sleeping.
Solved LAN client running qBittorrent crashes gt-ax6000 (running Merlin 3004.388.4)
- Thread starter ika
- Start date
Just as another data point: I have had the same GT-AX6000 router for about 6 months, with Skynet (and a couple of countries blocked in there), and I have alternated between Diversion and AdAware Home, and I regularly use Qbittorrent as well with no issues/slowdowns or crashes whatsoever. I even have the total max connections set in Qbittorrent to 999 (not 256, as you do), and still no crashing.
My uptime is now over 40 days on 3004.388.4, so there is something unique about your router or environment.
My uptime is now over 40 days on 3004.388.4, so there is something unique about your router or environment.
Thank you for the reply.
I agree with you. From the very beginning of this investigation, I believed that it is extremely unlikely that qBittorrent or Skynet or Diversion causing the issue (the main reason I did not start this thread in the addon forum). I just try to figure out the problem (after all I would like to enjoy my new router).
What I can tell you for sure that the very same environment works fine if I replace the router to my old ac86u (even if I increase the max connection to 1999).
This obviously doesn't mean that the cause of the issue is the gt-ax6000, but it means that it does handle something differently compared to the ac86u.
Thank you for the reply.
Just curious about this guess: What would cause the the connection table to overflow exactly 10 minutes after I quit the client?
Thank you.
I can agree with that, but I do not think the connection table overflows, because I would have no internet then.
One thing is that others do not have such issue with qBittorrent, and the other is that in that 10 minutes, I can do anything I want, I can even restart the torrent client and it will work fine in that 10 minutes.
We will see how it goes with the stock fw on the weekend, I'm very curious.
One thing is that others do not have such issue with qBittorrent, and the other is that in that 10 minutes, I can do anything I want, I can even restart the torrent client and it will work fine in that 10 minutes.
We will see how it goes with the stock fw on the weekend, I'm very curious.
Update:
First of all, thank you again for everybody who read and tried to help.
Installed stock 3.0.0.6. The issue did not happen. Installed back Merlin 3.0.0.4, and the issue is not happening anymore.
I do not understand.
I reset 3.0.0.4 many times. I have the steps written down on paper, just to make sure I set up everything the same way how I set it up for the previous tests.
Now I can throw anything to it, country-blocks, maxed out torrent client connection numbers, any of the AMTM addons, it eats all like nothing. Can't reproduce anymore, so I also can't investigate further.
I really do not understand.
First of all, thank you again for everybody who read and tried to help.
Installed stock 3.0.0.6. The issue did not happen. Installed back Merlin 3.0.0.4, and the issue is not happening anymore.
I do not understand.
I reset 3.0.0.4 many times. I have the steps written down on paper, just to make sure I set up everything the same way how I set it up for the previous tests.
Now I can throw anything to it, country-blocks, maxed out torrent client connection numbers, any of the AMTM addons, it eats all like nothing. Can't reproduce anymore, so I also can't investigate further.
I really do not understand.
sfx2000
Part of the Furniture
Happy you might have it solved...
Generally - bittorrent can open up a lot of connections by default, and in some cases, more that consumer routers can handle... Each one of those connections takes up some RAM - so depending on the torrent client configuration, one can run the router NAT tables out of memory, and when that happens, things can go awry...
Thank you.
This was definitely something else. Installing 3.0.0.6 stock cleared something what installing 3.0.0.4 could not (as I wrote, I do not understand). I was down to limiting the connections on the client to 8(!), and it still crashed 10 minutes later I exited the app, every single time.
Sorry for the resurrect, I removed "Solved" because it turns out it is back again. After upgrading to 3004.388.5, it started happening again, so I did a nuclear reset which mislead me to believe it is good, but it is still happening just not as consistent (it always crashes, but not exactly after 10 mins I quit the client).
The first time I had it, the router crashed exactly 10 mins after the moment I quit the torrent client, now (as I did 4 tests today) it is different, it happened while the torrent app was still running (took about 10 mins from the start I think, but not sure).
I just give up now, it is hopeless. I'm not gonna debug Asus IT problems in my free time when I'm supposed to have fun, I'M not gonna work only because some bug I have no clue how to investigate. I even replaced the unit, spent so much time with this.
Maybe it is some stupid combination, like I use 192.168.128.0/24 and disable iTunes server or my VPN director settings, or idk, the permutation of the settings I would need to test is just way too high and the OS is too closed to dig into the issue. This is a very bad user experience, and definitely not why I used these routers from the n66u times.
Putting the thing back to the box. The AC86U has zero issues with the very same settings, with the very same clients and in the very same environment. Maybe I try again some months later, to see if anything changed.
Thank you all for your time and for trying to help.
The first time I had it, the router crashed exactly 10 mins after the moment I quit the torrent client, now (as I did 4 tests today) it is different, it happened while the torrent app was still running (took about 10 mins from the start I think, but not sure).
I just give up now, it is hopeless. I'm not gonna debug Asus IT problems in my free time when I'm supposed to have fun, I'M not gonna work only because some bug I have no clue how to investigate. I even replaced the unit, spent so much time with this.
Maybe it is some stupid combination, like I use 192.168.128.0/24 and disable iTunes server or my VPN director settings, or idk, the permutation of the settings I would need to test is just way too high and the OS is too closed to dig into the issue. This is a very bad user experience, and definitely not why I used these routers from the n66u times.
Putting the thing back to the box. The AC86U has zero issues with the very same settings, with the very same clients and in the very same environment. Maybe I try again some months later, to see if anything changed.
Thank you all for your time and for trying to help.
L&LD
Part of the Furniture
The times of the RT-N66U and today's AX+ class equipment have seen almost everything change in the WiFi/networking space.
I'm not saying you need to beta-test anything for Asus or anyone else.
But, you do need to change/adapt to the current environment.
If it's working well (enough) for everyone else, then it is something you're doing.
Asus, and all other manufacturers, have to follow the current best practices as dictated by law, changing WiFi standards, and other influences. Individually, we're just along for the ride, for the better of all.
You can simply blame Asus and have an unstable network. Or, you can use a systematic procedure to determine what actually breaks your network, and if there is anything you can do about it.
That is what the outline of the Nuclear Reset attempts if followed to the letter.
Overview:
Step 1: Make sure the router/firmware is working as intended and the firmware is using its anticipated defaults and variables within the ranges expected. At this step, we're assuming the hardware is functional.
Step 2: Verify by observation (for as long as it is required, depending on the original issues observed), that the router hardware is working as expected. This is as close as we can verify the hardware isn't at fault without using lab equipment at our homes.
Step 3: With a base/default configuration (above), we should have ruled out whether those settings are stable or not. Assuming stability, we now add a single additional variable and test further for as long as necessary (again, depending on the original issues we had with the router/network.
These aren't random variables, features, scripts, etc. we're adding. These are specifically what we're using on our personal, individual networks. No need to test the billions of possible combinations. Only ours.
Step 4: Satisfied with the stability of our router/network with the last configuration we changed, we repeat Step 3 with another that we (think) we need/use in our networks.
Repeat, until the system is fully configured as we want, or we find what additional change breaks our network/router.
Keeping excellent notes is essential for this type of troubleshooting. Particularly if it is done over days and weeks. But the rewards of a network perfectly matching our needs are well worth it.
www.snbforums.com
Additional points to keep in mind:
Don't use, enable/change/set options/features, or scripts just because you did in the past. They may be not needed, or outright detrimental in today's (vastly changed) networking environments.
Don't toggle settings on/off to see what they do. This is not the same as simply leaving the setting at its default (on or off). A full reset is more than likely the fastest way to make sure the router is in a good/known state once again if you have been doing this.
With each change made, even after a router-initiated reboot, I would still recommend rebooting the router once more via the GUI after 10 or 15 minutes. And verifying after each reboot that the changes you have made so far are preserved and intact.
The 'notes' you're taking above should be incorporated even when not troubleshooting.
The journal you keep of the changes and adjustments you make to your network may help you avoid doing all the above in the future. A dated, time-stamped 'diary' of your router/network is a must if you're not using simple defaults, whether that is with consumer hardware or more enterprise-level models.
And I'll repeat, you're not troubleshooting anything here for Asus (at least not directly). You're doing this for your unique network setup. You may still not want to do this, but that doesn't mean Asus is (or 'can' be) responsible for these corner cases, such as yours.
I'm not saying you need to beta-test anything for Asus or anyone else.
But, you do need to change/adapt to the current environment.
If it's working well (enough) for everyone else, then it is something you're doing.
Asus, and all other manufacturers, have to follow the current best practices as dictated by law, changing WiFi standards, and other influences. Individually, we're just along for the ride, for the better of all.
You can simply blame Asus and have an unstable network. Or, you can use a systematic procedure to determine what actually breaks your network, and if there is anything you can do about it.
That is what the outline of the Nuclear Reset attempts if followed to the letter.
Overview:
Step 1: Make sure the router/firmware is working as intended and the firmware is using its anticipated defaults and variables within the ranges expected. At this step, we're assuming the hardware is functional.
Step 2: Verify by observation (for as long as it is required, depending on the original issues observed), that the router hardware is working as expected. This is as close as we can verify the hardware isn't at fault without using lab equipment at our homes.
Step 3: With a base/default configuration (above), we should have ruled out whether those settings are stable or not. Assuming stability, we now add a single additional variable and test further for as long as necessary (again, depending on the original issues we had with the router/network.
These aren't random variables, features, scripts, etc. we're adding. These are specifically what we're using on our personal, individual networks. No need to test the billions of possible combinations. Only ours.
Step 4: Satisfied with the stability of our router/network with the last configuration we changed, we repeat Step 3 with another that we (think) we need/use in our networks.
Repeat, until the system is fully configured as we want, or we find what additional change breaks our network/router.
Keeping excellent notes is essential for this type of troubleshooting. Particularly if it is done over days and weeks. But the rewards of a network perfectly matching our needs are well worth it.
Merlin on ASUS ax86U Question
I have an ASUS AX86U and contemplating the installation of Merlin firmware. The DDNS settings on the AX86U are limited to select dns providers. If I install Merlin, will I have more flexability (choices) with the DDNS Settings? Thanks in advance!
www.snbforums.com
Additional points to keep in mind:
Don't use, enable/change/set options/features, or scripts just because you did in the past. They may be not needed, or outright detrimental in today's (vastly changed) networking environments.
Don't toggle settings on/off to see what they do. This is not the same as simply leaving the setting at its default (on or off). A full reset is more than likely the fastest way to make sure the router is in a good/known state once again if you have been doing this.
With each change made, even after a router-initiated reboot, I would still recommend rebooting the router once more via the GUI after 10 or 15 minutes. And verifying after each reboot that the changes you have made so far are preserved and intact.
The 'notes' you're taking above should be incorporated even when not troubleshooting.
The journal you keep of the changes and adjustments you make to your network may help you avoid doing all the above in the future. A dated, time-stamped 'diary' of your router/network is a must if you're not using simple defaults, whether that is with consumer hardware or more enterprise-level models.
And I'll repeat, you're not troubleshooting anything here for Asus (at least not directly). You're doing this for your unique network setup. You may still not want to do this, but that doesn't mean Asus is (or 'can' be) responsible for these corner cases, such as yours.
Thank you very much for the long and detailed post L&LD, much appreciated, but the situation is really and truly different:The times of the RT-N66U and today's AX+ class equipment have seen almost everything change in the WiFi/networking space.
I'm not saying you need to beta-test anything for Asus or anyone else.
But, you do need to change/adapt to the current environment.
If it's working well (enough) for everyone else, then it is something you're doing.
Asus, and all other manufacturers, have to follow the current best practices as dictated by law, changing WiFi standards, and other influences. Individually, we're just along for the ride, for the better of all.
You can simply blame Asus and have an unstable network. Or, you can use a systematic procedure to determine what actually breaks your network, and if there is anything you can do about it.
That is what the outline of the Nuclear Reset attempts if followed to the letter.
Overview:
Step 1: Make sure the router/firmware is working as intended and the firmware is using its anticipated defaults and variables within the ranges expected. At this step, we're assuming the hardware is functional.
Step 2: Verify by observation (for as long as it is required, depending on the original issues observed), that the router hardware is working as expected. This is as close as we can verify the hardware isn't at fault without using lab equipment at our homes.
Step 3: With a base/default configuration (above), we should have ruled out whether those settings are stable or not. Assuming stability, we now add a single additional variable and test further for as long as necessary (again, depending on the original issues we had with the router/network.
These aren't random variables, features, scripts, etc. we're adding. These are specifically what we're using on our personal, individual networks. No need to test the billions of possible combinations. Only ours.
Step 4: Satisfied with the stability of our router/network with the last configuration we changed, we repeat Step 3 with another that we (think) we need/use in our networks.
Repeat, until the system is fully configured as we want, or we find what additional change breaks our network/router.
Keeping excellent notes is essential for this type of troubleshooting. Particularly if it is done over days and weeks. But the rewards of a network perfectly matching our needs are well worth it.
Merlin on ASUS ax86U Question
I have an ASUS AX86U and contemplating the installation of Merlin firmware. The DDNS settings on the AX86U are limited to select dns providers. If I install Merlin, will I have more flexability (choices) with the DDNS Settings? Thanks in advance!
Additional points to keep in mind:
Don't use, enable/change/set options/features, or scripts just because you did in the past. They may be not needed, or outright detrimental in today's (vastly changed) networking environments.
Don't toggle settings on/off to see what they do. This is not the same as simply leaving the setting at its default (on or off). A full reset is more than likely the fastest way to make sure the router is in a good/known state once again if you have been doing this.
With each change made, even after a router-initiated reboot, I would still recommend rebooting the router once more via the GUI after 10 or 15 minutes. And verifying after each reboot that the changes you have made so far are preserved and intact.
The 'notes' you're taking above should be incorporated even when not troubleshooting.
The journal you keep of the changes and adjustments you make to your network may help you avoid doing all the above in the future. A dated, time-stamped 'diary' of your router/network is a must if you're not using simple defaults, whether that is with consumer hardware or more enterprise-level models.
And I'll repeat, you're not troubleshooting anything here for Asus (at least not directly). You're doing this for your unique network setup. You may still not want to do this, but that doesn't mean Asus is (or 'can' be) responsible for these corner cases, such as yours.
The AC86U is doing the very same thing in my
with the very same settings just without crashing and restarting. I sit front of the very same PC and I test with the very same torrent clients and no crash. It is the gt-ax6000 for sure. I do understand that it is my setup and environment causing it of course (sadly I cannot leave everything on default because, for example: many of my IOT devices have manually entered IP addresses) , but (as I wrote it earlier multiply times) no scripts, no USB stick, no entware is needed after a nuclear reset to make the crashes happen.
Maybe it is my NIC triggering the GT-AX6000's STP protection and restarts the switch, maybe something else, but I'm really tired of investigating because I tried 50 things and still have like 30 more ideas and it is a lot easier to just use something I know it works instead of debugging an Asus hardware level problem. There is nothing in the logs whatsoever before the crash, so it is most likely some very low (driver) level problem I will never empirically diagnose.
Thanks, but it is TCP only on all the torrent apps I tried, and it did not matter before the dirty upgrade and it does not matter with the ac86u.
maxbraketorque
Very Senior Member
I haven't gone back to re-read this thread so this could have already been asked - have you tried other BT applications? I've never had a problem with qBT, but I prefer the GUI of Transmission, and its been rock solid on my network.
Yes I did, it is crashing with transmission as well.
I just could not drop it so easily, so yesterday evening I made some more tests with other models (besides the AC86U, which is the router in use atm).
- AX58U (Merlin, same userscripts),
- AX53U (Stock, no userscripts),
- N66U(john9527,'s fork, no userscripts),
- N18U (Stock, no userscripts),
- AC68U (Merlin, same userscripts).
edit: I suspect the AX6000 "hates" my mobo's 8125BG. I do not have a spare NIC card atm to try, but I ordered one.
Last edited:
Similar threads
Similar threads
Similar threads
-
GT-AX6000 - 3004_388.6_0 - Wireguard client - No Access to Servers local LAN
- Started by Drihha
- Replies: 5
-
How to route domain from server side lan via remote ovpn client
- Started by j911
- Replies: 6
-
Wireguard Client Can't Communicate with Ubuntu Server on LAN
- Started by cobolsam
- Replies: 3
-
2x AC86U connected through OpenVPN (LAN only), additional server on client side not reachable
- Started by naabo
- Replies: 4
-
-
LAN > DHCP List - Manually Assigned Name + Icon DONT SAVE
- Started by copperhead
- Replies: 4
-
-
RESOLVED: Lost access to WebUI from LAN, SSH is working
- Started by GPSMapper
- Replies: 1
-
Connecting an ax58u to a BT homehub 5, via a lan port, and not getting internet access.
- Started by Nickat1
- Replies: 3
-
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!