Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

Hi nitroshift,

Thanks for getting back to me. Using lan has no effect. I used 0.0.0.0, and it did not work.
I created a guest wifi network for these smartplugs(currently testing the firewall rules on one) that is not bridged to lan, and used every single network I have as the source zone, including the guest network (APGuest). The device has a static ip address assigned on my lan, so I can rule out the address changing.

I also tried creating a rule for incoming traffic(2nd rule). Here is what the firewall config currently reads:

config rule
        option name 'smartplug'
        list proto 'all'
        list src_ip '192.168.123.204'
        option dest 'wan'
        list dest_ip '0.0.0.0'
        option target 'REJECT'
        option src 'APGuest'

config rule
        option name 'smartplug2'
        list proto 'all'
        option src 'wan'
        list src_ip '0.0.0.0'
        list dest_ip '192.168.123.204'
        option target 'REJECT'
        option dest 'APGuest'

Here is a tcpdump of the smartplug, continuing to defy me:

root@router:~# tcpdump -i wlan1-2 host 192.168.123.204
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan1-2, link-type EN10MB (Ethernet), capture size 262144 bytes
09:09:19.884939 IP ec2-3-230-193-66.compute-1.amazonaws.com.443 > Smart-Plug.lan.50659: Flags [P.], seq 1753640462:1753640691, ack 20110, win 263, length 229
09:09:19.893538 IP Smart-Plug.lan.50659 > ec2-3-230-193-66.compute-1.amazonaws.com.443: Flags [P.], seq 1:86, ack 229, win 11833, length 85
09:09:19.967732 IP ec2-3-230-193-66.compute-1.amazonaws.com.443 > Smart-Plug.lan.50659: Flags [.], ack 86, win 263, length 0
09:09:19.972696 IP Smart-Plug.lan.50659 > ec2-3-230-193-66.compute-1.amazonaws.com.443: Flags [P.], seq 86:1003, ack 229, win 11833, length 917
09:09:19.997041 IP ec2-3-230-193-66.compute-1.amazonaws.com.443 > Smart-Plug.lan.50659: Flags [.], ack 1003, win 270, length 0
09:09:20.366432 IP ec2-3-230-193-66.compute-1.amazonaws.com.443 > Smart-Plug.lan.50659: Flags [P.], seq 229:522, ack 1003, win 270, length 293
09:09:20.385752 IP Smart-Plug.lan.50659 > ec2-3-230-193-66.compute-1.amazonaws.com.443: Flags [P.], seq 1003:1088, ack 522, win 11687, length 85

Is 192.186.123.204 set as the static IP address for the device named smartplug? (Check under the Network > DHCO and DNS > Static Leases tab.) If not try adding that to the list and restarting the router.

Yes I assigned this device a static ip address previously. I had to reboot the router last night for an unrelated reason, and it worked blocking the device initially. I then disabled the rules, and re-enabled them, and the firewall rules were no longer working. It must be a bug of some kind.

Edit: Manually restarting the firewall service ('service firewall restart') is what gets things working again after enabling or disabling the firewall rules.

Thanks all.

1 Like

Lot of nice mvebu fixes going in lately (since the last davidc502 build I've had incredible success with over the last few months). Can't help but think if there is ever an official OpenWrt 20.x release it'll be a big upgrade.

For example, I'm wondering if this commit is why some people had wifi issues and others didn't:

3 Likes

Restarting the firewall daemon will do that for you... :wink:

hello.
i've just looked at the openwrt bug tracker, and it seems the dsa issues for mvebu have been removed, and most others have been designated as low or very low priority. does this mean the openwrt developers have essentially deprioritizedd this line, or are things actually working?
i have not had a stable lan/wifi configuration since dsa was moved into development snapshots for this series (wrt1900, wrt3200).
the superwrt builds incorporate a lot of packages on the new dsa snapshot builds, and would be great - but the dsa issues above persist for me.

thankfully, david's last build, and 19.07.4 still work.
i'm trying to get a handle on where openwrt devlopment for this line of routers has moved.

1 Like

Don't overestimate priority levels in flyspray, no one classifies bugs that way. DSA for netifd is staging, but pending merging to master, afaik initial DSA support is also being tested and just waiting for the former.

1 Like

Hello folks

I have a WRT1900AC and have tried 18.06.1 and 19.07.4 with very unstable Wifi. The latency to the router's own IP is in the 2 digits milisecons mark. Very often it disconnects from either 2Ghz or 5 Ghz radios and takes a while to re-connect.

Using David's build (r13342) it seems better than 19.07.4, although not 100% still with some instability on the radios that disconnect every in a while and takes some time to be able to connect again.

Has anyone had any success with 19.07.4 ?
The current OpenWrt snapshot for some reasons doesn't seem to have the builds for WRT1900AC v1, only for v2. Does anyone know why ?

@davidc502 does your build use the same mwlwifi driver of OpenWrt Snapshot or does it use any modified version that makes it more stable ?

Hi! Iā€™m using 19.07.4 with this driver and stability is about 90%, meaning you can use it pretty well https://github.com/eduperez/mwlwifi_LEDE/releases

Partition size has been exceeded for two wrtpac targets (mamba, venom). See PR3205

i will repeat my plea to increase the size of the lernel partition to 6 MB for wrt1900v1 and for wrt32x. the rationale is clearly stated here:

1 Like

You need to check if the bootloader can really cope with larger kernels, afaik linksys sets a fixed size in ubootenv to load from flash - just changing the partitioning wouldn't help without changing ubootenv (and that's problematic for first time installers, upgraders and anyone wanting to revert to the OEM firmware); this wasn't an issue on the ipq806x devices covered by my patches.

1 Like

Those two targets still build successfully for individuals, but the size increase with each kernel push will bite eventually. For example two builds done today:

5.4.71

  3070498 Oct 19 12:41 linksys_wrt1900ac-v1-kernel.bin
  3065738 Oct 19 12:41 linksys_wrt32x-kernel.bin

5.4.72

  3070666 Oct 19 14:00 linksys_wrt1900ac-v1-kernel.bin
  3065906 Oct 19 14:00 linksys_wrt32x-kernel.bin

Thanks for the reply @anomeome
Strange because WRT1900ACv1 has 128MB of total flash, so even with 2 partitions there is a fair amount of space to have a much bigger partition, doesn't it ?

Seems the rationale behind @ghoffman make sense, what do you think ?

You need to check https://openwrt.org/toh/linksys/linksys_wrt1900ac#flash_layout for details, https://openwrt.org/toh/linksys/linksys_wrt1900ac#openwrt_bootlog (in particular NAND read: device 0 offset 0xa00000, size 0x400000) would also be relevant. So even with 6 MB flash being reserved for the kernel, the bootloader will only attempt to read the first 4 MB of that. In the best of all cases this size value it defined in uboot-env (see fw_printenv for hints) - changing this might work, or it might fail fatally <-- this would need testing (with an oversized kernel), in worse cases the bootloader would need rebuilding with different settings or the introduction of a second stage bootloader between u-boot and kernel+rootfs.

Hi @slh perhaps some stuff from the kernel can be moved to modules. But yes, second stage could be also an option in the worse case.

Hi @razor7 did you install 19.07.4 and then dowgraded it to eduperez/mwlwifi version with "opkg install --force-downgrade" ?

Yes, that's it!

@davidc502 : Can you help clarify this for me?

Just a quick question. I am getting ready to upgrade from kernel 4.14.103 r9506 to 5.4.41 r13342 of David's builds. Any gotcha's I need to know about (1900ACS)?

(I was advised download a backup of my config, remove /etc/config/ubootenv and /etc/fw_env, repack. Upgrade w/o keeping config, then restore the modified backup.)