I like to know the revision since I keep a copy of all Kong R7000 firmware as he posts them.
However I am unable personally to determine the revision since I am running XVortex on my R7000.
<Kong> wrote:
mchaney wrote:
I fear my post above might be interpretted as complaining. Didn't mean it that way. No complaints here. It's just that Kong is the only one who supports the R8500 and that's one expensive piece of equipment to have to blindly install versions to find out what version it is or what's in it (I have no way to debrick it if something goes wrong). So I just ask here if I don't already see that answered in a thread. A small txt file in the same folder as the versions, stating what it is, would help but I can always just wait a day or two and look here, so no "complaints" from me.
Mike
If I think there are important changes, then I increase the version number so ddup will tell you.
All the changes in those 29300 updates are one or two liner that fix specific little probs I have seen in my setup. Thus in general just use ddup it will tell you when to update.
_________________ Router currently owned:
Netgear R7800 - Router
Netgear R7000 - AP mode
Flashed dd-wrt.K3_R7000.chk 04-15-16 to my R7000 and dd-wrt.v24-K3_AC_ARM_R8000.bin 04-15-16 to my R8000. My setup is pretty simple so I don't need a lot. IPv6 is native with DHCPv6 from TWC/RR. In addition, I use DNS-o-matic to keep my OpenDNS IP address current. DDNS works without issue, but the IPv6 is inconsistent on both routers. When using tomato or stock on the R7000 or stock on the R8000 (haven't had a stable R8000 tomato yet), the IPv6 is always there, but when using dd-wrt it fluctuates. I can look at the GUI and sometimes there is an address in the upper left corner and sometimes not. Thanks @Kong for your work. _________________ NETGEAR R9000 DD-WRT v3.0-r45192 std (12/29/20) (ROUTER)
NETGEAR ORBI Stock FW V2.7.2.102 (MESH)
WRT3200ACM (BS Build Usually) (BACKUP)
I was changing some settings on the latest 29300 (dated 4/14 in status) today and changed wl2 to AC/N only because my son's bridge doesn't like "Mixed" mode. I applied those settings changes and everything was working except two of my security cameras. 2 of 8 security cameras would not connect and if you look at the wireless status page, their MAC addresses would come and go every few seconds. Signal said 100% and speeds just said NA, then they'd disappear and retry. Unplugging the security cameras and plugging them back in did not fix it: did the same thing. Turning off the R8500 and turning it back on did fix it. Seems like there's still a loose nut or two with WiFi authentication. On two other occasions, all my cameras dropped and wouldn't reconnect until I powered off the R8500 (this occurred without me even accessing the web GUI or making any changes: just happened after a few days of up-time). Last time that happened was with the 4/13 R29300 (the one prior to this latest).
Thought I should report it. Thanks as always. BTW, I did check SysLog but it seems there's never anything in there of relevance. Just a bunch of DHCP requests and acks, mostly from stuff like my Xbox One.
Regards,
Mike
This is similar to what I've seen with the R8500. Changes to WiFi security/auth settings often seem to put it in an odd state until after I reboot.
Recently from a factory reset I changed only the auth mode from nothing to WPA2. The router reported that the change had been made, but the radios didn't actually start advertising any security to clients until after reboot. I went back to stock firmware just to A/B test and did not experience this, for what it's worth.
I was changing some settings on the latest 29300 (dated 4/14 in status) today and changed wl2 to AC/N only because my son's bridge doesn't like "Mixed" mode. I applied those settings changes and everything was working except two of my security cameras. 2 of 8 security cameras would not connect and if you look at the wireless status page, their MAC addresses would come and go every few seconds. Signal said 100% and speeds just said NA, then they'd disappear and retry. Unplugging the security cameras and plugging them back in did not fix it: did the same thing. Turning off the R8500 and turning it back on did fix it. Seems like there's still a loose nut or two with WiFi authentication. On two other occasions, all my cameras dropped and wouldn't reconnect until I powered off the R8500 (this occurred without me even accessing the web GUI or making any changes: just happened after a few days of up-time). Last time that happened was with the 4/13 R29300 (the one prior to this latest).
Thought I should report it. Thanks as always. BTW, I did check SysLog but it seems there's never anything in there of relevance. Just a bunch of DHCP requests and acks, mostly from stuff like my Xbox One.
Regards,
Mike
This is similar to what I've seen with the R8500. Changes to WiFi security/auth settings often seem to put it in an odd state until after I reboot.
Recently from a factory reset I changed only the auth mode from nothing to WPA2. The router reported that the change had been made, but the radios didn't actually start advertising any security to clients until after reboot. I went back to stock firmware just to A/B test and did not experience this, for what it's worth.
I'm seeing the same thing ... My foscam wireless cameras stopped connecting after build 3/30 ... Also after any wireless changes all b/g clients disconnect and have to reboot for them to connect again ... I have a r7000
Adding to this subject of WiFi devices dropping, my experience on the R8500 has been that each rev of 29300 has gotten a bit worse. The latest (dated 4/14 in status page) was bad enough that I went back and reinstalled the older 29200 with the 4.4 kernel because I remember I didn't have any issues with that. With 29300, Foscam and Axis cameras started losing connection more often and son's 5Ghz Netgear WNC3001 wireless adapter started having problems. The 4/14 29300 was causing various devices to lose connection after just an hour or so. Now the k4.4 29200 has been up for about 5 hours without issue and seems quite a bit faster.
I wonder if it's time to can the 3.1x kernels and go back (or forward) to 4.4?
Adding to the R8500 wifi discussion, it seems *both* 5GHz radios will choose the same channel (36) if set to "Auto." This proximity to another radio on the same channel keeps either of them from operating at full 802.11ac width. Only after changing one to be in the higher-channel range do they both open up fully.
Not sure if this is related to some of the aforementioned connection drops, but figured it was worth reporting either way. My guess is that Auto mode triggers each radio to do a scan. With both scanning simultaneously they both make the same decision and ... fire up on the same channel.
On my R8500 running 29200 (the latest one with the 4.4 kernel which seems to run the best for me), I'm trying to understand some things about the 5Ghz networks.
My wl0 5Ghz is set to SSID "DDI-5G" and is on channel 161 with upper, upper. The wl2 5Ghz is set to SSID "DDI-5G2" running channel 36 with lower, lower. Both are set to VHT80. First question is, I only see two channels for both. wl0 shows 144 and 161 and wl2 shows 36 and 52. Is this normal? Also, if I use channel 52 on the wl2, my phone and a few other devices can't see it. Choose channel 36 and it sees it and connects. Don't know why.
Last question is, when my phone connects to either one, the transmission rate is always high (780M for example) but the rx rate is always low (like 24M). Occasionally the Tx rate will drop way down, and occasionally (very occasionally) I'll see the Rx rate jump up. What's going on there? The phone is about 6 feet from the router and distance doesn't seem to affect it. On the one wireless access point (WNCE3001) that connects to wl0, it shows a steady 150M and 300M for it's rates but it is using HT40 whereas the phone says VHT80PS.
On my R8500 running 29200 (the latest one with the 4.4 kernel which seems to run the best for me), I'm trying to understand some things about the 5Ghz networks.
My wl0 5Ghz is set to SSID "DDI-5G" and is on channel 161 with upper, upper. The wl2 5Ghz is set to SSID "DDI-5G2" running channel 36 with lower, lower. Both are set to VHT80. First question is, I only see two channels for both. wl0 shows 144 and 161 and wl2 shows 36 and 52. Is this normal? Also, if I use channel 52 on the wl2, my phone and a few other devices can't see it. Choose channel 36 and it sees it and connects. Don't know why.
Last question is, when my phone connects to either one, the transmission rate is always high (780M for example) but the rx rate is always low (like 24M). Occasionally the Tx rate will drop way down, and occasionally (very occasionally) I'll see the Rx rate jump up. What's going on there? The phone is about 6 feet from the router and distance doesn't seem to affect it. On the one wireless access point (WNCE3001) that connects to wl0, it shows a steady 150M and 300M for it's rates but it is using HT40 whereas the phone says VHT80PS.
I guess I don't get it. Why the discrepancies?
Thanks,
Mike
Someone may have a far more technical answer for all of this, but aside from the phone not seeing the radio on channel 52 (which I haven't tested), this is all very much in line with what I've seen, both on DD-WRT-based routers and others.
Only seeing two channels for both? That's normal. On 5GHz, that means 80MHz. On 2.4GHz that means 40MHz. As an aside, you probably don't need 40MHz, especially if you're using Apple devices. NONE of them will use more than 20MHz on 2.4GHz and Alf Watt, former Apple Wi-Fi engineer, came on our Mac Geek Gab podcast and pleaded with everyone to stop using 40MHz and cluttering up the airwaves unnecessarily.
As for the reported Tx and Rx rates in the WebIf, that's normal, too. I use iPhones here and see them do the same thing. I always assumed (help me out if I'm wrong, please!) that this was a power-saving measure. It ratchets down to slow speed and one radio unless and until it needs to send data, then it ramps up. Regardless of the accuracy of my assumption, this is exactly what I see everywhere, DD-WRT or not.
VHT80 is 80MHz, VHT80PS adds "power saving" to that. Or at least that's my assumption.
Thanks. That helps. I did notice that if I run a speed test on my phone, it switches from VHT80PS to just VHT80 and the phone actually gets my full ISP's bandwidth (230Mbps). Not that I'll ever use it. It was more a curiosity than anything. My phone is a Google Nexus 6.
FWIW, 29200 with the 4.4 kernel has been flawless for about 24 hours now on my R8500. If I switch to one of the 29300 releases, some of my security cameras start dropping after a few hours and won't reconnect until I reboot my router. So I'm sticking to 29200 until/if Kong goes to the 4.4 kernel again. It is what it is I guess.
Posted: Mon Apr 18, 2016 14:43 Post subject: Initial flash on R6300v2CH
I have an R6300v2CH with a few bad areas on flash. I was able to get the recent OpenWrt build to flash correctly on it (which is further than I got in the past), but DD-WRT is still having issues up to a point.
Basically, what happens is it starts to flash, but when it gets to that area it pukes and soft bricks it. The only way is to open it up, hook up my USB-TTL adapter, and flash it back to factory.
I'm not sure what OpenWrt recently did in 15.05.1:
- bcm47xxpart: fix bcm53xx booting on NAND with badblocks
..but if it could get integrated into a dd-wrt build that would be AWESOME.
FWIW, 29200 with the 4.4 kernel has been flawless for about 24 hours now on my R8500. If I switch to one of the 29300 releases, some of my security cameras start dropping after a few hours and won't reconnect until I reboot my router. So I'm sticking to 29200 until/if Kong goes to the 4.4 kernel again. It is what it is I guess.
Which 29200 are you running? The 3/5 version or the 3/8 hotfix?
Posted: Mon Apr 18, 2016 16:31 Post subject: Re: update ddup to use https URLs instead?
<Kong> wrote:
qGUBcZWwBHb1 wrote:
Kong,
While looking at ddup, I noticed that it is updating via HTTP instead of HTTPS, now that Let's Encrypt is available, please consider updating things so that ddup pulls over https instead.
Between Let's Encrypt and Cloudflare, I would think that you could easily secure and improve updates. Thanks much.
ddup does something way more secure. It downloads and checks the signature of the file, this means, even if the file has been modified on the server(e.g. someone hacked it) or through the download (http) ddup will tell you and exit.
The last couple of builds already came with my public key, the key is used to verify the signature.
Only I have the private key without that key it is not possible to sign the fw or the packages in a way that it is not detected by ddup.
Thus https is not giving any benefit besides increasing the firmware size as https support requires a whole bunchs of certs on the router.
Same signature mechanism applies to my packages that you can install via opkg.
The reason why I did this is because I have a whole bunch of routers that I also update via ddup:-)
Actually, this is the exact problem that the Sparkle guys ran into. HTTP + signed is not sufficient.
With the careful selection of ciphers, it should not incur significant overhead. Additionally, Cloudflare can easily help cache the binaries that you make available thereby reducing the load on your server as well as cost of bandwidth.
I know it's kind of a pain to set up but I think the ROI is well worth it. Just a thought.
Thanks for your releases regardless.
PS. Let's Encrypt lets you get SSL certs for free so really there's not going to be any additional out of pocket costs other than setup time.
FWIW, 29200 with the 4.4 kernel has been flawless for about 24 hours now on my R8500. If I switch to one of the 29300 releases, some of my security cameras start dropping after a few hours and won't reconnect until I reboot my router. So I'm sticking to 29200 until/if Kong goes to the 4.4 kernel again. It is what it is I guess.
Which 29200 are you running? The 3/5 version or the 3/8 hotfix?
Posted: Mon Apr 18, 2016 18:17 Post subject: Re: update ddup to use https URLs instead?
qGUBcZWwBHb1 wrote:
<Kong> wrote:
qGUBcZWwBHb1 wrote:
Kong,
While looking at ddup, I noticed that it is updating via HTTP instead of HTTPS, now that Let's Encrypt is available, please consider updating things so that ddup pulls over https instead.
Between Let's Encrypt and Cloudflare, I would think that you could easily secure and improve updates. Thanks much.
ddup does something way more secure. It downloads and checks the signature of the file, this means, even if the file has been modified on the server(e.g. someone hacked it) or through the download (http) ddup will tell you and exit.
The last couple of builds already came with my public key, the key is used to verify the signature.
Only I have the private key without that key it is not possible to sign the fw or the packages in a way that it is not detected by ddup.
Thus https is not giving any benefit besides increasing the firmware size as https support requires a whole bunchs of certs on the router.
Same signature mechanism applies to my packages that you can install via opkg.
The reason why I did this is because I have a whole bunch of routers that I also update via ddup:-)
Actually, this is the exact problem that the Sparkle guys ran into. HTTP + signed is not sufficient.
No this is not the same problem and in the link you gave nobody is talking about public key signatures.
Again ddup checks the signature with its included public key, if either the firmware file or the signature file is modified or both, ddup signature check will fail. Thus you can play man in the middle as often you want, but you can't do shit. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
