Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

okay.. then it has "common". Go ahead and try "mini". From the "Software" section in LuCi, uninstall hostapd-common and install hostapd-mini, and see how that works for you. mini typically has less issue.

I can see mwlwifi on 49 and 50. Should I pin both to CPU 1?

           CPU0       CPU1   
...
 49:     799170    8390676     GIC-0  61 Level     mwlwifi
 50:    7800781          0     GIC-0  65 Level     mwlwifi

Over the last 2 davidc502 builds I have noticed 2 sets of errors in the System Log that I never noticed before. All seems to work OK on the WRT3200ACM but do I need to be concerned about these types of log entries?

Currently on davidc502's latest build "OpenWrt SNAPSHOT r9886-399aa0b933 / LuCI Master (f138fc93)" on a WRT3200ACM setup as a main AP and router connected to a FritzBox 7590 (no routeing or DCHP) for VDSL2 access.

1st error set:

Wed Apr 24 20:25:12 2019 kern.info kernel: [ 63.783239] F2FS-fs (mtdblock9): Magic Mismatch, valid(0xf2f52010) - read(0x0)
Wed Apr 24 20:25:12 2019 kern.err kernel: [ 63.791466] F2FS-fs (mtdblock9): Can't find valid F2FS filesystem in 1th superblock
Wed Apr 24 20:25:12 2019 kern.info kernel: [ 63.800903] F2FS-fs (mtdblock9): Magic Mismatch, valid(0xf2f52010) - read(0x0)
Wed Apr 24 20:25:12 2019 kern.err kernel: [ 63.809202] F2FS-fs (mtdblock9): Can't find valid F2FS filesystem in 2th superblock
Wed Apr 24 20:25:12 2019 kern.info kernel: [ 63.818309] F2FS-fs (mtdblock9): Magic Mismatch, valid(0xf2f52010) - read(0x0)
Wed Apr 24 20:25:12 2019 kern.err kernel: [ 63.826934] F2FS-fs (mtdblock9): Can't find valid F2FS filesystem in 1th superblock
Wed Apr 24 20:25:12 2019 kern.info kernel: [ 63.836043] F2FS-fs (mtdblock9): Magic Mismatch, valid(0xf2f52010) - read(0x0)
Wed Apr 24 20:25:12 2019 kern.err kernel: [ 63.844667] F2FS-fs (mtdblock9): Can't find valid F2FS filesystem in 2th superblock

2nd error set:

Wed Apr 24 20:25:12 2019 user.info kernel: [ 64.538077] procd: - early -
Wed Apr 24 20:25:12 2019 user.info kernel: [ 64.541006] procd: - watchdog -
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.670704] procd: cannot set group dialout for /dev/ttyS11
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.676623] procd: cannot set group dialout for /dev/ttyS8
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.682463] procd: cannot set group dialout for /dev/ttyS6
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.688211] procd: cannot set group dialout for /dev/ttyS4
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.693949] procd: cannot set group dialout for /dev/ttyS2
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.699707] procd: cannot set group dialout for /dev/ttyS14
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.705552] procd: cannot set group dialout for /dev/ttyS0
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.711296] procd: cannot set group dialout for /dev/ttyS12
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.717146] procd: cannot set group dialout for /dev/ttyS9
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.722887] procd: cannot set group dialout for /dev/ttyS10
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.728719] procd: cannot set group dialout for /dev/ttyS7
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.734474] procd: cannot set group dialout for /dev/ttyS5
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.740279] procd: cannot set group dialout for /dev/ttyS3
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.746027] procd: cannot set group dialout for /dev/ttyS15
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.751853] procd: cannot set group dialout for /dev/ttyS1
Wed Apr 24 20:25:12 2019 user.err kernel: [ 64.757598] procd: cannot set group dialout for /dev/ttyS13
Wed Apr 24 20:25:12 2019 user.info kernel: [ 65.274935] procd: - watchdog -
Wed Apr 24 20:25:12 2019 user.info kernel: [ 65.278256] procd: - ubus -
Wed Apr 24 20:25:12 2019 user.info kernel: [ 65.332084] procd: - init -

You can only pin the irq if that wifi device is "enabled". So, if you have both 2.4 Ghz and 5 Ghz enabled, I see no harm in that. I believe the 3200ACM and 32X are almost identical?

1 Like

I'm having a surprising issue. I'm running the latest davidc502 build (r9886) on a Linksys WRT1900ACS V2 and when I go to the Statistics Graphs page under LuCI, I get the following:

Failed to execute template dispatcher target for entry '/admin/statistics/graph'.
The called action terminated with an exception:
/usr/lib/lua/luci/template.lua:74: Failed to load template 'admin_statistics/index'.
Error while parsing template '/usr/lib/lua/luci/view/admin_statistics/index.htm':
Permission denied
stack traceback:
	[C]: in function 'error'
	/usr/lib/lua/luci/template.lua:74: in function '__init__'
	/usr/lib/lua/luci/util.lua:65: in function 'Template'
	/usr/lib/lua/luci/template.lua:27: in function 'render'
	/usr/lib/lua/luci/dispatcher.lua:852: in function </usr/lib/lua/luci/dispatcher.lua:851>

I rebooted the router and had the same error. I've never seen anything like this before. As far as I can tell, I have no other problems. I'm running the usual rosy theme and I've had no issues with it. Any ideas?

Thanks

See https://forum.openwrt.org/t/buggy-builds-luci-statistics-error-while-showing-graphs/35547/27?
and https://forum.openwrt.org/t/vpn-policy-based-routing-web-ui-discussion/10389/424?

Assumes you have the "stangri_repo" setup in your feeds.

I added the VPR package to the suggested reinstall and did it in the below sequence: (Note that I did the VPR updates via GUI but should be same result as below)

opkg update;
opkg install --force-reinstall luci-app-vpn-policy-routing;
opkg install --force-reinstall vpn-policy-routing:
opkg install --force-reinstall luci-app-statistics;

This fixed the Statistics issue along with the "Started without PROCD support" for me.

Hope this helps.

2 Likes

Thanks, FCS001FCS.... The three force reinstalls you suggested cleared up the statistics page for me.

@jookra, my STB provided by the ISP works on both TRUNK and VLAN85. It does authentication on TRUNK (requires internet access) and sends/receives IPTV packets on VLAN85.

The port connected by my STB is LAN4, so my VLAN setting is:

VID  CPU0    CPU1    LAN1      LAN2      LAN3      LAN4      WAN
1    tagged  off     untagged  untagged  untagged  untagged  off
2    off     tagged  off       off       off       off       untagged
85   off     tagged  off       off       off       tagged    tagged

WAN is connected to the EPON device and has a pppoe interface.

Today, the STB is able to do authentication on eth0.1 and also gets another "private" ip on eth1.85. The problem is that multicast packets arrives at WAN in VLAN51, but the STB doesn't monitor VLAN51, so I have to find some ways to re-tag these packets as 85.

Any suggestion is really appreciated!

@WiteWulf
You can pin both irq's to 5g & 2g bands. A power cycle will fix the luci app page slowdown/lockup without reverting your changes.

EDIT: I'm still having issues using this build even after erasing pinning both irq's. switched backed to stock 18.06.2 and using pinning on both bands flawlessly. Anyone have a clue why?

1 Like

Anything showing in kernel or system logs?

Does this libupnp security issue affect OpenWrt or Davidc502 builds? https://twitter.com/GossiTheDog/status/1123327720581160960

Below libupni 1.8.4.2 is available in the repo, but is not a part of the build. Meaning you can download and install it if you want. This is way newer than 1.6.21 which is listed in your article.

root@dc502wrt:~# opkg list |grep libupnp
libupnp - 1.8.4-2 - The portable SDK for UPnP Devices (libupnp) provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.0 of the Universal Plug and Play Device Architecture Specification.**

Just a feedback for latest release (in compare of January one).

  • LuCi is not hangs if old uHttpd config used.
  • Samba4 spams errors about master browser if netbios enabled (seems like nnpd is non-working at all)
  • Samba speed is better, but still below possibilities at wifi.
  • (!) Physical connection speed at 5G wifi is lower, then January release. Don't check iperf yet, so update about real speed soon.

The rest is stable as usual.

PS: If anyone use my remove/install script, please add a line at the end:
rm /etc/config/*-opkg
It's a cleanup for config files installed with opkg packages, but not used.

As more APIs get added to mac80211/hostapd as they are updated, the more data the mwlwifi driver/cpu/WNIC has to filter out during processing, slowing the throughput.

From the last code review when mwlwifi was attempted to be upstreamed into the main Linux kernel:

The only thing that really seems questionable to me is the whole beacon
parsing (and apparent rebuilding in firmware?). It's very odd that you
could do that, with a softmac device where all the authentication and
association is handled by hostapd anyway, and you can't possibly
pretend to handle everything hostapd might throw at you - this will
mean that you'll have features hostapd and every other mac80211
supports that you will silently drop afaict - which is rather
unexpected.

First, you're parsing the data obtained from hostapd, in
mwl_fwcmd_parse_beacon(), and then you send them all to the firmware in
mwl_fwcmd_set_ies(), but only the things you actually understood. New
higher-level features you don't understand, or vendor beacon IEs that
aren't WMM, would be completely dropped.

I'm not very happy with that behaviour.

Why does the firmware require this? Why not just pack all IEs into the
pcmd->ie_list_len_proprietary, and leave everything else 0? Or - if
perhaps firmware for some reason requires HT/VHT to be treated
specially, only parse out the ones that are really needed specially and
leave everything else in the ie_list_len_proprietary?

Also, this is dropping all the encryption stuff - even those are
extensible btw, and hostapd might do so. Having the firmware rebuild
those out of out-of-band information is very unexpected for a mac80211
driver.

  • Johannes Berg

I happen to concur with Johannes' comments regarding the IEs and
your beacon processing. This is a significant issue, with potential for big
bugs down the road. At the very least, it's a maintenance headache.

From my perspective, I'd consider it a firmware bug if there's no way
around it. Is the firmware going to strip the IEs that hostapd happens
to add to the beacons? Is there some "passthrough" or some other way
that it can be reconciled?

I strongly suspect there's better ways to handle it, even without
changing the firmware, but I haven't yet taken a look to see if there is.

  • Steve deRosier

You can find these quotes and more technical criticisms of the mwlwifi driver here: https://patchwork.kernel.org/patch/9482477

3 Likes

Hey @davidc502

Would you have any idea why this commit would not be included in your latest build: https://github.com/lede-project/source/commit/2a8175a7ac79f37444eed1dc72054e170c71491e ?

I'm using r9886 and cryptsetup should now have ripemd160 support again but it is apparently not the case.

I just checked trunk sources, and ripemd 160 support is in crypto.mk. The commit was from March and the latest build from April 20, so it has to be in there or it isn't working as expected.

iirc, you'll have to enable under kernel/cryptographic modules;not there OOTB.

Thank you for link, it's quite interesting.

According to the maintainer here, "cryptsetup benchmark" should now have values for ripemd160 again. However, in r9886 it still does not.

@anomeome
Is that something I or david would need to do?

It's a kmod that needs to be enabled at build time.