Does "Enabling upnp functionality" from LuCi, need any other action ? It seems to have broken the internet connection from the lan.
Ok, I am getting a bit confused here. I have 2 machine wired to the router, and the one I am currently on doesn't want to connect to the router, but has now internet connection. The other one is happily connecting to the router, but without internet connection. Mind that I have not changed the default lan settings and I am only trying to get my Plex server to get accessible from outside.
I have tried to set static route, but that broke the internet connection. I have tried upnp, but the result seems to be equally unsatisfying.
Thanks David. It's a great theme, although personally, I typically disable Web interface when not needed... BUT, that doesn't mean I still don't like to be wow'd when I do need to do web gui stuff:)
Why doesn't LEDE team just adopt it as primary, it blows dd-wrt theme out of the water (or any router theme for that matter)
I guess that @cantenna is refering to UPnP having a bad rep for allowing ports throught without much control, as opposed to static routes+port forwarding.
Still having latency and disconnect issues here. I tried putting the stock Linkys firmware back on the device to see how I fared and things still weren't great. Here's another screen grab of my smokeping test over the last couple of days. The high jitter and latency to the left is with the stock linksys firmware (and is pretty much identical to the performance I was seeing with Lede 18.06 snapshot), the smooth line to the right is with my Airport Extreme connected:
Smokeping tests gives you an indication of latency, jitter an packet loss by pinging your device 20 times every 5 minutes and displaying this using the black->grey part for ping times and the coloured plots for packet loss. The server running the test is on a 20Gb/s connection at my work place. I appreciate there's a lot more going on under the hood on an openwrt box than on an Airport Extreme, but I'd expect ICMP to be prioritised and it not to be a huge burden on the system as it's only receiving 56 bytes every 300s
While running the linksys firmware (which, incidentally, identifies itself as the bleeding edge "Designated Driver" openwrt build, for those that didn't know) I also ran into problems again with my Amazon Echo disconnecting and refusing to reconnect to either the 2.4GHz or 5GHz radios. I couldn't even see the device attempting to connect in the logs. I appreciate this isn't a forum for Linksys firmware support but thought I'd mention it as part of my overall woes (it's good to share, apparently ).
FYI, during this testing I was still attempting to run with DHCP and DNS provided by my linux server on the LAN and the router LAN NIC changed from 192.168.1.1 to 10.0.0.1
To "disable" dhcp on the WRT32X I changed the DHCP range to two addresses and created fake reservations for them (which is the same way I disable DHCP on my Airport Extreme).
On Tuesday I'll have more time to devote to this so will attempt to go back to a Lede snapshot, properly shutdown my LAN DHCP and DNS and run everything on the default 192.168.1.0/24 range and see if that works any better. It's not a solution for me, but should help track the problems.
@WiteWulf -
how about using your apple airport as the wireless acces point, and the wrt32x iwth lede as your gateway?
then you could isolate the issue to the wireless part of the wrt32x, and retain the advantages of lede for management and routing.
i have used this solution in challenging wireless environements because airports have great radios; (i place them in their create/extend network modes for may main access points that span a large spatieal area with lots of radio obstacles and no good wired pathway)
This seems like a huge find and reminiscent of the R7800 latency issues that were fixed in the thread I linked above. Your settings seem unconventional, but this is something that should be investigated. You should post a bug report to OpenWrt and post on Linksys' forums for support too, as this wouldn't be davidc502 build specific. Clearly the WRT series has a long way to go.
The irony here is that the WRT32X is actually advertised to reduce latency provided you set priorities and have Killer NIC (who actually has these cards I have no idea most people use the one built into their motherboards).
Interesting report ... From just looking at this, and your advanced knowledge and refined wording as an indication of a professionalism and knowledge of what you're doing here ... it just looks that the OLD Airport is just a better router to do ICMP than the WRT
Indeed, this a 4th gen box (same form factor as an iMac) and it's been performing admirably for me for the past 7 or 8 years. It's a move to a bigger house that it can't quite cover, a desire for better firewall and IPv6 handling and upgraded broadband (we're on 220Mb/s now which the Airport doesn't seem to be able to saturate) that's prompted an upgrade.
It is rather ironic, isn't it! I didn't buy the device for it's "killer" features, but as a cheap way to get the WRT3200ACM hardware (which I believe this is almost identical to internally). I didn't, however, expect my ping times to be so negatively affected, though. Apparently the "killer" stuff is basically just a QoS script in the box reacting to DSCP packet markings from the drivers on the "killer" branded NICs. I'm sure the client side of things could be easily hacked together with some wiresharking of a "real" killer NIC
Afaik the hardware is 100% identical to the WRT3200ACM... Just a different flash chip ?
Btw, i never had any ping time problems with my WRT3200ACM but i'm still using build 7093 but i've noticed that the Wifi pingtimes are always 1-2ms higher compared to my DIR-860L and other Wifi hardware, but stable. I think that could be a typical marvel thing...
As far as my understanding, the wrt32x is the exact same hardware as version 2 of the 3200acm, just adding dfferent case color and the killer software on top. Both are said to have new proprietary closed source wifi driver parts that confirm to legislatory needs of untamperability (preventing manipulation of wifi sending power)
v1 of 3200acm was said to be sold until ~mid 2017, having fully opensourced drivers and is said to have different flash chip and according to the device pages, it seems to, it has little bit smaller firmware partition layout.
I own the 32x as well since a few days, got a cheap deal, but have not yet found the time to put Openwrt on it, needing it while still busy configuring v18.06rc1 on my 860l-b1.
May I ask for a short scenario description of your wrt32x ping problem, are you pinging from a Wifi client to an Internet server?
David
It's working well for me; in fact I added the vpn-policy-routing package and it's also worked well.
However, I'd like to use DNSCrypt-Proxy to send DNS requests over HTTPS to cloudflare. Unfortunately, cloudflare isn't offered as a Resolver despite being on the server list at https://dnscrypt.info/public-servers/ I've "Refresh List" in the General Options but cloudflare still isn't there. Any thoughts on how I can address this?
Sure, I'm pinging from an internet server to the WAN interface on the wrt32x. As I mentioned earlier, I'm using a tool called smokeping which sends 20 pings every 5 minutes and shows the maximum, minimum and average values with the black/grey plot and any packet loss as the coloured plot. The server running the test is part of the monitoring infrastructure at my work place and is used to chart ping times to a number of partner institutions, service providers and staff's home equipment.
Oops, actually ignore my last message. I found https://davidc502sis.dynamic-dns.net/dnscrypt/ and realized I had to install dnscrypt-proxy 2. Now I have DNS-over-HTTPS with cloudflare. However there is no GUI in Luci for it. How do I install that?
Yeah, currently there isn't a app specifically for dnscrypt-proxy Version 2. Unknown if someone is currently working on one, though I've heard there are others using the Version 1 app to manage Version 2's configuration file.
BTW -- I'm glad to hear that vpn-policy-routing is working.
Dear Dave,
Hello for your r7210 Build I was finally able to get it up and running. The problem was evidently due to my flashing r7210 from Linksys Stock. As I had described when I set static IP on Lan other than 192.168.1.1 ( default router address ) I would lose internet connection all together.
As many of the areas were greyed out or non-existent in Luci ( firewall zones, dropbear, network bridged interfaces and more ) I figured that something was awry with config files. I believe that is /etc/config/system and all the other associated files of that type and nature.
So I followed this guide : https://wiki.openwrt.org/doc/howto/generic.backup after installing r7093 with minimal configuration. Go to bottom of page for specific instructions. Look for Backup OpenWrt configuration
and then for when you are on r7210 - Restore OpenWrt configuration
Minimal settings included Network / wireless settings / dropbear change port / - domain - I left out anything beyond that.
I took the backup while on r7093 from web gui - Luci .Next, I went back to Linksys stock and then I installed r7210. To be sure everything went smoothly when restoring backup - I installed tar. opkg update / opkg install tar.
Then I restored backup and everything worked as desired and expected. From there I finished configuring r7210 on my WRT1900ACS. By the way Dave - in the header you list WRT1900ac Version 1 and 2 twice.
You do not mention that you also support the WRT1900ACS Version 1 and 2.
I just bring that to your attention so that 1900ACS folks will be able to use your great OpenWrt / Lede firmware.
For others who may have had similar issues with r7210 - this is one method to work around that. Hopefully, Dave you consider my feedback as being useful in your future builds.
Thanks for all you do for the entire community now and always.
In Peace and God's Grace,
@Kherby yes the WRT3200ACM and WRT32X are nearly identical for hardware. Basically just a different case and different web UI. Now that they are both supported by OpenWrt if you run that there is really no functional difference.
This possible latency issue is worrisome though. Hope he gets to the bottom of it, going to start running my own tests. I have a feeling there is a deeper issue here with this platform, perhaps even with Linksys firmware. People barely talk about performance on OpenWrt, just features I don't need, what I care about is performance.
).
