Rpi4 < $(community_build)

Hi does this build work ok with MWAN3 ? - i tried a recent snapshot r14383-c2c701e058 and whilst MWAN worked ok in failover it would not load balance. Just wondering if this has same issue before i swap loads as kernel is same 5.4.61. many tks

apologies, I can't offer much help with MWAN3.... are you running a config that worked on a regular build? buildbots have been doing funny things hence why this build has not advanced from r14315... the best thing to do would be to try it and see.... although i'd expect similar behavior to regular builds ( apart from having to manually enable services :upside_down_face: )

1 Like

thanks for the reply will give it a try and see what happens - my current regular build is on a HH5 with 19.07.1 r10911-c155900f66 and MWAN works well. So i tried the config on a RPI4 with r14383-c2c701e058 but load balance would not work hence shifting to try this community build. There is a warning on the MWAN page that snapshots based on kernel 5.x are buggy so it may be the root cause of issues.

1 Like

@anon50098793 mind if I ask where exactly do you set the prompt PS1? I had my own set in /etc/profile but it seems to be overwritten.

1 Like
[root@dca632 /usbstick 44°]# cat /etc/profile.d/ashprofile.sh 
if [ -f /root/ashprompt ]; then
	. /root/ashprompt
	export PS1='\[\e[1;32m\][\[\e[1;37m\]\u@\h \[\e[1;35m\]\w\[\e[1;32m\]]\[\e[1;31m\]\\$\[\e[m\] '


[root@dca632 /usbstick 44°]# cat /root/.bashrc
[ -f ~/bashprompt ] && . ~/bashprompt
1 Like

imagebuilder is mostly functional again ( yay! :person_fencing: )... any builds that go up labelled TESTING ( r144xx ) are to be considered UNSTABLE and would be best avoided...

for reference... key changes are block subsystems... htop major bump... and teency luci tweaks / bumps etc. and 5.4.63 ( one or two 27xx patches changed I think )

in other words... nothing super beneficial...

thanks for that... was not aware of that... and for sure... that would be the likely issue/s...

as i'm not a user of mwan3, i'm kind of relying on you ( build userbase ) for guidance re: anything to do with that package set... so if a better 'testing' ipk becomes available let me know... etc.

i tried MWAN3 with this build and yep it does not work but also tried the official snapshot and another community build based on 19.073 all exhibit different but broken MWAN3 symptoms which is a bit of a pain (for me) as my setup has dual WAN's. Will keep hunting tho and try a post on the MWAN forum to see if anyone has ideas about a working build for RPI4 incl MWAN. onwards and hopefuly upwards

1 Like


well this is probably the most direct way to give / get up-to-date input in regards to snapshot bugs/fixes... possibly add some input/buglogs there...

otherwise if I were you i'd be trying the 32bit 2708 @ 19.x OR vpn-pbr and some script-fu...


cheers will give that a try and report back

tried that ipk and also did a syspugrade to r14315-976d3e2234 just in case.

with MWAN disabled all good can route down either WAN link
enable MWAN not so good- routing badly affected 80% packet loss on WAN links
Also LUCI hangs trying to change MWAN config needing reboot to clear

So i think- better but maybe still buggy

1 Like

thanks for that...

next time... to save you the hassle... should be fine to just use some 'opkg [remove||install]' action only to test newer ipk... i'll have a play over the next day or two and validate a little better what is going on...

cool many thanks i did do a opkg remove and install 1st and got weird stuff going on so i thought re flash and maybe try that as a just in case.. same routing weirdness unfortunately with packet loss...

Hi Trendy

how did u enable it?
starting from scratch, adding PPPOE, then enable Banip, selecting some IPset sources, don't get further than:
: banIP runtime information

  • status : disabled
  • version : 0.3.11
  • util_info : -, false
  • ipset_info : 0 IPSets with overall 0 IPs/Prefixes
  • backup_dir : /mnt
  • last_run : 11.09.2020 02:06:33
  • system : Raspberry Pi 4 Model B Rev 1.2, OpenWrt SNAPSHOT r14443-f1bc66c765

or from a command line;

/etc/init.d/banip enable

the git README has had a note about this... need to update the top post as it's tripped a few people up...

setting things up like this allows for packing in a wide range of packages... yet not bloating everybodys logs / performance with stuff they dont need to be running... much easier to turn on one or two things than to disable 25 :flushed:

1 Like

More to what @anon50098793 wrote already, I didn't start from scratch, as I had already a working banip from the previous installation. I had to enable it (service banip enable) after I upgraded.

1 Like

@migube you are a genius... you've hit two birds with the one stone here...

after all my talk about disabling stuff out of the box... it seems vpn-policy-routing has snuk through the cracks... (doh!, thats the whole reason for disabling things that and two adblocks at the same time are defo nono dodo ) and seems like it might be behind some of @alpynz 's / mwan3 issues...

it was kinda unresponsive... ( to disables ) so alpy, best of you trash the package all together...

opkg remove --force-removal-of-dependent-packages vpn-policy-routing

reboot ( or full network restart ) might not hurt either...

onwards an upwards!

cheers will do and continue testing... MWAN3 2.10.0-1 seems happier but vpn policy rouitng will definetly be trying to do same thing ... was still seeing occasional LUCI hangs on config chnages to MWAN but hard to pin down...

why ram usage is increasing over time?
uptime 2d 5h