As I said this one was running Kong's build until it crashed on an upgrade. It has been on Kong's builds since the first builds came out and I have 11 other in family locations as well as three in my place (along with an r7800 and some Cisco NGFWs), so it is not a BoardID issue.
It has been up since I did the serial cable recovery on Netgears F/W with zero issues running a couple of stress tests on it. _________________ NetGear R7800 x2
Netgear R7000P
NetGear R6400V2 x 4
Buffalo WZR-HP-AG300H
Buffalo WZR-HP-G300NH2
Linksys WRT54G x3
Cisco NGFW
Joined: 18 Mar 2014 Posts: 12879 Location: Netherlands
Posted: Sun Jun 30, 2019 15:29 Post subject:
visiter555 wrote:
It is U12H332T20_NETGEAR
As I said this one was running Kong's build until it crashed on an upgrade. It has been on Kong's builds since the first builds came out and I have 11 other in family locations as well as three in my place (along with an r7800 and some Cisco NGFWs), so it is not a BoardID issue.
It has been up since I did the serial cable recovery on Netgears F/W with zero issues running a couple of stress tests on it.
I just changed the Netgear f/w to a different version and working 100% which means the proability of the hardware failure in the flash is really tiny.
egc wrote:
visiter555 wrote:
It is U12H332T20_NETGEAR
As I said this one was running Kong's build until it crashed on an upgrade. It has been on Kong's builds since the first builds came out and I have 11 other in family locations as well as three in my place (along with an r7800 and some Cisco NGFWs), so it is not a BoardID issue.
It has been up since I did the serial cable recovery on Netgears F/W with zero issues running a couple of stress tests on it.
My guess is a hardware failure, DDWRT uses other/more parts of the flash memory and if that is corrupt than you can not upgrade with DDWRT.
Posted: Thu Aug 08, 2019 10:19 Post subject: R6400 as repeter wifi
I have configured the R6400V2 as wifi repeater with the last firmware.
It work correctly but if for some reason the connection between main router and the repeater was lost, the repeater go in a state of continue rebooting when it try to enstablish a connection with the main roter.
what can i do to solve this problem?
Because in this case a power-off for 30second is useless the only solution founded is change the password on both router and repeater and it will start work correctly but if connection is lost again the problem return.
Please help me
An other solution for me is find a usb 4g dongle compatible with R6400V2 with ddwrt and avoid to use the main router, but i don't find any compatibility list
What is the last firmware i.e. build number and date?
I use this
DD-WRT v3.0-r40459 std (07/30/19)
EDIT:
I have problem only in the case of a connection lost, normally it work well, for exemple if main router rebooted or r6400v2 switched off and on for some reason.
I got my 6400v2 setup running the latest build (r40559). Is there any reason to be using the June stable Kong build instead?
I am trying to set this up as a repeater. My main router is an R7000. I am setting this up from LAN to main router to LAN on R6400.
Right now on the main router, I have a VLAN set up on a port hooked up to a switch with my IoT devices. I have avahi running fine on here, so everything on my 192.168.1.0/24 network can talk to everything on the 172.0.0.0/24 IoT VLAN.
If I put the r6400v2 in Router mode, disable DHCP and keep it on the same network as the main router, it will be able to act as a switch and extend my wifi from what I understand. my question is how do I configure further VLANs down the road if I want to connect them to the 6400v2? For example, I would like to move the switch with the IoT vlan devices hooked up next to the r6400. Would I then need to configure the vlan on the r6400, the r7000 (main router), or both?
first of all thanks to you for this dedicated topic and detailed step by step instructions for installing dd-wrt on r6400v2 routers
linux and dd-wrt things are new for me, yes i am newbie
installed stable version of kongac build with help of egc and it is running nicely
but yesterday i noticed something unusual , access restriction policies are only working when i disable openVPN client on dd-wrt
if i enable openvpn client then all access restriction policies are bypassed
is there a way to fix this issue?
already tried to search on duckduckgo but not able to find results
Last edited by d0d0 on Tue Sep 17, 2019 14:10; edited 1 time in total
Joined: 18 Mar 2014 Posts: 12879 Location: Netherlands
Posted: Fri Aug 23, 2019 15:35 Post subject:
Hmm interesting, you better ask in the advanced networking forum, this seems not specific to the R6400v2
I think it is related to how DDWRT handles the firewall rules, most rules are in the firewall "table" but rules for the OVPN client are generated when the client starts (in the route-up script) those rules are inserted and on the top of the table so the rules allowing VPN traffic will be executed before the access restriction rules.
I can think of three possible ways to deal with this:
Add access rules to the route-up script, use dev tun0 for the OVPN client and make your own firewall rules (probabaly inserting at at the top) or make your own access rules and insert them after the VPN client is up, but you need a script for checking and also if the client restarts
So basically something not very easy.
BUT I have no experience with access rules so it might well be that there is an easy fix .
So post this in the advanced networking forum
Edit: thinking about it maybe the addition of an iptables rule to jump to the lan2wan chain at the top of the table will do
Edit 2, thinking about it (I do a lot of thinking) the following two rules maybe will work
Hmm interesting, you better ask in the advanced networking forum, this seems not specific to the R6400v2
I think it is related to how DDWRT handles the firewall rules, most rules are in the firewall "table" but rules for the OVPN client are generated when the client starts (in the route-up script) those rules are inserted and on the top of the table so the rules allowing VPN traffic will be executed before the access restriction rules.
I can think of three possible ways to deal with this:
Add access rules to the route-up script, use dev tun0 for the OVPN client and make your own firewall rules (probabaly inserting at at the top) or make your own access rules and insert them after the VPN client is up, but you need a script for checking and also if the client restarts
So basically something not very easy.
BUT I have no experience with access rules so it might well be that there is an easy fix .
So post this in the advanced networking forum
[/code]
just for testing execute those rules after the VPN client is up and see if that restores the access restrictions, just execute from the CLI/putty
thanks for your reply
ok will create a topic inside advanced network section
i am using expressvpn they recommends Additional Dnsmasq Options
interface=tun1
so i am using tun1
Quote:
Edit 2, thinking about it (I do a lot of thinking) the following two rules maybe will work
just for testing execute those rules after the VPN client is up and see if that restores the access restrictions, just execute from the CLI/putty
its seems no one replying in advanced networking section regarding this issue
so continuing here i hope you don't mind
sorry delay in reply , i was not aware of what is putty and how to use it
now i know what is putty
i am not sure whether my steps are correct or not( i am able to find any good tutorial about putty and ddwrt testing)
steps:
first i enabled openvpn in ddwrt
now opened putty with admin rights(windows user)
entered my router ip
logged in as a root
entered your iptables commands
now i tried to access the blocked domains/servcies which i defined in access restriction policy
services and domain are blocked its working
sorry for newbie type question's
are my steps are correct or wrong?
now these iptables commands are already included in my routers firewall or should i add them manually?
if rules are temporary applied using putty so i can test other rules safely ?
as specified by the guide, only to find out that Kong is our of business:
Quote:
As you may have noticed I have not been able to follow dd-wrt development for a few weeks now.
Due to changes in life I don't have time anymore to continue compile/test/publish any custom builds anymore.
It is simply to time consuming, especially since I moved to openwrt.
It's been a fun time, but now it is time to move on.
Looks like we'd have to update the guide, trying BS's builds now...