Your reports are highly appreciated !
Router:
Firmware:
Kernel:
Status:
Reset:
Errors:
This build thread is for reporting successes and problem with loading this experimental test build. This is important info for developers and users. Always state your hardware and SPECIFIC build (e.g. 27715_NEWD-2_K2.6_mega-nv64k.bin). Do not ask questions about your specific router or how to configure it in this thread; create your own thread to discuss any specific problems you have or need resolved. Please also do not respond to such questions. This thread is to report info, not to seek it. Posts that do not add to understanding this build will be deleted. Make sure you know how to flash properly and the risk before using this build. It is important to adhere to these requirements, to keep this thread from becoming impossibly long and useless. If you don't know what build to flash and how to flash properly and have a means of recovery if things should go wrong, do NOT flash this experimental test build. _________________ THERE ARE NO STRANGERS HERE; ONLY FRIENDS YOU HAVEN'T YET MET.
________________________________________________________________________________________________________
DD-WRT CHANGELOG | DEVICES | DD-WRT BUILDS | KONG BUILDS | UNOFFICIAL BUILDS | DD-WRT in VIRTUALBOX
Last edited by KrypteX on Wed Sep 02, 2015 7:37; edited 2 times in total
Posted: Mon Aug 24, 2015 1:30 Post subject: Found a bug in this one
Thanks for the great work Kong.
Have found a bug in this one though (R27715M). If you attempt to RDP over a SSH tunnel to a machine which is asleep or not responding then the SSH tunnel is terminated . The message from putty is 'Server unexpectedly closed network connection'.
Sounds weird, but it didn't happen with the previous build. Also doesn't happen if the sleeping machine is WOL'ed first.
Edit: The SSH tunnel will be terminated when trying to access anything over it that is not available without fail. Even trying to access a website that is down over the SSH tunnel will cause it to disconnect. _________________ R7000 - 30910M - Kong
Last edited by Free2bme on Mon Aug 24, 2015 22:10; edited 1 time in total
Works on R7000 now with openvpn, dlnr-server and privoxy. I only use 2,4GHz ng (AP).
I noticed that policy based routing in the openvpn client isn't working correctly. I don't need that at the moment, but it seems that clients specified in that field cannot use the tunnel.
I only get one device to bypass the tunnel (ipad), all other devices have no internet access at all.
Up and running with r27715M, so far so good after some preliminary testing.
There is only one problem I've seen so far, and it's probably not a Kong specific issue. It has to do with the OUI search, where you click on a MAC address in the GUI (on the LAN tab for example). Ordinarily doing so would open a window showing the IEEE page giving the manufacturer's info for that MAC address' device. I believe the IEEE web administrators recently changed the interface, so now the new window shows a rather lengthy list of what looks like all of the manufacturers in their database.
A minor problem, but one that is probably easy to fix if the new interface is available. _________________ Netgear R7000: v3.0-r54248 std (11/29/23)
EdgeRouter-X: EdgeOS v2.0.9-hotfix 7
Joined: 24 Mar 2015 Posts: 175 Location: Tacoma, Wa
Posted: Wed Aug 26, 2015 4:29 Post subject:
allcius wrote:
All good on my r7000 the only thing i can not select wht 80+80 on 5g wireless
Same issue here on my R8000. 80+80 isn't available at all now.. _________________ Routers:
Netgear R8000 - DD-WRT v3.0-r43420 std (06/15/20)
Netgear R9000 - DD-WRT v3.0-r43420 std (06/15/20)
Joined: 24 Mar 2015 Posts: 175 Location: Tacoma, Wa
Posted: Wed Aug 26, 2015 5:18 Post subject:
Router: R8000
Firmware: DD-WRT v3.0-r27715M kongac (08/23/15)
Kernel: Linux 3.10.87 #411 SMP Sun Aug 23 00:17:52 CEST 2015 armv7l
Status: Working
Reset: No
Errors:
1. No VHT 80+80 available for 5G
2. Number of channels available now is a very limited list (2 and 1 for the 5G radios)
Router: Netgear R7000
Firmware: DD-WRT v3.0-r27715M kongac (08/23/15)
Kernel: Linux 3.10.87 #411 SMP Sun Aug 23 00:17:52 CEST 2015 armv7l
Status: Working
Reset: Yes
Errors: Remote Access "use HTTPS" doesn't appear to work. If I disable HTTPS, normal HTTP works.
Netgear R6300v2
Kong PTB 27525 file dated 7/16/2015 --> Kong PTB 27715 file dated 8/23/2015
**Dirty Flash -- NO RESET**-- But did have to power cycle the device once to get it to "come back up" properly.
File: No point to linking official Kong PTB repo, next PTB will overwrite this file... (but HERE is link to my personal repo of kong's historical work) MD5: See ddup details below for details.
DDNS -- OK (custom for dnsomatic)
SSH Tunneling -- OK
RDP session via SSH Tunneling -- OK
OpenDNS Content Filtering -- OK
SAMBA -- OK, 2tb public NAS no security
MiniDLNA -- OK (upon initial review, I will give the db time to build before testing thoroughly)
NO REBOOTS! (since new WiFi driver 2015-02)
so far no WiFi drops either (will keep this thread updated if anything changes)
**note testing performed based on 30 minutes of observations from the far end of an SSH tunnel, I will update if anything above is not accurate**
ddup command love notes:
login as: root
DD-WRT v3.0-r27525M kongac (c) 2015 NewMedia-NET GmbH
Release: 07/15/15
Authenticating with public key "xxxxxxxxxx"
Passphrase for key "xxxxxxxxxx":
==========================================================
root@DD-WRT:~# ddup --flash-latest
New release 27715 for Netgear R6300V2 available.
Do you want to update (y/n) [default=n]:
y
Connecting to www.desipro.de (82.165.89.193:80)
fw.bin 100% |*******************************| 20800k 0:00:00 ETA
Connecting to www.desipro.de (82.165.89.193:80)
fw.bin.md5 100% |*******************************| 63 0:00:00 ETA
Checksum: 2a2f8751501b52dd117c4ecd7975165e expected 2a2f8751501b52dd117c4ecd7975165e
Checksum for dd-wrt.v24-K3_AC_ARM_STD.bin ok.
Are you sure you want to proceeed (y/n) [default=n]:
y
Closing ssh connections now. Flashing now...
root@DD-WRT:~#
... reboot ...
login as: root
DD-WRT v3.0-r27715M kongac (c) 2015 NewMedia-NET GmbH
Release: 08/23/15
Authenticating with public key "xxxxxxxxxx"
Passphrase for key "xxxxxxxxxx":
==========================================================
Assumptions:
1. Everyone on the forum has read the relevant forum section announcements.
2. For Broadcom section we have ALL at least tried to understand the "Peacock" thread,HERE
Posted: Wed Aug 26, 2015 16:46 Post subject: Re: Found a bug in this one
Free2bme wrote:
Thanks for the great work Kong.
Have found a bug in this one though (R27715M). If you attempt to RDP over a SSH tunnel to a machine which is asleep or not responding then the SSH tunnel is terminated . The message from putty is 'Server unexpectedly closed network connection'.
Sounds weird, but it didn't happen with the previous build. Also doesn't happen if the sleeping machine is WOL'ed first.
Edit: The SSH tunnel will be terminated when trying to access anything over it that is not available without fail. Even trying to access a website that is down over the SSH tunnel will cause it to disconnect.
Same issue here. Any SSH tunnel is not working. Was working on the previous release. Get "Server unexpectedly closed network connection" message once you try to tunnel anything.
Still having problems with the openvpn client when internet connection drops. If I put in the name of the server, the client can't resolve the name. The client stucks in status "RESOLVE".
If I put in the ip everything is fine.
Posted: Wed Aug 26, 2015 21:30 Post subject: [R6300v2] Windows client connections dropping (ARP issue?)
Router: Netgear R6300V2
Firmware: DD-WRT v3.0-r27715M kongac (08/23/15)
Kernel: Linux 3.10.87 #411 SMP Sun Aug 23 00:17:52 CEST 2015 armv7l
Status: Loaded fine, working with one issue described below
Reset: Automatic/successful on update
Errors:
I have an ongoing issue that has continued with this build on R6300v2 (and has been a problem for at least a few months). I figured it's right to post it here, but please let me know if it would be more appropriate to start a new thread.
Two different Windows client machines experience intermittent connectivity interruptions. This appears to affect WiFi but not wired. These Windows client machines do not have issues on other (non-DD-WRT) networks. Devices running other OSes (Linux, Android, Roku, TV WiFi adapters, etc.) no not have issues on this network.
The user-facing behaviour tends to be that pages suddenly fail to load, DNS queries don't come back, and the adapter resets or connectivity just shows as "limited". Manually disconnecting and re-selecting the network results in it working fine again until the next drop (usually ~8-15 mins or longer).
I have attached a tab-delimited text file pulling from as many Windows event log sources as I could during one of these disconnect/ manual-reconnect events. It includes a message that is a common thread: one of the first signs of trouble is a logged error that lists the reason as "Suspect ARP probe failed".
ddwrt_drop_win_excerpt_ac.txt
Description:
Tab-delimited text of Windows event logs dumped from a client disconnect event. ARP problem?
Router: R7000
Firmware: DD-WRT v3.0-r27715M kongac (08/23/15)
Kernel: Linux 3.10.87 #411 SMP Sun Aug 23 00:17:52 CEST 2015 armv7l
Status: Works
Reset: Yes
Errors: Everything seems to work apart from VHT 80+80@5GHz.
Changing wl1 to 20Hz works and takes effect.
Changing wl1 to 40Hz also works and takes effect as expected.
Setting wl1 to VHT80 however doesn't take effect and channel width stays at the previous setting. Inspecting the network with a client device confirms this.
When VHT 80+80 is enabled for wl1 in GUI it wrongly reports in Status>Wireless>Clients that clients connect using VHT80 (see screenshot).
It seems as if the VHT80 setting doesn't get saved properly although I may be wrong.
I'm coming from 24200M build and I noticed a significantly lower signal strength with 27715M build. In both cases had TxPower set to 999 in GUI. Measurements taken within 30min time window. Noise level without change (-95dBm).
24200M RSSI oscillated around -48dBm
27715M RSSI oscillates around -65dBm
Could new drivers be the cause of this?
