So I followed the link by slim, not working ..
edit: do i need to remove dnscrypt-proxy before installing this ?
edit: well seem to be working after i removed dnscrypt
is there supposed to be 6 servers when i run dnsleaktest ?
I have this 5Ghz problem with my wrt1900ac v2 latest Davidc502 Lede build. If I set the 5Ghz channel on auto, the 5Ghz will not work but if I choose a channel for it (149) it will work. No problem with 2.4Ghz. Any ideas? Thanks. By the way, the 5Ghz is set to 80 channel width.
good mourning david do i have pay to have a build without extra stuff that i dount use i only going to use a ps4 thanks
You should see the DNS servers from your stubby.yml file when you do a dns leak test. Fortunately, those requests are DNS over TLS so they are encrypted.
I'm surprised you needed to remove dnscrypt to get this to work. If you weren't using dnscrypt, its existence shouldn't interfere at all with DNS over TLS (i.e., stubby).
The reasons to use david's builds is for his integrated packages. If you don't want or need them, I suggest you just use the 18.06.01 stable build.
1 Like
Help from networking gurus needed 
I'm getting this from the firewall:
Populating IPv4 raw table
* Redirect 'FTP WDMyCloud'
- Auto-selected conntrack helper 'ftp' based on proto/port
* Redirect 'SNMP return packets'
! Skipping protocol tcp since helper 'snmp' does not support it
- Auto-selected conntrack helper 'snmp' based on proto/port
* Zone 'lan'
- Using automatic conntrack helper attachment
* Zone 'wan'
I hate warnings and autoconfigurations .. how can i get those properly configured ?
firewall config:
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '21'
option dest_port '21'
option name 'FTP WDMyCloud'
option dest_ip '192.168.1.1'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp udp'
option src_dport '161'
option dest_port '161'
option name 'SNMP return packets'
option dest_ip '192.168.1.207'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option network 'lan'
option forward 'REJECT'
@davidc502 , @hayman ... I continue to run out of space on \ all time time when updating the packages between David releases ... I'd assume it's because the base packages included in the build are part of the /upper portion of memory, and when i update them, the new versions are stored on \ AND ALSO on \upper.
Am I right?
Is there a way around this issue? Can I delete the updated files from \upper after updating them?
Isn't there a filesystem that uses compression to store the files on the flash, other than ext4? I remember back in the days when we used D.O.S. and struggled with disk space, we used a couple of realtime compression/decompression drivers to save space at the expense of CPU power. I've found that JFFS2 ( https://en.wikipedia.org/wiki/JFFS2 ) would do this, and it is stated that it's used in OpenWRT? From reading a little bit more, it looks like \upper is actually JFFS2 already .. but not the rest of the filesystem?
Well... You can use DD-WRT approach for this issue:
- Plug USB3 flash drive
- Copy some folders into it (\upper, etc...)
- Mount it on boot instead of internal flash one
Wouldn't that approach break something when upgrading the build?
No. In fact, as a result you will have 2 copy of packages - one in firmware (original), and one at the flash drive (with you updates).
Them you update firmware, just remove mount, copy new content from FW again and mount back.
Even better - you always have an option just remove drive if you broke something, then reboot back to vanilla.
As i say, it's a common way for DD-WRT.
PS: I think, it's nice idea copy /usr and /var too. First at least.
1 Like
Since the kernel is at 4.14 now, any reason not to include and enable flow_offloading? I'm getting:
Warning: Section @defaults[0] requires not available kernel module xt_FLOWOFFLOAD, disabling
ref: Enable fast path
flowoffload != fast_path, all 4.14 images have flowoffload enabled by default, see posts here
1 Like
Now I'm confused. I didn't mention fast_path (it's in the thread name though), just the flow_offloading parameter in /etc/config/firewall. Is there a naming issue here?
I am on 4.14 with latest davidc502 release, but I'm getting the error about the xt_FLOWOFFLOAD module not being there?
I did not go to the thread to read, I just assumed a thread with that title was about ...
As to the actual point of your post (and my response), a quick perusal of the manifest for an image provided by this community release would indicate that flowoffload has been removed.
Hi i'm using r8810 for the last 24 hours.
maybe im repeating things people already reported so sorry if this the case .
i'm using wrt1200ac , i experienced the below :
1] not able to change wifi password
errors i see in logs (not related to above):
2]
Sat Jan 12 09:34:14 2019 kern.debug kernel: [ 353.067014] ieee80211 phy1: change: 0x40
Sat Jan 12 09:34:15 2019 kern.debug kernel: [ 353.237169] ieee80211 phy1: change: 0x40
Sat Jan 12 09:34:15 2019 kern.debug kernel: [ 353.417338] ieee80211 phy1: change: 0x40
Sat Jan 12 09:34:15 2019 kern.debug kernel: [ 353.597496] ieee80211 phy1: change: 0x40
3]Sat Jan 12 09:34:14 2019 daemon.notice hostapd: handle_probe_req: send failed
Sat Jan 12 09:34:14 2019 daemon.notice hostapd: handle_probe_req: send failed
Sat Jan 12 09:34:14 2019 daemon.notice hostapd: handle_probe_req: send failed
Sat Jan 12 09:34:14 2019 daemon.notice hostapd: handle_probe_req: send failed
Sat Jan 12 09:34:14 2019 daemon.notice hostapd: handle_probe_req: send failed
i'm reverting to the older build for now cause i really need to change wifi pass.
Actually in the earlier build i cant also change wifi password , changes does not persist and applied... someone has any clue ?
i changed it eventually in /etc/config/wireless ... through the UI it does not persists the changes.... also in the latest build...
Added issue for Update Lists in LuCi -
3 Likes
New builds have been uploaded to the site and are ready for download.
Kernel version = 4.14.91
WiFi driver = 10.3.8.0-20181210
Build = r9028
Please note the LuCi issue listed above. The work around is to run the 'opkg update' command from command line.
1 Like
I was starting to be afraid something happened to you. Glad you came back with a release.
Sorry if i bother but there are any major difference, known problems compared to r8873?
PS: IOT smart plugs, light etc still has problems with WMM Mode enabled, i would recommend to add something like this to the FAQ:
"If you have a problem with smart plugs, light etc just make another 2.4ghz interface and disable WMM on that."
I will install right away the new build and report for any bug i'll found. Thanks for your work.
1 Like