Rpi4 < $(community_build)

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
    tx

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

ok... you have to make this... shoutout to DarkElvenAngel [thankyou], i used an alpine chroot on-device - /etc/init.d/ntop will set one up for you if you edit the variables at the top and start it... chroot CHROOTDIR, ( apk add dtc git make etc. ), git clone, make all, (i skipped this: make install), mkdir /run, cp argononed /usr/sbin/, cp argonone-shutdown /usr/sbin, cp argonone.dtbo /boot/overlays/ ( maybe run the setup-overlay.sh )... then likely reboot and run 'argononed' ( or add /usr/sbin/argononed & to your rc.local etc. )...

jennnniiii-i-am-runnnnniiiiiiiiiing
[root@dca632 ../argonFANcompiled 46°]# ps w | grep argon
21458 root       840 S    ./argononed
21460 root         0 SW   [irq/42-argonone]

[root@dca632 ../argonFANcompiled 45°]# cat /var/log/argononed.log 

Sun Sep 13 17:32:02 2020 
[INFO] Startup ArgonOne Daemon ver 0.1.6
[INFO] Loading Configuration
[INFO] Reading values from device-tree
[INFO] GPIO initialized
[INFO] RPI MODEL 4B 2GB rev 1.1
[INFO] Lock file created
[INFO] Now running as a daemon
[INFO] Set GPIO 4 to mode INPUT
[INFO] Set GPIO 4 pull up/down to DOWN
[INFO] Now waitting for button press
[INFO] Monitoring line 4 on /dev/gpiochip0
[INFO] Successfully opened /dev/vcio for temprature sensor

( as with most things build related, a few users need this, i'll look at integrating it (wrt.ini option and init.d script) into the build once sort out git versioning )

Thank you so much for looking into this. I have never done some of this stuff before but this is a great opportunity to learn.

I followed your explanation and the daemon is now running.
The issue is the I2C is still not working.
I have installed kmod-2c-core, i2c-tools but no i2c device appears in /dev .
Is there anything else i should be trying?

/boot/config.txt include distroconfig.txt

[all]
dtparam=i2c_arm=on
dtparam=i2c1=on
dtoverlay=argonone

argononed log

argononed log

Sun Sep 13 15:12:41 2020 [INFO] Startup ArgonOne Daemon ver 0.1.6
Sun Sep 13 15:12:41 2020 [INFO] Loading Configuration
Sun Sep 13 15:12:41 2020 [INFO] Reading values from device-tree
Sun Sep 13 15:12:41 2020 [INFO] Hysteresis set to 3
Sun Sep 13 15:12:41 2020 [INFO] Fan Speeds set to 10% 55% 100%
Sun Sep 13 15:12:41 2020 [INFO] Fan Temps set to 55 60 65
Sun Sep 13 15:12:41 2020 [INFO] GPIO initialized
Sun Sep 13 15:12:41 2020 [INFO] RPI MODEL 4B 4GB rev 1.1
Sun Sep 13 15:12:41 2020 [INFO] Lock file created
Sun Sep 13 15:12:41 2020 [CRITICAL] Failed to open the i2c bus
Sun Sep 13 15:12:41 2020 [INFO] Now running as a daemon
Sun Sep 13 15:12:41 2020 [INFO] Set GPIO 4 to mode INPUT
Sun Sep 13 15:12:41 2020 [INFO] Set GPIO 4 pull up/down to DOWN
Sun Sep 13 15:12:41 2020 [INFO] Now waitting for button press
Sun Sep 13 15:12:41 2020 [INFO] Monitoring line 4 on /dev/gpiochip0
Sun Sep 13 15:12:43 2020 [INFO] Successfully opened /dev/vcio for temprature sensor

she runs;

dtparam=i2c_arm=on #i2c-tools kmod-i2c-bcm2835|core

[root@dca632 /usbstick 47°]# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:         -- -- -- -- -- -- -- -- -- -- -- -- -- 
...

try removing: dtparam=i2c1=on ( keep: dtparam=i2c_arm=on line )

Turns out i was missing kmod-i2c-bcm2835.
Seems to be working now.
Thank you very much!

1 Like

just a quick report to say testing seems all ok with this MWAN vers- no LUCI hangs after 2 days and routing down 3 wan links works as per expected. seems pretty stable.. :grinning:

1 Like

I have issue with SQM. I get very stuttery movement in games. Now i installed the new package
rpi4.64-snapshot-23300-1.13.57-5-r14475-ext4-sys.img
SQM is off and game is working fine without any stutter.

please show

uci show sqm

and the speeds up / down from a speedtest with nothing using the network...

you can try the command

speedtest-ookla
uci show sqm
sqm.eth1=queue
sqm.eth1.ingress_ecn='ECN'
sqm.eth1.egress_ecn='NOECN'
sqm.eth1.itarget='auto'
sqm.eth1.etarget='auto'
sqm.eth1.verbosity='5'
sqm.eth1.qdisc='cake'
sqm.eth1.qdisc_advanced='1'
sqm.eth1.squash_dscp='1'
sqm.eth1.squash_ingress='1'
sqm.eth1.qdisc_really_really_advanced='1'
sqm.eth1.eqdisc_opts='nat dual-srchost ack-filter'
sqm.eth1.linklayer='ethernet'
sqm.eth1.linklayer_advanced='1'
sqm.eth1.tcMTU='2047'
sqm.eth1.tcTSIZE='128'
sqm.eth1.linklayer_adaptation_mechanism='default'
sqm.eth1.debug_logging='1'
sqm.eth1.enabled='1'
sqm.eth1.iqdisc_opts='nat dual-dsthost ingress'
sqm.eth1.interface='eth1'
sqm.eth1.download='20100'
sqm.eth1.upload='10050'
sqm.eth1.overhead='34'
sqm.eth1.tcMPU='64'
sqm.eth1.script='piece_of_cake.qos'

Latency: 14.73 ms (0.55 ms jitter)
Download: 21.77 Mbps (data used: 19.0 MB)
Upload: 9.73 Mbps (data used: 4.4 MB)
package is 20mb download and 10mb upload

and one more thing when i was getting stuttery movement in game. Ping plotter was showing smooth pings. no packet loss whatsever

1 Like

ok, not sure if adaption->default + overhead is normal? either way... this isn't build related... and there is likely something else going on...

make a separate thread so all the sqm experts will see it. ( you can link to the post above by clicking the diagonal-chain icon on the lower right of the post )

@anon50098793 what you did? after updating the pi4. All the packages installed automatically without doing anythings.
before i used to install all the packages one by one now they are already installed.
Thanks great :+1:

1 Like

fantastic to get feedback ( working even better ) from someone in the wild about the autorestore...

in my testing, it was just a tad unpredictable to make perma-default setting... so in future ( r145xx+ ) i'm disabling the 'apply' of this...

what this means...

  • you can sysupgrade -R to perform autorestore during firstboot
  • you can enable always with AUTORESTOREAPPLY=1

But I recommend manually using the method below after firstboot is all finished, so you review / verify what package actions are to be performed...

MANUAL METHOD

Once sysupgraded.... from luci;

  • go to SYSTEM > CUSTOM COMMANDS
  • click 'RUN' on 'restorepackages'
  • if you are happy with the list you can type 'run' in the box, then click RUN again

From the command line (alternative to luci method);

restorepackages.sh
restorepackages.sh run
#(or edit /autorestore.sh and run that yourself)
sample restorepackages.sh
[root@dca632 /usbstick 41°]# restorepackages.sh 
unsupported:  > show
INTERACTIVE restorepackages.sh> curl [installed]
/etc/custom/autorestore.sh [default:restoredalready] add:18 rem:0
opkg install mailsend #[ok]#[ok]#customapp
opkg install libmount1 #[ok]#[ok]#customapp
opkg install mount-utils #[ok]#[ok]#customapp
opkg install libopcodes #[ok]#[ok]#customapp
opkg install libctf #[ok]#[ok]#customapp
opkg install objdump #[ok]#[ok]#customapp
opkg install binutils #[ok]#[ok]#customapp
opkg install gcc #[ok]#[ok]#customapp
opkg install make #[ok]#[ok]#customapp
opkg install git #[ok]#[ok]#customapp
opkg install boost #[ok]#[ok]#customapp
opkg install libevent2-core7 #[ok]#[ok]#customapp
opkg install libevent2-pthreads7 #[ok]#[ok]#customapp
opkg install mtr #[ok]#[ok]#customapp
opkg install libi2c #[ok]#[ok]#customapp
opkg install i2c-tools #[ok]#[ok]#customapp
opkg install kmod-i2c-core #[ok]#[ok]#customapp
opkg install kmod-i2c-bcm2835 #[ok]#[ok]#customapp
################################################ firstboot allgood 202009190702
################################### Added... 18
binutils
boost
gcc
git
i2c-tools
kmod-i2c-bcm2835
kmod-i2c-core
libctf
libevent2-core7
libevent2-pthreads7
libi2c
libmount1
libopcodes
mailsend
make
mount-utils
mtr
objdump
################################### Removed... 0

Has anyone tried USB boot to see if theres any perf increase?

Not sure if there would be.

http://www.jeffgeerling.com/blog/2020/im-booting-my-raspberry-pi-4-usb-ssd

https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance

wanted to but...

  1. pros(for me): usb boot, particularly 'boot order' aka fallback when not present etc. also tftpboot

  2. cons: current one works pretty well ( minus the above feature ), mmc so far seems to be the quickest...

  3. need to keep this pi as common / bugfree as possible for the builds, and i've fried the primary uart pins... and without those i'm reluctant to mess around with the bootloader...

pretty sure the openwrt images will be fine... athough the default cmdline.txt would need to be changed after writing the image, preferably to PARTUUID= should work... come to think of it... there is probably a bit of stuff in preinit / init.d / lib-upgrade... that's likely hardcoded to mmcblk... so sysupgrade would be 'broken'

( edit: not as bad as i'd guessed )

[root@dca632 /usbstick 46°]# fgrep -r mmc /lib
/lib/preinit/79_move_config:BOOTPART=/dev/mmcblk0p1

only a few lines tho...

i think practically the newer firmware has bugfixes particularly for usb/video... so anyone with buggy usb or video behavior would have a good practical reason to take the plunge...

1 Like