actually, in terms of 'consistency' pretty sure that is actually the ideal situation...
suspect almost identical underlying system as with a typical rpi4... you can try adding these two parameters to wrt.ini on that board...
WIFIREMOVE=1
DISABLEDSERVICES="wpad"
next build includes new option;
-add NO_ONECLICKFLASH=1 for anyone who wishes to prevent accidental flashing
(multi modal confirmation is a bit beyond my skill level <-> event occurrence frequency)
Just an update on progress with this board,
Everything worked out of the box and now using it as my primary home router.
Using this with a CM4 1Gb Lite edition with no EMMC.
Main observations so far - Looking at my latency graph on the wan in comparison to the USB version, it does appear a little less volatile, and requests feel a little snappier. Running an identical OpenWrt setup before/after.
Cheers @anon50098793
was missing the dtb for that board...
curl -sSL https://github.com/wulfy23/rpi4/raw/master/utilities/bcm2711-rpi-cm4.dtb > /boot/bcm2711-rpi-cm4.dtb
reboot
Continuing the discussion from Rpi4 < $(community_build):
Hi all, is anyone here using MWAN3 with external USB adapters? I'm having trouble and could use some help.
uci show mwan3; uci show network
/etc/init.d/mwan3 status
ip -4 a; ip -6 a; ip -4 ro; ip -6 ro
logread | grep mwan | tail -n21
(remove/alter all private info like public ips' or macs... and use the GEAR SYMBOL when posting to select area then choose 'hide details' after your place it inside code tags </>)
fwiw... i carry a teency mwan3 patch to return early in hotplug if it's not enabled...
other than that... everything is 'vanilla' so if you get no response here you can ask on the main forum... (although if you are using that interface rename script and your issues are on boot... then that's more 'specific' / non-mwan3 related exactly)
that said... it's always getting patches and improvements... a fair few came in recently so mwan3 users on the next build be sure to checkout the luci changes...
while there are at least 7 reasons why this is not a good idea... and using a direct usb/network mount is better...
i have to admit... I also have a use case for this feature... ( chroots / lxc / docker volatile images )
added to next release... will require two upgrades to take effect as it's been activated late in the sysupgrade logic (which the first upgrade doesn't have)
###################################### rpi4only
################################### discouraged backup and migration of your data is your responsibility
################################### upgrade only not applicable to factory
################################### applies only to unmodified 2 partition defaults
#####-discourages upgrades
#####-internal data migration not possible via sysupgrade -b
#####-requires custom data migration
#####-introduces additional fault points
#####-increases fsck and or boot times
#####-high io may adversely effect core router function
# ROOTFSEXPAND=1
[root@dca632 /usbstick 49°]# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 29.0G 1.4G 27.5G 5% /
(default-not backported takes effect on first upgrade)
(wont touch a modified disk - hopefully)
just remembered / realized stangri kindly makes ipks available
so any vpn-pbr users can try those on 3.2... if the fix is not applied upstream after another week... i'll patch for this locally in the build...
edit: fixed
-3.2.61-72 ffwd<vpn-pbr-static-ib-ipk master packges taking
too long to push fix - import from stangri-repo
< vpn-policy-routing - 0.3.2-20
---
> vpn-policy-routing - 0.3.5-1
speaking of @stangri while I was there I've borrowed his;
packages... these are locally hacked so if they don't work you'll have to report issues here...
thankyou!
what's the purpose? can I use it to see packets of other devices?
yes... thats the purpose...
it 'forwards'(copies) traffic (limited to one capture ip right now (i think... did not try subnet)) to your PC for viewing (sorting / filtering / searching) in the wireshark program
depending on if that is just your regular PC ethernet ip you are sending it to... you have to apply the suggested filter shown in the luci-app to get rid of all the regular traffic that comes into that PC interface...
(without this app tcpdump can also be used... but it needs more effort / work on the actual dump/filter commands to see/forward what you want... and is pretty much a command line dependent solution... this app ideally would allow someone with only GUI skills to run a decent / clear capture... usually to debug something... or chase down 'rogue' clients / odd connections ... i may at some stage if I get time... add some tcpdump capabilities to it)
(there is also ntop for broader views... which i'd actually favour over this for client fingerprinting... but I would use this to debug for instance 'what the hell does a chromecast/lightbulb really do?')
'fakeinternet' is (basically) for some stubborn apps or clients that expect to talk to internet services that are not always present... and to trick them into believing that service ABC is contactible...
both are added for 'fun/experiment'... if they are not used/useful enough after month or two i'll remove... simple enough to download and install on your own if you really need them...
Fixed. Not enough power off the Raspberry PI power supply. Using powered hub and USB PD Power supply. Now I shall deal with Open VPN.
Will VPN-PBR work with MWAN3?
the general (overwhelming) guidance is to only use one at a time...
as they do similar things.. and can take some serious skill to combine the two... or even just comprehend why/how you would do that...
state your goals clearly... diagrams will help...
(a new thread is best for this)
MWAN3 manages two WAN connections.
Now there is a VPN client.
I want to send the VPN client over a specific WAN unless that WAN fails.
I want to send a VLAN over the VPN.
Can't figure the last two out. Without MWAN3 was able to use PBR to accomplish the latter.
I believe they do work together with a tweak in the VPR settings, search https://docs.openwrt.melmac.net/vpn-policy-routing/ for the word mwan3.
Thanks, will try tomorrow and see if that helps!
ROOTFSEXPAND=1
i've decided to backport this parameter (3.2.100-11_r17143) so everyone gets it by default (will occur over two upgrades or one if from supported factory version)
the only reason to comment it out... is if you perhaps are dd-ing whole partitions and need to keep it small... or you want the spare space for some other custom use...
there is no more a "line" showing the version i am running and if update is available or not
it is there sorry 