[iamgroot]

First off, thank you admin folks & developers for creating the dd-wrt project, I've been using dd-wrt since the early builds in the mid - late 2000's never actually posted nor needed to as the wiki & other documentation is quite fabulous and most builds have been generally quite stable in my experience, at least when paired with the right router hardware and configured correctly. I generally know my way around network hardware and a Linux terminal etc. But this particular issue is making me feel like a blockhead.

And now here - I have collected a rather tall stack of routers that do not work and have tried all of them running various versions of the latest dd-wrt builds, even some older builds and all of them are behaving similar with the same types of issues. I will get more specific as we go along, and can certainly post logs I will attempt to not bore you with a novel but unfortunately to get a clear picture of what I'm dealing with this post may get lengthy.

so the devils in the details; in front of me I have a quick trick brick stack of...

Netgear R7000's (multiples)
Netgear R6700 V3
Netgear R7000p
Netgear R7800
TP-Link Archer C7 v5 (Three of them)

Symptoms: All of them act very much in the same organized chaotic fashion. The LED's begin to behave very strangely on boot up compared to what I've known in the past. Wireless lights flicker on/off randomly, The LAN port lights that are not plugged in turn on/off at times. and seems to go through a re-boot up sequence of sorts, then the wireless lights come BACK on & stay on even frequently after being disabled in webgui, 20+ character passwords, even when I lock down all the security settings and disable remote access, restrict IP addresses, change to alternate subnets. disable SSH, telnet services, restrict access IP addresses, At best the router simply wont work and locks me out of the interface and the wireless lights flicker and some of the LAN port lights come on (even when disabled & ethernet unplugged). Thats mostly what happens now; God forbid I plug one into the WAN that was resulting in DNS hijacks/redirects, in spite of VPN and local machine firewalls.

I've tried just about I can possibly rack my brain over.

I can fire them up after a good hard reset, & get into webgui interface, clear factory reset, firmware upgrade goes fine and dandy. I can set strong admin passwords configure the settings as I want, and I've tried many variations... soon as I log out and reboot the router kaboom

That being said, I'm stumped over here getting tired of banging my head against a wall, and figured it cant hurt to ask for a little help, and maybe if whats happening as I suspect is indeed some kind of vulnerability in the wireless being exploited that may need patching as I've seen tell of on various channels recently. To be clear, as part of my job in IT I am on the front lines to mitigating a lot of active-threats and having recently helped some small business clients clean up their infected networks of some nasty successful phishing attempts landed them with rootkits combined with other malware delivery methods and their unfortunate subsequent payload deliveries made their way up into one of my personal LAN's unnoticed. Guessing through some vulnerability in one of my many devices.

I've subsequently sterilized and squashed the bugs in my LAN, disabled all wireless functions, quarantined all hard drives, potentially infected devices, and flash media, nuked and paved all the local machines, replaced any old motherboards if the firmware wasn't able to update. Most of the test-rigs I'm running for the moment while I'm trying to configure the routers are all simply linux live boot mostly debian based distros from DVD's (verified PGP keys), with no persistence and no hard drives installed. Therefore I know this isn't coming from the local machines, or at least not anymore... I hope.

The only two routers I have been able to get working & fully secured so far are one of the TP-Link Archer C7's running the latest stock firmware, and a brand new TP-Link Archer C4000, also completely stock firmware configured with maximum security and disabled wireless, I don't think dd-wrt supports it yet.. I was able to get these working by using the physical disable wireless button, configuring it from a completely sandboxed laptop running blackarch or puppy linux and bound the sandboxed computer as the only mac address I've bound as being able to access the admin panel interface.

I know I promised you some logs, but that's been a bit of a hassle to reliably collect them as the only time I can get reliable access to the backend functionality is when the quick trick brick in question is plugged into a sandboxed machine and therefore my copy and paste function consists of encrypted sneakernet thumbdrives or dvds just to be safe. I also just realized its almost 3 am now so that might have to wait for a post tomorrow; Let me know what logs /routers/ builds you want first? lol any recommended builds to try or settings my tired brain overlooked would appreciated.

Thank you for your time.

[kernel-panic69]

And we have no idea what DD-WRT build version you are experiencing these issues on. When you come back to this thread, please provide all applicable information. Thanks.

[iamgroot]

[egc]

Do not use Chrome or chromium based browsers.
Use Waterfox classic, FF without any extensions often also works.

Probably do not disable http access.

Edit: if you are the only one connected by wire you can safety use http

[kernel-panic69]

[iamgroot]

Thank you for the reminder on being patient. I realize sometimes do work too fast for the router to process the settings. I will ensure a more patient awareness of the basic save/apply/reboot process here for my next attempt and report back.

[Alozaros]

on R7000 and r7800 only https works fine...
just don't use chrome based browsers...i use pale-moon only for router stuff...

I clearly didn't get your full issue, LEDs are funny or you suspect of been wifi hacked?

Collect logs, firewall and syslogs logs, do a Wireshark on TAP... What type is your WAN connection...?

Of course WPA2 can be bruteforced, but takes time, if you use a crafty WiFi password...apart of that, there are few other methods of overtaking WPA2 AES some of them very easy and you cannot do anything against it..sadly...But you can create a honeypot and get some details about the perpetrator..if he is that stupid...unless he is not, your final chance is honeypot with bomb and he will get some fun too...but those cases require strategy, patience and planning...as well some skills

Other things that you can do it to put some restrictions via DNSmasq/iptables and harden you router with static addresses and not free DHCP, but this is smoken mirror

[iamgroot]

So it does appear that changing it to HTTPS only mode was my primary culprit that I kept stumbling on boy do I feel silly - And thank you Alozaros for pointing out that it does/can actually work on r7000/r7800's so now I don't feel completely crazy because I was pretty sure I had that feature working at one point or another? lol

I now have just HTTP mode, restricted IP address access etc. etc. At least was able to get the R6700 working OK, still have the rest of the quick trick brick stack to flash through but I don't anticipate that will be an issue now that I have the network cleaned up.

[kernel-panic69]

It may only be enabled and usable on certain devices:

https://svn.dd-wrt.com/ticket/3589

But, I am sure if I scoured this forum for posts over the past few years, I will find a recent enough post that says a startup script is required for it to work properly. I still don't waste the time specifically because upgrading firmware over https is not enabled.

[Alozaros]

https is working ok on R7800 and R700 been using those always..do in mind it uses self signed certificate that you'd need to accept in your browser...but all is working as it should...

https has never worked on my TPlink 4MB flash size routers...as it doesn't have enough space, as BS stated in the past...if i can recall correctly there was an attempt that was not ok and since than https works only on 8MB+ flash size routers...(1043v2 is ok with https)...
Do not confuse https over WAN port...

You can harden GUI and SSH access with some iptables rules, that limit/restrict GUI accesses, bound to MAC address only.

iptables -I INPUT -p tcp --dport 443 -j REJECT
iptables -I INPUT -p tcp --dport 443 -s 192.168.1.101 -j ACCEPT

This will limit https GUI to a specific IP given by the router dhcp, so you need to add static IP bound to mac address

or this is to allow GUI to a specific mac only

iptables -I INPUT -i br0 -p tcp --dport 443 -j REJECT
iptables -I INPUT -i br0 -p tcp --dport 443 -m mac --mac-source xx:xx:xx:xx:xx:xx -j ACCEPT

good idea is to change SSh port to anything else and harden it with the same rules for example...

*you can remove this bit to make the rule more general (-i br0)

do in mind nothing will help, if your system is compromised from inside...but those above are good to have..

you can also limit DHCP given addresses via DNSmasq with some other rules, so even if the attacker knows your wifi pass, it will not get an IP, but this is not a general solution...

[kernel-panic69]