Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

Jruuu · October 8, 2020, 11:39am

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

BigRon · October 9, 2020, 6:37pm

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.

Jruuu · October 11, 2020, 4:00pm

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.

phinn · October 11, 2020, 8:53pm

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:

BigRon · October 14, 2020, 9:07pm

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

ghoffman · October 16, 2020, 11:04am

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.

slh · October 16, 2020, 11:49am

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.

ffredy · October 19, 2020, 5:14am

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 ?

ffredy · October 19, 2020, 5:17am

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

razor7 · October 19, 2020, 10:26am

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

anomeome · October 19, 2020, 6:32pm

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

ghoffman · October 19, 2020, 7:19pm

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:

github.com/openwrt/openwrt

Comment by hnyman to [RFC] treewide: try reduce kernel size on some targets

openwrt:master ← lucize:slimmvebu

> in the discourse of the RFC to take a more future-proof approach as been done… with dc50694 instead of constantly fiddling with the kernel source, increase the the boot partition to like 6 MiB and be done. ipq806x devices apparently survived the event even with the inherent inconvenience it may have caused their owners. Based on the experince from IPQ806x, I would recommend the kernel partition size increase approach to be tested. Looking for that kind of partition size modication solution might be easier than looking for a kernel contents change. Changing wrt32x DTS to have kernel+rootfs as 6+117 instead of 3+120 for both dual-boots should work, I think. The total size would still remain as 123 MB, so reverting back to OEM should be possible quite nicely. (for wrt1900ac that would be 6+34 vs. 3+37, I think) For reference R7800: * kernel size change: https://github.com/openwrt/openwrt/commit/dc50694bd1a8f81b40c185bc8cacbdc8e821a3c6 * and subsequently my commit fb8a578aa7 that futher increased the size taking a "Netgear reserved" area into use. (You can read from forum about my tests and debug, I also tested reverting to OEM from modied firmware) With ipq806x devices, the change broke the OpenWrt sysupgrade from older OpenWrt builds, and required using Netgear TFTP recovery flash to install the new version. (But flashing from OEM still works ok). I think that Linksys does not provide quite that easy TFTP recovery flash tool, so jumping to modified kernel size build might require flashing first OEM firmware and then using that for flashing the new OpenWrt, as OEM flashes images in a single sweep, right? Reason why ipq806x OpenWrt sysupgrade failed: our sysupgrade script writes kernel and rootfs in two steps to the locations given in the currently running DTS, not the DTS in the new image. I haven't looked at the mvebu sysupgrade specifics, but I think that follows the same model. If the OEM firmware flashes the image in one sweep, the new OpenWrt image with larger kernel area would likely be flashed quite ok.

github.com/openwrt/openwrt

ipq806x: increase kernel partition size for the Netgear r7800

committed 06:34PM - 22 May 18 UTC

pkgadd

+7 -7

Starting with kernel 4.14 and gcc 7, the kernel doesn't fit into the 2 MB reserv…ed for the kernel partition by the OEM firmware anymore. This patch increases the kernel partition from 2 MB to 4 MB, at the expense of the rootfs, for all supported kernels. WARNING: This breaks sysupgrade! Flashing a firmware containing this changed partitioning from an older image with 2 MB reserved for the kernel partion requires the tftp recovery procedure, thereby losing all settings. This patch is based on a corresponding change by Pavel Kubelun <be.dissent@gmail.com> and has been tested by Michael Yartys <michael.yartys@protonmail.com> Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>

slh · October 19, 2020, 7:41pm

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.

anomeome · October 19, 2020, 8:12pm

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

ffredy · October 19, 2020, 10:36pm

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 ?

slh · October 19, 2020, 10:46pm

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.

ffredy · October 19, 2020, 10:51pm

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.

ffredy · October 19, 2020, 11:08pm

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

razor7 · October 19, 2020, 11:40pm

Yes, that's it!

shuttleman58 · October 20, 2020, 4:10am

@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.)