Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

You have to use the image! and do not save ANY settings! After the router comes up, it will need to be re-configured from scratch.

There are too many differences between DD-WRT and LEDE to save any settings.

1 Like

Hi All,

I'm sorry in advance, I'm still not caught up on IPv6, but I just installed the latest build and noticed there is a lease that looks like:

Host IPv6-Address
? fdd5:241a:XXXX::XXX/128

Can someone tell me what this is? Is it a local address or something else?

Thanks

Thanks. Got it.

Hi All.

I've noticed a weird issue with Alexa and OpenWrt (Using David's build, but not sure if it's that per say but just after ideas/suggestions). I'm currently using a WRT1200AC.

Normally I have my 2.4 and 5ghz on the same SSID/Password etc. But I've noticed that Alexa gets a lot of dropouts when playing music on Spotify. It'll play a couple of songs, then drop out, then resume (sometimes with quite a delay etc).

The only way I've seemed to improve the situation is by creating a seperate 2.4ghz network and putting Alexa on that. I still get occasional dropouts but not as many. I tried initially doing the same but on 5Ghz but the performance was just as bad. I've done a scan to see what other networks are broadcasting on channels and adjusted accordingly. I tried the same with DD-WRT but keeping the SSIDs the same and the performance wasn't as bad (about the same as putting her on 2.4ghz with David's build.

Now I've done some reading and Alexa is meant to be uPnP compatible. But looking at UPnP in Luci I can't see any reference to it opening ports. I have even forwarded ports manually but this didn't make a difference. I didn't have any issues when I was originally using the Sky Q hub (But WiFi was rubbish on this generally!). Unfortunately I can't test the stock Linksys firmware as it doesn't support DHCP Option 61 (Required for Sky Fibre). But I don't think this is down to a faulty Alexa as it did work fine on the Q Hub.

Any ideas?

Hi guys .... anyone having this issue showing "uci: Entry not found" when doing opkg updates?

I use David's build, and then change the repos to point to the latest LEDE ones.

Upgrading luci-app-openvpn on root from git-18.216.64381-746a5a5-1 to git-18.228.27397-98d4eb1-1...
Configuring luci-app-watchcat.
uci: Entry not found
uci: Entry not found
Configuring rpcd.
Configuring luci-lib-ip.
Configuring luci-app-samba.
Configuring dmesg.
Configuring luci-theme-bootstrap.
uci: Entry not found
uci: Entry not found

I think based on my post above... this is leaving a lot of garbage in the /overlay/upper/usr/lib/opkg/info directory after each upgrade, therefore I'm running out of overlay space !?

I wouldn't recommend pointing to the lede repo for too long... The daily snapshots change every day and at some point the kernel version will change. If it changes, will no longer be compatible with the current build.

I have set opkg hold on netifd and kept your core files, so my repos look like this below. Do you think it's risky anyway?

src/gz lede_core https://davidc502sis.dynamic-dns.net/snapshots/r7493/targets/mvebu/cortexa9/packages
src/gz lede_darkmatter https://davidc502sis.dynamic-dns.net/snapshots/r7493/packages/arm_cortex-a9_vfpv3/darkmatter
src/gz reboot_base https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/base
src/gz reboot_luci https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/luci
src/gz reboot_packages https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/packages
src/gz reboot_routing https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/routing

@davidc502, what's why i use Transmission from you 4.4 build before (works well at any later firmware), but seems like you drop 4.4 repo.

Interesting you should mention this. My last remaining issue, since moving from an old Apple Airport Extreme to a WRT32X with David's builds, is a 1st gen Amazon Echo that cannot maintain audio streams for long periods of time. It was fine on the Airport and, indeed, I also have two Echo Dots and two 2nd gen Echos that are all fine on openwrt. However, the Echo drops BBC radio streams after less than 10 minutes usually, and long songs streamed from spotify usually fail at some point. There's nothing in the logs on the openwrt box suggest the device is disassociating.

Yeah it's my only issue too. Tagged @davidc502 for visibility. If your other Echo's/Dot's are working fine on
"normal" OpenWRT then that would suggest a configuration/build issue. I might try the newest 18.06 OpenWrt to see whether that helps.

Trouble is, I really like David's build haha :slight_smile:

Sorry, I think you misunderstood. I'm not running a regular openwrt release, only david's builds, so I can't compare to 18.06 unfortunately.

My apologies. I tried 18.06 earlier and it wasn't quite as bad but still occasional dropouts.

Hi,

Someone could help me, I do not understand the reason of being with 60% of the memory of the WRT3200 used,
I know it may be due the 160Mghz channel, but the difference in relation to my WRT1900 is very large,
help me to solve or improve this problem.

45

As far as I know the WRT3200ACM uses / reserves more memory to speed up data transfers over wireless compared to the other WRT models. So what you are seeing should be normal.

And since your screenshot is showing an uptime of 12 days this should not be a memory leak (maybe a very small one).

My WRT32X would frequently drop to around 9% Total Available Memory within a few hours of a reboot. Statistics App would always show a very sudden (almost instant) increase in cached memory.
I made a half-assed attempt to find the cause, but never did figure it out before moving back to stock.
It never seemed to affect performance, but I don't need to push my router very hard.

There was a discussion about a possible memory leak in the previous Davidc502 Thread:

I'm on Davidc build r7829 on a WRT1900ACS V2 and I've experienced the same problem with memory been filled up shortly after reboot. Memory clear up and back to normal if I run sync; echo 1 > /proc/sys/vm/drop_caches but sometimes, it's just filling up again. Seem to be random on every reboots, it can fill up in minutes or days or never.

I can see 90-100% RAM utilization possibly being an issue, depending on the situation, but this is far far below.

I can't be certain, but I don't think I experienced the memory issue with your builds or the 18.06 SNAPSHOTS. Only Master SNAPSHOT builds.
Also, I haven't run OpenWrt on my WRT32X in over a month so this could be moot.

I took what I learned here and have been using it to play around with the stock Venom firmware.
When I get the time I plan to attempt a DNSCrypt-Proxy v2 install.

1 Like