Would seem to call into question, going the extra mile, and doing the inline assmbler work.
drbanzi (first name bukaroo? 
),
Sure, it is very simple but here /etc/config/vpn-policy-routing is, with the first of many policies:
config vpn-policy-routing 'config'
option strict_enforcement '1'
option dnsmasq_enabled '1'
option ipv6_enabled '1'
option verbosity '0'
option enabled '1'
config policy
option interface 'wan'
option comment 'Master Bedroom Roku'
option local_address '192.168.1.102'
option proto 'tcp'
option chain 'PREROUTING'
Do you have your firewall zones set up properly? lan needs to have both your wireguard interface and wan as forwardings.
This is helpful; thanks! I'm trying to get my Plex server to be accessible via WAN. I have the port forwarded on the router, but I'm not sure what vpn policies I need to allow access to my Plex server. My router is at 192.168.1.1 and my Plex server is at 192.168.1.30. Port 32400 is forwarded at the router to the Plex server.
Hi @drbanzai, I'm running a Plex server behind an OpenWrt router successfully. Forwarding port 32400 on the WAN port to your internal host will do what you need. There's no need to create any VPN policy.
One thing that helps, though: if you're using a custom domain and have a hostname using that assigned to your server hosting PMS, make sure it's external record points to your router WAN address and that you have an internal record pointing to it's private IP address. This ensures remote clients connect to your router but internal clients connect directly and don't end up transcoding.
1 Like
Thanks; I have a custom domain via DynDNS for WAN access; how do I go about creating an internal record pointing to the private IP address? I don't think I've ever done this before.
Okay, if you try to ping that custom host (using it's FQDN) from a machine on your network, dnsmasq will try to resolve the name using your upstream resolver and get the same address as everyone on the internet (this should be your router's WAN IP address). This is good for remote clients wanting to access your PMS, but bad for you as your clients at home will try to connect to your router's WAN port, get NAT'd, and PMS will class them as remote clients.
You can fix this by logging in to your router on the console and editing /etc/hosts, adding an entry for that same hostname, but this time give it it's internal, private, IP address. dnsmasq on your router uses this file to do lookups before it queries your upstream DNS provider and you can use this override any response that would have come back from Dyn's DNS servers for that domain.
If you're also using IPv6 (and have it enabled in PMS) you may want to add the IPv6 address for your PMS server to /etc/hosts, too.
Awesome; thanks.
HTH, I'm active over on the Plex forums, too, so don't hesitate to ask over there if you have any more PMS questions/issues.
Hi there,
I have updated my LEDE to the davidc502 build to my wrt1900AC V1(mamba).
I have QOS set up perfectly but I am having some issues with my WIFI specially with the 5G band on my mobile devices.
I am running the latest driver (10.3.8.0-20181210), however sometimes the 5G ether never shows up on my mobile devices forcing me to reboot or change the settings.
Once i get it to connect it's fine then when I leave and come back again it does not show up on my mobile devices, forcing me to repeat the steps above.
If it is already connected and I reboot for another reason, it may not show after that reboot. I just never know what to expect from it
My 5G setting are all pretty much default:
Mode AC
Channel Auto
Width 40MHz
Transmit power auto
Just wondering if you guys had any idea what it might cause such instability. My 2.4G is always fine and shows up, no idea why the 5 is so unstable.
Any recommendations would be appreciated.
Thank you!
Welcome Andre.
Setting channel to auto is most likely causing you some grief. This setting does not have any smarts behind it. It just selects the first available channel from the list of possible channels. However in most cases, the radio just fails to come up as a result of this.
I would start there by setting it to channel 36 and see if the radio operates fine.
1 Like
What @lantis1008 stated is correct. Setting 5G on auto is going to cause issues for several reasons. One of which is when DFS channels are selected by the router automatically, and clients can't connect. I have 5G devices that just can't see some of the DFS channels and hence can never connect. The best thing to do is to select channel 36 or 161, and you likely won't have any more problems.
3 Likes
I've been using channel 149 with latest mwlwifi drivers at any given time for over a year now with great success. My understanding of wireless specs in general is quite limited, therefore I don't make changes very often.
Would I also be better of switching to either 36 or 161?
I have seen channel 36 recommended multiple times here and also over on Github but never really understood how much that relates to the mwlwifi drivers pros and/or cons.
1 Like
I recommend sticking with what works for you.
Here is a detail list of all the wifi channels if you are interested. https://en.wikipedia.org/wiki/List_of_WLAN_channels
1 Like
Thanks for the advice everyone. I will change the channel setting and see what happens.
While I was running the regular LEDE release I remember setting a channel, then run into this issue and seeing that the channel that I set vs the channel that was broadcasting was different. That's why I went auto at the time. Bug maybe?
I will get back at you with an update.
Thanks again!
Sounds like you set it to a DFS channel, it detected something that looked like radar, so moved to another channel. A DFS CAC will work its way down through the channels from whatever you specified until it settles on a "clear" channel. Auto will always default to 36, afaik.
New builds have just been uploaded to the server.
Kernel version = 4.14.105
WiFi driver = 10.3.8.0-20181210
Build = r9614
There have been some changes.
- All of the build names all start with openwrt instead of lede. It appeared to cause some confusion as some seemed to think anything named lede would be really old.
- Most of the references to LEDE have been changed to OpenWrt on the website.
- The cypto errors have been fixed.
- Kernel bump to 4.14.105
- There have been no new changes with the wifi driver since the last build.
EDIT
The 3rd party firmware listed in the openwrt wrt_ac_series now has bad image links to the davidc502 builds because of the name change. I've already requested someone clean it up.
https://openwrt.org/toh/linksys/wrt_ac_series#community_firmware_builds
4 Likes
Just flashed the firmware now, however i have noticed there is a new Wifi Interface called Generic 802.11 Wireless Controller showing up. All other builds didn't have this show up.
I thought i'd best mention it before hand. Going to do tests now on the rest of the stuff.
Looking in /etc/config/wireless it shows
config wifi-device 'radio2'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'
option htmode 'VHT80'
option disabled '1'
It's been a long time since I monitored the CPU temperatures in my WRT1900ACS, however I remember doing so simply through LuCI statistics. I no longer seem to have the option to capture temperature. I'm using r9614. Any advice on how I can get collectd to capture temperature so I can plot them out over time?
Thanks.
Did you install both collectd mod sensors and thermal?
If you have the 3200acm or 32x, there is a 3rd wifi that may be discovered. My recommendation would be to just disable the Generic Wifi Interface.